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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 3C4C1C5519F for ; Thu, 12 Nov 2020 17:53:20 +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 B5D4E216C4 for ; Thu, 12 Nov 2020 17:53:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B5D4E216C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org 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.25996.54104 (Exim 4.92) (envelope-from ) id 1kdGln-000282-L5; Thu, 12 Nov 2020 17:52:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 25996.54104; Thu, 12 Nov 2020 17:52:27 +0000 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" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kdGln-00027v-H0; Thu, 12 Nov 2020 17:52:27 +0000 Received: by outflank-mailman (input) for mailman id 25996; Thu, 12 Nov 2020 17:52:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kdGll-00027q-Ii for xen-devel@lists.xenproject.org; Thu, 12 Nov 2020 17:52:25 +0000 Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e15a3fc2-f6e3-4e06-830c-b1d07598f259; Thu, 12 Nov 2020 17:52:24 +0000 (UTC) Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1kdGlh-000BVF-1b; Thu, 12 Nov 2020 17:52:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kdGll-00027q-Ii for xen-devel@lists.xenproject.org; Thu, 12 Nov 2020 17:52:25 +0000 X-Inumbo-ID: e15a3fc2-f6e3-4e06-830c-b1d07598f259 Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e15a3fc2-f6e3-4e06-830c-b1d07598f259; Thu, 12 Nov 2020 17:52:24 +0000 (UTC) Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1kdGlh-000BVF-1b; Thu, 12 Nov 2020 17:52:21 +0000 Date: Thu, 12 Nov 2020 17:52:21 +0000 From: Tim Deegan To: Jan Beulich Cc: Roger Pau =?iso-8859-1?Q?Monn=E9?= , "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , George Dunlap Subject: Re: [PATCH 5/5] x86/p2m: split write_p2m_entry() hook Message-ID: <20201112175221.GB43943@deinos.phlegethon.org> References: <29d30de1-2a8d-aee2-d3c3-331758766fc9@suse.com> <7b2b7cc9-8828-41bd-7949-764161bbe7ff@suse.com> <20201110135944.hbsojy6eeyw53has@Air-de-Roger> <20201111121730.pblsf6inot5gixfc@Air-de-Roger> <7f916527-9a9c-8afe-5e5c-781554d1bd73@suse.com> <20201112130709.r3acpkrkyck6arul@Air-de-Roger> <51e646d4-3e1b-3698-c649-a39840275ec9@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51e646d4-3e1b-3698-c649-a39840275ec9@suse.com> X-SA-Known-Good: Yes X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tim@xen.org X-SA-Exim-Scanned: No (on deinos.phlegethon.org); SAEximRunCond expanded to false At 15:04 +0100 on 12 Nov (1605193496), Jan Beulich wrote: > On 12.11.2020 14:07, Roger Pau Monné wrote: > > On Thu, Nov 12, 2020 at 01:29:33PM +0100, Jan Beulich wrote: > >> I agree with all this. If only it was merely about TLB flushes. In > >> the shadow case, shadow_blow_all_tables() gets invoked, and that > >> one - looking at the other call sites - wants the paging lock held. [...] > > The post hook for shadow could pick the lock again, as I don't think > > the removal of the tables needs to be strictly done inside of the same > > locked region? > > I think it does, or else a use of the now stale tables may occur > before they got blown away. Tim? Is this the call to shadow_blow_tables() in the write_p2m_entry path? I think it would be safe to drop and re-take the paging lock there as long as the call happens before the write is considered to have finished. But it would not be a useful performance improvement - any update that takes this path is going to be very slow regardless. So unless you have another pressing reason to split it up, I would be inclined to leave it as it is. That way it's easier to see that the locking is correct. Cheers, Tim.