[vfio-users] pci passthrough of Intel igp

Wed Aug 26 17:02:33 UTC 2020

On Wed, 26 Aug 2020 07:27:59 +0200
daggs <daggs at gmx.com> wrote:

> Greetings Alex,
> 
> > Sent: Wednesday, August 26, 2020 at 12:54 AM
> > From: "Alex Williamson" <alex.williamson at redhat.com>
> > To: "daggs" <daggs at gmx.com>
> > Cc: "Patrick O'Callaghan" <poc at usb.ve>, vfio-users at redhat.com
> > Subject: Re: [vfio-users] pci passthrough of Intel igp
> >
> > On Tue, 25 Aug 2020 23:34:48 +0200
> > daggs <daggs at gmx.com> wrote:
> >  
> > > Greetings Alex,
> > >  
> > > > Sent: Wednesday, August 12, 2020 at 8:04 PM
> > > > From: "Alex Williamson" <alex.williamson at redhat.com>
> > > > To: "Patrick O'Callaghan" <poc at usb.ve>
> > > > Cc: vfio-users at redhat.com, "daggs" <daggs at gmx.com>
> > > > Subject: Re: [vfio-users] pci passthrough of Intel igp
> > > >
> > > > On Wed, 12 Aug 2020 17:46:33 +0100
> > > > "Patrick O'Callaghan" <poc at usb.ve> wrote:
> > > >  
> > > > > On Wed, 2020-08-12 at 18:02 +0200, daggs wrote:  
> > > > > > Greetings,
> > > > > >
> > > > > > I have a machine with an Intel igp of HD Graphics 610 [8086:5902].
> > > > > > I found several discussions on the subject stating that it isn't possible but all of them are several years old.
> > > > > > so I wanted to know if it is possible to pass it to a vm?
> > > > > > I'm using kernel 5.4.43, libvirt-6.6.0 and qemu-5.0.0.  
> > > > >
> > > > > If this is your only GPU, it doesn't make much sense. The idea of
> > > > > passthrough is to let the VM control an additional GPU, not the main
> > > > > one.  
> > > >
> > > > There are plenty of people trying to assign their primary graphics
> > > > device, it makes perfect sense for someone that doesn't intend to run a
> > > > graphical environment on the host.  Assigning the primary GPU can be
> > > > more challenging, but that doesn't mean it isn't done.
> > > >
> > > > For daggs, I can only say try it yourself, I don't know of any specific
> > > > reason it wouldn't work, but direct assignment of IGD is a fair bit of
> > > > luck anyway since the hardware is constantly changing and we don't
> > > > really keep up with it.  You might need to play with the x-igd-gms
> > > > value on the vfio-pci device in QEMU, several people have found that
> > > > x-igd-gms=1 is necessary on some versions of hardware.  Thanks,
> > > >
> > > > Alex
> > > >
> > > >  
> > >
> > > I'm trying to boot the vm up with the igd pass-through, here is my xml: https://dpaste.com/CNDHRLNXC
> > > the boot ends up with no signal and this is visible in dmesg:
> > > [   36.181635] DMAR: DRHD: handling fault status reg 3
> > > [   36.181641] DMAR: [DMA Read] Request device [00:02.0] PASID ffffffff fault addr c6000000 [fault reason 06] PTE Read access is not set
> > > [   36.182298] DMAR: DRHD: handling fault status reg 3
> > > [   36.182304] DMAR: [DMA Read] Request device [00:02.0] PASID ffffffff fault addr c603d000 [fault reason 06] PTE Read access is not set
> > > [   36.183459] DMAR: DRHD: handling fault status reg 3
> > > [   36.183464] DMAR: [DMA Read] Request device [00:02.0] PASID ffffffff fault addr c603e000 [fault reason 06] PTE Read access is not set
> > > [   36.184614] DMAR: DRHD: handling fault status reg 3
> > > [   36.721979] vfio-pci 0000:00:02.0: vfio_ecap_init: hiding ecap 0x1b at 0x100
> > >
> > > I've dumped the rom, do I need to run the fixer on it? if so, what is the vid and did?
> > > than I need to place this <rom file='/home/streamer/vga.rom'/> in the hostdev section?
> > > I've noticed most of the reports say it works only on i440fx but they
> > > are all a few years old, is that still the case?
> > >
> > > as part of this contexts, I have this in the kernel cmdline:
> > > pcie_acs_override=id:8086:a170 does it means device 8086:a170 is
> > > "broken" out of the iommu table?  
> >
> > If you dump the ROM and provide it via a <rom> tag in the xml, then yes
> > you need to fix the device ID and checksum, if QEMU loads it from the
> > device it will do this itself.  You can find the vendor ID (vid) and
> > device ID (did) with 'lspci -nns 0000:00:02.0", they will be the
> > numbers in the last set of brackets, ex: [8086:a170].  They're also
> > available in sysfs under the device:
> >
> > $ cat /sys/bus/pci/devices/0000\:00\:02.0/vendor
> > $ cat /sys/bus/pci/devices/0000\:00\:02.0/device  
> 
> I'll try that and see what happens.
> 
> > Legacy IGD assignment still requires 440FX due to Q35 placing it's own
> > device at a conflicting address to the one needed by IGD.  
> 
> duh, my question wasn't clear enough, figures, not the first time I do it.
> what I meant is do I need Legacy IGD assignment or running the an Q35 machine is enough?
> the host is booting in uefi mode if it matters to the issue on hand.

"It depends".  You're welcome to try Q35 and see if you can get it to
work, but the Legacy mode specifically depends on having an address
on the root bus free which is not available on Q35.  The UPT/Universal
PassThrough mode is largely abandoned by Intel AFAICT.

If your host is booting in UEFI mode then you may not have a BIOS mode
ROM available.  If you're dumping the ROM, run the parser on it to see
if it has a BIOS section.  If not, you might need to boot the host in
non-UEFI mode with a live image and see if you get a different ROM in
that mode.  Legacy IGD mode also depends on SeaBIOS support.

> > The ACS override patch should never be needed for IGD, though it probably tells
> > us the vendor and device IDs that you'd need to patch into the ROM.
> > IGD is always a single function device on the root complex and
> > therefore will always be in its own IOMMU group.  Thanks,  
> 
> once again, my question wasn't clear enough... I'll try better next time.
> the question pver the ACS override patch is related to the sound card (which at the moment I'm not passing to the vm),
> the card is part of the following group:
> IOMMU Group 9 00:1f.0 ISA bridge [0601]: Intel Corporation H110 Chipset LPC/eSPI Controller [8086:a143] (rev 31)
> IOMMU Group 9 00:1f.2 Memory controller [0580]: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller [8086:a121] (rev 31)
> IOMMU Group 9 00:1f.3 Audio device [0403]: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller [8086:a170] (rev 31)
> IOMMU Group 9 00:1f.4 SMBus [0c05]: Intel Corporation 100 Series/C230 Series Chipset Family SMBus [8086:a123] (rev 31)
> 
> when I tried to pass it to the vm, I got an error stating that I need
> to pass all of the devices in the group into the guest. the error
> persisted when I booted the system without that cmd line param. from
> what I understood (which might have been wrong), adding
> pcie_acs_override=id:8086:a170 to the command line params "breaks"
> the sound card away from the iommu group. is that the case?

Sorry, the ACS override patch is not upstream, I don't get involved in
its usage, there are too many variants and possibilities that it's
broken.  Thanks,

Alex