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

Re: [Xen-devel] [PATCH v5 03/21] xen/x86: Generate deep dependencies of features

On 08/04/16 16:17, Jan Beulich wrote:
>>>> On 08.04.16 at 01:36, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 08/04/2016 00:18, Jan Beulich wrote:
>>>>>> On 07.04.16 at 13:57, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> +    deps = {
>>>> +        # FPU is taken to mean support for the x87 regisers as well as the
>>>> +        # instructions.  MMX is documented to alias the %MM registers 
>>>> over the
>>>> +        # x87 %ST registers in hardware.
>>>> +        FPU: [MMX],
>>>> +
>>>> +        # The PSE36 feature indicates that reserved bits in a PSE 
>>>> superpage
>>>> +        # may be used as extra physical address bits.
>>>> +        PSE: [PSE36],
>>>> +
>>>> +        # Entering Long Mode requires that %CR4.PAE is set.  The NX and 
>>>> PKU
>>>> +        # pagetable bits are only representable in the 64bit PTE format
>>>> +        # offered by PAE.
>>>> +        PAE: [LM, NX, PKU],
>>> PKU is explicitly documented to be available only in IA-32e paging,
>>> so I think it should be listed as a dependent of LM.
>> I am not so sure.  Unlike PCID, it is not declared that setting CR4.PKE
>> will result in a #GP fault out of Long Mode, and the description does
>> say "If CR4.PKE = 0, or if IA-32e paging is not active, the processor
>> does not associate linear addresses with protection keys".
>> This suggests that CR4.PKE can be set out of Long Mode, but all
>> pagewalks will act as if key0 is in use.  PCID on the other hand goes to
>> lengths declaring that you can't set CR4.PCIDE out of Long Mode, nor may
>> you attempt to exit Long Mode if it is set.
>> I do have some Skylake hardware with PKU available in the office.  I
>> will investigate what really happens in this case.  (I am also mindful
>> of the fact that 32bit PV guests could in principle use PKU, at which
>> point the dependency on LM would be counter-productive.)
> With the goal of the series going in soon (today?), wouldn't putting
> in the tighter variant be the better approach, allowing us to relax
> things if we find they can be relaxed?

At this point, yes.  I will make a note when changing.

I need to rebase anyway as there is a textual collision with the xsave
bugfixes from yesterday.


Xen-devel mailing list



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