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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-09-12 at 20:32 +0100, Mukesh Rathor wrote:
> On Wed, 12 Sep 2012 19:26:20 +0100
> Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> > > On Wed, 12 Sep 2012 09:12:25 +0100
> > > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > > 
> > > > On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> > > > > On Mon, 10 Sep 2012 14:55:52 +0100
> > > > > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > > > It would likely be sufficient to just ifdef the bit which tells
> > > > the builder that this kernel image supports PVH, which I guess is
> > > > one or more XENFEATs in arch/x86/xen/xen-head.S?
> > > > 
> > > Nop, I've not added any new bits. Just using existing bits:
> > > 
> > > XENFEAT_writable_page_tables
> > > XENFEAT_auto_translated_physmap
> > > XENFEAT_supervisor_mode_kernel
> > 
> > Currently we declare:
> >         ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz
> > "!writable_page_tables|pae_pgdir_above_4gb")
> > 
> > It might be a mistake for writable_page_tables to be there already but
> > in any case when you add the other two you should gate them on this
> > new option.
> > 
> > (nb: "!foo" means "foo is required" rather than "not foo". I chose a
> > very confusing character for this!)
> > 
> > It may also be worth having a XENFEAT_pvh for us in communicating
> > support for this feature from the kernel to the tools (like
> > XENFEAT_dom0). That's the opposite of case we wanted to avoid
> > (enabling behaviour in the kernel).
> 
> Well, the way I have it is, it's the PV binary. To boot in PVH mode, you
> put pvh=1 in vm.cfg file. The tool stacks read it and tell xen via
> new flag XEN_DOMCTL_CDF_hybrid_guest. Err, make that _pvh_guest.
> xen sets the new is_pvh bit in struct domain. The PVH guest upon boot
> does xen_setup_features() first thing. xen sends it:
> 
> > XENFEAT_writable_page_tables
> > XENFEAT_auto_translated_physmap
> > XENFEAT_supervisor_mode_kernel
>  
> that with callback vector makes it a PVH guest. 

Callback vector is XENFEAT_hvm_callback_vector, I think.

A PV kernel is required to announce the features which it supports via
the elf notes (defined in xen-head.S).

It would be a bug for the toolstack to enable PVH mode for a kernel
which did not claim to support the required featureset.

The aim should be that the user should not normally need to specify pvh
one way or the other, imagine a use case where pygrub is used to boot
both old and new kernels using it.

The toolstack (or the dom0 builder) can make the determination whether
to enable this mode itself itself based on the notes (although it is
always handy to have an override to force things for debug).

Ian.


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