All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Will Deacon <will.deacon@arm.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	pawel.moll@arm.com, virtualization@lists.linux-foundation.org,
	robh+dt@kernel.org, Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [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

WARNING: multiple messages have this Message-ID (diff)
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: 59+ 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 12:25 ` Robin Murphy
2017-02-01 14:57 ` Will Deacon
2017-02-01 14:57   ` Will Deacon
     [not found]   ` <20170201145711.GC8177-5wv7dgnIgG8@public.gmane.org>
2017-02-01 17:58     ` Rob Herring
2017-02-01 17:58       ` Rob Herring
2017-02-01 17:58   ` Rob Herring
     [not found] ` <8a6494f6409c20b4609cd6bdcdd751f68b5c0564.1485951731.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2017-02-01 18:09   ` Michael S. Tsirkin
2017-02-01 18:09     ` Michael S. Tsirkin
2017-02-01 18:27     ` Will Deacon
2017-02-01 18:27       ` Will Deacon
2017-02-01 18:27       ` Will Deacon
2017-02-01 19:19       ` Michael S. Tsirkin
     [not found]       ` <20170201182659.GM8177-5wv7dgnIgG8@public.gmane.org>
2017-02-01 19:19         ` Michael S. Tsirkin
2017-02-01 19:19           ` Michael S. Tsirkin
     [not found]           ` <20170201210648-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-02-02 11:26             ` Will Deacon
2017-02-02 11:26               ` Will Deacon
2017-02-02 13:34               ` Robin Murphy
2017-02-02 13:34                 ` Robin Murphy
2017-02-02 16:16                 ` Michael S. Tsirkin
2017-02-02 16:30                 ` Michael S. Tsirkin
     [not found]                 ` <bb041fbe-3fde-0dc1-ae28-cca5acfe9dc5-5wv7dgnIgG8@public.gmane.org>
2017-02-02 16:16                   ` Michael S. Tsirkin
2017-02-02 16:16                     ` Michael S. Tsirkin
2017-02-02 16:39                     ` Marc Zyngier
     [not found]                     ` <20170202181357-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-02-02 16:39                       ` Marc Zyngier
2017-02-02 16:39                         ` Marc Zyngier
2017-02-02 16:44                         ` Michael S. Tsirkin
     [not found]                         ` <d9732885-7cd2-461c-6812-37581294b47f-5wv7dgnIgG8@public.gmane.org>
2017-02-02 16:44                           ` Michael S. Tsirkin
2017-02-02 16:44                             ` Michael S. Tsirkin
2017-02-02 16:30                   ` Michael S. Tsirkin
2017-02-02 16:30                     ` Michael S. Tsirkin
2017-02-02 16:40                     ` Will Deacon
2017-02-02 16:40                       ` Will Deacon
2017-02-02 16:45                       ` Michael S. Tsirkin
     [not found]                       ` <20170202164049.GI13839-5wv7dgnIgG8@public.gmane.org>
2017-02-02 16:45                         ` Michael S. Tsirkin
2017-02-02 16:45                           ` Michael S. Tsirkin
2017-02-09 18:17                       ` Michael S. Tsirkin
2017-02-09 18:17                         ` Michael S. Tsirkin
2017-02-09 18:31                         ` Will Deacon
2017-02-09 18:31                           ` Will Deacon
2017-02-09 18:49                           ` Michael S. Tsirkin [this message]
2017-02-09 18:49                             ` Michael S. Tsirkin
2017-02-09 18:54                             ` Ard Biesheuvel
2017-02-09 18:54                             ` Ard Biesheuvel
2017-02-09 18:54                               ` Ard Biesheuvel
2017-02-09 18:56                             ` Will Deacon
2017-02-09 18:56                               ` Will Deacon
2017-02-10 17:16                           ` Michael S. Tsirkin
2017-02-10 17:16                             ` Michael S. Tsirkin
2017-02-13 11:57                             ` Will Deacon
2017-02-13 11:57                               ` Will Deacon
2017-02-02 11:26           ` Will Deacon
2017-02-08 12:58           ` Alexander Graf
2017-02-08 12:58             ` Alexander Graf
2017-02-09 20:57             ` Michael S. Tsirkin
2017-02-09 20:57               ` Michael S. Tsirkin
2017-02-09 22:20               ` Alexander Graf
2017-02-09 22:20                 ` Alexander Graf
2017-02-01 18:09 ` Michael S. Tsirkin

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=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will.deacon@arm.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.