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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Nov 18, 2013 at 12:15:58PM +0000, George Dunlap wrote:
> On 16/11/13 01:56, Mukesh Rathor wrote:
> >On Fri, 15 Nov 2013 17:12:27 -0800
> >Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> >
> >>On Fri, 15 Nov 2013 15:56:52 -0800
> >>Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> >>
> >>>On Fri, 15 Nov 2013 13:56:54 -0800
> >>>Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> >>>
> >>>>On Fri, 15 Nov 2013 16:45:47 +0000
> >>>>"Jan Beulich" <JBeulich@xxxxxxxx> 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.

Please base it on stable/pvh.v9. Or if you have a branch where
you had done:

        git checkout v3.12
        git merge konrad/stable/pvh.v9
        [reworked the merge issues]
--> this is the baseline <---
        git am -s < "Xen/PVH: simplifiy..."

You would want to post the patches _past_ the baseline.

Also, do include the prefix 'xen/pvh' in your Linux patches.

> 
> The patches were checked in on the understanding that the interface
> was not yet finalized.  I definitely think we should not submit the
> patches in Linux for inclusion until we have it sorted out.

Keep in mind that the merge window for Linux has openned, which means
that the next merge window in which PVH would be an candidate for is
in 60 days.


> Originally we were thinking of this for 4.5, but we may well be able
> to get the interface nailed down for 4.4.
> 
>  -George

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