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

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

(+ 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@xxxxxxxxxx> 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

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.


Julien Grall

Xen-devel mailing list



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