[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, 20 Aug 2012 12:02:55 +0100
Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:

> On Fri, 17 Aug 2012, Mukesh Rathor wrote:
> > On Fri, 17 Aug 2012 15:36:04 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> > 
> > 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.

Agree.

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

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

Ok, getting rid of SIF flag. The guest will check for above conditions. 

Thanks for the feedback.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.