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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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
here).

Jan


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