[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 3/4] xen/domctl: Introduce fault_ttl
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |