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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 07/19/18 1:55 PM >>>
>On 19/07/18 12:47, Jan Beulich wrote:
>>>>> On 19.07.18 at 13:15, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 19/07/18 11:50, Jan Beulich wrote:
>>>> Since strictly speaking it is incorrect for guest_walk_tables() to read
>>>> L3 entries during PAE page walks, try to overcome this where possible by
>>>> pre-loading the values from hardware into the cache. Sadly the
>>>> information is available in the EPT case only. On the positive side for
>>>> NPT the spec spells out that L3 entries are actually read on walks, so
>>>> us reading them is consistent with hardware behavior in that case.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> I'm afraid that this isn't architecturally correct.  It means that an
>>> emulated memory access will read the PDPTE register values, rather than
>>> what is actually in RAM.
>> I'm afraid I don't understand: A CR3 load loads the PDPTEs into
>> registers, and walks use those registers, not memory. That's the very
>> difference between PAE and all other walks.
>
>Patch 3 causes memory reads to come from the cache.
>
>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.


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


Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel