From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 216C1C433E0 for ; Tue, 5 Jan 2021 16:39:45 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D5DED22CB2 for ; Tue, 5 Jan 2021 16:39:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D5DED22CB2 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.62083.109701 (Exim 4.92) (envelope-from ) id 1kwpMq-0006nz-3G; Tue, 05 Jan 2021 16:39:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 62083.109701; Tue, 05 Jan 2021 16:39:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kwpMq-0006ns-0I; Tue, 05 Jan 2021 16:39:32 +0000 Received: by outflank-mailman (input) for mailman id 62083; Tue, 05 Jan 2021 16:39:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kwpMo-0006nn-NJ for xen-devel@lists.xenproject.org; Tue, 05 Jan 2021 16:39:30 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e90c9cb6-f0cf-4796-bd48-436200305fdb; Tue, 05 Jan 2021 16:39:29 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 15384AA7C; Tue, 5 Jan 2021 16:39:29 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e90c9cb6-f0cf-4796-bd48-436200305fdb X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1609864769; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=znRVwlmzHraFEzooLiJ9sHODpAkG7p0BL1iV5YqA+no=; b=E5l3YwUtCKb+E7+7ayjEyIoccna0oHTYn1asW2xvnKvM8thttf1uuD97/+X0GmB9ZhxNea HUZgxfOFSodUjQE2F2M65EIeo7eYCENnnKm6UEInXAT6O3uFD3x9tV6YNp2AMLpaN64gbb xmBAzo5ubVxiDHZYFJQQbFgi2D4VK5Y= Subject: Re: [PATCH 3/4] xen/domctl: Introduce fault_ttl To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Tamas K Lengyel , Xen-devel References: <20201223163442.8840-1-andrew.cooper3@citrix.com> <20201223163442.8840-4-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 5 Jan 2021 17:39:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201223163442.8840-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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)? > RFC: > * Probably wants to be Kconfig'd Yes. > * 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. > --- 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()? Jan