From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web09.7846.1651222078044658197 for ; Fri, 29 Apr 2022 01:47:58 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=W72DJE9s; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651222077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xVk6uknRQa/briyGCt9b7GnrHDKJ2CIuj1BxSTlsJFE=; b=W72DJE9sjCp1EJqnAr/taIOLo0H/h9aU2E9zKZNhK7S1lvLD1Tw6VYSgIjAD2oTFGKB4aa wJanBTMuPdQCTHuneYmY/R8vEL9RaPqrbU3k+c8wY3jSAMJDt06luWGWjEpSt8JkDZ98TP YVpeG/1rvFWORUnRRm4ZNKDnrLiYCTc= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-339-4_tNtVkVNKO9IDMPKhnFSw-1; Fri, 29 Apr 2022 04:47:12 -0400 X-MC-Unique: 4_tNtVkVNKO9IDMPKhnFSw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 52EC2381D196; Fri, 29 Apr 2022 08:47:12 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.13]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EA99F463E06; Fri, 29 Apr 2022 08:47:11 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 48D5F18000B4; Fri, 29 Apr 2022 10:47:10 +0200 (CEST) Date: Fri, 29 Apr 2022 10:47:10 +0200 From: "Gerd Hoffmann" To: "Ni, Ray" Cc: "devel@edk2.groups.io" , "ardb@kernel.org" , Pawel Polawski , Ard Biesheuvel , "Gao, Liming" , "Wu, Hao A" , Oliver Steffen , Leif Lindholm , "Justen, Jordan L" , "Yao, Jiewen" , "Chang, Abner" , "Wang, Jian J" Subject: Re: [edk2-devel] [PATCH v5 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory Message-ID: <20220429084710.r7qrmtwov5tngzj7@sirius.home.kraxel.org> References: <20220422073713.2087781-1-kraxel@redhat.com> <20220422073713.2087781-2-kraxel@redhat.com> <20220429065047.7ed7xvawzmfdja2h@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > 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. > Do you know how Linux handles this? > Can Linux allocate resource for PCI(E) devices? How does it deal with the IO type? Yes. Details depend a bit on the specific configuration, but in general linux will try assign io address space to pcie root ports and devices plugged into those ports. A failure is not considered fatal though. A more common case than the pci root bridge not supporting io address space at all is having more than 16 pcie root ports. Given io bride windows are 1k in size and we have 16k total there is simply not enough io address space in that case, so some of the root ports stay without io and linux is fine with that. > Why changing the MdeModulePkg's IncompatiblePciDevice driver can avoid > stalling the patch series? > I feel it's enough to just change the OvmfPkg version. It's not much of a problem for ovmf even without such an update, typically the devices used with microvm don't have io bars in the first place. Also note that without this series pcie devices are not supported at all on microvm, so not supporting all devices initially wouldn't be a regression. I'll look into it in any case. take care, Gerd