Greetings Alex, > Sent: Saturday, August 29, 2020 at 3:44 PM > From: "daggs" <da...@gmx.com> > To: "daggs" <da...@gmx.com> > Cc: "Alex Williamson" <alex.william...@redhat.com>, vfio-users@redhat.com > Subject: Re: [vfio-users] pci passthrough of Intel igp > > forgot the link https://dpaste.com/H2RPE9GEX > > > Sent: Saturday, August 29, 2020 at 3:42 PM > > From: "daggs" <da...@gmx.com> > > To: "Alex Williamson" <alex.william...@redhat.com> > > Cc: vfio-users@redhat.com > > Subject: Re: [vfio-users] pci passthrough of Intel igp > > > > Greetings Alex, > > > > > Sent: Friday, August 28, 2020 at 9:11 AM > > > From: "daggs" <da...@gmx.com> > > > To: "Alex Williamson" <alex.william...@redhat.com> > > > Cc: vfio-users@redhat.com > > > Subject: Re: [vfio-users] pci passthrough of Intel igp > > > > > > Greetings Alex, > > > > > > > Sent: Friday, August 28, 2020 at 1:46 AM > > > > From: "Alex Williamson" <alex.william...@redhat.com> > > > > To: "daggs" <da...@gmx.com> > > > > Cc: "Patrick O'Callaghan" <p...@usb.ve>, vfio-users@redhat.com > > > > Subject: Re: [vfio-users] pci passthrough of Intel igp > > > > > > > > On Thu, 27 Aug 2020 23:17:52 +0200 > > > > daggs <da...@gmx.com> wrote: > > > > > > > > > Greetings Alex, > > > > > > > > > > > Sent: Wednesday, August 26, 2020 at 8:02 PM > > > > > > From: "Alex Williamson" <alex.william...@redhat.com> > > > > > > To: "daggs" <da...@gmx.com> > > > > > > Cc: "Patrick O'Callaghan" <p...@usb.ve>, vfio-users@redhat.com > > > > > > Subject: Re: [vfio-users] pci passthrough of Intel igp > > > > > > > > > > > > On Wed, 26 Aug 2020 07:27:59 +0200 > > > > > > daggs <da...@gmx.com> wrote: > > > > > > > > > > > > > Greetings Alex, > > > > > > > > > > > > > > > Sent: Wednesday, August 26, 2020 at 12:54 AM > > > > > > > > From: "Alex Williamson" <alex.william...@redhat.com> > > > > > > > > To: "daggs" <da...@gmx.com> > > > > > > > > Cc: "Patrick O'Callaghan" <p...@usb.ve>, vfio-users@redhat.com > > > > > > > > Subject: Re: [vfio-users] pci passthrough of Intel igp > > > > > > > > > > > > > > > > On Tue, 25 Aug 2020 23:34:48 +0200 > > > > > > > > daggs <da...@gmx.com> wrote: > > > > > > > > > > > > > > > > > Greetings Alex, > > > > > > > > > > > > > > > > > > > Sent: Wednesday, August 12, 2020 at 8:04 PM > > > > > > > > > > From: "Alex Williamson" <alex.william...@redhat.com> > > > > > > > > > > To: "Patrick O'Callaghan" <p...@usb.ve> > > > > > > > > > > Cc: vfio-users@redhat.com, "daggs" <da...@gmx.com> > > > > > > > > > > Subject: Re: [vfio-users] pci passthrough of Intel igp > > > > > > > > > > > > > > > > > > > > On Wed, 12 Aug 2020 17:46:33 +0100 > > > > > > > > > > "Patrick O'Callaghan" <p...@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@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. > > > > > unfortunately UPT ends up in the three DMAR errors above and a black > > > > > screen. > > > > > > > > > > > > > > > > > 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. > > > > > it doesn't have a bios section afaics: > > > > > Valid ROM signature found @0h, PCIR offset 40h > > > > > PCIR: type 0 (x86 PC-AT), vendor: 8086, device: 0406, class: > > > > > 030000 > > > > > PCIR: revision 3, vendor revision: 0 > > > > > Last image > > > > > > > > That is a BIOS image, an UEFI image would be type 3 (EFI). Note this > > > > image is for device ID 0406 where you initially indicated you were > > > > using 5902, so I assume you haven't run the fixer on this image. > > > > > > > > > > so it looks like I need to fight the bios, looks like this means war :) > > > actually, I did, I ran the parser on the original image as I assumed the > > > fixer changes more than these two values, see: > > > $ rom-parser/rom-parser vga.rom > > > Valid ROM signature found @0h, PCIR offset 40h > > > PCIR: type 0 (x86 PC-AT), vendor: 8086, device: 5902, class: > > > 030000 > > > PCIR: revision 3, vendor revision: 0 > > > Last image > > > > > > Thanks, > > > > > > Dagg. > > > > I've tried with legacy, still getting the same behavior like in uefi boot > > (including the errors in dmesg), here is the joint output of dmesg, lspci > > -nnk and the legacy xml of the vm. > > I've booted the system in legacy, extracted the vga rom and fixed the did. > > > > help will be appreciated. > > > > Thanks. > > > > Dagg. > >
got it to work, I'm using qemu 5.0.0, I think the issue is that the igd quirks are missing. after applying this commit: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=643a4eacef87a318c I see the vm's output on the screen. can this bug affect vms booting the vm in uefi? (q35+ovmf) Thanks, Dagg. _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
