From: Halil Pasic <pasic@linux.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
"Singh, Brijesh" <brijesh.singh@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [PATCH V2] vhost: correctly turn on VIRTIO_F_IOMMU_PLATFORM
Date: Fri, 13 Mar 2020 13:44:46 +0100 [thread overview]
Message-ID: <20200313134446.782c5f7c.pasic@linux.ibm.com> (raw)
In-Reply-To: <20200227104233-mutt-send-email-mst@kernel.org>
[..]
> >
> > CCing Tom. @Tom does vhost-vsock work for you with SEV and current qemu?
> >
> > Also, one can specify iommu_platform=on on a device that ain't a part of
> > a secure-capable VM, just for the fun of it. And that breaks
> > vhost-vsock. Or is setting iommu_platform=on only valid if
> > qemu-system-s390x is protected virtualization capable?
> >
> > BTW, I don't have a strong opinion on the fixes tag. We currently do not
> > recommend setting iommu_platform, and thus I don't think we care too
> > much about past qemus having problems with it.
> >
> > Regards,
> > Halil
>
>
> Let's just say if we do have a Fixes: tag we want to set it correctly to
> the commit that needs this fix.
>
I finally did some digging regarding the performance degradation. For
s390x the performance degradation on vhost-net was introduced by commit
076a93d797 ("exec: simplify address_space_get_iotlb_entry"). Before
IOMMUTLBEntry.addr_mask used to be based on plen, which in turn was
calculated as the rest of the memory regions size (from address), and
covered most of the guest address space. That is we didn't have a whole
lot of IOTLB API overhead.
With commit 076a93d797 I see IOMMUTLBEntry.addr_mask == 0xfff which comes
as ~TARGET_PAGE_MASK from flatview_do_translate(). To have things working
properly I applied 75e5b70e6, b021d1c044, and d542800d1e on the level of
076a93d797 and 076a93d797~1.
Regarding vhost-vsock. It does not work with iommu_platform=on since the
very beginning (i.e. 8607f5c307 ("virtio: convert to use DMA api")). Not
sure if that is a good or a bad thing. (If the vhost driver in the kernel
would actually have to do the IOTLB translation, then failing in case
where it does not support it seems sane. The problem is that
ACCESS_PLATFORM is used for more than one thing (needs translation, and
restricted memory access).)
I don't think I've heard back from AMD whether vsock works with SEV or
not... I don't have access to HW to test it myself.
We (s390) don't require this being backported to the stable qemus,
because for us iommu_platform=on becomes relevant with protected
virtualization, and those qemu versions don't support it.
Cheers,
Halil
next prev parent reply other threads:[~2020-03-13 12:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 9:43 [PATCH V2] vhost: correctly turn on VIRTIO_F_IOMMU_PLATFORM Jason Wang
2020-02-26 9:53 ` Michael S. Tsirkin
2020-02-26 10:17 ` Jason Wang
2020-02-26 11:44 ` Michael S. Tsirkin
2020-02-26 12:50 ` Halil Pasic
2020-02-26 12:55 ` Halil Pasic
2020-02-26 13:45 ` Michael S. Tsirkin
2020-02-26 13:28 ` Halil Pasic
2020-02-26 13:37 ` Michael S. Tsirkin
2020-02-26 15:36 ` Halil Pasic
2020-02-26 16:52 ` Michael S. Tsirkin
2020-02-27 13:02 ` Halil Pasic
2020-02-27 15:47 ` Michael S. Tsirkin
2020-03-03 14:44 ` Halil Pasic
2020-03-13 12:44 ` Halil Pasic [this message]
2020-03-13 15:29 ` Michael S. Tsirkin
2020-03-13 16:31 ` Peter Xu
2020-03-16 16:57 ` Halil Pasic
2020-03-16 17:31 ` Peter Xu
2020-03-16 17:19 ` Michael S. Tsirkin
2020-03-16 18:14 ` Peter Xu
2020-03-17 3:04 ` Jason Wang
2020-03-17 14:13 ` Peter Xu
2020-03-18 2:06 ` Jason Wang
2020-03-17 6:28 ` Michael S. Tsirkin
2020-03-17 14:39 ` Peter Xu
2020-03-17 14:55 ` Michael S. Tsirkin
2020-03-13 20:27 ` Brijesh Singh
2020-03-14 18:22 ` Michael S. Tsirkin
2020-02-27 20:36 ` Tom Lendacky
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=20200313134446.782c5f7c.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=brijesh.singh@amd.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=thomas.lendacky@amd.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 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).