Re: [Xen-devel] [PATCH RFC 2/9] xen: Optimize introspection access to guest state

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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