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 what
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 re
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
>>> supe
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?
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-v
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 e
