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.web08.6909.1654178346602582265 for ; Thu, 02 Jun 2022 06:59:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=LpSdsqOL; 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6E27B617DE for ; Thu, 2 Jun 2022 13:59:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4B04C3411D for ; Thu, 2 Jun 2022 13:59:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654178344; bh=VnjReKI6zaCoPZ66FGyfHreRDl8GeF8+i1SARBHNoLA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LpSdsqOLnBGhv1neZuOn1HPRqDYXSZzAO+SR0y9u4S40d4lEjpn5JMRCJpm2dM55K yLzMfLBsyWhmJV5v+Gy+XLaWB8utWZ2sEOFlKcuoXbAQefR9o8UUbdqN+LAOoZ1sKR ckzlYUwQu/ag2hIrs5HSF/3cFolSjaPZY5DBcQf8t0WE8q2WI/OEu6Umo7Fy29Fc4/ TwOnJ/rXx9a/PDdhfeZVg35vBGPZc5CRjEijmttu/q6YCAz+t2FFcdsdGqvd0SVqZ5 o5DVt/7oen7Tm2dddjN28kzVS0+U16zbMoJoDc8JogIPVOHBTveltmfdM6eYNaWEzV fUKCloRDST9XQ== Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-e656032735so6893894fac.0 for ; Thu, 02 Jun 2022 06:59:04 -0700 (PDT) X-Gm-Message-State: AOAM533gl3i8b6pJcz03dA3Z878JjaUN398XH8SV5H5C0pL/JTldU70m GxsErY5UnhauTr9wG0OtCW+0sAiVBi/UM5oNiCg= X-Google-Smtp-Source: ABdhPJxBPrv1kMqUF6QPmwNKFCGiSGO4CA2XASslAxXnTdcVMpdDHfNtGMmLyuxlRAAL8SxU/nPHmsyUzm70b2z6E+g= X-Received: by 2002:a05:6871:5c8:b0:f3:3c1c:126f with SMTP id v8-20020a05687105c800b000f33c1c126fmr2834245oan.126.1654178343920; Thu, 02 Jun 2022 06:59:03 -0700 (PDT) MIME-Version: 1.0 References: <20220602084216.159028-1-kraxel@redhat.com> <20220602084216.159028-2-kraxel@redhat.com> <20220602131457.75zndaiipdosgiid@sirius.home.kraxel.org> In-Reply-To: <20220602131457.75zndaiipdosgiid@sirius.home.kraxel.org> From: "Ard Biesheuvel" Date: Thu, 2 Jun 2022 15:58:52 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory To: Gerd Hoffmann Cc: "Ni, Ray" , "devel@edk2.groups.io" , "Wu, Hao A" , Pawel Polawski , Ard Biesheuvel , "Albecki, Mateusz" , "Chang, Abner" , Leif Lindholm , "Yao, Jiewen" , Oliver Steffen , "Gao, Liming" , "Wang, Jian J" , "Justen, Jordan L" Content-Type: text/plain; charset="UTF-8" On Thu, 2 Jun 2022 at 15:15, Gerd Hoffmann wrote: > > Hi, > > > I did a quick test with both ArmVirtQemu and microvm (using this > > series but omitting the MdeModulePkg), and I can confirm that not > > having a I/O resource window at all seems to work fine if none of the > > PCI devices have I/O BARs. > > > > Gerd, do you remember why exactly this patch is needed? Is it related > > to devices that have I/O BARs but don't actually require them to > > function correctly? > > Well, the difference seem to be pcie root ports. When plugging my > virtio device into the root bus everything is fine: > > PCI Bus First Scanning > PciBus: Discovered PCI @ [00|00|00] > > PciBus: Discovered PCI @ [00|01|00] > BAR[1]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset = 0x14 > BAR[4]: Type = PMem64; Alignment = 0x3FFF; Length = 0x4000; Offset = 0x20 > [ ... ] > PciHostBridge: NotifyPhase (AllocateResources) > RootBridge: PciRoot(0x0) > Mem64: Base/Length/Alignment = 6000000000/100000/FFFFF - Success > Mem: Base/Length/Alignment = C0000000/100000/FFFFF - Success > PciBus: HostBridge->NotifyPhase(AllocateResources) - Success > > When plugging the virtio device into a pcie root port it doesn't work > and the log looks like this: > > PCI Bus First Scanning > PciBus: Discovered PCI @ [00|00|00] > > PciBus: Discovered PPB @ [00|08|00] > Padding: Type = Mem32; Alignment = 0x1FFFFF; Length = 0x200000 > Padding: Type = Io; Alignment = 0x1FF; Length = 0x200 > BAR[0]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset = 0x10 > > PciBus: Discovered PCI @ [01|00|00] > BAR[1]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset = 0x14 > BAR[4]: Type = PMem64; Alignment = 0x3FFF; Length = 0x4000; Offset = 0x20 > [ ... ] > PciHostBridge: NotifyPhase (AllocateResources) > RootBridge: PciRoot(0x0) > Mem: Base/Length/Alignment = C0000000/300000/1FFFFF - Success > Mem64: Base/Length/Alignment = 6000000000/100000/FFFFF - Success > I/O: Base/Length/Alignment = FFFFFFFFFFFFFFFF/1000/FFF - Out Of Resource! > [ ... ] > PciHostBridge: NotifyPhase (AllocateResources) > RootBridge: PciRoot(0x0) > Mem64: Base/Length/Alignment = 6000000000/100000/FFFFF - Success > Mem: Base/Length/Alignment = C0000000/200000/FFFFF - Success > I/O: Base/Length/Alignment = FFFFFFFFFFFFFFFF/0/FFF - Out Of Resource! > > So, it's apparently the io window of the pcie root port which causes > edk2 try allocate io resources. > This seems to be related to the padding logic, i.e., we are trying to preserve some extra I/O space for the root port in case we hotplug something that might need it. The hack below gets around this - we'll need something suitable check here that avoids I/O padding when the root port has not I/O resource window in the first place. Care to cook something up? --- a/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c +++ b/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c @@ -733,7 +733,7 @@ GetResourcePadding ( } } - if (DefaultIo) { + if (DefaultIo && FALSE) { // // Request defaults. //