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

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 13 Jan 2021 23:58:04 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JEm9ojvtREQkn9StehDvgBy5mR2MLp+t0ipJHvgVba4=; b=NAG2t3kSyR2VszpJnJNAtiTOAj6aeT03sRICDO0S+bGLgOQHIf2sftQdPFLli/jE7Er0IZErvezjAMfFh4iEHyep1St3j/TkzaczOgMJ616huxPo+BCiH/zJqXlBEcdmbj45/7IJ0AFq04XKPYBEj9HC+arVvQ18kVdcnHOtvvvTduumK/6fOY+oroqfWt+CANxgc8514zyhJrWmXeo9XRn4UEOI1sKyR844+uLgzNXn2snTHtTVCBXyWQkRPm1GHjTFasF+jLtCLKQGfWEAMYhy4Jh5sns9F1OEmNdiHzTLal8KKlhfHjQi4Jhwg0YTF9jNmVtaHFiSHCUMVkdIfg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gIDFDj+fAu9POhTpz6vjjA0ipK5nb61AZjp8u4GRjfILLcaL0G6nrCQN8rsxmMQlpwtmhuPtAeg/fu8whX3lDiWHhIL8oK5vwEIVPVTBwDIyPQ68s/groyFWazZqoymAb80oLkm1eVLMByG00k9Kj23ss+bHPUVwyyVkwxplz0R+472XLRCbqWCrlj1N32huUDdJgevsN82NjLCI0rKxO5BUrh7IUtfn2FAXth89vfg+blIWJ4Bv6ZBTXStZINVAm4fo99fOj3KWpC90QWzUTfcRRlLqX+Jp/vHNI2lBtSOd6e/0L7wAMLurS31CQ7roRhx/Qffh2pQCluVNvKEuKA==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, "Tamas K Lengyel" <tamas@xxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 13 Jan 2021 23:58:41 +0000
  • Ironport-sdr: OVsMO7QtlJGuAV/ZHW7vjm9y4w2f3i9sU3az/ekevqegxi+KFmM4yKe0aPQZcT7EXmQpD6eXB6 DZQ/GCBbtpAUn/u+VGW7hoZiNT9aC4XvBJD6yaD/ttwVxAx9l2k1NABTDwVYgfIHFvzxLIpKoX qg0AfzegQu/IaLQF+tyiibWLIuzqXPW1GAMI/YKCKLmNA14HW0syk7iIgmtxsHYjNC14Wsev9q use/WN7e8rv5LfSe2utLVHy9ufd+OonFo+OLsOx7o5qGIZhLJeLRbDrWdmXi0kFRsjc8/V+iCL uiI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

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




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.