[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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,
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.