Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> On Mon, 10 Sep 2012 14:55:52 +0100
> Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > On Thu, 2012-08-16 at 01:57 +0100, Mukesh Rathor wrote:
> > > diff --git a/include/xen/xen.h b/include/xen/xen.h
> > > index a164024..e823639 100644
> > > --- a/include/xen/xen.h
> > > +++ b/include/xen/xen.h
> > > @@ -18,6 +18,10 @@ extern enum xen_domain_type xen_domain_type;
> > >                                  xen_domain_type == XEN_PV_DOMAIN)
> > >  #define xen_hvm_domain()       (xen_domain()
> > > &&                        \ xen_domain_type == XEN_HVM_DOMAIN)
> > > +/* xen_pv_domain check is necessary as start_info ptr is null in
> > > HVM. Also,
> > > + * note, xen PVH domain shares lot of HVM code */
> > > +#define xen_pvh_domain()       (xen_pv_domain()
> > > &&                     \
> > > +                               (xen_start_info->flags &
> > > SIF_IS_PVINHVM))
> > 
> > Can I suggest that for the time being this be gated on a new
> > CONFIG_XEN_PVH option (I think it's new, I can't find one right now)
> > which "depends EXPERIMENTAL".
> > 
> > We don't want to get into the situation where whatever goes into Linux
> > now makes it into a distro (and is enabled) and is subsequently broken
> > on top of whatever the final hypervisor side stuff ends up looking
> > like. We've done the same for the ARM support for example.
> > 
> > Ian.
> 
> Well, I'm pretty much removing all xen_pv_domain() checks and moving to
> other checks, like you guys wanted. This code is pretty intermingled and
> can't be ifdef'd easily.

It would likely be sufficient to just ifdef the bit which tells the
builder that this kernel image supports PVH, which I guess is one or
more XENFEATs in arch/x86/xen/xen-head.S?

Ian.


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