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

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: George.Dunlap@eu.citrix.com, xen-devel@lists.xenproject.org,
	kevin.tian@intel.com, jun.nakajima@intel.com
Subject: Re: [PATCH 5/6] x86/HVM: prefill cache with PDPTEs when possible
Date: Thu, 19 Jul 2018 20:07:26 +0100	[thread overview]
Message-ID: <4ba21c83-e1e5-fa2b-01e0-04f2b92b79aa@citrix.com> (raw)
In-Reply-To: <5B50DFE70200007800137635@prv1-mh.provo.novell.com>

On 19/07/18 20:00, Jan Beulich wrote:
>>>> Andrew Cooper <andrew.cooper3@citrix.com> 07/19/18 8:47 PM >>>
>> On 19/07/18 19:37, Jan Beulich wrote:
>>>>> Andrew Cooper <andrew.cooper3@citrix.com> 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.

Oh - I'd not looked in that much detail at your algorithm.  As a first
gut feel, tagging by level doesn't sound as if it will interact
correctly with linear pagetables.

Both the Intel and AMD ORM's maintain paging structure caches so I'd
expect that a linear pagetable entry would be served from that cache
rather than being read twice from RAM.

~Andrew

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