From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: 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 13:20:45 -0500 [thread overview]
Message-ID: <20190114131114-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ac6d83d8-02de-dbdf-e309-3a1115642d50@redhat.com>
On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
>
> On 2019/1/14 下午5:50, Christoph Hellwig wrote:
> > On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
> > > On 2019/1/11 下午5:15, Joerg Roedel wrote:
> > > > On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
> > > > > Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
> > > > > all virtio devices under AMD-SEV guests?
> > > > Yes, that is correct. Emulated DMA can only happen on the SWIOTLB
> > > > aperture, because that memory is not encrypted. The guest bounces the
> > > > data then to its encrypted memory.
> > > >
> > > > Regards,
> > > >
> > > > Joerg
> > >
> > > Thanks, have you tested vhost-net in this case. I suspect it may not work
> > Which brings me back to my pet pevee that we need to take actions
> > that virtio uses the proper dma mapping API by default with quirks
> > for legacy cases. The magic bypass it uses is just causing problems
> > over problems.
>
>
> Yes, I fully agree with you. This is probably an exact example of such
> problem.
>
> Thanks
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.
In fact whoever sets IOMMU_PLATFORM is completely unaffected by
Christoph's pet peeve.
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.
--
MST
next prev parent reply other threads:[~2019-01-14 18:20 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 [this message]
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
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=20190114131114-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=axboe@kernel.dk \
--cc=brijesh.singh@amd.com \
--cc=hch@lst.de \
--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=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).