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

[Ian Campbell <Ian.Campbell@citrix.com>]

On Fri, 2012-08-17 at 23:26 +0100, Mukesh Rathor wrote:
> On Fri, 17 Aug 2012 15:36:04 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > > > For example in balloon.c we are probably only interested in memory
> > > > related behavior, so checking for XENFEAT_auto_translated_physmap
> > > > should be enough.  In other parts of the code we might want to
> > > > check for xen_pv_domain(). If xen_pv_domain() and
> > > > XENFEAT_auto_translated_physmap are not enough, we could introduce
> > > > another small XENFEAT that specifies that the domain is running
> > > > in a HVM container. This way they are all reusable.
> > > 
> > > yeah, I thought about that, but wasn't sure what the implications
> > > would be for a guest thats not PVH but has auto xlated physmap, if
> > > there's such a possibility. If you guys think thats not an issue, I
> > > can change it.
> > 
> > dom0_shadow=on on the hypervisor mode enables that in PV mode.
> 
> So, if I just add checks for auto_translated_physmap like suggested,
> wouldn't I be changing and breaking the code paths for dom0_shadow boot
> of PV guest?

Changing, but not breaking, I think. Assuming auto_translated_physmap is
used in the logically correct way.

If anything I think you'd be making dom0_shadow work better, since you
are making stuff actually work.

>  is dom0_shadow depracated?

I hadn't even heard of it until today.

> 
> Following would be true for both, pvh and dom0_shadow:
> 
> #define xen_pvh_domain() (xen_pv_domain() && \
>                           xen_feature(XENFEAT_auto_translated_physmap) && \
>                           xen_have_vector_callback)  

FWIW I don't think dom0 shadow has vector callback support.

But even if it did we could add a new XENFEAT to allow you to
distinguish if necessary. Lets wait and see what uses of xen_pvh_domain
remain once you converted the easy ones to XENFEAT_writable etc etc. The
remaining uses may show some pattern which we can use to name the new
XENFEAT something more specific than XENFEAT_pvh.

I wonder if PVH deserves a new entry in the XENVER_capabilities string?

> Also, the SIF flag allows PVH to be enabled via config file where the
> tool pareses and sets it for the guest.
> 
> At present:
>   dom0: put pvh=true at grub command line
>   domU: put pvh=1 in the vm.cfg file.

I guess these turn into something like a new XEN_DOMCTL_CDF_* which is
passed to XEN_DOMCTL_createdomain? 

Ian.