Re: [Xen-devel] [PATCH] [v2] xen: Add FS and GS base to HVM VCPU context

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.04.12 at 22:20, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 24/04/2012 20:35, "Aravindh Puthiyaparambil" <aravindh@xxxxxxxxxxxx>
> wrote:
> 
>> On Tue, Apr 24, 2012 at 10:33 AM, Aravindh Puthiyaparambil
>> <aravindh@xxxxxxxxxxxx> wrote:
>>> On Tue, Apr 24, 2012 at 12:52 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 
>>>> Which still leaves one of gs_base_* unfilled in all cases. You'll need
>>>> to get ahold of vmcb->kerngsbase (AMD/SVM) or
>>>> v->arch.hvm_vmx.shadow_gs (Intel/VMX). You could either
>>>> introduce a new wrapper, or expose {svm,vmx}_save_cpu_state()
>>>> as a new function table entry, or pay the price of calling
>>>> ->save_cpu_ctxt(). But you will need to pay extra attention to
>>>> the case of the subject vCPU being current.
>>> 
>>> OK, I will try introducing a new wrapper that will return
>>> vmcb->kerngsbase /  v->arch.hvm_vmx.shadow_gs.
>> 
>> Jan,
>> 
>> How does this look?
> 
> Only the code in domctl.c needs to be ifdef x86_64. In fact as it is, the
> patch won't compile on i386, as you have inconsistently ifdef'ed. Just
> remove the ifdefs as far as possible, we'd rather have dead code on i386
> than ifdefs.

Not exactly: VMX's shadow_gs field is conditional upon __x86_64__
too, so at least the body of the corresponding VMX function needs
to be #ifdef-ed as well. But beyond the #ifdef-ery, this looks good
to me (and I realized only on my way home yesterday that I really
asked too much when wanting this getting called on the current
vCPU to be taken care of - HVM can't call domctls for the time being,
and hence that situation can't arise at present).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel