From: Christoph Hellwig <hch@lst.de>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>, Christoph Hellwig <hch@lst.de>,
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: Mon, 14 Jan 2019 21:19:35 +0100 [thread overview]
Message-ID: <20190114201935.GA10781@lst.de> (raw)
In-Reply-To: <20190114131114-mutt-send-email-mst@kernel.org>
On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote:
> I don't think so - the issue is really that DMA API does not yet handle
> the SEV case 100% correctly. I suspect passthrough devices would have
> the same issue.
The DMA API handles the SEV case perfectly. Its just that virtio_blk
supports huge segments that virtio does not generally support, but that
is not related to SEV in any way.
> In fact whoever sets IOMMU_PLATFORM is completely unaffected by
> Christoph's pet peeve.
No, the above happens only when we set IOMMU_PLATFORM.
> Christoph is saying that !IOMMU_PLATFORM devices should hide the
> compatibility code in a special per-device DMA API implementation.
> Which would be fine especially if we can manage not to introduce a bunch
> of indirect calls all over the place and hurt performance. It's just
> that the benefit is unlikely to be big (e.g. we can't also get rid of
> the virtio specific memory barriers) so no one was motivated enough to
> work on it.
No. The problem is that we still haven't fully specified what
IOMMU_PLATFORM and !IOMMU_PLATFORM actually mean. Your
"ACCESS_PLATFORM/ORDER_PLATFORM" commit in the virtio-spec repo
improves it a little bit, but it is still far from enough.
As a start VIRTIO_F_ORDER_PLATFORM and VIRTIO_F_ACCESS_PLATFORM
absolutely MUST be set for hardware implementations. Otherwise said
hardware has no chance of working on anything but the most x86-like
systems.
Second software implementations SHOULD set VIRTIO_F_ACCESS_PLATFORM,
because otherwise we can't add proper handling for things like SEV or
the IBM "secure hypervisor" thing.
Last but not least a lot of wording outside the area describing these
flags really needs some major updates in terms of DMA access.
next prev parent reply other threads:[~2019-01-14 20:19 UTC|newest]
Thread overview: 56+ 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 ` Joerg Roedel
2019-01-10 13:44 ` [PATCH 1/3] swiotlb: Export maximum allocation size Joerg Roedel
2019-01-10 13:44 ` Joerg Roedel
2019-01-10 13:44 ` Joerg Roedel
2019-01-10 17:02 ` Konrad Rzeszutek Wilk
2019-01-10 17:02 ` Konrad Rzeszutek Wilk
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 20:49 ` Konrad Rzeszutek Wilk
2019-01-14 21:59 ` Michael S. Tsirkin
2019-01-15 13:05 ` Christoph Hellwig
2019-01-15 13:05 ` Christoph Hellwig
2019-01-14 21:59 ` Michael S. Tsirkin
2019-01-11 9:12 ` Joerg Roedel
2019-01-10 13:44 ` [PATCH 2/3] virtio: Introduce virtio_max_dma_size() Joerg Roedel
2019-01-10 13:44 ` 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:44 ` Joerg Roedel
2019-01-10 13:59 ` [PATCH 0/3] Fix virtio-blk issue with SWIOTLB Christoph Hellwig
2019-01-10 13:59 ` Christoph Hellwig
2019-01-10 14:26 ` Joerg Roedel
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:41 ` Jason Wang
2019-01-14 9:50 ` Christoph Hellwig
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:22 ` Christoph Hellwig
2019-01-14 20:29 ` Michael S. Tsirkin
2019-01-14 20:29 ` Michael S. Tsirkin
2019-01-14 19:12 ` Robin Murphy
2019-01-14 20:19 ` Christoph Hellwig [this message]
2019-01-14 20:48 ` Michael S. Tsirkin
2019-01-15 13:09 ` Christoph Hellwig
2019-01-15 13:09 ` Christoph Hellwig
2019-01-14 20:48 ` Michael S. Tsirkin
2019-01-14 20:19 ` Christoph Hellwig
2019-01-15 8:37 ` Joerg Roedel
2019-01-15 13:20 ` Christoph Hellwig
2019-01-15 13:20 ` Christoph Hellwig
2019-01-16 14:16 ` Michael S. Tsirkin
2019-01-16 14:16 ` Michael S. Tsirkin
2019-01-15 8:37 ` Joerg Roedel
2019-01-14 18:20 ` Michael S. Tsirkin
2019-01-14 12:41 ` Jason Wang
2019-01-11 9:15 ` Joerg Roedel
2019-01-11 3:29 ` Jason Wang
-- strict thread matches above, loose matches on Subject: below --
2019-01-10 13:44 Joerg Roedel
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=20190114201935.GA10781@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 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.