[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 2/9] xen: Optimize introspection access to guest state
On 10/07/2014 09:05, Razvan Cojocaru wrote: > On 07/02/2014 06:31 PM, Andrew Cooper wrote: >> On 02/07/14 14:33, Razvan Cojocaru wrote: >>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c >>> index 2caa04a..fed21b6 100644 >>> --- a/xen/arch/x86/hvm/vmx/vmx.c >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c >>> @@ -425,6 +425,7 @@ static void vmx_vmcs_save(struct vcpu *v, struct >>> hvm_hw_cpu *c) >>> c->cr4 = v->arch.hvm_vcpu.guest_cr[4]; >>> >>> c->msr_efer = v->arch.hvm_vcpu.guest_efer; >>> + c->guest_x86_mode = vmx_guest_x86_mode(v); >> guest_x86_mode is a linear function of cr0, eflags and efer. It can be >> calculated by userspace doesn't need to transmitted individually. > OK, but 1) I'm not sending eflags into userspace, rflags is in the structure between r15 and dr7. > and 2) I thought Xen's > vmx_guest_x86_mode() function is more trustworthy It is not a matter of trust. It is a matter of correct or not, and it would be easy for userspace to simply copy what vmx_guest_x86_mode() already has. > than an userspace > translation of it, with not much overhead for the HV. Your proposed change would make the results of vmx_guest_x86_mode() part of the Xen ABI, and therefore hard to refactor in the future if the need were to arise. Also, it ties any SVM extension of your work to VT-x internals. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |