Re: [RFC] xen/arm: Handling cache maintenance instructions by set/way

[Julien Grall <julien.grall@linaro.org>]

(+ Marc)

@Marc: My Arm cache knowledge is somewhat limited. Feel free to correct 
me if I am wrong.

On 07/12/17 09:39, Jan Beulich wrote:
>>>> On 06.12.17 at 18:52, <julien.grall@linaro.org> wrote:
>> On 12/06/2017 03:15 PM, Jan Beulich wrote:
>>> What we do in x86 is that we flag all entries at the top level as
>>> misconfigured at any time where otherwise we would have to
>>> walk the full tree. Upon access, the misconfigured flag is being
>>> propagated down the page table hierarchy, with only the
>>> intermediate and leaf entries needed for the current access
>>> becoming properly configured again. In your case, as long as
>>> only a limited set of leaf entries are being touched before any
>>> S/W emulation is needed, you'd be able to skip all misconfigured
>>> entries in your traversal, just like with PoD you'd skip
>>> unpopulated ones.
>>
>> Oh, what you call "misconfigured bits" would be clearing the valid bit
>> of an entry on Arm. The entry would be considered invalid, but it is
>> still possible to store informations (the rest of the bits are ignored
>> by the hardware).
> 
> Well, on x86 we don't always have a separate "valid" bit, hence
> we set something else to a value which will cause a suitable VM
> exit when being accessed by the guest.
> 
>> But I think this is bringing another class of problem. When a
>> misconfigured is accessed, we would need to clean & invalidate the cache
>> for that region.
> 
> Why? (Please remember that I'm an x86 person, so may simply
> not be aware of extra constraints ARM has.) The data in the
> cache (if any) doesn't change while the mapping is invalid (unless
> Xen modifies it, but if there was a coherency problem between
> Xen and guest accesses, you'd have the issue with hypercalls
> which you describe later independent of the approach suggested
> here).

Caches on Arm are coherent and are controlled by attributes in the 
page-tables. The coherency is lost if you access a region with different 
memory attributes.

To take the hypercall case, we impose memory shared with the hypervisor 
or any other guests to have specific memory attributes. So this will 
ensure cache coherency. This applies to:
	- hypercall arguments passed via a pointer to guest memory
	- memory shared via the grant table mechanism
	- memory shared with the hypervisor (shared_info, vcpu_info, grant 
table...).

Now regarding access by a guest. Even though the entry is 
"misconfigured" in the guest page-tables, this same physical address may 
be have been mapped in other places (e.g Xen, guests...). Because of 
speculation, a line could have been pulled in the case. As we don't know 
the memory attribute used by the guest, you have to clean & invalidate 
that region on a guest access.

Getting back to the hypercall case, I am still trying to figure out if 
we need to clean & invalidate the buffer used when the guest entry is 
"misconfigured". I can't convince myself why this would not be 
necessary. I need to have a more thorough think.

Cheers,

-- 
Julien Grall

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