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

Re: [Xen-devel] [PATCH 5/6] x86/HVM: prefill cache with PDPTEs when possible

>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 07/19/18 8:47 PM >>>
>On 19/07/18 19:37, Jan Beulich wrote:
>>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 07/19/18 1:55 PM >>>
>> On 19/07/18 12:47, Jan Beulich wrote:
>>> This patch feeds the PDPTE registers into the cache, which breaks the
>>> architectural correctness of patch 3, because the PDPTE registers may
>>> legitimately be stale WRT the content in memory.
>> Exactly. And I want to use the register contents in that case. Hence the 
>> filling
>> of the cache here from the register values.
>But using the register values is wrong here.
>>> The pagewalk reading of top_map doesn't require that top_map points into
>>> guest space.  If you read the PDPTE registers onto the stack, and pass a
>>> pointer to the stack into the pagewalk in the 3-level case, then you fix
>>> the issue described here without breaking patch 3.
>> I'm afraid I still don't understand: Why "onto the stack"? And anyway - are
>> you trying to tell me this odd is how actual hardware behaves?
>Consider the following scenario:
>; %eax points at some valid PDPTEs
>mov %eax, %cr3 ; Copies 32 bytes into the hidden registers.
>mov $0xdead, 8(%eax) ; Clobbers PDPTE[1].  Hardware register still intact.
>FEP mov 8(%eax), %ebx ; Reads the memory behind the clobbered PDPTE[1]
>When emulating the 3rd instruction, you actually need to read memory,
>not the cached PDPTEs, because the value can be different.  Therefore,
>you must not put the PDPTEs into the cache in the first place, because
>it will cause erroneous behaviour.

So what lead you to believe the actual data access could be satisfied from the
cache? Cache entries are deliberately tagged by page table level, and no level 0
entries will (currently) ever be produced.


Xen-devel mailing list



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