[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 5/6] x86/PCI: avoid re-evaluation of extended config space accessibility


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 3 Feb 2026 18:19:03 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5KKguGCm0m/c0z83/a0cONcteUbXEG5AiIiGnVyiGzc=; b=MlLXQ+4jxYzdD+6rorU5ySfWf5aMriXQzBi2x2DOLcZAUTT8TY0ruaKZUvUf0Hj9hWsWTTM0G0/8yNP/DmRWSTlvUrRkHb27/FtDSeW19eRq/KA/R7g+RBgPELGIDlOQZLWBR4kqG7o4fwcIj/i+frLGg69dh4cN4SxgDS82iYnWk3Gk+BDiJ3OUIIgJ7Xw1rdYCwlMrHrukX4sUUapSuXMhK+lgMT+K/Apo+G8oA8MgV+wmO/pnVTCxZxDg42A+1DWVBsgrctSlOt4gFW3tDbSK6eHAFf2f2SKALdiSq5pE7UDq5OPHchCVgmfc3qG4pJpdSEmQrgUfPcAwSYLgig==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kBEib5t9FvKNwC6zWyQcxrvyFzeyHDvNZrierkEkJW7wm2Fl95svsrem5MH7PZ/P27MpUwZxaXxEJGHa3zZkob1x4EITX2oIsfE1ga3BInG90FLskdYBtVoZzU9bVSBHire35gSQ7KLhmk8cmc50BAIiOz1NBAxnf/F7T+E4HjIoT2HQfIeuFdQ8C4nP2awtaiumE3Qjc3leytLrfuXzhTxhmsm3j2dYuMA+9AZ8z4BfcLNtup+EkH5S3vpx3WgjshN7VOgkXkwe8KvGzLtHXcwsTdGIs317x/Yd7MYJ5SAcWxpw1JIYkGQl6PZ5HSot1vvUxcG1BupiPP55GUhCqA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Delivery-date: Tue, 03 Feb 2026 17:19:14 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Feb 03, 2026 at 03:48:52PM +0100, Jan Beulich wrote:
> On 02.02.2026 16:18, Roger Pau Monné wrote:
> > My copy of the PCI Firmware Spec v3.3 contains:
> > 
> > "4.1.2. MCFG Table Description
> > 
> > The MCFG table is an ACPI table that is used to communicate the base
> > addresses corresponding to the non-hot removable PCI Segment Groups
> > range within a PCI Segment Group available to the operating system at
> > boot.
> > 
> > [...]
> > 
> > 4.1.3. The _CBA Method
> > 
> > Some systems may support hot plug of host bridges that introduce
> > either a range of buses within an existing PCI Segment Group or
> > introduce a new PCI Segment Group. For example, each I/O chip in a
> > multi-chip PCI Express root complex implementation could start a new
> > PCI Segment Group."
> > 
> > Together with this:
> > 
> > "The MCFG table format allows for more than one memory mapped base
> > address entry provided each entry (memory mapped configuration space
> > base address allocation structure) corresponds to a unique PCI Segment
> > Group consisting of 256 PCI buses. Multiple entries corresponding to a
> > single PCI Segment Group is not allowed."
> > 
> > Given that each segment group can only appear once in the MCFG, and
> > that the _CBA method can introduce new segment groups, it would seem
> > to me the spec does allow for new segments appearing exclusively as
> > the return of _CBA method?  It does read as if hot-removable segment
> > groups must not appear in the MCFG table.  I'm not finding any clear
> > statement in the spec that says that ECAM areas must previously appear
> > in the MCFG table.
> > 
> > I'm not sure how common that is, but it doesn't seem impossible given
> > my reading of the spec.
> 
> Hmm, that'll be a bit of work then, as Dom0 will also need to propagate
> the necessary data into Xen.

TBH this is what the spec says, but I've never encountered such a
system.  In fact I've never tested hotplug of a PCI host bridge.

Not sure this can be simulated with QEMU so that we could at least
test whatever fixes we plan to do in that area?  I guess we could
"fake" a bodge where Xen ignores the MCFG completely and only becomes
aware of the ECAM areas from what the hardware domain reports back.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.