linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Jason Wang <jasowang@redhat.com>,
	Joerg Roedel <joro@8bytes.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jens Axboe <axboe@kernel.dk>,
	virtualization@lists.linux-foundation.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, jfehlig@suse.com,
	jon.grimm@amd.com, brijesh.singh@amd.com
Subject: Re: [PATCH 0/3] Fix virtio-blk issue with SWIOTLB
Date: Tue, 15 Jan 2019 14:09:22 +0100	[thread overview]
Message-ID: <20190115130922.GB28364@lst.de> (raw)
In-Reply-To: <20190114153004-mutt-send-email-mst@kernel.org>

On Mon, Jan 14, 2019 at 03:48:47PM -0500, Michael S. Tsirkin wrote:
> I think you are exaggerating a little here.  Limited access with e.g.
> need to flush caches is common on lower end but less common on higher
> end systems used for virtualization.  As you point out that changes with
> e.g. SEV but then SEV is a pretty niche thing so far.
> 
> So I would make that a SHOULD probably.

The problem is that without using DMA ops you can't just plug the device
into a random system, which is a total no-go for periphals.

And cache flushing is not that uncommmon, e.g. every sparc systems
needs it, many arm/arm64 ones, some power ones, lots of mips ones, etc.

But cache flushing is just one side of it - lots of systems have either
mandatory or option IOMMUs, and without the platform access flag that
doesn't work.  As does that case where you have a DMA offset, which
is extremly common on arm and power systems.  So you might find a few
non-x86 systems you can plug it in and it'll just work, but it won't
be all that many.  And even on x86 your device will be completely broken
if the users dares to use an IOMMU.

> > flags really needs some major updates in terms of DMA access.
> 
> Thanks for the reminder. Yes generally spec tends to still say e.g.
> "physical address" where it really means a "DMA address" in Linux terms.
> Whether changing that will make things much clearer I'm not sure. E.g.
> hardware designers don't much care I guess.

At least say bus address - as said above the CPU and bus concepts of
physicall addresses are different in many systems.  Including x86
when you use IOMMUs.

  reply	other threads:[~2019-01-15 13:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10 13:44 [PATCH 0/3] Fix virtio-blk issue with SWIOTLB Joerg Roedel
2019-01-10 13:44 ` [PATCH 1/3] swiotlb: Export maximum allocation size Joerg Roedel
2019-01-10 17:02   ` Konrad Rzeszutek Wilk
2019-01-11  9:12     ` Joerg Roedel
2019-01-14 20:49       ` Konrad Rzeszutek Wilk
2019-01-14 21:59         ` Michael S. Tsirkin
2019-01-15 13:05           ` Christoph Hellwig
2019-01-10 13:44 ` [PATCH 2/3] virtio: Introduce virtio_max_dma_size() Joerg Roedel
2019-01-10 13:44 ` [PATCH 3/3] virtio-blk: Consider virtio_max_dma_size() for maximum segment size Joerg Roedel
2019-01-10 13:59 ` [PATCH 0/3] Fix virtio-blk issue with SWIOTLB Christoph Hellwig
2019-01-10 14:26   ` Joerg Roedel
2019-01-11  3:29 ` Jason Wang
2019-01-11  9:15   ` Joerg Roedel
2019-01-14  9:41     ` Jason Wang
2019-01-14  9:50       ` Christoph Hellwig
2019-01-14 12:41         ` Jason Wang
2019-01-14 18:20           ` Michael S. Tsirkin
2019-01-14 19:09             ` Singh, Brijesh
2019-01-14 19:12             ` Robin Murphy
2019-01-14 20:22               ` Christoph Hellwig
2019-01-14 20:29               ` Michael S. Tsirkin
2019-01-14 20:19             ` Christoph Hellwig
2019-01-14 20:48               ` Michael S. Tsirkin
2019-01-15 13:09                 ` Christoph Hellwig [this message]
2019-01-15  8:37             ` Joerg Roedel
2019-01-15 13:20               ` Christoph Hellwig
2019-01-16 14:16                 ` 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=20190115130922.GB28364@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=brijesh.singh@amd.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=jfehlig@suse.com \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.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).