All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Cc: "joonas.lahtinen@linux.intel.com"
	<joonas.lahtinen@linux.intel.com>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"zhenyuw@linux.intel.com" <zhenyuw@linux.intel.com>,
	"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Intel-gfx] [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu
Date: Thu, 13 Apr 2017 08:53:12 -0600	[thread overview]
Message-ID: <20170413085312.4f4fa028@t450s.home> (raw)
In-Reply-To: <8082FF9BCB2B054996454E47167FF4EC1C4BDCC8@SHSMSX104.ccr.corp.intel.com>

On Thu, 13 Apr 2017 05:44:18 +0000
"Zhang, Xiong Y" <xiong.y.zhang@intel.com> wrote:

> > On Wed, 12 Apr 2017 20:20:00 +0800
> > Xiong Zhang <xiong.y.zhang@intel.com> 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,

Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>
Subject: Re: [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu
Date: Thu, 13 Apr 2017 08:53:12 -0600	[thread overview]
Message-ID: <20170413085312.4f4fa028@t450s.home> (raw)
In-Reply-To: <8082FF9BCB2B054996454E47167FF4EC1C4BDCC8@SHSMSX104.ccr.corp.intel.com>

On Thu, 13 Apr 2017 05:44:18 +0000
"Zhang, Xiong Y" <xiong.y.zhang@intel.com> wrote:

> > On Wed, 12 Apr 2017 20:20:00 +0800
> > Xiong Zhang <xiong.y.zhang@intel.com> 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,

Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-04-13 14:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05  2:08 [PATCH V4] drm/i915: Enhanced disable access to stolen memory as a guest Xiong Zhang
2017-04-05  2:19 ` ✓ Fi.CI.BAT: success for drm/i915: Enhanced disable access to stolen memory as a guest (rev4) Patchwork
2017-04-05  6:50 ` [PATCH V4] drm/i915: Enhanced disable access to stolen memory as a guest Daniel Vetter
2017-04-05  6:50   ` Daniel Vetter
2017-04-05  7:44   ` [Intel-gfx] " Jani Nikula
2017-04-12 12:20 ` [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu Xiong Zhang
2017-04-12 12:20   ` Xiong Zhang
2017-04-12 13:21   ` Joonas Lahtinen
2017-04-13  4:15     ` Zhang, Xiong Y
2017-04-13  4:15       ` Zhang, Xiong Y
2017-04-13  7:23     ` Tian, Kevin
2017-04-13  7:23       ` Tian, Kevin
2017-04-12 18:01   ` [Intel-gfx] " Alex Williamson
2017-04-12 18:01     ` Alex Williamson
2017-04-13  5:44     ` [Intel-gfx] " Zhang, Xiong Y
2017-04-13 14:53       ` Alex Williamson [this message]
2017-04-13 14:53         ` Alex Williamson
2017-04-14  6:39         ` [Intel-gfx] " Zhang, Xiong Y
2017-04-18 11:26           ` Gerd Hoffmann
2017-04-12 12:32 ` ✓ Fi.CI.BAT: success for drm/i915: Enhanced disable access to stolen memory as a guest (rev5) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170413085312.4f4fa028@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=xiong.y.zhang@intel.com \
    --cc=zhenyuw@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.