Re: [Xen-devel] [PATCH 6/8] xen/x86: Calculate PV CR4 masks at boot

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.06.15 at 15:31, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 25/06/15 14:08, Jan Beulich wrote:
>>>>> On 24.06.15 at 18:31, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -682,24 +682,47 @@ void arch_domain_unpause(struct domain *d)
>>>          viridian_time_ref_count_thaw(d);
>>>  }
>>>  
>>> -unsigned long pv_guest_cr4_fixup(const struct vcpu *v, unsigned long 
>>> guest_cr4)
>>> +/*
>>> + * These are the masks of CR4 bits (subject to hardware availability) 
>>> which a
>>> + * PV guest may not legitimiately attempt to modify.
>>> + */
>>> +static unsigned long __read_mostly pv_cr4_mask, compat_pv_cr4_mask;
>> The patch generally being fine, I still wonder why you chose to use
>> "pv" in the names instead of the previous "hv": To me, the latter
>> makes more sense: "the bits the hypervisor controls" instead of "the
>> bits pv guests do not control".
> 
> It is the set of bits Xen doesn't mind the guest attempting to modify,

It's the inverse of that set of bits really, isn't it?

Jan

> which is specifically different from the bits Xen actually controls, and
> different from the set of bits shadowed in a guests CR4.
> 
> The masks do represent a superset of the shadowed bits, (clamped by
> hardware support).  Bits such as PGE and FSGSBASE are deemed ok for a
> guest to attempt to modify, but are not shadowed and the guests
> interests are completely ignored.
> 
> ~Andrew




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