[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses
On 15/03/18 13:44, Jan Beulich wrote: >>>> On 15.03.18 at 14:35, <andrew.cooper3@xxxxxxxxxx> wrote: >> On 15/03/18 13:04, Jan Beulich wrote: >>> static inline void x86_emul_hw_exception( >>> --- a/xen/arch/x86/x86_emulate.c >>> +++ b/xen/arch/x86/x86_emulate.c >>> @@ -42,3 +42,50 @@ >>> }) >>> >>> #include "x86_emulate/x86_emulate.c" >>> + >>> +int x86emul_read_xcr(unsigned int reg, uint64_t *val, >>> + struct x86_emulate_ctxt *ctxt) >>> +{ >>> + switch ( reg ) >>> + { >>> + case 0: >>> + *val = current->arch.xcr0; >>> + return X86EMUL_OKAY; >>> + >>> + case 1: >>> + if ( cpu_has_xgetbv1 && >>> current->domain->arch.cpuid->xstate.xgetbv1 ) >> You can drop the cpu_has_xgetbv1 part of this test. The CPUID policy >> derivation logic won't allow xstate.xgetbv1 to be set without >> cpu_has_xgetbv1 > Hmm, I wasn't sure: Is that already the case? I thought > auditing of what the tool stack provides is only planned. > >> Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > Thanks, but please clarify the above. We currently zero out bad toolstack choices. The longterm changes will be to hand an error back, rather than ignore bad choices. In calculate_{pv,hvm}_max_policy(), we first copy the host cpuid policy, then &= down by the information derived from the magic comments in arch-x86/cpufeatureset.h Then in recalculate_cpuid_policy(), we: /* Clamp the toolstacks choices to reality. */ for ( i = 0; i < ARRAY_SIZE(fs); i++ ) fs[i] &= max_fs[i]; The purpose of doing this is so we can rely on the cpuid policy object being suitable without further qualification. The only issues come when we decide to emulate pipeline capabilities without hardware support, which will then fall into the same category as the difference between host_and_vcpu_must_have() and vcpu_must_have() in the main emulator. We've got just a single example of this currently, which is PV guests PVRDTSC support, and that code isn't long for this world. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |