From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Thiago Jung Bauermann <bauerman@linux.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: Mike Anderson <andmike@linux.ibm.com>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
Jason Wang <jasowang@redhat.com>,
Alexey Kardashevskiy <aik@linux.ibm.com>,
Ram Pai <linuxram@us.ibm.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
Christoph Hellwig <hch@lst.de>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Date: Tue, 16 Jul 2019 09:24:06 +1000 [thread overview]
Message-ID: <d5b4f80db724da9d7571b614be76dd8b2b57432e.camel@kernel.crashing.org> (raw)
In-Reply-To: <8736j7neg8.fsf@morokweng.localdomain>
On Mon, 2019-07-15 at 19:03 -0300, Thiago Jung Bauermann wrote:
> > > Indeed. The idea is that QEMU can offer the flag, old guests can
> > > reject
> > > it (or even new guests can reject it, if they decide not to
> > > convert into
> > > secure VMs) and the feature negotiation will succeed with the
> > > flag
> > > unset.
> >
> > OK. And then what does QEMU do? Assume guest is not encrypted I
> > guess?
>
> There's nothing different that QEMU needs to do, with or without the
> flag. the perspective of the host, a secure guest and a regular guest
> work the same way with respect to virtio.
This is *precisely* why I was against adding a flag and touch the
protocol negociation with qemu in the first place, back when I cared
about that stuff...
Guys, this has gone in circles over and over again.
This has nothing to do with qemu. Qemu doesn't need to know about this.
It's entirely guest local. This is why the one-liner in virtio was a
far better and simpler solution.
This is something the guest does to itself (with the participation of a
ultravisor but that's not something qemu cares about at this stage, at
least not as far as virtio is concerned).
Basically, the guest "hides" its memory from the host using a HW secure
memory facility. As a result, it needs to ensure that all of its DMA
pages are bounced through insecure pages that aren't hidden. That's it,
it's all guest side. Qemu shouldn't have to care about it at all.
Cheers,
Ben.
prev parent reply other threads:[~2019-07-15 23:26 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87zhrj8kcp.fsf@morokweng.localdomain>
2019-01-29 17:42 ` [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted Thiago Jung Bauermann
2019-01-29 19:02 ` Michael S. Tsirkin
2019-01-30 2:24 ` Jason Wang
2019-01-30 2:36 ` Michael S. Tsirkin
2019-01-30 3:05 ` Jason Wang
2019-01-30 3:26 ` Michael S. Tsirkin
2019-01-30 7:44 ` Christoph Hellwig
2019-02-04 18:15 ` Thiago Jung Bauermann
2019-02-04 21:38 ` Michael S. Tsirkin
2019-02-05 7:24 ` Christoph Hellwig
2019-02-05 16:13 ` Michael S. Tsirkin
2019-03-26 16:53 ` Michael S. Tsirkin
2019-02-04 18:14 ` Thiago Jung Bauermann
2019-02-04 20:23 ` Michael S. Tsirkin
2019-03-20 16:13 ` Thiago Jung Bauermann
2019-03-20 21:17 ` Michael S. Tsirkin
2019-03-22 0:05 ` Thiago Jung Bauermann
2019-03-23 21:01 ` Michael S. Tsirkin
2019-03-25 0:57 ` David Gibson
2019-04-17 21:42 ` Thiago Jung Bauermann
2019-04-17 21:42 ` Thiago Jung Bauermann
2019-04-19 23:09 ` Michael S. Tsirkin
2019-04-25 1:01 ` Thiago Jung Bauermann
2019-04-25 1:18 ` Michael S. Tsirkin
2019-04-26 23:56 ` Thiago Jung Bauermann
2019-05-20 13:08 ` Michael S. Tsirkin
2019-05-20 13:16 ` Michael S. Tsirkin
2019-06-04 1:13 ` Thiago Jung Bauermann
2019-06-04 1:42 ` Michael S. Tsirkin
2019-06-28 1:58 ` Thiago Jung Bauermann
2019-07-01 14:17 ` Michael S. Tsirkin
2019-07-14 5:51 ` Thiago Jung Bauermann
2019-07-15 14:35 ` Michael S. Tsirkin
2019-07-15 20:29 ` Thiago Jung Bauermann
2019-07-15 20:36 ` Michael S. Tsirkin
2019-07-15 22:03 ` Thiago Jung Bauermann
2019-07-15 22:16 ` Michael S. Tsirkin
2019-07-15 23:05 ` Thiago Jung Bauermann
2019-07-15 23:24 ` Benjamin Herrenschmidt [this message]
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=d5b4f80db724da9d7571b614be76dd8b2b57432e.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=aik@linux.ibm.com \
--cc=andmike@linux.ibm.com \
--cc=bauerman@linux.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jasowang@redhat.com \
--cc=jean-philippe.brucker@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=mdroth@linux.vnet.ibm.com \
--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).