(+ 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.gr...@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
