[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1570843519-8696-1-git-send-email-linuxram@us.ibm.com>
Date: Fri, 11 Oct 2019 18:25:17 -0700
From: Ram Pai <linuxram@...ibm.com>
To: linux-kernel@...r.kernel.org
Cc: iommu@...ts.linux-foundation.org, linuxppc-dev@...ts.ozlabs.org,
virtualization@...ts.linux-foundation.org,
benh@...nel.crashing.org, david@...son.dropbear.id.au,
mpe@...erman.id.au, paulus@...abs.org, mdroth@...ux.vnet.ibm.com,
aik@...ux.ibm.com, paul.burton@...s.com, robin.murphy@....com,
b.zolnierkie@...sung.com, m.szyprowski@...sung.com, hch@....de,
jasowang@...hat.com, linuxram@...ibm.com, andmike@...ibm.com,
sukadev@...ux.vnet.ibm.com
Subject: [PATCH 0/2] virtio: Support encrypted memory on powerpc secure guests
**We would like the patches to be merged through the virtio tree. Please
review, and ack merging the DMA mapping change through that tree. Thanks!**
The memory of powerpc secure guests can't be accessed by the hypervisor /
virtio device except for a few memory regions designated as 'shared'.
At the moment, Linux uses bounce-buffering to communicate with the
hypervisor, with a bounce buffer marked as shared. This is how the DMA API
is implemented on this platform.
In particular, the most convenient way to use virtio on this platform is by
making virtio use the DMA API: in fact, this is exactly what happens if the
virtio device exposes the flag VIRTIO_F_ACCESS_PLATFORM. However, bugs in the
hypervisor on the powerpc platform do not allow setting this flag, with some
hypervisors already in the field that don't set this flag. At the moment they
are forced to use emulated devices when guest is in secure mode; virtio is
only useful when guest is not secure.
Normally, both device and driver must support VIRTIO_F_ACCESS_PLATFORM:
if one of them doesn't, the other mustn't assume it for communication
to work.
However, a guest-side work-around is possible to enable virtio
for these hypervisors with guest in secure mode: it so happens that on
powerpc secure platform the DMA address is actually a physical address -
that of the bounce buffer. For these platforms we can make the virtio
driver go through the DMA API even though the device itself ignores
the DMA API.
These patches implement this work around for virtio: we detect that
- secure guest mode is enabled - so we know that since we don't share
most memory and Hypervisor has not enabled VIRTIO_F_ACCESS_PLATFORM,
regular virtio code won't work.
- DMA API is giving us addresses that are actually also physical
addresses.
- Hypervisor has not enabled VIRTIO_F_ACCESS_PLATFORM.
and if all conditions are true, we force all data through the bounce
buffer.
To put it another way, from hypervisor's point of view DMA API is
not required: hypervisor would be happy to get access to all of guest
memory. That's why it does not set VIRTIO_F_ACCESS_PLATFORM. However,
guest decides that it does not trust the hypervisor and wants to force
a bounce buffer for its own reasons.
Thiago Jung Bauermann (2):
dma-mapping: Add dma_addr_is_phys_addr()
virtio_ring: Use DMA API if memory is encrypted
arch/powerpc/include/asm/dma-mapping.h | 21 +++++++++++++++++++++
arch/powerpc/platforms/pseries/Kconfig | 1 +
drivers/virtio/virtio.c | 18 ++++++++++++++++++
drivers/virtio/virtio_ring.c | 8 ++++++++
include/linux/dma-mapping.h | 20 ++++++++++++++++++++
include/linux/virtio_config.h | 14 ++++++++++++++
kernel/dma/Kconfig | 3 +++
7 files changed, 85 insertions(+)
--
1.8.3.1
Powered by blists - more mailing lists