iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Linda Knippers <linda.knippers-VXdhtT5mjnY@public.gmane.org>
Cc: chegu_vinod-VXdhtT5mjnY@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] iommu/intel: Exclude devices using RMRRs from IOMMU API domains
Date: Wed, 21 May 2014 18:09:52 +0100	[thread overview]
Message-ID: <1400692192.13839.101.camel@shinybook.infradead.org> (raw)
In-Reply-To: <537CDCC2.6020209-VXdhtT5mjnY@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 1208 bytes --]

On Wed, 2014-05-21 at 13:05 -0400, Linda Knippers wrote:
> 
> > Exactly, I have a hard time bringing myself to care about supporting
> > such devices.  Vendors that proliferate RMRR usage need to be aware of
> > the implications of RMRRs for all use cases of a device.  First and
> > foremost, we need to lock out devices with RMRRs because we have no
> > ability to either honor or disable RMRRs when used by the IOMMU API.  If
> > vendors that rely on RMRRs want to make such devices assignable by
> > providing interfaces to describe and map the area into a VM, or even a
> > mechanism to disable the RMRR, more power to them.  The current
> > situation is simply unsafe and needs to be prevented.  
> 
> I care but I think this patch should go in until there is a better
> solution.

I was quite happy with our earlier "solution" of just assuming that
RMRRs were a boot-time thing only. Once a driver takes over the device,
or it's given to a guest, we forget the RMRRs entirely. The hardware has
no business still doing rogue DMA after we've taken control of it.

Again, it's only those who stupidly designed hardware who suffer. And
life was a lot simpler for us.

-- 
dwmw2


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



      parent reply	other threads:[~2014-05-21 17:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14 19:27 [PATCH] iommu/intel: Exclude devices using RMRRs from IOMMU API domains Alex Williamson
     [not found] ` <20140514192620.7767.43842.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2014-05-21 10:38   ` David Woodhouse
     [not found]     ` <1400668716.13839.66.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org>
2014-05-21 13:20       ` Alex Williamson
     [not found]         ` <1400678426.3289.396.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-05-21 17:05           ` Linda Knippers
     [not found]             ` <537CDCC2.6020209-VXdhtT5mjnY@public.gmane.org>
2014-05-21 17:09               ` David Woodhouse [this message]

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=1400692192.13839.101.camel@shinybook.infradead.org \
    --to=dwmw2-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
    --cc=chegu_vinod-VXdhtT5mjnY@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linda.knippers-VXdhtT5mjnY@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).