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.133.124]) by mx.groups.io with SMTP id smtpd.web10.8261.1651225575519992997 for ; Fri, 29 Apr 2022 02:46:16 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=U3nHJRyE; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651225574; 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=XrH8sfy9Z/L2v0USxt8/QTFR8DtghUc1XYoZtpkDs9k=; b=U3nHJRyEH6W7E61bWIYlE0Js5EL9xtSB607Vk+J56uXqJlroXywGS6McO78j0a++HMBZ+E pSMNnPD047owNykXtVykxWNolEUgJxoTuqsw2q0I2buWb7mZWmvIT5KlKO/ccWCyjHcHfb aZi+OfWaD01Nguv+iNihp3bykTFLoU4= 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-542-Ohp4lywzP5-p9JqTDvrixw-1; Fri, 29 Apr 2022 05:46:11 -0400 X-MC-Unique: Ohp4lywzP5-p9JqTDvrixw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CF8613810798; Fri, 29 Apr 2022 09:46:10 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.13]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 93FA2400E436; Fri, 29 Apr 2022 09:46:10 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 7725E18000B4; Fri, 29 Apr 2022 11:46:08 +0200 (CEST) Date: Fri, 29 Apr 2022 11:46:08 +0200 From: "Gerd Hoffmann" To: "Ni, Ray" Cc: "devel@edk2.groups.io" , "Nong, Foster" , "Albecki, Mateusz" , "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: <20220429094608.nm5e6ny5az5wtykx@sirius.home.kraxel.org> References: <20220422073713.2087781-1-kraxel@redhat.com> <20220422073713.2087781-2-kraxel@redhat.com> <20220429065047.7ed7xvawzmfdja2h@sirius.home.kraxel.org> <20220429084710.r7qrmtwov5tngzj7@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 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, > > > 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. > > An error message and continue? Not even an error message. In case the pci core code assigns a io window to the pci root port it will log a message saying so. In case it doesn't it stays silent. > > 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. > > Does it have some certain policy that IO resource for first root bridge should > be satisfied? I don't know for sure. From the boot logs it looks like the kernel simply assigns resources in pci scan order, and when it runs out of resources it stops assigning. take care, Gerd