Avi Kivity wrote:
On 05/06/2010 07:23 AM, Cui, Dexuan wrote:
+ goto err;
+ vcpu-arch.guest_xstate_mask = new_bv;
+ xsetbv(XCR_XFEATURE_ENABLED_MASK, vcpu-arch.guest_xstate_mask);
Can't we run with the host xcr0? isn't it guaranteed to be a
superset of the guest xcr0?
I
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
On 05/06/2010 10:45 PM, Avi Kivity wrote:
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.
I think I see the reason - xgetbv is unprivileged, so applications can
see
Avi Kivity wrote:
On 04/29/2010 08:22 AM, Dexuan Cui wrote:
When the host enables XSAVE/XRSTOR, the patch exposes the
XSAVE/XRSTOR
related CPUID leaves to guest by fixing up kvm_emulate_cpuid() and
the
patch allows guest to set CR4.OSXSAVE to enable XSAVE.
The patch adds per-vcpu
On 04/29/2010 08:22 AM, Dexuan Cui wrote:
When the host enables XSAVE/XRSTOR, the patch exposes the XSAVE/XRSTOR
related CPUID leaves to guest by fixing up kvm_emulate_cpuid() and the
patch allows guest to set CR4.OSXSAVE to enable XSAVE.
The patch adds per-vcpu host/guest xstate image/mask and
When the host enables XSAVE/XRSTOR, the patch exposes the XSAVE/XRSTOR
related CPUID leaves to guest by fixing up kvm_emulate_cpuid() and the
patch allows guest to set CR4.OSXSAVE to enable XSAVE.
The patch adds per-vcpu host/guest xstate image/mask and enhances the
current FXSAVE/FRSTOR with the
