Re: [Xen-devel] [PATCH v6 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.08.14 at 15:07, <paul.durrant@xxxxxxxxxx> wrote:
> The following commits introduced the time reference counter MSR and
> TSC/APIC frequency MSRs into the viridian feature set respectively:
> 
> e36cd2cdc9674a7a4855d21fb7b3e6e17c4bb33b
> 84657efd9116f40924aa13c9d5a349e007da716f
> 
> The time reference counter MSR feature was then reverted by commit
> 
> 1cd4fab14ce25859efa4a2af13475e6650a5506c
> 
> because a flaw in the implementation meant the counter was reset on
> migration.
> 
> All of these changes were made without any addtional options being
> added to the VM configuration, or any compatibility checks being made
> in the domain save/restore code. Hence setting the single boolean
> 'viridian' option in the VM configuration yields a different set of
> features depending on which version of Xen the VM is started on, and the
> feature set can change across migration (so new MSRs can magically appear).
> 
> This patch grandfathers in the current viridian features set and calls them
> the 'base' and 'freq' feature sets. HVM_PARAM_VIRIDIAN is re-purposed as
> a feature mask. The hypervisor has only ever allowed it ot be set to 0
> or 1, so the presence of the base and freq sets are indicated by setting
> bit 0. The freq set can then be turned off by setting bit 1, thus
> restoring the pre-Xen-4.4 base set. Newly implemented viridian features
> can be optionally enabled in future by setting further bits.
> 
> The viridian option in xl.cfg(5) has also been changed to a string list so
> that the sets can be individually sepcified. For compatibility, if the
> option is specified as a boolean, then a true (1) value will be translated
> to a string list containing "base" and "freq".
> 
> This patch also alters the allowed write accesses to HVM_PARAM_VIRIDIAN.
> Currently there is nothing to stop the guest writing this value (which,
> while harmless to anything else, should not happen) and nothing to
> stop a toolstack from setting the value back to zero whilst the guest is
> running, causing CPUID leaves to disappear and MSR accesses to start
> causing GPFs in the guest. Both of these possibilities are now disallowed:
> Once the parameter is set to a non-zero value it may not be cleared, and
> guests no longer have any write access.
> 
> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

Hypervisor parts
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>


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