|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |