Re: [PATCH v3 08/28] xen/x86: Annotate VM applicability in featureset

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 21/03/16 11:53, Jan Beulich wrote:

>>>> +XEN_CPUFEATURE(X2APIC,        1*32+21) /*A  Extended xAPIC */
>>> Does this make sense for PV?
>> It is currently visible, and we already have to leak APIC through to PV
>> guests.
> Having to leak on piece of state doesn't mean when need to leak
> more, when that's clearly impossibly to be meaningful to a guest.

PV guests can already real real APIC IDs out cpu leaves in the masking case.

Now I think about it, this is special just like HTT and CMP_LEGACY, and
must have the host value leaked through to PV guests when masking is in
effect.

>>>> +XEN_CPUFEATURE(HYPERVISOR,    1*32+31) /*A  Running under some hypervisor */
>>> Wouldn't this better be one of the special ones?
>> Why? It doesn't need any special handling in Xen.  For all intents and
>> purposes, it is just like a regular feature bit.
> Except that you don't pass through its host value, but instead
> override it to 1. Which makes it kind of special, I would say.

HVM guests go straight from the toolstack settings.  PV guests have it
unilaterally set.

I suppose this does qualify for special under the guidelines I was
using.  I suspect it is only unilaterally set so it appears as set to
dom0.  DomUs also have it unilaterally set by the toolstack.

I suspect it makes very little difference for a PV guest, which knows
for certain that it is virtualised.


>>>> +XEN_CPUFEATURE(LM,            2*32+29) /*A  Long Mode (x86-64) */
>>> I think I had asked before, but doesn't the customization needed
>>> for 32-bit PV guests also rather make this a special one?
>> Why would it?  It is a simple feature which isn't present for 32bit guests.
> Together with the above the question really is: What exactly makes
> a feature special? The need for run time overrides, or something
> more sophisticated?

"Things which Xen has to deal specially with", which includes
conditionally leaking host state through.

~Andrew

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