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

Re: [Xen-devel] [PATCH 5/6] tools/libx[cl]: Don't use HVM_PARAM_PAE_ENABLED as a function parameter



Andrew Cooper writes ("[PATCH 5/6] tools/libx[cl]: Don't use 
HVM_PARAM_PAE_ENABLED as a function parameter"):
> The sole use of HVM_PARAM_PAE_ENABLED is as a non-standard calling
> convention for xc_cpuid_apply_policy().  Pass PAE as a regular
> parameter instead.

Following our conversation on irc, I have tried to write an
explanation in my own words of what this commit is doing.

  The value of HVM_PARAM_PAE_ENABLED is set by the toolstack.  And the
  only place that reads it is also in the toolstack, in
  xc_cpuid_apply_policy.  Effectively, this hypervisor domain
  parameter is used solely as a way to pass this boolean parameter
  from one part of the toolstack to another.

  This is not sensible.

  Replace its use in xc_cpuid_apply_policy with a plain boolean
  parameter, passed directly by the one (in-tree) caller.
  The now-redundant code to set the value in the hypervisor will be
  deleted in the next patch.

> Leave a rather better explaination of why only HVM guests have a
> choice in PAE setting.

I approve of this part of the commit message.

> No functional change.

I would write

   No overall functional change.  The new code fior calculating the
   `pae' value (in libxl__cpuid_legacy) is isomorphic to the
   obselescent code (in libxl_x86.c).

I had a look to see whether this was true and it seemed to be.

>          /*
> -         * HVM_PARAM_PAE_ENABLED is a parameter to this function, stashed in
> -         * Xen.  Nothing else has ever taken notice of the value.
> +         * PAE used to be a parameter passed to this function by
> +         * HVM_PARAM_PAE_ENABLED.  It is now passed normally.
>           */

I find this phrasing confusing, particularly this very loose use of
the word `parameter'.  I would drop this comment entirely and let the
commit message stand as the historical documentation.

>      char *cpuid_res[4];
> +    bool pae = true;
> +
> +    /*
> +     * PAE is a Xen-controlled for PV guests (it is the 'p' that causes the
> +     * difference between the xen-3.0-x86_32 and xen-3.0-x86_32p ABIs).  It\
 is
> +     * mandatory as Xen is running in 64bit mode.
> +     *
> +     * PVH guests don't have a top-level PAE control, and is treated as
> +     * available.
> +     */

I approve of putting a new comment here with an explanation.  However,
it should be wrapped rather more tightly (eg, in my MUA it is now
suffering from wrap damage as I demonstrate above) and it seems to
have some problems with the grammar ?  And I think the 2nd sentence
"It is mandatory" could usefully be re-qualified "for PV guests".  Or
you could write something like this.

   PV guests: PAE is Xen-controlled (it is the 'p' that causes the
   difference between the xen-3.0-x86_32 and xen-3.0-x86_32p ABIs);
   Xen is in 64-bit mode so PAE is mandatory.

   PVH guests: there is no top-level PAE control in the libx domain
   config; we always make it available.

   So only this test only applies to HVM guests:

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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