Thread (50 messages) 50 messages, 7 authors, 2016-03-18
STALE3783d
Revisions (2)
  1. v3 current
  2. v3 [diff vs current]

[PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

From: Peter Maydell <hidden>
Date: 2016-03-14 17:29:44
Also in: kvm, kvmarm

On 14 March 2016 at 11:13, Andre Przywara [off-list ref] wrote:
So I see two ways to fix this:
1.) we find a KVM specific way of letting userland save and restore the
ITS tables directly
2.) we implement the BASER<n> registers, but still use our "cache" for
normal operations. On demand we would serialize KVM's virtual ITS data
structures and put them into the guest's memory, so they could be
saved/restored from there.
I feel like we're rehashing a bunch of design choices we talked
through way back in the last-but-one Connect. I don't suppose
anybody wrote down our rationales from back then?

(In particular I forget whether we decided the ITS tables were
large enough to need to allow some sort of before-the-VM-stops
migration of the data, which would be relatively doable with
option 2 but painful under option 1.)
quoted
Only caveat there I think was that we had to decide on a storage format
in those memory regions, to allow QEMU to understand the state and to
ensure back/forwards compatibility between KVM versions.
Do we need QEMU to actually understand this? Can't we just leave this
all to the kernel and QEMU just passes on the data? That would still
require some ABI stability between kernel versions in this respect, but
it's less problematic than exposing the data format to userland at all.
This would preclude ever being able to migrate a VM from KVM to
TCG QEMU, which seems a shame. (That doesn't work right now, but
I'm a bit wary of shutting the door to it forever.)

thanks
-- PMM
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help