Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Alex Williamson <alex.williamson@redhat.com>]

On Tue, 2016-02-02 at 00:04 +0000, Kay, Allen M wrote:
> 
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Sunday, January 31, 2016 9:42 AM
> > To: Kay, Allen M; Gerd Hoffmann; David Woodhouse
> > Cc: igvt-g@ml01.01.org; xen-devel@lists.xensource.com; Eduardo Habkost;
> > Stefano Stabellini; qemu-devel@nongnu.org; Cao jin; vfio-
> > users@redhat.com
> > Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> > tweaks
> > 
> > On Sat, 2016-01-30 at 01:18 +0000, Kay, Allen M wrote:
> > > 
> > > > -----Original Message-----
> > > > From: iGVT-g [mailto:igvt-g-bounces@lists.01.org] On Behalf Of Alex
> > > > Williamson
> > > > Sent: Friday, January 29, 2016 10:00 AM
> > > > To: Gerd Hoffmann
> > > > Cc: igvt-g@ml01.01.org; xen-devel@lists.xensource.com; Eduardo
> > > > Habkost; Stefano Stabellini; qemu-devel@nongnu.org; Cao jin; vfio-
> > > > users@redhat.com
> > > > Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough
> > > > chipset tweaks
> > > > 
> > > > Do guest drivers depend on IGD appearing at 00:02.0?  I'm currently
> > > > testing for any Intel VGA device, but I wonder if I should only be
> > > > enabling anything opregion if it also appears at a specific address.
> > > > 
> > > 
> > > No.  Both Windows and Linux IGD driver should work at any PCI slot.  We
> > have seen 0:5.0 in the guest and the driver works.
> > 
> > Thanks Allen.  Another question, when I boot a VM with an assigned HD
> > P4000 GPU, my console stream with IOMMU faults, like:
> > 
> > DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa30000
> > DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa30000
> > DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa30000
> > DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa30000
> > DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa30000
> > 
> > All of these fall within the host RMRR range for the device:
> > 
> > DMAR: Setting RMRR:
> > DMAR: Setting identity map for device 0000:00:02.0 [0x9f800000 - 0xaf9fffff]
> 
> Hi Alex,
> 
> Do you configure IGD as primary or secondary display in your KVM setup?   If primary, are you running Intel vBIOS as part of guest boot?
> 
> On BDW/SKL systems, we have started to configure IGD as secondary and QEMU VGA and primary.  In this setup, we are no longer running vBIOS in the guest which avoids some complications.  vBIOS uses
> stolen memory for display buffers which requires RMRR mapping.  We have been using similar setup (IGD as secondary) on other hypervisors and have not seen IOMMU faults.
> 
> I will setup a KVM configuration on my SKL and see if I can duplicate your problem here.   I will try to call into Don's Thursday meeting to discuss this (I'm on call for jury duty this week).  I
> will give you a heads up on Wednesday evening.

Hi Allen,

I'm currently trying to run as primary, but I don't get any output until
well into the guest boot, so clearly the Intel vBIOS is not happy,
regardless of whether I provide VGA region access.  When I try to run as
secondary I don't get any output at all on the assigned device and the
FC23 Live CD I'm booting doesn't appear to see the IGD output.  I've
only just started playing with actually using it though, so perhaps I
haven't dialed it in just yet.  I will note though that the DMAR faults
are well after the vBIOS would have been run, I see the i915 driver
reads the stolen memory base from config register 0x5c.  Emulating this
register as returning 0x0 avoids the DMAR faults and fixes corruption of
the framebuffer, so this doesn't appear to be exclusive to the vBIOS.

Regardless of which we intend to support, device assignment is an
advanced topic for most users and I think we need to do something to
protect users from having their VM memory stomped on by an IGD device
writing framebuffer data over RAM.  Thanks,

Alex