Re: [Xen-devel] [PATCH v14 04/17] Introduce pv guest type and has_hvm_container macros

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/11/13 16:20, Jan Beulich wrote:
> > > > On 04.11.13 at 13:14, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> > The goal of this patch is to classify conditionals more clearly, as to
> > whether they relate to pv guests, hvm-only guests, or guests with an
> > "hvm container" (which will eventually include PVH).
> >
> > This patch introduces an enum for guest type, as well as two new macros
> > for switching behavior on and off: is_pv_* and has_hvm_container_*.  At the
> > moment is_pv_* <=> !has_hvm_container_*.  The purpose of having two is that
> > it seems to me different to take a path because something does *not* have PV
> > structures as to take a path because it *does* have HVM structures, even if
> > the
> > two happen to coincide 100% at the moment.  The exact usage is occasionally
> > a bit
> > fuzzy though, and a judgement call just needs to be made on which is
> > clearer.
> >
> > In general, a switch should use is_pv_* (or !is_pv_*) if the code in
> > question
> > relates directly to a PV guest.  Examples include use of pv_vcpu structs or
> > other behavior directly related to PV domains.
> >
> > hvm_container is more of a fuzzy concept, but in general:
> So sadly this is still being retained, despite its redundancy.
I understood our discussion at XenSummit to be that I should send the 
series as-is, once I had fixed the outstanding bugs.  I'm inclined to 
consider Tim's suggestion (as I understand it), that we get rid of the 
separate PVH mode, but instead have a number of features which can be 
enabled and disabled (apic, qemu, &c). But that shouldn't affect the 
interface to Linux.
 -George

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