Re: [PATCH RFC] pvh: clearly specify used parameters in vcpu_guest_context

["Roger Pau Monné" <roger.pau@citrix.com>]

On 16/11/13 02:56, Mukesh Rathor wrote:
> On Fri, 15 Nov 2013 17:12:27 -0800
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
>> On Fri, 15 Nov 2013 15:56:52 -0800
>> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>>
>>> On Fri, 15 Nov 2013 13:56:54 -0800
>>> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>>>
>>>> On Fri, 15 Nov 2013 16:45:47 +0000
>>>> "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>
>> ........
>>>>
>>>> We had talked about this while ago, but upon boot, the first thing
>>>> a vcpu needs is access to kernel data structure. (A secondary vcpu
>>>> is bootstrapped way up into the kernel). It would be possible to
>>>> get rid of gs_base_kernel, but will take some work on the linux
>>>> side. I can try and test it out, and let you guys know.
>>>
>>> Ok, looking at this more, I can hack cpu_bringup_and_idle() in
>>> linux to include a static variable for cpuid, which is the least a
>>> vcpu needs to know first thing. But, I think that would not work
>>> when vcpu hotplug support is added. Another option would be to pass
>>> cpuid in one of the registers, say rdi. Thus, rdi == cpuid will be
>>> passed to VCPUOP_initialise. In bringup function, the booting vcpu
>>> can then load it's own gs based on the cpuid. If linux folks,
>>> konrad (CCd), is OK with this, we can remove gs_base_kernel.
>>> Otherwise, it's such a small thing, hopefually it can stay.
>>
>> Konrad,
>>
>> Here's the changes needed on linux side to remove gs_base_kernel.
>> Since, I imagine vcpu hotplug would go thru the same path, it would
>> work there also. If this looks OK to everybody, we can remove
>> gs_base_kernel from the VCPUOP_initialise call.
>>
>> thanks,
>> Mukesh
>>
>>
>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>> index aa89bbf..54d1022 100644
>> --- a/arch/x86/xen/smp.c
>> +++ b/arch/x86/xen/smp.c
>> @@ -99,14 +99,8 @@ static void cpu_bringup(void)
>>  	wmb();			/* make sure everything is out
> 
> Rats, just realized this is not going to make sense because you
> don't have the earlier patch: 
> "PVH: simplify cpu_initialize_context. add pvh_set_bringup_context()"
> 
> So, just look for it at:
> 
> https://oss.oracle.com/git/mrathor/linux.git/ in branch tmp2.
> 
> In a nutshell, for PVH we only need to pass eip, rsp, cr3, and
> gs_base_kernel. If we pass cpuid in rdi for context setting, we can get
> rid of gs_base_kernel. 
> 
> Since, PVH is now merged, Konrad I'll officially send you the
> patches you see in my above tree after the merge to v3.12. I'll do
> that next week, lmk what tree the patches should be based on for
> submission.

I think we should wait to have a stable AP bringup interface before
committing anything to Linux. I'm going to rework this patch in order to
also check and load cr0/cr4 (as suggested by Tim).