linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mst@redhat.com (Michael S. Tsirkin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] virtio: Try to untangle DMA coherency
Date: Thu, 9 Feb 2017 20:49:41 +0200	[thread overview]
Message-ID: <20170209203752-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170209183118.GI19397@arm.com>

On Thu, Feb 09, 2017 at 06:31:18PM +0000, Will Deacon wrote:
> On Thu, Feb 09, 2017 at 08:17:16PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote:
> > > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote:
> > > > I am inclined to say, for 4.10 let's revert
> > > > c7070619f3408d9a0dffbed9149e6f00479cf43b since what it fixes is not a
> > > > regression in 4.10.
> > > 
> > > No complaints there, as long as we can keep working to fix this for 4.11
> > > and onwards. You'll also need to cc stable on the revert.
> > > 
> > > > So I think we can defer the fix to 4.11.
> > > > I think we still want f7f6634d23830ff74335734fbdb28ea109c1f349
> > > > for hosts with virtio 1 support.
> > > > 
> > > > All this will hopefully push hosts to just implement virtio 1.
> > > > For mmio the changes are very small: several new registers,
> > > > that's all. You want this for proper 64 bit dma mask anyway.
> > > 
> > > As I've said, virtio 1 will have exactly the same issue unless we start
> > > requiring firmware to advertise dma-coherent/_CCA for virtio-mmio
> > > devices correctly.
> > > 
> > 
> > OK I read up on _CCA in ACPI spec. It says:
> > The _CCA object returns whether or not a bus-master device supports
> > hardware managed cache coherency. Expected values are 0 to indicate it
> > is not supported, and 1 to indicate that it is supported.
> > 
> > So if host is cache coherent, and guest thinks it isn't, we incur
> > unnecessary overhead by wasting coherent memory.
> > I get that but you said it actually breaks - why does it?
> 
> It breaks because QEMU doesn't set _CCA for virtio-mmio devices, and that
> only becomes a problem when we use the DMA API, because that results in the
> guest taking out a non-cacheable mapping. On ARM (and other archs such as
> Power), having a mismatch between a cacheable and a non-cacheable mapping
> can result in a loss of coherency between the two (for example, if the
> non-cacheable gues accesses bypass the cache, but the cacheable host
> accesses allocate in the cache).
> 
> Will

I see. And I guess using a cacheable mapping is significantly faster.
I would say we want to typically use cacheable for virtio then,
whether we bypass the IOMMU or not. I guess this is why we always set
_CCA/DT correctly, right?

-- 
MST

  reply	other threads:[~2017-02-09 18:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 12:25 [PATCH] virtio: Try to untangle DMA coherency Robin Murphy
2017-02-01 14:57 ` Will Deacon
2017-02-01 17:58   ` Rob Herring
2017-02-01 18:09 ` Michael S. Tsirkin
2017-02-01 18:27   ` Will Deacon
2017-02-01 19:19     ` Michael S. Tsirkin
2017-02-02 11:26       ` Will Deacon
2017-02-02 13:34         ` Robin Murphy
2017-02-02 16:16           ` Michael S. Tsirkin
2017-02-02 16:39             ` Marc Zyngier
2017-02-02 16:44               ` Michael S. Tsirkin
2017-02-02 16:30           ` Michael S. Tsirkin
2017-02-02 16:40             ` Will Deacon
2017-02-02 16:45               ` Michael S. Tsirkin
2017-02-09 18:17               ` Michael S. Tsirkin
2017-02-09 18:31                 ` Will Deacon
2017-02-09 18:49                   ` Michael S. Tsirkin [this message]
2017-02-09 18:54                     ` Ard Biesheuvel
2017-02-09 18:56                     ` Will Deacon
2017-02-10 17:16                   ` Michael S. Tsirkin
2017-02-13 11:57                     ` Will Deacon
2017-02-08 12:58       ` Alexander Graf
2017-02-09 20:57         ` Michael S. Tsirkin
2017-02-09 22:20           ` Alexander Graf

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=20170209203752-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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).