Re: [Xen-devel] PVH: libxl expertise...

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-11-14 at 01:31 +0000, Mukesh Rathor wrote:
> On Tue, 13 Nov 2012 17:21:38 -0800
> Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> 
> > 
> > 
> > I can't tell why f_active is there. I also see supported, may be thats
> > the string of what the kernel supports. It is set to 0x11 ??? 
> 
> Debugging further, I see in xc_dom_parse_elf_kernel() after
> elf_parse_binary(), the strings are set as:
> 
>       type = XEN_ENT_STR, name = 0x3cadc2e116 "PAE_MODE", data = {
>         str = 0x7ffff61e14b0 "yes", num = 0x7ffff61e14b0}}, {
>       type = XEN_ENT_STR, name = 0x3cadc2dd2d "FEATURES", data = {
>         str = 0x7ffff61e1414 "!writable_page_tables|pae_pgdir_above_4gb", 
>         num = 0x7ffff61e1414}}, {type = XEN_ENT_NONE, name = 0x0, data = {
>         str = 0x0, num = 0x0}}, {type = XEN_ENT_LONG, 
> 
> So, may be it's not properly set in bzImage and something else needs to
> be done to get the correct strings there???

bzImage is a container for the ELF file, possibly things don't get
parsed early enough by xc_dom in this case?

Did you say that if you use the raw ELF file it works?

I think in the default case you don't need to touch libxl here (yet),
you need libxc to do the correct thing.

Do you need to know if this is a PV vs PVH domain at
XEN_DOMCTL_createdomain (aka xc_domain_create) time or can it be set
later? My suspicion is that when the domain is created the kernel hasn't
been parsed yet so the feature flags are not available. This would be
easier to deal with if the PVH selection could be moved later on to the
point where you are actually building the domain -- but I don't know how
hard that would be.

When I prototyped this stuff years ago I added XEN_DOMCTL_setfeatures
which was called from xc_dom_parse_image:
        @@ -668,8 +669,26 @@ int xc_dom_parse_image(struct xc_dom_ima
             /* check features */
             for ( i = 0; i < XENFEAT_NR_SUBMAPS; i++ )
             {
        -        dom->f_active[i] |= dom->f_requested[i]; /* cmd line */
        -        dom->f_active[i] |= dom->parms.f_required[i]; /* kernel   */
        +        domctl.cmd = XEN_DOMCTL_setfeatures;
        +        domctl.domain = dom->guest_domid;
        +
        +        domctl.u.setfeatures.submap_idx = i;
        +        domctl.u.setfeatures.submap = 0;
        +
        +        domctl.u.setfeatures.submap |= dom->f_requested[i]; /* cmd 
line */
        +        domctl.u.setfeatures.submap |= dom->parms.f_required[i]; /* 
kernel   */
        +
        +        xc_dom_printf(dom->xch, "requesting features[%d] = %#x", 
domctl.u.setfeatures.submap_idx, domctl.u.setfeatures.submap);
        +        if (do_domctl(dom->xch, &domctl))
        +        {
        +            xc_dom_panic(dom->xch, XC_INVALID_PARAM,
        +                         "%s: unable to set requested features\n", 
__FUNCTION__);
        +            goto err;
        +        }
        +
        +        xc_dom_printf(dom->xch, "received   features[%d] = %#x", 
domctl.u.setfeatures.submap_idx, domctl.u.setfeatures.submap);
        +        dom->f_active[i] = domctl.u.setfeatures.submap;
        +
                 if ( (dom->f_active[i] & dom->parms.f_supported[i]) !=
                      dom->f_active[i] )
                 {
        
On the hypervisor side setting the features would enable "PVH" mode as
appropriate.

You only need to worry about libxl integration to allow the user to
override these defaults, but shall we worry about that later once we
have libxc sorted?

BTW for the purposes of parallelising things up you could post the
hypervisor side part of the series stuff + a patch to force enable PVH
in libxc (obviously the last not to be applied) first then we can be
reviewing the h/v side things while simultaneously figuring out how the
tools side fits together.

Ian.


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