On Wed, 28 May 2025 23:55:48 +0800
Tomita Moeko wrote:
> Introduce x-pci-class-code option to allow users to override PCI class
> code of a device, similar to the existing x-pci-vendor-id option. Only
> the lower 24 bits of this option are used, though a uint32 is used here
> for determining whet
errp)) {
> +if (!vfio_pci_igd_opregion_detect(vdev, &opregion)) {
> return true;
> }
> info_report("OpRegion detected on Intel display %x.", vdev->device_id);
> @@ -695,7 +693,7 @@ static bool vfio_pci_kvmgt_config_quirk(VFIOPCIDevice
> *vdev, E
On Sat, 24 May 2025 23:31:02 +0800
Tomita Moeko wrote:
> Introduce x-pci-class-code option to allow users to override PCI class
> code of a device, similar to the existing x-pci-vendor-id option. Only
> the lower 24 bits of this option are used, though a uint32 is used here
> for determining whet
On Wed, 21 May 2025 23:40:36 +0800
Tomita Moeko wrote:
> In vfio_pci_igd_opregion_detect(), errp will be set when device does
> not have OpRegion or is hotplugged. This errp will be propergated to
propagated
> pci_qdev_realize(), which interprets it as failure, causing unexpected
> termination
[Please Cc maintainers - added here]
On Mon, 19 May 2025 18:08:39 +0300
Qwinci wrote:
> Change the IGD detection logic to also accept gpus with
> PCI_CLASS_DISPLAY_OTHER class which is used if the igpu is not
> set as the primary boot gpu.
>
> Signed-off-by: Qwinci
> ---
> hw/vfio/igd.c | 16
On Sun, 18 May 2025 22:09:33 +
"edmund.raile" wrote:
> Restore SR-IOV Intel iGPU VF passthrough capability:
> Check x-igd-opregion=off parameter in vfio_pci_igd_config_quirk and
> vfio_pci_kvmgt_config_quirk to ensure x-igd-opregion=off is
> respected despite subsequent attempt of automatic
>
hen x-igd-gms is set
> vfio/igd: Remove generation limitation for IGD passthrough
>
> docs/igd-assign.txt | 11 ++-
> hw/vfio/igd.c | 218 ++--
> hw/vfio/pci.c | 2 +-
> 3 files changed, 137 insertions(+), 94 deletions(-)
>
Looks ok to me, my Kaby Lake GVT-g and GVT-d configs still work.
Reviewed-by: Alex Williamson
Tested-by: Alex Williamson
On Tue, 22 Apr 2025 00:31:03 +0800
Tomita Moeko wrote:
> There is currently no straightforward way to distinguish if a Intel
> graphics device is IGD or discrete GPU. However, only IGD devices expose
> OpRegion. Use the presence of VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION
> to identify IGD devices.
On Tue, 22 Apr 2025 00:31:01 +0800
Tomita Moeko wrote:
> Intel only provides legacy VBIOS for IGD up to Gen9, and there is no
> CSM support on later devices. Additionally, Seabios can only handle
> 32-bit BDSM register used until Gen9. Since legacy mode requires VGA
> capability, restrict it to G
On Tue, 22 Apr 2025 00:31:07 +0800
Tomita Moeko wrote:
> OpRegion is exposed to guest as a read-only fw_cfg item, so hotplugging
> with it wouldn't cause issues. Since OpRegion needs to be set up by
> guest firmware, a guest reboot is typically required. For linux guests,
> i915 driver is able to
On Thu, 17 Apr 2025 01:41:22 +0800
Tomita Moeko wrote:
> On 4/17/25 00:10, Alex Williamson wrote:
> > On Wed, 16 Apr 2025 23:45:08 +0800
> > Tomita Moeko wrote:
> >
> >> On 4/16/25 03:04, Alex Williamson wrote:
> >>> On Wed, 16 Apr 202
On Wed, 16 Apr 2025 23:45:08 +0800
Tomita Moeko wrote:
> On 4/16/25 03:04, Alex Williamson wrote:
> > On Wed, 16 Apr 2025 01:36:15 +0800
> > Tomita Moeko wrote:
> >>
> >> The generation register also exists on discrete GPUs. In the new xe
> >> driv
On Wed, 16 Apr 2025 01:36:15 +0800
Tomita Moeko wrote:
>
> The generation register also exists on discrete GPUs. In the new xe
> driver [1], the Battlemage discrete GPU shares the same logic reading
> GMD_ID_DISPLAY register. The driver itself uses is_dgfx bit mapped to
> device id. In QEMU, we n
On Sun, 13 Apr 2025 19:30:10 +0800
Tomita Moeko wrote:
> On 4/10/25 01:18, Alex Williamson wrote:
> > On Wed, 26 Mar 2025 01:22:39 +0800
> > Tomita Moeko wrote:
> >
> >> So far, all Intel VGA adapters, including discrete GPUs like A770 and
> >> B580,
On Mon, 14 Apr 2025 01:23:56 +0800
Tomita Moeko wrote:
> On 4/10/25 15:34, Cédric Le Goater wrote:
> > + Corvin
> >
> > On 4/9/25 19:18, Alex Williamson wrote:
> >> On Wed, 26 Mar 2025 01:22:39 +0800
> >> Tomita Moeko wrote:
> >>
> >
On Thu, 10 Apr 2025 09:07:51 -0700
Farhan Ali wrote:
> On 4/3/2025 2:24 PM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 13:33:17 -0700
> > Farhan Ali wrote:
> >
> >> On 4/3/2025 11:05 AM, Alex Williamson wrote:
> >>> On Thu, 3 Apr 2
On Wed, 26 Mar 2025 01:22:39 +0800
Tomita Moeko wrote:
> So far, all Intel VGA adapters, including discrete GPUs like A770 and
> B580, were treated as IGD devices. While this had no functional impact,
> a error about "unsupported IGD device" will be printed when passthrough
> Intel discrete GPUs.
On Thu, 3 Apr 2025 10:33:52 -0700
Farhan Ali wrote:
> On 4/3/2025 9:27 AM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 11:44:42 -0400
> > Stefan Hajnoczi wrote:
> >
> >> On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
> >>>
On Thu, 3 Apr 2025 13:33:17 -0700
Farhan Ali wrote:
> On 4/3/2025 11:05 AM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 10:33:52 -0700
> > Farhan Ali wrote:
> >
> >> On 4/3/2025 9:27 AM, Alex Williamson wrote:
> >>> On Thu, 3 Apr 2025 1
On Thu, 3 Apr 2025 11:44:42 -0400
Stefan Hajnoczi wrote:
> On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
> > On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnoczi wrote:
> > > On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
> > > > Hi,
> > > >
> > > > Recently on
On Tue, 18 Mar 2025 17:52:53 +
Shivaprasad G Bhat wrote:
> Currently, the PCI_INTERRUPT_PIN alone is checked before enabling
> the INTx. It is also necessary to have the IRQ Lines assigned for
> the INTx to work.
>
> The problem was observed on Power10 systems which primarily use
> MSI-X, an
com/
>
> docs/igd-assign.txt | 265
> 1 file changed, 196 insertions(+), 69 deletions(-)
Reviewed-by: Alex Williamson
| Data Stolen | +-+
> +| | (Host)|
> ++>+-----+<--Host BDSM
> + Non-| | "real" one in HW
> + Passthrough | | Programmed by host FW
> + +-+
>
> Footnotes
> =
> -[1] Nothing precludes adding additional emulated or assigned graphics devices
> -as non-primary, other than the combination typically not working. I only
> -intend to set user expectations, others are welcome to find working
> -combinations or fix whatever issues prevent this from working in the
> common
> -case.
> +[1]
> https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/dump-video-bios.html
> [2] # echo "vfio-pci" > /sys/bus/pci/devices/:00:02.0/driver_override
> +[3]
> https://web.archive.org/web/20240827012422/https://bugzilla.tianocore.org/show_bug.cgi?id=935
> +Tianocore bugzilla was down since Jan 2025 :(
> +[4] https://eci.intel.com/docs/3.3/components/kvm-hypervisor.html, Patch
> 0001-0004
> +[5] https://github.com/tomitamoeko/VfioIgdPkg
> +[6]
> https://winraid.level1techs.com/t/tool-guide-news-uefi-bios-updater-ubu/30357
This is great and a much needed update. Thanks!
With above corrections:
Reviewed-by: Alex Williamson
}
>
We should probably predicate calls to vfio_bar_quirk_setup() on
VFIOBAR.size to avoid such segfaults, but agree this likely fixes the
reported issue as well.
Reviewed-by: Alex Williamson
tch to solve the possible KVMGT/GVT-g fail.
> Link:
> https://lore.kernel.org/all/20250303175220.74917-1-tomitamo...@gmail.com/
See comment on 07/ but otherwise works for me with GVT-d and GVT-g on
my i7-7700:
Reviewed-by: Alex Williamson
Tested-by: Alex Williamson
On Fri, 7 Mar 2025 02:01:27 +0800
Tomita Moeko wrote:
> So far, IGD-specific quirks all require enabling legacy mode, which is
> toggled by assigning IGD to 00:02.0. However, some quirks, like the BDSM
> and GGC register quirks, should be applied to all supported IGD devices.
> A new config opti
On Tue, 4 Mar 2025 01:52:17 +0800
Tomita Moeko wrote:
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index a58d555934..b0620a0ae8 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -3363,6 +3363,8 @@ static const Property vfio_pci_dev_properties[] = {
> VFIO_FEATURE_ENA
On Fri, 28 Feb 2025 00:27:41 +0800
Tomita Moeko wrote:
> As suggested by Cédric, I'm glad to be a maintainer of vfio-igd.
>
> Signed-off-by: Tomita Moeko
> ---
> MAINTAINERS | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
We welcome your expert
On Tue, 25 Feb 2025 02:29:17 +0800
Tomita Moeko wrote:
> This patchset removes some legacy checks and converts the legacy mode
> implicitly enabled by BDF 00:02.0 into x-igd-* options, including:
> * Removing PCI ROM BAR and VGA IO/MMIO range check before applying quirk
> * Using unified x-igd-op
On Thu, 27 Feb 2025 09:32:46 +0100
Eric Auger wrote:
> Hi Cédric,
>
> On 2/26/25 9:47 AM, Cédric Le Goater wrote:
> > VFIO Platforms was designed for Aarch64. Restrict availability to
> > 64-bit host platforms.
> >
> > Cc: Eric Auger
> > Signed-off-by: Cédric Le Goater
> Reviewed-by: Eric Au
The pm_cap on the PCIExpressDevice object can be distilled down
to the new instance on the PCIDevice object.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Zhenzhong Duan
Reviewed-by: Eric Auger
Signed-off-by: Alex Williamson
---
hw/pci-bridge
This is now redundant to PCIDevice.pm_cap.
Cc: Cédric Le Goater
Reviewed-by: Zhenzhong Duan
Reviewed-by: Eric Auger
Signed-off-by: Alex Williamson
---
hw/vfio/pci.c | 9 -
hw/vfio/pci.h | 1 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio
Apfelbaum
Cc: Cédric Le Goater
Signed-off-by: Alex Williamson
---
hw/net/e1000e.c | 3 +--
hw/net/eepro100.c | 4 +---
hw/net/igb.c| 3 +--
hw/nvme/ctrl.c | 3 +--
hw/pci-bridge/pcie_pci_bridge.c | 2 +-
hw/vfio/pci.c
machine state bump, or are there alternatives?
Thanks,
Alex
[1]https://lore.kernel.org/all/20250219175941.135390-1-eric.au...@redhat.com/
Alex Williamson (5):
hw/pci: Basic support for PCI power management
pci: Use PCI PM capability initializer
vfio/pci: Delete local pm_cap
pcie, virtio:
sk to enable guest writes to
initiate a power state change. The contents and write access of the
PM capability are still managed by the caller.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Alex Williamson
---
hw/pci/pci.c| 93 -
h
doesn't enable the BARs.
Cc: Cédric Le Goater
Reviewed-by: Zhenzhong Duan
Reviewed-by: Eric Auger
Signed-off-by: Alex Williamson
---
hw/vfio/pci.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index eab8974
On Mon, 24 Feb 2025 20:03:56 +0100
Eric Auger wrote:
> Hi Alex,
>
> On 2/20/25 11:48 PM, Alex Williamson wrote:
> > The memory and IO BARs for devices are only accessible in the D0
> > power state. In other power states the PCI spec defines that the
> > device
On Mon, 24 Feb 2025 19:37:03 +0100
Eric Auger wrote:
> Hi Alex,
>
> On 2/20/25 11:48 PM, Alex Williamson wrote:
> > Switch callers directly initializing the PCI PM capability with
> > pci_add_capability() to use pci_pm_init().
> >
> > Cc: Dmitry Fleytman
>
On Mon, 24 Feb 2025 09:14:19 +0100
Cédric Le Goater wrote:
> > An aspect that needs attention here is whether this change in the
> > wmask and PMCSR bits becomes a problem for migration, and how we
> > might solve it. For a guest migrating old->new, the device would
> > always be in the D0 power
The pm_cap on the PCIExpressDevice object can be distilled down
to the new instance on the PCIDevice object.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Alex Williamson
---
hw/pci-bridge/pcie_pci_bridge.c | 1 -
hw/virtio/virtio-pci.c | 8 +++-
include/hw/pci
This is now redundant to PCIDevice.pm_cap.
Cc: Cédric Le Goater
Signed-off-by: Alex Williamson
---
hw/vfio/pci.c | 9 -
hw/vfio/pci.h | 1 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 6903f831e45f..ba4ef65b16fa 100644
--- a/hw
unmapped, removing them from
the address space.
Introduce an interface to register the PM capability such that
the device power state is considered relative to the BAR mapping
state.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Alex Williamson
---
hw/pci/pci.c| 83
d a
machine state bump, or are there alternatives?
Thanks,
Alex
[1]https://lore.kernel.org/all/20250219175941.135390-1-eric.au...@redhat.com/
Alex Williamson (5):
hw/pci: Basic support for PCI power management
pci: Use PCI PM capability initializer
vfio/pci: Delete local pm_cap
pcie, vir
Apfelbaum
Cc: Cédric Le Goater
Signed-off-by: Alex Williamson
---
hw/net/e1000e.c | 3 +--
hw/net/eepro100.c | 4 +---
hw/net/igb.c| 3 +--
hw/nvme/ctrl.c | 3 +--
hw/pci-bridge/pcie_pci_bridge.c | 2 +-
hw/vfio/pci.c
doesn't enable the BARs.
Cc: Cédric Le Goater
Signed-off-by: Alex Williamson
---
hw/vfio/pci.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index ba4ef65b16fa..fcc5f118bf90 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/
On Thu, 20 Feb 2025 11:45:35 +0100
Eric Auger wrote:
> Hi Alex,
>
> On 2/20/25 11:31 AM, Eric Auger wrote:
> >
> > Hi Alex,
> >
> > On 2/19/25 10:19 PM, Alex Williamson wrote:
> >> On Wed, 19 Feb 2025 11:58:44 -0700
> >> Alex Williamso
On Thu, 20 Feb 2025 08:07:23 -0700
Alex Williamson wrote:
> On Thu, 20 Feb 2025 11:45:35 +0100
> Eric Auger wrote:
>
> > Hi Alex,
> >
> > On 2/20/25 11:31 AM, Eric Auger wrote:
> > >
> > > Hi Alex,
> > >
> > > On 2/19/25 10:
On Thu, 20 Feb 2025 04:24:13 +
"Duan, Zhenzhong" wrote:
> >-Original Message-----
> >From: Alex Williamson
> >Subject: Re: [RFC 0/2] hw/vfio/pci: Prevent BARs from being dma mapped in
> >d3hot state
> >
> >On Wed, 19 Feb 2025 18:58:58 +0100
On Wed, 19 Feb 2025 11:58:44 -0700
Alex Williamson wrote:
> On Wed, 19 Feb 2025 18:58:58 +0100
> Eric Auger wrote:
>
> > Since kernel commit:
> > 2b2c651baf1c ("vfio/pci: Invalidate mmaps and block the access
> > in D3hot power state")
> > any att
On Wed, 19 Feb 2025 18:58:58 +0100
Eric Auger wrote:
> Since kernel commit:
> 2b2c651baf1c ("vfio/pci: Invalidate mmaps and block the access
> in D3hot power state")
> any attempt to do an mmap access to a BAR when the device is in d3hot
> state will generate a fault.
>
> On system_powerdown, if
e MSI interrupts (DEBUG)");
> +object_class_property_set_description(klass, /* 2.5 */
> + "x-no-kvm-msix",
> + "Disable direct VFIO->KVM MSIx
> injection. Allows to "
> +
On Fri, 14 Feb 2025 15:34:15 +0100
Cédric Le Goater wrote:
> Investigate the git history to uncover when and why the VFIO
> properties were introduced and update the models. This is mostly
> targeting vfio-pci device, since vfio-platform, vfio-ap and vfio-ccw
> devices are simpler.
>
> Sort the
On Thu, 13 Feb 2025 14:50:50 +0100
Cédric Le Goater wrote:
> Investigate the git history to uncover when and why the VFIO
> properties were introduced and update the models. This is mostly
> targeting vfio-pci device, since vfio-plateform, vfio-ap and vfio-ccw
> devices are simpler.
>
> Organize
| 3 ---
> hw/vfio/common.c | 40 +--
> hw/vfio/container.c | 2 --
> hw/vfio/helpers.c | 10 +++++
> hw/vfio/pci.c | 2 +-
> util/error.c | 11 ++
> 8 files changed, 64 insertions(+), 17 deletions(-)
>
Reviewed-by: Alex Williamson
On Thu, 6 Feb 2025 13:13:39 +0100
Corvin Köhne wrote:
> From: Corvin Köhne
>
> We've recently imported the PCI ID list of knwon Intel GPU devices from
> Linux. It allows us to properly match GPUs to their generation without
> maintaining an own list of PCI IDs.
>
> Signed-off-by: Corvin Köhne
On Fri, 31 Jan 2025 14:23:58 +0100
Gerd Hoffmann wrote:
> On Fri, Jan 31, 2025 at 01:42:31PM +0100, Cédric Le Goater wrote:
> > + Gerd for insights regarding vIOMMU support in edk2.
> >
> > > > +static bool vfio_device_check_address_space(VFIODevice *vbasedev,
> > > > Error **errp)
> > > > +{
On Fri, 31 Jan 2025 17:15:01 +
Shivaprasad G Bhat wrote:
> Currently, the PCI_INTERRUPT_PIN alone is checked before enabling
> the INTx. Its also necessary to have the IRQ Lines assigned for
> the INTx to work. So, check the PCI_INTERRUPT_LINE against 0xff
> indicates no connection.
>
> The
On Fri, 31 Jan 2025 02:33:03 +0800
Tomita Moeko wrote:
> On 1/25/25 15:42, Tomita Moeko wrote:
> > On 1/25/25 05:13, Alex Williamson wrote:
> >> On Sat, 25 Jan 2025 03:12:45 +0800
> >> Tomita Moeko wrote:
> >>
> >>> Both enable opregion
On Thu, 30 Jan 2025 14:43:45 +0100
Cédric Le Goater wrote:
> Print a warning if IOMMU address space width is smaller than the
> physical address width. In this case, PCI peer-to-peer transactions on
> BARs are not supported and failures of device MMIO regions are to be
> expected.
>
> This can o
On Thu, 30 Jan 2025 14:43:38 +0100
Cédric Le Goater wrote:
> Depending on the configuration, a passthrough device may produce
> recurring DMA mapping errors at runtime and produce a lot of
> output. It is useful to report only once.
>
> Cc: Markus Armbruster
> Signed-off-by: Cédric Le Goater
>
On Sat, 25 Jan 2025 03:12:45 +0800
Tomita Moeko wrote:
> Both enable opregion option (x-igd-opregion) and legacy mode require
> setting up OpRegion copy for IGD devices. Move x-igd-opregion handler
> in vfio_realize() to vfio_probe_igd_config_quirk() to elimate duplicate
> code. Finally we moved
On Thu, 23 Jan 2025 01:17:30 +0800
Tomita Moeko wrote:
> The actual IO BAR4 write quirk in vfio_probe_igd_bar4_quirk() was
> removed in previous change, leaving the function not matching its name,
> so move it into the newly introduced vfio_config_quirk_setup(). There
> is no functional change in
On Thu, 16 Jan 2025 17:53:55 +0800
Wencheng Yang wrote:
> On confidential VM platform, for example, AMD-SEV, P2P doesn't work.
> The underlying reason is that IOMMU driver set encryption bit on
> IOMMU page table pte entry, it's reasonalbe if the pte maps iova
> to system memory. However, if the
igd.c| 125 +++
> hw/vfio/pci-quirks.c | 57 +++-
> hw/vfio/pci-quirks.h | 72 +
> 3 files changed, 109 insertions(+), 145 deletions(-)
> create mode 100644 hw/vfio/pci-quirks.h
>
Reviewed-by: Alex Williamson
EN8_GGMS_SHIFT) & IGD_GMCH_GEN8_GGMS_MASK;
> if (ggms != 0) {
> - ggms = 1 << ggms;
> +ggms = 1ULL << ggms;
> }
> }
>
Reviewed-by: Alex Williamson
On Tue, 7 Jan 2025 13:43:49 -0500
Rorie Reyes wrote:
> This patch series creates and registers a handler that is called when
> userspace is notified by the kernel that a guest's AP configuration has
> changed. The handler in turn notifies the guest that its AP configuration
> has changed. This a
On Tue, 31 Dec 2024 23:19:52 +0800
Tomita Moeko wrote:
> Device may only expose a specific portion of PCI config space through a
> region in a BAR, such behavior is seen in igd GGC and BDSM mirrors in
> BAR0. To handle these, config_offset is introduced to allow mirroring
> arbitrary region in PC
On Tue, 31 Dec 2024 23:19:53 +0800
Tomita Moeko wrote:
> With the introduction of config_offset field, VFIOConfigMirrorQuirk can
> now be used for those mirrored register in igd bar0. This eliminates
> the need for the macro intoduced in 1a2623b5c9e7 ("vfio/igd: add macro
> for declaring mirrored
igd: fix GTT stolen memory size calculation for gen 8+" to
> the first.
> Link:
> https://lore.kernel.org/qemu-devel/20241205105535.30498-1-tomitamo...@gmail.com/
Series:
Reviewed-by: Alex Williamson
tel.com/content/www/us/en/content-details/330835
>
> Reported-By: Alex Williamson
> Signed-off-by: Tomita Moeko
> ---
> hw/vfio/igd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
This should come before the preceding patch in the series so that we're
no
On Tue, 3 Dec 2024 21:35:45 +0800
Tomita Moeko wrote:
> igd devices have multipe registers mirroring mmio address and pci
> config space, more than a single BDSM register. To support this,
> the read/write functions are made common and a macro is defined to
> simplify the declaration of MemoryRe
On Tue, 3 Dec 2024 21:35:46 +0800
Tomita Moeko wrote:
> The GGC register at 0x50 of pci config space is a mirror of the same
> register at 0x108040 of mmio bar0 [1]. i915 driver also reads that
> register from mmio bar0 instead of config space. As GGC is programmed
> and emulated by qemu, the mm
On Tue, 3 Dec 2024 16:30:56 +
Corvin Köhne wrote:
> On Tue, 2024-12-03 at 21:35 +0800, Tomita Moeko wrote:
> > CAUTION: External Email!!
> > DSM region is likely to store framebuffer in Windows, a small DSM
> > region may cause display issues (e.g. half of the screen is black).
> > By defaul
On Tue, 3 Dec 2024 21:35:42 +0800
Tomita Moeko wrote:
> Add helper functions igd_gtt_memory_size() and igd_stolen_size() for
> calculating GTT stolen memory and Data stolen memory size in bytes,
> and use macros to replace the hardware-related magic numbers for
> better readability.
>
> Signed-
On Tue, 3 Dec 2024 21:35:41 +0800
Tomita Moeko wrote:
> Define the igd device generations according to i915 kernel driver to
> avoid confusion, and adjust comment placement to clearly reflect the
> relationship between ids and devices.
>
> The condition of how GTT stolen memory size is calculat
On Tue, 3 Dec 2024 21:35:39 +0800
Tomita Moeko wrote:
> This patchset extends the support of legacy mode igd passthrough to
> all Intel Gen 11 and 12 devices (including Ice Lake, Jasper Lake,
> Rocket Lake, Alder Lake and Raptor Lake), and emulates GGC register
> in MMIO BAR0 for better compatib
nity checks added via 88c869198aa63
> ("pci: Sanity test minimum downstream LNKSTA") outside of the
> branch to make sure downstream ports always have a valid LNKSTA.
>
> Signed-off-by: Sebastian Ott
> Tested-by: Zhenyu Zhang
> ---
> hw/pci/pcie.c | 12 ++++
>
On Mon, 11 Nov 2024 13:37:56 +0100
Sebastian Ott wrote:
> PCI hotplug for downstream endpoints on arm fails because Linux'
> PCIe hotplug driver doesn't like the QEMU provided LNKSTA:
>
> pcieport :08:01.0: pciehp: Slot(2): Card present
> pcieport :08:01.0: pciehp: Slot(2): Link Up
>
On Sun, 1 Dec 2024 22:11:29 -0700
Alex Williamson wrote:
> On Mon, 2 Dec 2024 00:09:31 +0800
> Tomita Moeko wrote:
>
> > Both intel documentation [1][2] and i915 driver shows GGMS represents
> > GTT stolen memory size in multiple of 1MB, not 2MB starting from gen 8.
&g
On Mon, 2 Dec 2024 00:09:34 +0800
Tomita Moeko wrote:
> Define the igd device generations according to i915 kernel driver to
> avoid confusion, and adjust comment placement to clearly reflect the
> relationship between ids and devices.
>
> Signed-off-by: Tomita Moeko
> ---
> hw/vfio/igd.c | 3
3500:
> -case 0xa000:
> -return -1;
> /* SandyBridge, IvyBridge, ValleyView, Haswell */
> case 0x0100:
> case 0x0400:
Reviewed-by: Alex Williamson
On Mon, 2 Dec 2024 00:09:32 +0800
Tomita Moeko wrote:
> Add helper functions igd_gtt_memory_size() and igd_stolen_size() for
> calculating GTT stolen memory and Data stolen memory size in bytes,
> and use macros to replace the hardware-related magic numbers for
> better readability.
>
> Signed-
On Mon, 2 Dec 2024 00:09:31 +0800
Tomita Moeko wrote:
> Both intel documentation [1][2] and i915 driver shows GGMS represents
> GTT stolen memory size in multiple of 1MB, not 2MB starting from gen 8.
>
> [1]
> https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/3rd-gen-core
On Tue, 12 Nov 2024 22:02:12 +
Juan Pablo Ruiz wrote:
> Some platform devices have large MMIO regions (e.g., GPU reserved memory). For
> certain devices, it's preferable to have a 1:1 address translation in the VM
> to
> avoid modifying driver source code.
Why do we need 1:1 mappings? Shou
uint32_t gmch)
> if (gms < 0xf0)
> return gms * 32;
> else
> - return gms * 4 + 4;
> +return (gms - 0xf0) * 4 + 4;
> }
> }
>
Reviewed-by: Alex Williamson
; +case 0x3e00:
> +return 9;
> /* ElkhartLake */
> case 0x4500:
> return 11;
Reviewed-by: Alex Williamson
On Wed, 23 Oct 2024 14:44:19 +0200
Cédric Le Goater wrote:
> On 10/22/24 22:08, Alex Williamson wrote:
> > Thanks to work by Peter Xu, support is introduced in Linux v6.12 to
> > allow pfnmap insertions at PMD and PUD levels of the page table. This
> > means that provid
Move error handling code to the end of the function so that it can more
easily be shared by new mmap failure conditions. No functional change
intended.
Signed-off-by: Alex Williamson
---
hw/vfio/helpers.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions
pping level sizes, therefore this takes the simple approach
to align the mapping to the power-of-two size of the region, up to 1GiB,
which is currently the maximum alignment we care about.
Cc: Peter Xu
Signed-off-by: Alex Williamson
---
hw/vfio/helpers.c | 32 ++--
1
value for mmap, please share.
Thanks,
Alex
Alex Williamson (2):
vfio/helpers: Refactor vfio_region_mmap() error handling
vfio/helpers: Align mmaps
hw/vfio/helpers.c | 66 +--
1 file changed, 47 insertions(+), 19 deletions(-)
--
2.46.2
On Sat, 21 Sep 2024 00:14:40 -0700
Zhi Wang wrote:
> To support CXL device passthrough, vfio-cxl-core is introduced. This
> is the QEMU part.
>
> Get the CXL caps from the vfio-cxl-core. Trap and emulate the HDM
> decoder registers. Map the HDM decdoers when the guest commits a HDM
> decoder.
I
gt; hw/vfio/igd.c| 185 +--
> hw/vfio/pci-quirks.c | 1 +
> hw/vfio/pci.h | 1 +
> 3 files changed, 161 insertions(+), 26 deletions(-)
>
LGTM, for series
Reviewed-by: Alex Williamson
On Thu, 22 Aug 2024 13:08:29 +0200
Corvin Köhne wrote:
> The BDSM register is mirrored into MMIO space at least for gen 11 and
> later devices. Unfortunately, the Windows driver reads the register
> value from MMIO space instead of PCI config space for those devices [1].
> Therefore, we either h
On Tue, 13 Aug 2024 20:37:24 -0300
Jason Gunthorpe wrote:
> On Tue, Aug 13, 2024 at 03:03:20PM -0600, Alex Williamson wrote:
>
> > How does the guest know to write a remappable vector format? How does
> > the guest know the host interrupt architecture? For example why wo
On Tue, 13 Aug 2024 13:43:41 -0300
Jason Gunthorpe wrote:
> On Mon, Aug 12, 2024 at 11:00:40AM -0600, Alex Williamson wrote:
> > These devices have an embedded interrupt controller which is programmed
> > with guest physical MSI address/data, which doesn't work. We need
On Tue, 13 Aug 2024 11:35:15 -0400
Peter Xu wrote:
> On Mon, Aug 12, 2024 at 02:37:59PM -0400, Steven Sistare wrote:
> > On 8/8/2024 2:32 PM, Steven Sistare wrote:
> > > On 7/29/2024 8:29 AM, Igor Mammedov wrote:
> > > > On Sat, 20 Jul 2024 16:28:25 -0400
> > > > Steven Sistare wrote:
> > >
On Sat, 20 Jul 2024 12:15:27 -0700
Steve Sistare wrote:
> Do not map VFIO PCI BARs for DMA. This stops a raft of warnings of the
> following form at QEMU start time when using -object iommufd:
>
> qemu-kvm: warning: IOMMU_IOAS_MAP failed: Bad address, PCI BAR?
> qemu-kvm: vfio_container_dma_map
uires interrupt remapping support in
the host.
NB. The #define for the new vfio feature is temporary for RFC/RFT, a
formal proposal will include a proper linux-headers update.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216055
Signed-off-by: Alex Williamson
---
hw/vfio/pci-quirks.c
On Tue, 9 Jul 2024 13:58:53 -0700
Steve Sistare wrote:
> Enable vfio-pci devices to be saved and restored across a cpr-exec of qemu.
>
> At vfio creation time, save the value of vfio container, group, and device
> descriptors in CPR state.
>
> In the container pre_save handler, suspend the use
On Fri, 5 Jul 2024 17:08:49 +0800 (CST)
tugouxp <13824125...@163.com> wrote:
> Hi folks:
>
>
> I have a questions about device vfio pass-through usage snarios,
> PCI device pass-throug for example. did the GPA that host physical
> memory mapped to Guest vcpu through MMU must be identical wi
1 - 100 of 2766 matches
Mail list logo
