All of lore.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 <linux-kernel@vger.kernel.org>,
	"Miller, Mike (OS Dev)" <mike.miller@hp.com>
Subject: Re: [PATCH] intel-iommu: Fix alloc_coherent for pass-through devices
Date: Thu, 22 Oct 2009 09:01:16 -0600	[thread overview]
Message-ID: <1256223676.3615.68.camel@8530w.home> (raw)
In-Reply-To: <1256222867.2990.47.camel@macbook.infradead.org>

On Thu, 2009-10-22 at 23:47 +0900, David Woodhouse wrote:
> On Thu, 2009-10-22 at 06:24 -0600, Alex Williamson wrote:
> > The coherent_dma_mask is independent of the dma_mask and can be set
> > separately by the device.  The default for any device that doesn't
> > specify one is 32bits.  iommu_should_identity_map() only checks the
> > dma_mask, not the coherent_dma_mask. 
> 
> Are you telling me that this particular device supports only a 32-bit
> coherent DMA mask, but that it _does_ support a 64-bit DMA mask for
> non-coherent DMA? On x86?

Yes, yes.  AFAIK, this is not that exceptional.

> >  BTW, we skip RMRR setup when doing hardware pass-through, but I can't
> > find where they get reloaded if we then end up removing the device
> > from the si_domain.  Is this another issue?
> 
> Maybe, theoretically. In practice, the whole RMRR thing is just broken
> by design anyway. We have to quiesce the offending devices before we
> turn on the IOMMU, because BIOSes tend to leave things out of the RMRR
> table... and then crash in SMM mode when their DMA goes AWOL. 

Hmm, we've had a lot of trouble getting our RMRRs to reflect shared
memory regions correctly, so I'm reluctant to just drop them like that.

Another issue, iommu_should_identity_map() only dumps devices if their
dma_mask is 32bit or less, but being greater than 32bits does not imply
64bit DMA support.  If the device exports a DMA mask that's less than
the physical address width of the processor, you might be in trouble
(for example, a 40bit dma_mask on a platform that supports 44bits for
physical memory).  Maybe dropping swiotlb out of the picture isn't such
a clean solution?  Thanks,

Alex



  parent reply	other threads:[~2009-10-22 15:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-22  3:41 [PATCH] intel-iommu: Fix alloc_coherent for pass-through devices Alex Williamson
2009-10-22  6:28 ` David Woodhouse
2009-10-22 12:24   ` Alex Williamson
2009-10-22 14:47     ` David Woodhouse
2009-10-22 15:00       ` FUJITA Tomonori
2009-10-22 15:01       ` Alex Williamson [this message]
2009-10-22 15:49         ` David Woodhouse
2009-11-03 23:57           ` Andrew Morton
2009-11-04  4:51             ` Alex Williamson
2009-10-22 15:49 ` David Woodhouse

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=1256223676.3615.68.camel@8530w.home \
    --to=alex.williamson@hp.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.miller@hp.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.