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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.01.14 at 17:35, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2014-01-29 at 15:01 +0000, Jan Beulich wrote:
>> >>> On 29.01.14 at 15:15, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Wed, 2014-01-29 at 13:00 +0000, Jan Beulich wrote:
>> >> >>> On 29.01.14 at 13:11, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
>> >> > +    case XEN_DOMCTL_cacheflush:
>> >> > +    {
>> >> > +        long rc = p2m_cache_flush(d, &domctl->u.cacheflush.start_mfn);
>> >> > +        if ( __copy_to_guest(u_domctl, domctl, 1) )
>> >> 
>> >> While you certainly say so in the public header change, I think you
>> >> recall that we pretty recently changed another hypercall to not be
>> >> the only inconsistent one modifying the input structure in order to
>> >> handle hypercall preemption.
>> > 
>> > That was a XNEMEM though IIRC -- is the same requirement also true of
>> > domctl's?
>> 
>> Not necessarily - I was just trying to point out the issue to
>> avoid needing to fix it later on.
> 
> OK, but you do think it should be fixed "transparently" rather than made
> an explicit part of the API?

I'd prefer if it would be done that way. Otherwise we'd need to
mentally store that we're allowing exceptions for domctls, but not
for other hypercalls.

> Before I get too deep into that, do you think that
>         struct xen_domctl_cacheflush {
>             /* start_mfn is updated for progress over preemption. */
>             xen_pfn_t start_mfn;
>             xen_pfn_t end_mfn;
>         };
>         
> is acceptable or do you want me to try and find a way to do preemption
> without the write back?

As per above - if possible, I'd prefer you avoiding the write back.

> The blobs written by the toolstack aren't likely to be >1GB in size, so
> rejecting over large ranges would be a potential option, but it's not
> totally satisfactory.

Agreed, but good enough for now (considering the various other
cases that already have similar "issues").

Jan


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