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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 17 Aug 2012, Mukesh Rathor wrote:
> 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?

I think that it is just a debugging option. The most recent reference to
dom0_shadow is in 2005, according to Google. Not many people would miss
it.


> 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)  

If I understand dom0_shadow correctly, it wouldn't have
xen_have_vector_callback set, so the above #define would still work as
you expect.
But if all the above characterists are actually true for dom0_shadow
guests too, then it might make sense to call them pvh domains anyway.


> 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.

We can still have a pvh option in the VM config file or as a Xen
parameter for dom0: it doesn't have to be exported as a SIF flag
to the Linux kernel though.
If xen_have_vector_callback is enabled and
XENFEAT_auto_translated_physmap is also set, then we are effectively
running as a PVH domain, otherwise we are not. As a consequence only the
toolstack needs to know about the pvh option in the config file to build
the guest correctly.

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