[vfio-users] pci passthrough of Intel igp

Wed Aug 26 17:32:10 UTC 2020

I was able to finally get mine working reliably, display will initialize
and show content even after shutting down VM and rebooting the VM.  Not
unplugging / replugging of the HDMI cable necessary.

Using up to date arch with qemu and libvirt.  Machine is booting in EFI.

The QEMU command line is:

qemu-system-x86_64 -monitor telnet:127.0.0.1:1234,server,nowait -enable-kvm
-machine q35 -cpu host -smp 3 -nographic -vga none -m 2G -device
vfio-pci,host=00:02.0,rombar=0 -device vfio-pci,host=00:0e.0 -drive
if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd -drive
if=pflash,format=raw,file=/home/admin/myvars.fd -net nic -drive
file=/home/admin/kodi_drive.img,if=virtio,format=raw

Hardware is an Odroid N2.  CPU is Intel(R) Celeron(R) J4105 and GPU is UHD
Graphics 605 [8086:3185].

The mkinitcpio.conf file needed to be changed in accordance with the Arch
VFIO passthrough page.

Kernel command line options:
root=PARTLABEL=Arch_root quiet rw ipv6.disable=1 intel_iommu=on iommu=pt
vfio-pci.ids=8086:3185,8086:3198 video=efifb:off,vesafb:off
module_blacklist=i915,snd_hda_intel,snd

No blacklisting files in /etc/modprobe.d

Note that it did not work when the video= line had vesafb:off was before
the efifb:off.  Switching them to call efifb:off first made everything work
like a charm.  If other people are still having problems, one command I
found very useful was to check iomem to find things that might still be
binding the device:

sudo cat /proc/iomem

On Wed, Aug 26, 2020 at 10:03 AM Alex Williamson <alex.williamson at redhat.com>
wrote:
>
> 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
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20200826/a112d4e2/attachment.htm>