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

Re: [Xen-devel] [PATCH 3/4 RFC] x86/p2m: use large pages for MMIO mappings



>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 09/17/15 6:38 PM >>>
>On 15/09/15 08:34, Jan Beulich wrote:
>> - error unmapping in map_mmio_regions() and error propagation to caller
>>   from unmap_mmio_regions() are not satisfactory (for the latter a
>>   possible model might be to have the function - and hence the domctl -
>>   return the [non-zero] number of completed entries upon error,
>>   requiring the caller to re-invoke the hypercall to then obtain the
>>   actual error for the failed slot)
>
>Doesn't this mean the caller must always make two hypercalls to confirm
>success?

No - no-zero would still only be returned upon error, just that to obtain the
error code for the failure you need to make second call.

>> +static unsigned int mmio_order(const struct domain *d,
>> +                               unsigned long start_fn, unsigned long nr)
>
>Do you mean "start_gfn" ?

No, intentionally not (the caller passes the or of MFN and GFN).

>> @@ -2044,22 +2078,45 @@ int map_mmio_regions(struct domain *d,
>>  {
>>      int ret = 0;
>>      unsigned long i;
>> +    unsigned int iter, order;
>>  
>>      if ( !paging_mode_translate(d) )
>>          return 0;
>>  
>> -    for ( i = 0; !ret && i < nr; i++ )
>> +    for ( iter = i = 0; i < nr && iter < MAP_MMIO_MAX_ITER;
>> +          i += 1UL << order, ++iter )
>>      {
>> -        ret = set_mmio_p2m_entry(d, start_gfn + i, _mfn(mfn + i),
>> -                                 p2m_get_hostp2m(d)->default_access);
>> -        if ( ret )
>> +        for ( order = mmio_order(d, (start_gfn + i) | (mfn + i), nr - i); ;
>> +              order = ret - 1 )
>
>It is hard to reason as to whether this loop will terminate.  All it
>would take is a bug in set_mmio_p2m_entry() which causes it to
>unilaterally return 1 and this loop would never terminate.
>
>Is there any other condition which can be used as a safety check?

Not that I could see any.

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®.