On 05/06/2010 05:20 PM, Cui, Dexuan wrote:
However, switching xcr0 may be slow. That's our experience with msrs.
Can you measure its latency?
We can measure that.
However, I think the changing xcr0 to guest xcr0 in handle_xsetbv() is necessary --
or else, inside guest xgetbv() would return host xcr0 rather than guest xcr0 --
this is obviously incorrect. Once handle_xsetbv() changes the xcr0 to guest's value,
the xsetbv() in kvm_fx_restore_host() is also necessary, and the xsetbv() in
kvm_fx_restore_guest() is also necessary. So looks guest can't run with the
host xcr0.
Right. Moreover, xsave would write into memory the guest doesn't expect.
btw, it needs save/restore for live migration, as well as save/restore
for the new fpu state.
Yes. This part is missing. Sheng and I is also doing this -- it may be a bittle
troublesome as the number of XSTATEs can grown as time goes on. We'll
have to handle the compatibility issue.
Reserve tons of space in the ioctl - and we can use the same format as
xsave.
All those control registers are annoying, we have cr1 and cr5-cr7 free,
cr9-cr15 on x86_64, infinite msr space, and now we have XCRs. Great.
Looking forward to YCR0.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
