From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.7154.1651215644561679178 for ; Fri, 29 Apr 2022 00:00:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ULFUkB/1; spf=pass (domain: kernel.org, ip: 145.40.68.75, 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 ams.source.kernel.org (Postfix) with ESMTPS id 68D12B832A9 for ; Fri, 29 Apr 2022 07:00:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 108DEC385B3 for ; Fri, 29 Apr 2022 07:00:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651215641; bh=PLOcXe9ZWM2/VyC8dyBePjrXlXbRMU6ewgbmDsoEe3E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ULFUkB/1ZSN40FcAfXYLqzfUtKxobTQJeKJk4TkxNFc9UekJ2ZpJx06HJT+WUZ2+p dwfaPH/AF/VRCAeQtc8Br4zNR5/jBQdErL1/LmvaJs7poM4x8P9TgRJdB8AEOJbBvp X2623Bc6KYIz6fG8B2fKBvEd/cr18tYyYbMZ6c/oncpeAZ6Dh1s9B5VTezx4o63LrM IHclaUw+zN34pag94ERhRvTJnymwvsAjNOTQ0MTVYu5O9MOLTJtjaNkKxqtqhhtAZT tooAP5amwxNHLDUR6m5TfKIkTOPoAbMRx9FslXhnoq1ORv5dkC+OqdSDTxmP8zSEQQ FsIjoC09Cewtg== Received: by mail-ot1-f45.google.com with SMTP id z15-20020a9d65cf000000b00605f064482cso1787027oth.6 for ; Fri, 29 Apr 2022 00:00:40 -0700 (PDT) X-Gm-Message-State: AOAM532nz1DWt3gFaPczKfAcyYbpYditDEZC7577yMTPq3hVDEZ+xBrq nZ/nQhKEkq0B9v0t+HJYV0QW19ZACx+HFIp4ZaQ= X-Google-Smtp-Source: ABdhPJz7ULtFKnRVYDhm0PCci/mnw55mWX68goL/u05bcp9Eksbd7IlEnzZh50Wzqa6ibt9VGzsgtOqSIctkTbQuUsY= X-Received: by 2002:a9d:84f:0:b0:605:e229:3c82 with SMTP id 73-20020a9d084f000000b00605e2293c82mr3373980oty.71.1651215640161; Fri, 29 Apr 2022 00:00:40 -0700 (PDT) MIME-Version: 1.0 References: <20220422073713.2087781-1-kraxel@redhat.com> <20220422073713.2087781-2-kraxel@redhat.com> <20220429065047.7ed7xvawzmfdja2h@sirius.home.kraxel.org> In-Reply-To: <20220429065047.7ed7xvawzmfdja2h@sirius.home.kraxel.org> From: "Ard Biesheuvel" Date: Fri, 29 Apr 2022 09:00:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v5 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory To: Gerd Hoffmann Cc: "Ni, Ray" , "devel@edk2.groups.io" , Pawel Polawski , Ard Biesheuvel , "Gao, Liming" , "Wu, Hao A" , Oliver Steffen , Leif Lindholm , "Justen, Jordan L" , "Yao, Jiewen" , "Chang, Abner" , "Wang, Jian J" Content-Type: text/plain; charset="UTF-8" On Fri, 29 Apr 2022 at 08:50, Gerd Hoffmann wrote: > > On Wed, Apr 27, 2022 at 03:08:50AM +0000, Ni, Ray wrote: > > Ard, > > can you explain more? > > > > Your code changes the PciHostBridge driver to ignore the failure of IO allocation. > > If IO requirement of certain PCI(E) devices can be ignored, can you change the IncompatiblePciDevice protocol implementation to override the IO request from the devices? > > Hmm, it's a problem indeed, device initialization fails in case an > io bar is present even if the bar is not required to drive the device. > I'd say the risk for regressions is rather low, though, given that it only affects configurations that would fail PCI resource allocation today. Or am I missing something? In any case, the PCIe spec is clear about this: I/O space is optional, and we need to incorporate this into the generic code at *some* point. It makes no sense for every individual platform to keep adding these hacks. > Suggestions how to deal with this best? ovmf has it's own > IncompatiblePciDevice Protocol implementation, so I could > handle it there because only OvmfPkg/Microvm needs this. > > Or should the MdeModulePkg version be updated too? > I'd say we do both, to avoid stalling your series forever :-)