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 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 Thu, 10 Apr 2025 15:04:35 -0700
Sean Christopherson wrote:
> On Thu, Apr 10, 2025, Alex Williamson wrote:
> > The "token" terminology seems a little out of place after all is said
> > and done in this series.
>
> Ugh, yeah, good point. I don't know why
On Fri, 4 Apr 2025 14:14:45 -0700
Sean Christopherson wrote:
> diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
> index 9bdb2a781841..379725b9a003 100644
> --- a/include/linux/irqbypass.h
> +++ b/include/linux/irqbypass.h
> @@ -10,6 +10,7 @@
>
> #include
>
> +struct eventf
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 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 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 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 Thu, 20 Mar 2025 23:24:49 +0530
Shivaprasad G Bhat wrote:
> On 3/18/25 11:28 PM, Alex Williamson wrote:
> > On Tue, 18 Mar 2025 17:29:21 +
> > Shivaprasad G Bhat wrote:
> >
> >> On POWER systems, when the device is behind the io expander,
> &g
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
8aa3bf.alex.william...@redhat.com/
>
> Signed-off-by: Shivaprasad G Bhat
> Suggested-By: Alex Williamson
> ---
> drivers/vfio/pci/vfio_pci_core.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_
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
On Sun, 2 Mar 2025 18:27:23 +0200
Yishai Hadas wrote:
> With a functional and tested backend for virtio-block live migration,
> add the virtio-block device ID to the pci_device_id table.
>
> Currently, the driver supports legacy IO functionality only for
> virtio-net, and it is accounted for in
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 Wed, 26 Feb 2025 13:51:17 +0200
Yishai Hadas wrote:
> On 26/02/2025 10:06, Tian, Kevin wrote:
> >> From: Yishai Hadas
> >> Sent: Monday, February 24, 2025 8:19 PM
> >>
> >> config VIRTIO_VFIO_PCI
> >> - tristate "VFIO support for VIRTIO NET PCI VF devices"
> >> + tristate "VFIO support fo
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 Mon, 6 Jan 2025 13:47:50 -0600
Shawn Anastasio wrote:
> Hi all,
>
> Just wanted to check in and let the community know that Raptor
> Engineering will be officially dedicating development resources towards
> maintaining, developing, and testing the existing Linux KVM facilities
> for PowerNV m
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
; >
> > Signed-off-by: Philipp Stanner
>
> Not applied yet, pending ack from Alex.
Acked-by: Alex Williamson
>
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 2 +-
> > drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
> > 2 files changed, 6 ins
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 Wed, 13 Nov 2024 13:51:53 +0200
Yishai Hadas wrote:
> This series enhances the vfio-virtio driver to support live migration
> for virtio-net Virtual Functions (VFs) that are migration-capable.
Applied to vfio next branch for v6.13. Thanks,
Alex
On Wed, 13 Nov 2024 13:51:58 +0200
Yishai Hadas wrote:
> diff --git a/drivers/vfio/pci/virtio/migrate.c
> b/drivers/vfio/pci/virtio/migrate.c
> new file mode 100644
> index ..a0ce3ec2c734
> --- /dev/null
> +++ b/drivers/vfio/pci/virtio/migrate.c
...
> +static int virtiovf_add_migratio
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
On Tue, 12 Nov 2024 10:37:27 +0200
Yishai Hadas wrote:
> diff --git a/drivers/vfio/pci/virtio/migrate.c
> b/drivers/vfio/pci/virtio/migrate.c
> new file mode 100644
> index ..3d5eaa1cbcdb
> --- /dev/null
> +++ b/drivers/vfio/pci/virtio/migrate.c
...
> +static int virtiovf_add_migratio
On Mon, 11 Nov 2024 15:30:47 +
Joao Martins wrote:
> On 11/11/2024 14:17, Yishai Hadas wrote:
> > On 11/11/2024 12:32, Joao Martins wrote:
> > depends on VIRTIO_PCI
> > select VFIO_PCI_CORE
> > select IOMMUFD_DRIVER
>
> IIUC, this is
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 Thu, 7 Nov 2024 14:57:39 +0200
Yishai Hadas wrote:
> On 07/11/2024 0:27, Alex Williamson wrote:
> > On Wed, 6 Nov 2024 09:59:09 -0400
> > Jason Gunthorpe wrote:
> >
> >> On Tue, Nov 05, 2024 at 04:29:04PM -0700, Alex Williamson wrote:
> >>>
On Wed, 6 Nov 2024 04:32:31 -0500
"Michael S. Tsirkin" wrote:
> On Mon, Nov 04, 2024 at 12:21:24PM +0200, Yishai Hadas wrote:
> > This series enhances the vfio-virtio driver to support live migration
> > for virtio-net Virtual Functions (VFs) that are migration-capable.
> >
> > This series foll
On Wed, 6 Nov 2024 09:59:09 -0400
Jason Gunthorpe wrote:
> On Tue, Nov 05, 2024 at 04:29:04PM -0700, Alex Williamson wrote:
> > > @@ -1,7 +1,7 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > config VIRTIO_VFIO_PCI
> > > tristate &
On Wed, 6 Nov 2024 13:16:34 +0200
Yishai Hadas wrote:
> On 06/11/2024 1:18, Alex Williamson wrote:
> > On Mon, 4 Nov 2024 12:21:30 +0200
> > Yishai Hadas wrote:
> >
> >> Add PRE_COPY support for live migration.
> >>
> >> This functionality may
On Wed, 6 Nov 2024 12:21:03 +0200
Yishai Hadas wrote:
> On 06/11/2024 0:47, Alex Williamson wrote:
> > On Mon, 4 Nov 2024 12:21:29 +0200
> > Yishai Hadas wrote:
> >> diff --git a/drivers/vfio/pci/virtio/main.c
> >> b/drivers/vfio/pci/virtio/main.c
> >&g
On Mon, 4 Nov 2024 12:21:31 +0200
Yishai Hadas wrote:
> Now that the driver supports live migration, only the legacy IO
> functionality depends on config VIRTIO_PCI_ADMIN_LEGACY.
>
> Move the legacy IO into a separate file to be compiled only once
> VIRTIO_PCI_ADMIN_LEGACY was configured and let
On Mon, 4 Nov 2024 12:21:30 +0200
Yishai Hadas wrote:
> Add PRE_COPY support for live migration.
>
> This functionality may reduce the downtime upon STOP_COPY as of letting
> the target machine to get some 'initial data' from the source once the
> machine is still in its RUNNING state and let it
On Mon, 4 Nov 2024 12:21:29 +0200
Yishai Hadas wrote:
> diff --git a/drivers/vfio/pci/virtio/main.c b/drivers/vfio/pci/virtio/main.c
> index b5d3a8c5bbc9..e2cdf2d48200 100644
> --- a/drivers/vfio/pci/virtio/main.c
> +++ b/drivers/vfio/pci/virtio/main.c
...
> @@ -485,16 +478,66 @@ static bool virti
On Thu, 31 Oct 2024 15:04:51 +
Parav Pandit wrote:
> > From: Alex Williamson
> > Sent: Wednesday, October 30, 2024 1:58 AM
> >
> > On Mon, 28 Oct 2024 17:46:57 +
> > Parav Pandit wrote:
> >
> > > > From: Alex Williamson
On Wed, 30 Oct 2024 20:54:09 +0800
Yi Liu wrote:
> Hi Alex,
>
> On 2024/10/18 13:40, Yi Liu wrote:
> I think we need to monotonically increase the structure size,
> but maybe something more like below, using flags. The expectation
> would be that if we add another flag that exten
On Mon, 28 Oct 2024 17:46:57 +
Parav Pandit wrote:
> > From: Alex Williamson
> > Sent: Monday, October 28, 2024 10:24 PM
> >
> > On Mon, 28 Oct 2024 13:23:54 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Oct 28, 2024 at 10:13:48AM -06
On Sun, 27 Oct 2024 12:07:44 +0200
Yishai Hadas wrote:
> This series enhances the vfio-virtio driver to support live migration
> for virtio-net Virtual Functions (VFs) that are migration-capable.
What's the status of making virtio-net VFs in QEMU migration capable?
There would be some obvious b
On Mon, 28 Oct 2024 13:23:54 -0300
Jason Gunthorpe wrote:
> On Mon, Oct 28, 2024 at 10:13:48AM -0600, Alex Williamson wrote:
>
> > If the virtio spec doesn't support partial contexts, what makes it
> > beneficial here?
>
> It stil lets the receiver 'wa
1 - 100 of 1263 matches
Mail list logo
