All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Xiong Zhang <xiong.y.zhang@intel.com>,
	kevin.tian@intel.com, daniel.vetter@intel.com,
	zhenyuw@linux.intel.com, jani.nikula@linux.intel.com,
	alex.williamson@redhat.com, David Woodhouse <dwmw2@infradead.org>,
	"Bloomfield, Jon" <jon.bloomfield@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm
Date: Tue, 25 Apr 2017 15:06:43 +0300	[thread overview]
Message-ID: <1493122003.3731.27.camel@linux.intel.com> (raw)
In-Reply-To: <1493116501-29327-1-git-send-email-xiong.y.zhang@intel.com>

+ David and Jon

On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:

The blocking issue I see is that bisecting is still not pointing at
relevant commits. Both bisected commits from Bugzilla are not related
to changes in stolen memory usage behavior. I'd assume a successful
bisect to land at the patches where we start creating kernel internal
objects from stolen memory. Otherwise we could be ignoring a bug
elsewhere. If it consistently lands on those patches, then there might
be something wrong with them, in addition to stolen memory problems.

Disabling power saving makes many bugs go away, but we still don't
disable power saving as a resolution to such bugs, but instead root
cause and fix the individual bugs.

> Stolen memory isn't a standard pci resource and exists in RMRR which has
> identity mapping in iommu table when host boot up, so 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.

Commit message text still fails to address that an exclusion was added
by commit:

commit 18436afdc11a00ac881990b454cfb2eae81d6003
Author: David Woodhouse <David.Woodhouse@intel.com>
Date:   Wed Mar 25 15:05:47 2015 +0000

    iommu/vt-d: Allow RMRR on graphics devices too

    Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API
    domains") prevents certain options for devices with RMRRs. This even
    prevents those devices from getting a 1:1 mapping with 'iommu=pt',
    because we don't have the code to handle *preserving* the RMRR regions
    when moving the device between domains.

<SNIP>

The quoted part of David's commit message leads me to believe it's
simply lack of some code in kernel for juggling the RMRRs when moving a
device between domains that is missing. Why is not that considered
instead? With that implemented, we would have more transparent pass-
through, which should be good.

Also, was fixing the IGD driver loading with zero stolen memory
considered instead? All this information should exist in the commit
message.

After the bisecting is properly done, there is an agreement that
suggested RMRR preservation is absolutely a no-go, other options are
not viable, the commit message should be updated to reflect all that.
Then we should look in more detail on how to detect the scenarios when
we're running in a virtual machine that doesn't set up the 1:1 mapping
for RMRRs.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

WARNING: multiple messages have this Message-ID (diff)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Xiong Zhang <xiong.y.zhang@intel.com>,
	kevin.tian@intel.com, daniel.vetter@intel.com,
	zhenyuw@linux.intel.com, jani.nikula@linux.intel.com,
	alex.williamson@redhat.com, David Woodhouse <dwmw2@infradead.org>,
	"Bloomfield, Jon" <jon.bloomfield@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm
Date: Tue, 25 Apr 2017 15:06:43 +0300	[thread overview]
Message-ID: <1493122003.3731.27.camel@linux.intel.com> (raw)
In-Reply-To: <1493116501-29327-1-git-send-email-xiong.y.zhang@intel.com>

+ David and Jon

On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:

The blocking issue I see is that bisecting is still not pointing at
relevant commits. Both bisected commits from Bugzilla are not related
to changes in stolen memory usage behavior. I'd assume a successful
bisect to land at the patches where we start creating kernel internal
objects from stolen memory. Otherwise we could be ignoring a bug
elsewhere. If it consistently lands on those patches, then there might
be something wrong with them, in addition to stolen memory problems.

Disabling power saving makes many bugs go away, but we still don't
disable power saving as a resolution to such bugs, but instead root
cause and fix the individual bugs.

> Stolen memory isn't a standard pci resource and exists in RMRR which has
> identity mapping in iommu table when host boot up, so 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.

Commit message text still fails to address that an exclusion was added
by commit:

commit 18436afdc11a00ac881990b454cfb2eae81d6003
Author: David Woodhouse <David.Woodhouse@intel.com>
Date:   Wed Mar 25 15:05:47 2015 +0000

    iommu/vt-d: Allow RMRR on graphics devices too

    Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API
    domains") prevents certain options for devices with RMRRs. This even
    prevents those devices from getting a 1:1 mapping with 'iommu=pt',
    because we don't have the code to handle *preserving* the RMRR regions
    when moving the device between domains.

<SNIP>

The quoted part of David's commit message leads me to believe it's
simply lack of some code in kernel for juggling the RMRRs when moving a
device between domains that is missing. Why is not that considered
instead? With that implemented, we would have more transparent pass-
through, which should be good.

Also, was fixing the IGD driver loading with zero stolen memory
considered instead? All this information should exist in the commit
message.

After the bisecting is properly done, there is an agreement that
suggested RMRR preservation is absolutely a no-go, other options are
not viable, the commit message should be updated to reflect all that.
Then we should look in more detail on how to detect the scenarios when
we're running in a virtual machine that doesn't set up the 1:1 mapping
for RMRRs.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2017-04-25 12:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-25 10:34 [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm Xiong Zhang
2017-04-25 11:42 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-04-25 12:06 ` Joonas Lahtinen [this message]
2017-04-25 12:06   ` [PATCH V6] " Joonas Lahtinen
2017-04-27  5:54   ` Zhang, Xiong Y
2017-05-05  9:14     ` Joonas Lahtinen
     [not found]   ` <8082FF9BCB2B054996454E47167FF4EC1C4D0CAA@SHSMSX104.ccr.corp.intel.com>
2017-05-03  9:22     ` Zhang, Xiong Y
2017-05-03  9:22       ` Zhang, Xiong Y
2017-05-05  9:21       ` Joonas Lahtinen
2017-05-05  9:21         ` Joonas Lahtinen
2017-05-06  2:58         ` Zhang, Xiong Y
2017-05-08 10:07           ` Joonas Lahtinen
2017-05-08 10:07             ` Joonas Lahtinen
2017-05-08 15:01             ` Alex Williamson

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=1493122003.3731.27.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=daniel.vetter@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jon.bloomfield@intel.com \
    --cc=kevin.tian@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.