From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id D8252740035 for ; Wed, 19 Jul 2023 22:07:03 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=gnrwP/2+7qmz7VR/VGEivh0kDPqwhMpmGZ3VaTHNYzY=; c=relaxed/simple; d=groups.io; h=X-Received:X-Received:X-Received:X-Received:X-Received:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-ID:Message-ID:Subject:To:Cc:Precedence:List-Unsubscribe:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:Content-Type; s=20140610; t=1689804422; v=1; b=OLOs1HJkEMOHZyak+j9/6awL6NdvlSr0iWajVrfZZLLP+uHgIGCq6VjtsvVBxNP2iOa1scot T2imfyMGW5nfCE4EzoUr0XITHqNg+p1uBe85GibHLBWVNQhgExrTkIoKWCq1DGvyvR32Kgs8mPL UnOBytWskQd0PiWCzCIQC/0s= X-Received: by 127.0.0.2 with SMTP id ny0DYY7687511xNddVGQ6ZCr; Wed, 19 Jul 2023 15:07:02 -0700 X-Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.2776.1689804421970852410 for ; Wed, 19 Jul 2023 15:07:02 -0700 X-Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 46033617C9 for ; Wed, 19 Jul 2023 22:07:01 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE67DC433C7 for ; Wed, 19 Jul 2023 22:07:00 +0000 (UTC) X-Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-4fdd14c1fbfso169889e87.1 for ; Wed, 19 Jul 2023 15:07:00 -0700 (PDT) X-Gm-Message-State: ce349aTT3r3tJayVqQTxM9LPx7686176AA= X-Google-Smtp-Source: APBJJlFtpeKLDMh+ohvdRAcEZwe3NQvLvorkA4sTf9Aj9hj/rL8Q7E/zAOLpalWDHjbclIQ+NVmLu9xlWA8hz3feTO4= X-Received: by 2002:a05:6512:15a8:b0:4fb:7666:3bc0 with SMTP id bp40-20020a05651215a800b004fb76663bc0mr949727lfb.47.1689804418718; Wed, 19 Jul 2023 15:06:58 -0700 (PDT) MIME-Version: 1.0 References: <20230719113317.276124-1-kraxel@redhat.com> <010201896ee54d34-2b5c712c-d799-49b0-a2eb-f0838988b313-000000@eu-west-1.amazonses.com> <010201896f3cee08-297652da-0698-47a8-8832-246bc0d63518-000000@eu-west-1.amazonses.com> In-Reply-To: <010201896f3cee08-297652da-0698-47a8-8832-246bc0d63518-000000@eu-west-1.amazonses.com> From: "Ard Biesheuvel" Date: Thu, 20 Jul 2023 00:06:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg/IoMmuDxe: add locking to IoMmuAllocateBounceBuffer To: Michael Brown Cc: Gerd Hoffmann , devel@edk2.groups.io, Jiewen Yao , Jordan Justen Precedence: Bulk List-Unsubscribe: List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ardb@kernel.org Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=OLOs1HJk; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Wed, 19 Jul 2023 at 19:40, Michael Brown wrote: > > On 19/07/2023 17:52, Ard Biesheuvel wrote: > > On Wed, 19 Jul 2023 at 18:32, Gerd Hoffmann wrote: > >> On Wed, Jul 19, 2023 at 04:04:28PM +0000, Michael Brown wrote: > >>> It looks as though IoMmuFreeBounceBuffer() should also raise to TPL_NOTIFY > >>> while modifying mReservedMemBitmap, since the modification made in > >>> IoMmuFreeBounceBuffer() is not an atomic operation: > >>> > >>> mReservedMemBitmap &= (UINT32)(~MapInfo->ReservedMemBitmap); > >> > >> I'd expect modern compilers optimize that to a single instruction, > > > > You mean something along the lines of > > > > andl %reg, mReservedMemBitmap(%rip) > > > > right? > > Even with a single orl/andl instruction, the operation is unlocked. > It's guaranteed atomic against interrupts (since interrupts always occur > at instruction boundaries) but it's not guaranteed atomic against > concurrent accesses to the same global variable from other processors. > > (I have no idea if the UEFI model allows APs to call into the IOMMU > protocol or not, so I don't know if this is a real problem.) > No, it's not really a problem. While there is a notion of 'run function F() on AP #n' in the MpServices protocol, there is no real SMP support where the same code and data are being used concurrently on multiple cores in parallel. > On a quick review of the code, there appear to be other points that also > modify mReservedMemBitmap (IoMmuAllocateCommonBuffer() and > IoMmuFreeCommonBuffer()). I'd guess that these also need to raise to > TPL_NOTIFY, but I'm not familiar with the code so I don't know if > there's anything that makes this unnecessary. > Thanks for mentioning that - perhaps Gerd could have another look? (I merged the v2 already) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107064): https://edk2.groups.io/g/devel/message/107064 Mute This Topic: https://groups.io/mt/100233359/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-