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

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Fri, 17 Aug 2012 15:36:04 -0400
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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? is dom0_shadow depracated?

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)  


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.


thanks,
Mukesh



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