RE: [Intel-gfx] [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Thu, 13 Apr 2017 05:44:18 +0000
> "Zhang, Xiong Y" <xiong.y.zhang@xxxxxxxxx> wrote:
> 
> > > On Wed, 12 Apr 2017 20:20:00 +0800
> > > Xiong Zhang <xiong.y.zhang@xxxxxxxxx> wrote:
> > >
> > > > Stolen memory isn't a standard pci resource and exists in RMRR which
> has
> > > > identity mapping in iommu table, IGD could access stolen memory in
> host
> > > OS.
> > > > While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude
> devices
> > > using
> > > > RMRRs from IOMMU API domains")',RMRR isn't supported by kvm, then
> > > both EPT
> > > > and guest iommu domain table lack of maaping for stolen memory in
> kvm
> > > IGD
> > > > passthrough environment. If IGD access stolen memory in such
> environment,
> > > > many iommu exceptions exist in host dmesg and gpu hang exists also.
> > > > DMAR: [DMA Read] Request device [00:02.0] fault addr da012000
> > > > [fault reason 05] PTE Write access is not set
> > > > DMAR: [DMA Read] Request device [00:02.0] fault addr da2df000
> > > > [fault reason 06] PTE Read access is not set
> > > >
> > > > So stolen memory should be disabled in KVM IGD passthrough
> environment,
> > > > this patch detects such environment through the existence of qemu
> > > emulated
> > > > isa bridge.
> > > >
> > > > When the real ISA bridge is also passed through to guest, guest will have
> > > > two isa bridges: emulated and real. Qemu guarantees the
> busnum:devnum.
> > > > funcnum of emulated isa bridge is always less than the real one. Then
> > > > emulated isa bridge is always detected first by pci_get_class(ISA). So
> > > > stolen memory will be disabled in this case also.
> > >
> > > Where does QEMU make this guarantee or any sort of guarantee wrt the
> > > ISA bridge?  Thanks,
> > >
> > > Alex
> > >
> > [Zhang, Xiong Y] In my guest environment I always see emulated devices
> > are at head of pci device list, the passed through devices are at tail. Even if
> > I want to assign the passed IGD to 00:02.0, the qemu tell me 00:02.0 has
> already
> > occupied by emulated graphic card.
> > If I pass through real ISA bridge to guest, the emulated ISA bridge is at
> 00:01.0,
> > While real ISA bridge is at 00:04.0.
> > Then I checked the code: emulated devices are created in pc_init1() function,
> it
> > creates host_bridge firstly, create isa_bridge secondly, create all other
> devices following.
> > So I think Qemu could guarantee. Now I'm suspect it, and need your coach.
> 
> So you're calling the current default behavior a guarantee.  That's not
> valid, it ignores that we might have future chipsets that do things
> differently and it ignores that the user can override some of those
> defaults and specify addresses for devices that may not match your
> expectations.  There is no agreement with the QEMU community to make
> this a stable feature of the VM.  What about using smbios information
> or detecting kvm (or any hypervisor) via the hypervisor MSRs?  You could
> maybe use the VM PCI host bridge and figure out that this version of
> IGD never shipped on 440fx or q35, but then you'll have the maintenance
> headache of updating the code for any new chipset QEMU decides to
> implement. Thanks,
> 
[Zhang, Xiong Y] Thanks for your teach and propose.
For smbios, could you teach me which type and field could be used ?
For hypervisor MSRs, from https://www.kernel.org/doc/Documentation/virtual/kvm/msr.txt,
We should use cupid(0x40000001) first, then use rdmsr(), in this case we could use
cupid(0x40000000) directly to detect kvm. But I don't know whether community could accept
it or not ?

> Alex



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]