Re: [Xen-devel] [PATCH 1/3] x86/PoD: correctly handle non-order-0 decrease-reservation requests

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.12.17 at 13:56, <george.dunlap@xxxxxxxxxx> wrote:
> On 12/04/2017 11:06 AM, Jan Beulich wrote:
>> p2m_pod_decrease_reservation() returning just (not) all-done is not
>> sufficient for the caller: If some pages were processed,
>> guest_remove_page() returning an error for those pages is the expected
>> result rather than an indication of a problem. Make guest_remove_page()
>> return a distinct error code for this very case, and special case
>> handling in case of seeing this error code in decrease_reservation().
> 
> The solution is good, but I think it needs more comments and a better
> explanation.

You suggestions in this regard all sound good; I'll integrate them,
and unless you tell me otherwise I'll then also add you S-o-b.

>> +        for ( j = 0; j + pod_done < (1UL << a->extent_order); j++ )
>> +        {
>> +            switch ( guest_remove_page(a->domain, gmfn + j) )
>> +            {
>> +            case 0:
>> +                break;
>> +            case -ENOENT:
>> +                if ( !pod_done )
>> +                    goto out;
>> +                --pod_done;
>> +                break;
>> +            default:
>>                  goto out;
>> +            }
>> +        }
>>      }
> 
> What about:
> 
> ASSERT(pod_done == 0);

No, there's nothing preventing another vCPU of the guest doing
something that could result in triggering this assertion. If anything
I could make pod_done being non-zero after the loop a failure,
too. But part of me thinks this is too harsh ...

Jan


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