linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: "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: Mon, 03 Jun 2019 22:13:59 -0300	[thread overview]
Message-ID: <877ea26tk8.fsf@morokweng.localdomain> (raw)
In-Reply-To: <20190520090939-mutt-send-email-mst@kernel.org>



Michael S. Tsirkin <mst@redhat.com> writes:

> On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
>> I rephrased it in terms of address translation. What do you think of
>> this version? The flag name is slightly different too:
>>
>>
>> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same
>>     meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set,
>>     with the exception that address translation is guaranteed to be
>>     unnecessary when accessing memory addresses supplied to the device
>>     by the driver. Which is to say, the device will always use physical
>>     addresses matching addresses used by the driver (typically meaning
>>     physical addresses used by the CPU) and not translated further. This
>>     flag should be set by the guest if offered, but to allow for
>>     backward-compatibility device implementations allow for it to be
>>     left unset by the guest. It is an error to set both this flag and
>>     VIRTIO_F_ACCESS_PLATFORM.
>
>
> OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged
> drivers. This is why devices fail when it's not negotiated.

Just to clarify, what do you mean by unprivileged drivers? Is it drivers
implemented in guest userspace such as with VFIO? Or unprivileged in
some other sense such as needing to use bounce buffers for some reason?

> This confuses me.
> If driver is unpriveledged then what happens with this flag?
> It can supply any address it wants. Will that corrupt kernel
> memory?

Not needing address translation doesn't necessarily mean that there's no
IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's
always an IOMMU present. And we also support VFIO drivers. The VFIO API
for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls
to program the IOMMU.

For our use case, we don't need address translation because we set up an
identity mapping in the IOMMU so that the device can use guest physical
addresses.

If the guest kernel is concerned that an unprivileged driver could
jeopardize its integrity it should not negotiate this feature flag.
Perhaps there should be a note about this in the flag definition? This
concern is platform-dependant though. I don't believe it's an issue in
pseries.

--
Thiago Jung Bauermann
IBM Linux Technology Center


  reply	other threads:[~2019-06-04  1:15 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 [this message]
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

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=877ea26tk8.fsf@morokweng.localdomain \
    --to=bauerman@linux.ibm.com \
    --cc=aik@linux.ibm.com \
    --cc=andmike@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).