Re: [Xen-devel] Xen's Linux kernel config options

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On Thu, Feb 26, 2015 at 11:19:17AM +0000, Stefano Stabellini wrote:
> On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
> > On Wed, Feb 25, 2015 at 12:01:31PM +0000, Stefano Stabellini wrote:
> > > On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > > > On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
> > > > <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > > > > On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
> > > > >> On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> 
> > > > >> wrote:
> > > > >> > On Fri, Dec 12, 2014 at 9:29 AM, David Vrabel 
> > > > >> > <david.vrabel@xxxxxxxxxx> wrote:
> > > > >> >> On 12/12/14 13:17, Juergen Gross wrote:
> > > > >> >>> XEN_PVHVM
> > > > >> >>
> > > > >> >> Move XEN_PVHVM under XEN and have it select PARAVIRT and 
> > > > >> >> PARAVIRT_CLOCK.
> > > > >> >
> > > > >> > FWIW, although it seems we do not want to let users just build
> > > > >> > XEN_PVHVM hypervisors I have the changes required now to at least 
> > > > >> > get
> > > > >> > this to build so I do know what it takes.
> > > > >> >
> > > > >> >>> XEN_FRONTEND                                            XEN_PV ||
> > > > >> >>>                                                         XEN_PVH 
> > > > >> >>> ||
> > > > >> >>>                                                         XEN_PVHVM
> > > > >> >>
> > > > >> >> This enables all the basic infrastructure for frontends: event 
> > > > >> >> channels,
> > > > >> >> grant tables and Xenbus.
> > > > >> >>
> > > > >> >> Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
> > > > >> >> possible to have frontend drivers without support for any of the
> > > > >> >> PV/PVHVM/PVH guest types.
> > > > >> >
> > > > >> > David, can you elaborate on the type of Xen guest it would be on 
> > > > >> > x86
> > > > >> > its not PV, PVHVM, or PVH? I'm particularly curious about the
> > > > >> > xen_domain_type and how it would end up to selected. As it is we 
> > > > >> > tie
> > > > >> > in XEN_PVHVM at build time with XEN_PVH, in order to have XEN_PVHVM
> > > > >> > completely removed from XEN_PVH we need quite a bit of code changes
> > > > >> > which at least as code exercise I have completed already. If we 
> > > > >> > want
> > > > >> > at the very least xen_domain_type set when XEN_PV, XEN_PVHVM, and
> > > > >> > XEN_PVH are not available we need a bit more work.
> > > > >>
> > > > >> OK I think I see the issue. We have nothing quite like
> > > > >> xen_guest_init() on x86 enlighten.c, we do have this for ARM and I
> > > > >> think I can that close the gap I'm observing.
> > > > >>
> > > > >> >>  Frontends only need event channels, grant
> > > > >> >> table and xenbus.
> > > > >> >
> > > > >> > Well xenbus_probe_initcall() will check for xen_domain() and that
> > > > >> > won't be set on x86 right now unless we have XEN_PV, XEN_PVHVM or
> > > > >> > XEN_PVH set -- to start off with. Then
> > > > >> > drivers/xen/xenbus/xenbus_client.c will check xen_feature in quite 
> > > > >> > a
> > > > >> > bit of places as well, that won't be set unless 
> > > > >> > xen_setup_features()
> > > > >> > is called which right now is only done on x86 
> > > > >> > arch/x86/xen/enlighten.c
> > > > >> > which as Juergen pointed out, is not needed if you don't have 
> > > > >> > XEN_PV
> > > > >> > or XEN_PVH. As it turns out this is incorrect though, its needed 
> > > > >> > for
> > > > >> > XEN_PVHVM as well and my split exercise in code addresses this. 
> > > > >> > Now,
> > > > >> > at least in my code if you don't have XEN_PV, XEN_PVHVM, or 
> > > > >> > XEN_PVH we
> > > > >> > don't call xen_setup_features() and its unclear to me where or how
> > > > >> > that should happen in other cases.
> > > > >>
> > > > >> Yeah I think having an x86 equivalent of xen_guest_init() would solve
> > > > >> this, Stefano, thoughts?
> > > > >
> > > > > Having xen_guest_init() on x86 would be nice.  Being able to set
> > > > > xen_domain_type to XEN_HVM_DOMAIN if we are running on Xen, regardless
> > > > > of XEN_PV/PVH/PVHVM also makes sense from Linux POV.
> > > > 
> > > > OK great, thanks for the feedback.
> > > > 
> > > > > That said, I don't see much value in removing XEN_PVHVM: why are we 
> > > > > even
> > > > > doing this? What is the improvement we are seeking?
> > > > 
> > > > We would not, the above discussed about the possibility of letting
> > > > users enable XEN_PVHVM without XEN_PVH, that's all.
> > > 
> > > OK, that makes sense.
> > > 
> > > > As is the only thing that can enable XEN_PVHVM is if you enable
> > > > XEN_PVH.
> > > 
> > > This is the bit that we need to change but it shouldn't be difficult.
> > > 
> > > > If we want
> > > > xen_guest_init() alone though we might need the decoupling though at
> > > > least at build time so that if XEN_PV or XEN_PVH is not selected we'd
> > > > at least have XEN_PVHVM. Thoughts?
> > > 
> > > Today pv(h) and pvhvm have very different boot paths already: pv and pvh
> > > initialize via xen_start_kernel while pvhvm via xen_hvm_guest_init.
> > 
> > Ah I see, this helps a lot thanks!
> > 
> > > They are already very decoupled. You just need to make sure that
> > > init_hvm_pv_info() is called regardless on any XEN_PV/PVH/PVHVM configs.
> > 
> > I'm a bit confused about this given that as I see it right now
> > init_hvm_pv_info() is the Xen x86_hyper->init_platform() callback and that 
> > is
> > only called on init_hypervisor_platform() *iff* x86_hyper->detect() passed
> > (returned non-zero), but xen detect() returns 0 in the PV case:
> > 
> > static uint32_t __init xen_hvm_platform(void)                               
> >     
> > {                                                                           
> >     
> >         if (xen_nopv)                                                       
> >     
> >                 return 0;                                                   
> >     
> >                                                                             
> >     
> > **      if (xen_pv_domain())                                                
> >     
> > **              return 0;                                                   
> >     
> >                                                                             
> >     
> >         return xen_cpuid_base();                                            
> >     
> > }
> > 
> > To be clear that is when xen_domain_type == XEN_PV_DOMAIN, and that should 
> > only
> > ever happen when xen_start_kernel() gets called prior to xen_hvm_platform().
> > 
> > Since as you note xen_start_kernel() should only be run for XEN_PV and
> > XEN_PVH, that is in essence the "PV"iness of the guest -- the Xen
> > hypervisor will look for this via the ELF entry note and kick it off
> > upon guest start via the hypervisor launch_vm(), otherwise we'd boot the 
> > kernel
> > through the usual means and init/main.c --> start_kernel() will evetually 
> > call
> > setup_arch() and in the end init_hypervisor_platform().
> > 
> > I see no way then in which init_hvm_pv_info() would be called for XEN_PV
> > and XEN_PVH. In fact should we not be able to just BUG_ON(xen_pv_domain()) 
> > above?
> 
> Yes, that is true.
> 
> What I meant is that for HVM guests you could set xen_domain_type from
> something like xen_hvm_platform (x86_hyper->detect()) indepedently from
> PVH/PV/PVHVM config options. xen_domain_type = XEN_HVM_DOMAIN doesn't
> necessarely mean that we are going to use PV on HVM interfaces, it only
> means that we are running inside Xen HVM virtuam machine.

Sure, that is clear to me, so in other words right now we have no path that
only pegs a simple Xen HVM virtual machine upon setup on init, correct?

  Luis

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