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

Re: [Xen-devel] [PATCH v4 3/5] xen/arm: clean and invalidate all guest caches by VMID after domain build.



>>> On 07.02.14 at 13:57, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 07.02.14 at 13:12, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -885,6 +885,17 @@ struct xen_domctl_set_max_evtchn {
>>  typedef struct xen_domctl_set_max_evtchn xen_domctl_set_max_evtchn_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_max_evtchn_t);
>>  
>> +/*
>> + * ARM: Clean and invalidate caches associated with given region of
>> + * guest memory.
>> + */
>> +struct xen_domctl_cacheflush {
>> +    /* IN: page range to flush. */
>> +    xen_pfn_t start_pfn, nr_pfns;
>> +};
> 
> The name here (and of the libxc interface) is now certainly
> counterintuitive. But it's a domctl (and an internal interface),
> which we can change post-4.4 (I'd envision it to actually take
> a flags parameter indicating the kind of flush that's wanted).

Actually the naming of things in the hypervisor part of the patch
is now bogus too - sysc_page_to_ram(), for example, does in no
way imply that the cache needs not just flushing, but also
invalidating. The need for which, btw, I continue to not
understand: Are there ways in ARM for one guest to observe
cache contents put in place by another guest (incl Dom0)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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