On 10/26/2009 12:45 PM, Joerg Roedel wrote:
Ok, parts of the state can be saved in guest memory. But thats
currently not done. This will need some care to not introduce a security
hole. But it shouldn't be too difficult.
The state thats not reproducible in an sane way is the intercept bitmap
for the l2 guest.
From the nested state what needs to be exposed to userspace for
migration is:
* guest mode flag (as returned by is_nested)
* nested vmcb address
Yes, forgot that. We can store it in the hsave area (note the hsave
area format becomes an ABI).
* nested hsave msr
That's already saved.
* nested intercepts
These are part of the guest vmcb. The host nested intercepts can be
recalculated, no?
* for nested nested paging: guest nested cr3 value
Part of the guest vmcb.
Another state which needs exposure is the last branch record related
state.
Aren't those just more MSRs?
Off-topic question: Will the new migration protocol include some kind
handshake to find out if migration is possible at all?
It's assumed that migration always works for a newer qemu version, and
that the management tools don't attempt backward migration.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
