On Mon, Oct 26, 2009 at 12:09:25PM +0200, Avi Kivity wrote:
> On 10/26/2009 11:56 AM, Joerg Roedel wrote:
> >On Mon, Oct 26, 2009 at 11:39:46AM +0200, Avi Kivity wrote:
> >>On 10/26/2009 11:30 AM, Joerg Roedel wrote:
> >>>>Which host state? As far as I can tell, it can all be regenerated.
> >>>The state which is loaded into the vcpu when a #vmexit is emulated. This
> >>>includes segments, control registers and the host rip for example.
> >>All of this state does not change between nested guest and normal
> >>guest mode.
> >I am talking about all the state that is saved in svm->nested.hsave.
> >When we migrate a guest vcpu while it is running in guest mode itself
> >(without forcing a nested #vmexit) this state is required when a #vmexit
> >needs to be emulated on this vcpu after migration.
> >Same is true for the nested intercept conditions.
>
> The state that is saved by VMRUN can be saved to guest memory and
> migrated. Extra state (like the intercepts for the previous mode)
> must be saved to host memory and not migrated; host intercepts can
> be regenerated.
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
* nested hsave msr
* nested intercepts
* for nested nested paging: guest nested cr3 value
Another state which needs exposure is the last branch record related
state.
Off-topic question: Will the new migration protocol include some kind
handshake to find out if migration is possible at all?
Joerg
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
