public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 4/5] intel-iommu: Reinstate RMRRs if a device is removed from passthrough domain
Date: Wed, 28 Oct 2009 14:35:42 -0600	[thread overview]
Message-ID: <1256762142.5937.151.camel@bling> (raw)
In-Reply-To: <1256746015.5937.128.camel@bling>

On Wed, 2009-10-28 at 10:06 -0600, Alex Williamson wrote:
> On Wed, 2009-10-28 at 14:36 +0000, David Woodhouse wrote:
> > On Tue, 2009-10-27 at 09:50 -0600, Alex Williamson wrote:
> > > 
> > > Yes, good point.  I'm not seeing any convenient ways to setup a new
> > > domain for a device while it's still a member of the si_domain.  It
> > > looks like I'd need to extract parts of the get_valid_domain_for_dev()
> > > path and ignore any bits about using the already existing domain.
> > 
> > That seems like a sane plan. That code wants cleaning up anyway, and
> > factoring out the 'make new domain' part of get_valid_domain_for_dev()
> > should be simple enough.
> 
> Ok, I'll work on something along those lines.  FWIW, even though I sent
> these as a series, each one stands on it's own.  While I think
> reinstating RMRRs is the right thing to do, I don't know of any devices
> that break with the current model (the device I know of with the
> interesting RMRR usage shouldn't be demoted from the si_domain).  So
> please consider pushing patches 2, 3 & 5 upstream (particularly 2).

On IRC David brought up that VT-d requires a context entry to be marked
not present before it can be changed, making a seamless transition for
devices with RMRRs impossible.  This really makes devices with RMRRs
difficult to deal with, and I'm not sure what we can do with them other
than warn when we might hit problems and prevent them from being moved
to a VM domain.  The patch below does that, though I fear we may be
tweaking what devices we white-list for a while.  Comments?  Thanks,

Alex

commit db9778445a5347a817263db60bfb432f235411ba
Author: Alex Williamson <alex.williamson@hp.com>
Date:   Wed Oct 28 14:10:56 2009 -0600

    intel-iommu: warn/prevent operations on devices with RMRRs
    
    RMRRs throw a wrench in our ability to change VT-d domain mapping since
    they may be used for side-band platform purposes and we cannot switch
    domain mappings seamlessly.  RMRRs for USB devices are typical, but
    anything else is likely suspect.  Provide a warning when such devices
    are removed from an identity map and prevent them from being assigned
    to a VM.
    
    Signed-off-by: Alex Williamson <alex.williamson@hp.com>

diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index aa19d75..45f3485 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -49,6 +49,7 @@
 
 #define IS_GFX_DEVICE(pdev) ((pdev->class >> 16) == PCI_BASE_CLASS_DISPLAY)
 #define IS_ISA_DEVICE(pdev) ((pdev->class >> 8) == PCI_CLASS_BRIDGE_ISA)
+#define IS_USB_DEVICE(pdev) ((pdev->class >> 8) == PCI_CLASS_SERIAL_USB)
 #define IS_AZALIA(pdev) ((pdev)->vendor == 0x8086 && (pdev)->device == 0x3a3e)
 
 #define IOAPIC_RANGE_START	(0xfee00000)
@@ -2517,6 +2518,25 @@ static int iommu_dummy(struct pci_dev *pdev)
 	return pdev->dev.archdata.iommu == DUMMY_DEVICE_DOMAIN_INFO;
 }
 
+static int device_has_rmrr(struct pci_dev *pdev)
+{
+	struct dmar_rmrr_unit *rmrr;
+	int i;
+
+	/*
+	 * USB devices do typically have RMRRs for DOS
+	 * compatibility, but can typically be ignored.
+	 */
+	if (IS_USB_DEVICE(pdev))
+		return 0;
+
+	for_each_rmrr_units(rmrr)
+		for (i = 0; i < rmrr->devices_cnt; i++)
+			if (pdev == rmrr->devices[i])
+				return 1;
+	return 0;
+}
+
 /* Check if the pdev needs to go through non-identity map and unmap process.*/
 static int iommu_no_mapping(struct device *dev)
 {
@@ -2546,6 +2566,13 @@ static int iommu_no_mapping(struct device *dev)
 			domain_remove_one_dev_info(si_domain, pdev);
 			printk(KERN_INFO "%s uses non-identity mapping\n",
 			       pci_name(pdev));
+
+			if (device_has_rmrr(pdev))
+				printk(KERN_WARNING
+				       "IOMMU: Warning RMRRs for %s not mapped\n",
+				       pci_name(pdev));
+
+
 			return 0;
 		}
 	} else {
@@ -3544,6 +3571,13 @@ static int intel_iommu_attach_device(struct iommu_domain *domain,
 	int addr_width;
 	u64 end;
 
+	if (device_has_rmrr(pdev)) {
+		printk(KERN_WARNING
+		       "IOMMU: Device %s requires RMRRs, cannot be attached\n",
+		       pci_name(pdev));
+		return -EBUSY;
+	}
+	
 	/* normally pdev is not mapped */
 	if (unlikely(domain_context_mapped(pdev))) {
 		struct dmar_domain *old_domain;




  reply	other threads:[~2009-10-28 20:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-26 23:24 [PATCH 0/5] intel-iommu fixes Alex Williamson
2009-10-26 23:24 ` [PATCH 1/5] dma: create dma_generic_alloc/free_coherent() Alex Williamson
2009-10-27  0:57   ` Paul Mundt
2009-10-27  2:26     ` Alex Williamson
2009-10-27  1:47   ` FUJITA Tomonori
2009-10-26 23:25 ` [PATCH 2/5] intel-iommu: Use dma_generic_alloc_coherent() for passthrough mappings Alex Williamson
2009-10-27  3:24   ` [PATCH v2 2/5] intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthrough Alex Williamson
2009-10-26 23:25 ` [PATCH 3/5] intel-iommu: Use max_pfn to determine whether a device can passthrough Alex Williamson
2009-10-26 23:25 ` [PATCH 4/5] intel-iommu: Reinstate RMRRs if a device is removed from passthrough domain Alex Williamson
2009-10-27  8:15   ` David Woodhouse
2009-10-27 15:50     ` Alex Williamson
2009-10-28 14:36       ` David Woodhouse
2009-10-28 16:06         ` Alex Williamson
2009-10-28 20:35           ` Alex Williamson [this message]
2009-10-26 23:25 ` [PATCH 5/5] intel-iommu: Quiet unnecessary output 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=1256762142.5937.151.camel@bling \
    --to=alex.williamson@hp.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.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