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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.12.17 at 16:22, <julien.grall@xxxxxxxxxx> wrote:
> On 07/12/17 09:39, Jan Beulich wrote:
>>>>> On 06.12.17 at 18:52, <julien.grall@xxxxxxxxxx> wrote:
>>> 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...).

But that's not an issue specific to the situation here, i.e. multiple
mappings with different memory attributes would always be a
problem. Hence I assume you have code in place to deal with that.
By retaining the entry contents except for the valid bit (or
something else to allow you to gain control upon access) nothing
should really change for the rest of the hypervisor logic, provided
such entries are not explicitly being ignored on any of the involved
logic.

Jan


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