From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.4098.1687773159394506754 for ; Mon, 26 Jun 2023 02:52:39 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DciyBPpz; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) 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 D1CA960DCE for ; Mon, 26 Jun 2023 09:52:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 394BBC43391 for ; Mon, 26 Jun 2023 09:52:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687773158; bh=8fkM4Z0Z6hFskWVfQm26wRfRoyyG0cXQgg2KXwVgpgQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DciyBPpzhBbyA+SoX8OQLub9L72+nQMKEXnhHWzSIqZkNohC7dBmAsRuk94triN0W cCYC+8pGJwh+kPA5ZwYPt/F/o1hkav2LtkyjhzYtN4kFcjgcuClIGOZ1aLjAac3esy Ui8h4sC4s+WbX6U5NQpa1rmrL7nCMw+psJ3PbnWq8UInWQIY+gOH0078mVeTBWrboE 4fXSUm2WDaelGNp+AEWcLHJzKqSMeyIMpc2XXaPYMiTM8B1mukmxAPw/lWLRIJeU0x EahVrO+N5zDH0b/k5c23UWvnULl2wqpi0x3MqvAk0lLvSyUyJNhHDpp8H/3l8+RN8J VYMpKK7uuNuaA== Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-4f766777605so3881343e87.1 for ; Mon, 26 Jun 2023 02:52:38 -0700 (PDT) X-Gm-Message-State: AC+VfDzW536+x7v3wK7VmLO8BF1EBRWFMpqSnhYlRpN17UOjCDOX21lF NuSEpnIYEHySXmgzap/eP+3Xiy3sdaD/r5J4s+w= X-Google-Smtp-Source: ACHHUZ6iRzB4lPZVO1hCR1tkVYetFlFsi92xJVPYgbObfkIk87IykyA+4AOWhckufHJm6+p1651FMRxeFJbN/aZArPM= X-Received: by 2002:a19:3813:0:b0:4f8:7697:5207 with SMTP id f19-20020a193813000000b004f876975207mr11280416lfa.23.1687773156162; Mon, 26 Jun 2023 02:52:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 26 Jun 2023 11:52:24 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] uefi VM and IO window overlap issue To: devel@edk2.groups.io, kraxel@redhat.com Cc: kallol.biswas@nutanix.com, Pritam Chatterjee , Jiewen Yao Content-Type: text/plain; charset="UTF-8" On Tue, 20 Jun 2023 at 16:27, Gerd Hoffmann wrote: > > On Mon, Jun 12, 2023 at 07:27:37PM +0000, Kallol Biswas [C] wrote: > > Hi, > > We have been observing an issue that IO BARs can't be claimed due to resource > > conflict. > > > > [ 0.457693] pci 0000:00:1d.0: can't claim BAR 4 [io 0x92a0-0x92bf]: address conflict with PCI Bus 0000:01 [io 0x9000-0x9fff] > > [ 0.457705] pci 0000:00:1d.1: can't claim BAR 4 [io 0x9280-0x929f]: address conflict with PCI Bus 0000:01 [io 0x9000-0x9fff] > > [ 0.457715] pci 0000:00:1d.2: can't claim BAR 4 [io 0x9260-0x927f]: address conflict with PCI Bus 0000:01 [io 0x9000-0x9fff] > > [ 0.457743] pci 0000:00:1f.2: can't claim BAR 4 [io 0x9240-0x925f]: address conflict with PCI Bus 0000:01 [io 0x9000-0x9fff] > > [ 0.457754] pci 0000:00:1f.3: can't claim BAR 4 [io 0x9200-0x923f]: address conflict with PCI Bus 0000:01 [io 0x9000-0x9fff] > > > > > > Please see the discussion thread: > > > > https://www.spinics.net/lists/linux-pci/msg133740.html > > > > The root of the problem is that OVMF does not take into account the limit register's granularity (limit) of a bridge, > > and programs EPs with overlapping IO ranges in a different bus. > > > > Should we fix the issue in the OVMF? > > IMHO yes. > > https://edk2.groups.io/g/devel/message/96645 > > Jiewen suggested to fix it somewhere in PCI code instead. > No response from the PCI maintainers on that comment. > > Jiewen, Ard? > How move forward with that? > But this issue is not limited to hotplug enabled platforms, right? AIUI, the I/O resource configuration is simply incorrect. Looking at the report: > Base = 0x8000; Length = 0x200; Alignment = 0xFFF; Owner = PPB [00|02|00:**] > Base = 0x8200; Length = 0x40; Alignment = 0x3F; Owner = PCI [00|1F|03:20] > Base = 0x8240; Length = 0x20; Alignment = 0x1F; Owner = PCI [00|1F|02:20] > Base = 0x8260; Length = 0x20; Alignment = 0x1F; Owner = PCI [00|1D|02:20] This seems to suggest that the range 0x8200 and up is assigned to other endpoints on bus 0x0 while it is also being decoded by the bridge. So that looks like something that needs to be fixed in the shared PCI resource allocation code.