From: Bjorn Helgaas <helgaas@kernel.org>
To: Nirmal Patel <nirmal.patel@linux.intel.com>
Cc: nirmal.patel@intel.com, linux-pci@vger.kernel.org,
bhelgaas@google.com, kwilczynski@kernel.org, mani@kernel.org,
robh@kernel.org, lpieralisi@kernel.org
Subject: Re: [PATCH v7] PCI: vmd: Add feature to scan BIOS enumerated devices.
Date: Mon, 20 Jul 2026 13:35:55 -0500 [thread overview]
Message-ID: <20260720183555.GA354351@bhelgaas> (raw)
In-Reply-To: <20260629165025.268836-1-nirmal.patel@linux.intel.com>
On Mon, Jun 29, 2026 at 04:50:25PM +0000, Nirmal Patel wrote:
> Newer VMD with device ID 0x28c1 has unique settings compared to its
> predecessor where BIOS enumerates the entire VMD device tree and
> assigns respective configurations.
>
> VMD configuration BAR0 carries over from GNR legacy VMD as the mechanism
> to access the configuration space of the devices owned by VMD. The size
> of this window is fixed at 256 MB, where each function consumes 4 KB and
> every bus consumes 1 MB.
>
> The shadow and scratchpad registers have been relocated from the VMD
> configuration space to the VMD MMIO space in VMD BAR4/BAR5, otherwise
> refers to as MEMBAR2 or MSI-X bar.
>
> VMD MSI-X remapping enable/disable is no longer supported.
>
> All the VMD driver code needs to do is to obtain bus hide range along
> with shadow register values set by BIOS and perform a bus scan.
>
> The commit also involves small refactoring of vmd_enable_domain function.
> ...
> +static int vmd_prepare_offsets_and_bus(struct vmd_dev *vmd,
> + unsigned long features,
> + resource_size_t *membar2_offset,
> + resource_size_t *offset1,
> + resource_size_t *offset2)
> +{
> + int ret;
> +
> + /*
> + * Shadow registers may exist in certain VMD device ids which allow
> + * guests to correctly assign host physical addresses to the root ports
> + * and child devices. These registers will either return the host value
> + * or 0, depending on an enable bit in the VMD device.
> + *
> + * For certain VMD devices (i.e. 0x28C1), BIOS places device info
> + * in BAR4 shadow registers to determine the base bus number and memory
> + * offsets.
> + */
> + if (features & VMD_FEAT_USE_BIOS_INFO) {
> + *membar2_offset = MEMBAR2_OFFSET_28C1;
> + ret = vmd_get_bus_info_from_bar4(vmd, offset1, offset2);
Is it guaranteed that for device 0x28C1, BIOS will *always* do the
enumeration? Sounds like a rev-lock between this device and the BIOS,
i.e., this device can't be used at all with an old BIOS that doesn't
know how to do that enumeration?
> @@ -1114,6 +1228,10 @@ static const struct pci_device_id vmd_ids[] = {
> .driver_data = VMD_FEAT_HAS_MEMBAR_SHADOW |
> VMD_FEAT_HAS_BUS_RESTRICTIONS |
> VMD_FEAT_CAN_BYPASS_MSI_REMAP,},
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_VMD_28C1),
> + .driver_data = VMD_FEAT_HAS_MEMBAR_SHADOW |
> + VMD_FEAT_CAN_BYPASS_MSI_REMAP |
> + VMD_FEAT_USE_BIOS_INFO,},
> {PCI_VDEVICE(INTEL, 0x467f),
> .driver_data = VMD_FEATS_CLIENT,},
> {PCI_VDEVICE(INTEL, 0x4c3d),
next prev parent reply other threads:[~2026-07-20 18:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 16:50 [PATCH v7] PCI: vmd: Add feature to scan BIOS enumerated devices Nirmal Patel
2026-06-29 17:01 ` sashiko-bot
2026-07-15 5:51 ` Manivannan Sadhasivam
2026-07-20 18:35 ` Bjorn Helgaas [this message]
2026-07-20 21:21 ` Nirmal Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260720183555.GA354351@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=kwilczynski@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=nirmal.patel@intel.com \
--cc=nirmal.patel@linux.intel.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.