Re: [PATCH 3/4] xen/domctl: Introduce fault_ttl

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/01/2021 16:39, Jan Beulich wrote:
> On 23.12.2020 17:34, Andrew Cooper wrote:
>> To inject a simulated resource failure, for testing purposes.
>>
>> Given a specific set of hypercall parameters, the failure is in a repeatable
>> position, for the currently booted Xen.  The exact position of failures is
>> highly dependent on the build of Xen, and hardware support.
> What about other kinds of resources, or ones only indirectly
> related to memory allocations (e.g. where we don't mean to
> associate them with the domain)?

I intend this for "any fail-able operation", not just plain memory
allocation.

It's merely that memory allocation is the simple first resource to go
after.  And after all, these 4 patches alone have already identified a
real bug in ARM's dom0less logic.

Perhaps what we actually want is a general "bool simulate_failure(d)"
which dalloc() and others can use.

>>  * I'm thinking of dropping handle from xen_domctl_createdomain because it's 
>> a
>>    waste of valuable space.
> Looks entirely unrelated, but yes - as long as Xen itself has no
> consumer of the field. The more that there already is
> XEN_DOMCTL_setdomainhandle.

It's purely for pretty printing in 'q' and handing back to userspace for
xentop, et al.  Nothing in Xen acts meaningfully upon the value.

>> --- a/xen/common/dmalloc.c
>> +++ b/xen/common/dmalloc.c
>> @@ -10,7 +10,13 @@ void dfree(struct domain *d, void *ptr)
>>  
>>  void *_dzalloc(struct domain *d, size_t size, size_t align)
>>  {
>> -    void *ptr = _xmalloc(size, align);
>> +    void *ptr;
>> +
>> +    if ( atomic_read(&d->fault_ttl) &&
>> +         atomic_dec_and_test(&d->fault_ttl) )
>> +        return NULL;
> Perhaps we want to introduce Linux'es atomic_add_unless()?

Possibly.  I definitely got caught out by the semantics of
atomic_dec_and_test() seeing as it has an implicit "!= 0".

~Andrew