Re: [Xen-devel] [PATCH v4 11/26] xen/x86: Improvements to in-hypervisor cpuid sanity checks

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/03/16 16:29, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2016 at 04:36:14PM +0000, Andrew Cooper wrote:
>> Currently, {pv,hvm}_cpuid() has a large quantity of essentially-static logic
>> for modifying the features visible to a guest.  A lot of this can be subsumed
>> by {pv,hvm}_featuremask, which identify the features available on this
>> hardware which could be given to a PV or HVM guest.
>>
>> This is a step in the direction of full per-domain cpuid policies, but lots
>> more development is needed for that.  As a result, the static checks are
>> simplified, but the dynamic checks need to remain for now.
>>
>> As a side effect, some of the logic for special features can be improved.
>> OSXSAVE and OSPKE will be automatically cleared because of being absent in 
>> the
>> featuremask.  This allows the fast-forward logic to be more simple.
>>
>> In addition, there are some corrections to the existing logic:
>>
>>  * Hiding PSE36 out of PAE mode is architecturally wrong.  It turns out that
>>    it was a bugfix for running HyperV under Xen, which wanted to see PSE36
>>    even after choosing to use PAE paging.  PSE36 is not supported by shadow
>>    paging, so is hidden from non-HAP guests, but is still visible for HAP
>>    guests.
>>  * Changing the visibility of RDTSCP based on host TSC stability or virtual
>>    TSC mode is bogus, so dropped.
> Why is it bogus? It is an PV ABI type CPUID.

The CPUID bit has a well defined meaning, and the vtsc infrastructure
went and diverged the ABI provided by Intel and AMD.

If it were only PV guests, it would be less bad.  However, it breaks HVM
guests as well which is absolutely not ok.

The meaning of the RDTSCP feature bit is well defined.  The presence of
the `rdtscp` instruction, and the TSC_AUX MSR.

The vtsc options control whether rdtsc(p) is intercepted by Xen, and
whether the guest or Xen controls the AUX MSR.  These options are
unrelated, and have no bearing on the availability of the instruction in
the first place.

>
> Independetly of that you would also need to modify tsc_mode.txt file and all 
> uses
> of 'tsc_mode=3'.

A guest kernel cannot use the presence or absence of the rdtscp feature
to identify which vtsc mode is in intended, which necessarily means
there is an extra out-of-band signal controlling its use.

In particular, the current issue fixed by this change is that for the
default case, on migrate, the rdtscp feature disappears from the domain
as the tsc logic decides that the frequency has changed and vtsc mode
should be enabled.

~Andrew

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