|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V3 3/6] x86/xsaves: enable xsaves/xrstors for hvm guest
On Wed, Aug 05, 2015 at 07:17:44PM +0100, Andrew Cooper wrote:
> On 05/08/15 02:57, Shuai Ruan wrote:
> > This patch enables xsaves for hvm guest, includes:
> > 1.handle xsaves vmcs init and vmexit.
> > 2.add logic to write/read the XSS msr.
> >
> > Signed-off-by: Shuai Ruan <shuai.ruan@xxxxxxxxxxxxxxx>
> > ---
> > xen/arch/x86/hvm/hvm.c | 44
> > ++++++++++++++++++++++++++++++++++++++
> > xen/arch/x86/hvm/vmx/vmcs.c | 7 +++++-
> > xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++
> > xen/arch/x86/xstate.c | 4 ++--
> > xen/include/asm-x86/hvm/vmx/vmcs.h | 5 +++++
> > xen/include/asm-x86/hvm/vmx/vmx.h | 2 ++
> > xen/include/asm-x86/xstate.h | 2 +-
> > 7 files changed, 78 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index c07e3ef..e5cf761 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -4370,6 +4370,10 @@ void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
> > }
> > }
> >
> > +#define XSAVEOPT (1 << 0)
> > +#define XSAVEC (1 << 1)
> > +#define XGETBV1 (1 << 2)
> > +#define XSAVES (1 << 3)
>
> These should be in cpufeature.h, not here.
>
Ok.
> > void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
> > unsigned int *ecx, unsigned int *edx)
> > {
> > @@ -4456,6 +4460,34 @@ void hvm_cpuid(unsigned int input, unsigned int
> > *eax, unsigned int *ebx,
> > *ebx = _eax + _ebx;
> > }
> > }
> > + if ( count == 1 )
> > + {
> > + if ( cpu_has_xsaves )
> > + {
> > + *ebx = XSTATE_AREA_MIN_SIZE;
> > + if ( v->arch.xcr0 | v->arch.msr_ia32_xss )
> > + for ( sub_leaf = 2; sub_leaf < 63; sub_leaf++ )
> > + {
> > + if ( !((v->arch.xcr0 | v->arch.msr_ia32_xss)
> > + & (1ULL << sub_leaf)) )
> > + continue;
> > + domain_cpuid(d, input, sub_leaf, &_eax, &_ebx,
> > &_ecx,
> > + &_edx);
> > + *ebx = *ebx + _eax;
> > + }
> > + }
> > + else
> > + {
> > + *eax &= ~XSAVES;
> > + *ebx = *ecx = *edx = 0;
> > + }
> > + if ( !cpu_has_xgetbv1 )
> > + *eax &= ~XGETBV1;
> > + if ( !cpu_has_xsavec )
> > + *eax &= ~XSAVEC;
> > + if ( !cpu_has_xsaveopt )
> > + *eax &= ~XSAVEOPT;
> > + }
>
> Urgh - I really need to get domain cpuid fixed in Xen. This is
> currently making a very bad situation a little worse.
>
In patch 4, I expose the xsaves/xsavec/xsaveopt and need to check
whether the hardware supoort it. What's your suggestion about this?
> > break;
> >
> > case 0x80000001:
> > @@ -4555,6 +4587,12 @@ int hvm_msr_read_intercept(unsigned int msr,
> > uint64_t *msr_content)
> > *msr_content = v->arch.hvm_vcpu.guest_efer;
> > break;
> >
> > + case MSR_IA32_XSS:
> > + if ( !cpu_has_vmx_xsaves )
>
> vmx_xsaves has nothing to do with this here. I presume you mean
> cpu_has_xsave?
>
> > + goto gp_fault;
> > + *msr_content = v->arch.msr_ia32_xss;
> > + break;
> > +
> > case MSR_IA32_TSC:
> > *msr_content = _hvm_rdtsc_intercept();
> > break;
> > @@ -4687,6 +4725,12 @@ int hvm_msr_write_intercept(unsigned int msr,
> > uint64_t msr_content,
> > return X86EMUL_EXCEPTION;
> > break;
> >
> > + case MSR_IA32_XSS:
> > + if ( !cpu_has_vmx_xsaves )
> > + goto gp_fault;
> > + v->arch.msr_ia32_xss = msr_content;
>
> You must validate msr_content here and possibly hand a gp fault back to
> the guest.
>
Ok, I will fix it.
> > + break;
> > +
> > case MSR_IA32_TSC:
> > hvm_set_guest_tsc(v, msr_content);
> > break;
> > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> > index 4c5ceb5..8e61e3f 100644
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -230,7 +230,8 @@ static int vmx_init_vmcs_config(void)
> > SECONDARY_EXEC_ENABLE_EPT |
> > SECONDARY_EXEC_ENABLE_RDTSCP |
> > SECONDARY_EXEC_PAUSE_LOOP_EXITING |
> > - SECONDARY_EXEC_ENABLE_INVPCID);
> > + SECONDARY_EXEC_ENABLE_INVPCID |
> > + SECONDARY_EXEC_XSAVES);
> > rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
> > if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
> > opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
> > @@ -921,6 +922,7 @@ void virtual_vmcs_vmwrite(void *vvmcs, u32
> > vmcs_encoding, u64 val)
> > virtual_vmcs_exit(vvmcs);
> > }
> >
> > +#define VMX_XSS_EXIT_BITMAP 0
>
> This define definitely doesn't live here.
>
Ok.
> > static int construct_vmcs(struct vcpu *v)
> > {
> > struct domain *d = v->domain;
> > @@ -1204,6 +1206,9 @@ static int construct_vmcs(struct vcpu *v)
> > __vmwrite(GUEST_PAT, guest_pat);
> > }
> >
> > + if ( cpu_has_vmx_xsaves )
> > + __vmwrite(XSS_EXIT_BITMAP, VMX_XSS_EXIT_BITMAP);
> > +
> > vmx_vmcs_exit(v);
> >
> > /* PVH: paging mode is updated by arch_set_info_guest(). */
> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> > index d3183a8..64ff63b 100644
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2708,6 +2708,16 @@ static int vmx_handle_apic_write(void)
> > return vlapic_apicv_write(current, exit_qualification & 0xfff);
> > }
> >
> > +static void vmx_handle_xsaves(void)
> > +{
> > + WARN();
> > +}
> > +
> > +static void vmx_handle_xrstors(void)
> > +{
> > + WARN();
> > +}
> > +
>
> What is these supposed to do? They are not an appropriate handlers.
>
These two handlers do nothing here. Perform xsaves in HVM guest will
not trap in hypersior in this patch (by setting XSS_EXIT_BITMAP zero).
However it may trap in the future. See SDM Volume 3 Section 25.1.3
for detail information.
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |