From: Michael Mueller <mimu@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>,
kvm@vger.kernel.org, linux-s390@vger.kernel.org,
Cornelia Huck <cohuck@redhat.com>,
Sebastian Ott <sebott@linux.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: virtualization@lists.linux-foundation.org,
"Michael S. Tsirkin" <mst@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Thomas Huth <thuth@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Viktor Mihajlovski <mihajlov@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Farhan Ali <alifm@linux.ibm.com>,
Eric Farman <farman@linux.ibm.com>,
"Jason J. Herne" <jjherne@linux.ibm.com>
Subject: Re: [PATCH v5 0/8] s390: virtio: support protected virtualization
Date: Thu, 13 Jun 2019 11:11:13 +0200 [thread overview]
Message-ID: <4d10d4f8-aeb0-a5bc-6900-ab7901c01cf2@linux.ibm.com> (raw)
In-Reply-To: <20190612111236.99538-1-pasic@linux.ibm.com>
Halil,
I just ran my toleration tests successfully on current HW for
this series.
Michael
On 12.06.19 13:12, Halil Pasic wrote:
> Enhanced virtualization protection technology may require the use of
> bounce buffers for I/O. While support for this was built into the virtio
> core, virtio-ccw wasn't changed accordingly.
>
> Some background on technology (not part of this series) and the
> terminology used.
>
> * Protected Virtualization (PV):
>
> Protected Virtualization guarantees, that non-shared memory of a guest
> that operates in PV mode private to that guest. I.e. any attempts by the
> hypervisor or other guests to access it will result in an exception. If
> supported by the environment (machine, KVM, guest VM) a guest can decide
> to change into PV mode by doing the appropriate ultravisor calls.
>
> * Ultravisor:
>
> A hardware/firmware entity that manages PV guests, and polices access to
> their memory. A PV guest prospect needs to interact with the ultravisor,
> to enter PV mode, and potentially to share pages (for I/O which should
> be encrypted by the guest). A guest interacts with the ultravisor via so
> called ultravisor calls. A hypervisor needs to interact with the
> ultravisor to facilitate interpretation, emulation and swapping. A
> hypervisor interacts with the ultravisor via ultravisor calls and via
> the SIE state description. Generally the ultravisor sanitizes hypervisor
> inputs so that the guest can not be corrupted (except for denial of
> service.
>
>
> What needs to be done
> =====================
>
> Thus what needs to be done to bring virtio-ccw up to speed with respect
> to protected virtualization is:
> * use some 'new' common virtio stuff
> * make sure that virtio-ccw specific stuff uses shared memory when
> talking to the hypervisor (except control/communication blocks like ORB,
> these are handled by the ultravisor)
> * make sure the DMA API does what is necessary to talk through shared
> memory if we are a protected virtualization guest.
> * make sure the common IO layer plays along as well (airqs, sense).
>
>
> Important notes
> ================
>
> * This patch set is based on Martins features branch
> (git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git branch
> 'features').
>
> * Documentation is still very sketchy. I'm committed to improving this,
> but I'm currently hampered by some dependencies currently.
>
> * The existing naming in the common infrastructure (kernel internal
> interfaces) is pretty much based on the AMD SEV terminology. Thus the
> names aren't always perfect. There might be merit to changing these
> names to more abstract ones. I did not put much thought into that at
> the current stage.
>
> * Testing: Please use iommu_platform=on for any virtio devices you are
> going to test this code with (so virtio actually uses the DMA API).
>
> @Sebastian: I kept your r-b on patch 2 "s390/cio: introduce DMA pools to
> cio" despite the small changes pointed out below. Please do complain if
> it ain't OK for you!
>
> Change log
> ==========
>
> v4 --> v5:
> * work around dma_pool API not tolerating NULL dma pool (patch 4)
> * make the genpool based dma pools API tolerate NULL genpool (patch 2)
> * fix typo (patch 2)
> * fix unintended code move (patch 7)
> * add more r-b's
>
>
>
> v3 --> v4
> * fixed cleanup in css_bus_init() (Connie)
> * made cio.h include genalloc.h instead of a forward declaration
> (Connie)
> * added comments about dma_mask/coherent_dma_mask values (Connie)
> * fixed error handling in virtio_ccw_init() (Connie)
> * got rid of the *vc_dma* wrappers (Connie)
> * added some Reviewed-bys
> * rebased on top of current master, no changes were necessary
>
> v2 --> v3:
> * patch 2/8
> potential cio_dma_pool_init() returning NULL issue fixed
> potential cio_gp_dma_create() returning NULL issue fixed
> warning issues with doc type comments fixed
> unused define statement removed
> * patch 3/8
> potential cio_gp_dma_create() returning NULL issue fixed
> whitespace issue fixed
> warning issues with doc type comments fixed
> * patch 8/8
> potential cio_dma_zalloc() returning NULL issue fixed
>
> v1 --> v2:
> * patch "virtio/s390: use vring_create_virtqueue" went already upstream
> * patch "virtio/s390: DMA support for virtio-ccw" went already upstream
> * patch "virtio/s390: enable packed ring" went already upstream
> * Made dev.dma_mask point to dev.coherent_dma_mask for css, subchannel
> and ccw devices.
> * While rebasing 's390/airq: use DMA memory for adapter interrupts' the
> newly introduced kmem_cache was replaced with an equivalent dma_pool;
> the kalloc() allocations are now replaced with cio_dma_zalloc()
> allocations to avoid wasting almost a full page.
> * Made virtio-ccw use the new AIRQ_IV_CACHELINE flag.
> * fixed all remaining checkpatch issues
>
> RFC --> v1:
> * Fixed bugs found by Connie (may_reduce and handling reduced, warning,
> split move -- thanks Connie!).
> * Fixed console bug found by Sebastian (thanks Sebastian!).
> * Removed the completely useless duplicate of dma-mapping.h spotted by
> Christoph (thanks Christoph!).
> * Don't use the global DMA pool for subchannel and ccw device
> owned memory as requested by Sebastian. Consequences:
> * Both subchannel and ccw devices have their dma masks
> now (both specifying 31 bit addressable)
> * We require at least 2 DMA pages per ccw device now, most of
> this memory is wasted though.
> * DMA memory allocated by virtio is also 31 bit addressable now
> as virtio uses the parent (which is the ccw device).
> * Enabled packed ring.
> * Rebased onto Martins feature branch; using the actual uv (ultravisor)
> interface instead of TODO comments.
> * Added some explanations to the cover letter (Connie, David).
> * Squashed a couple of patches together and fixed some text stuff.
>
> Halil Pasic (8):
> s390/mm: force swiotlb for protected virtualization
> s390/cio: introduce DMA pools to cio
> s390/cio: add basic protected virtualization support
> s390/airq: use DMA memory for adapter interrupts
> virtio/s390: use cacheline aligned airq bit vectors
> virtio/s390: add indirection to indicators access
> virtio/s390: use DMA memory for ccw I/O and classic notifiers
> virtio/s390: make airq summary indicators DMA
>
> arch/s390/Kconfig | 5 +
> arch/s390/include/asm/airq.h | 2 +
> arch/s390/include/asm/ccwdev.h | 4 +
> arch/s390/include/asm/cio.h | 11 ++
> arch/s390/include/asm/mem_encrypt.h | 18 ++
> arch/s390/mm/init.c | 47 ++++++
> drivers/s390/cio/airq.c | 37 +++--
> drivers/s390/cio/ccwreq.c | 9 +-
> drivers/s390/cio/cio.h | 2 +
> drivers/s390/cio/css.c | 134 ++++++++++++++-
> drivers/s390/cio/device.c | 68 ++++++--
> drivers/s390/cio/device_fsm.c | 49 +++---
> drivers/s390/cio/device_id.c | 20 ++-
> drivers/s390/cio/device_ops.c | 21 ++-
> drivers/s390/cio/device_pgid.c | 22 +--
> drivers/s390/cio/device_status.c | 24 +--
> drivers/s390/cio/io_sch.h | 20 ++-
> drivers/s390/virtio/virtio_ccw.c | 246 +++++++++++++++-------------
> 18 files changed, 538 insertions(+), 201 deletions(-)
> create mode 100644 arch/s390/include/asm/mem_encrypt.h
>
--
Mit freundlichen Grüßen / Kind regards
Michael Müller
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
next prev parent reply other threads:[~2019-06-13 15:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 11:12 [PATCH v5 0/8] s390: virtio: support protected virtualization Halil Pasic
2019-06-12 11:12 ` [PATCH v5 1/8] s390/mm: force swiotlb for " Halil Pasic
2019-06-13 8:09 ` Michael Mueller
2019-07-11 21:48 ` Thiago Jung Bauermann
2019-06-12 11:12 ` [PATCH v5 2/8] s390/cio: introduce DMA pools to cio Halil Pasic
2019-06-12 14:23 ` Cornelia Huck
2019-06-13 8:13 ` Michael Mueller
2019-06-12 11:12 ` [PATCH v5 3/8] s390/cio: add basic protected virtualization support Halil Pasic
2019-06-13 8:21 ` Michael Mueller
2019-06-12 11:12 ` [PATCH v5 4/8] s390/airq: use DMA memory for adapter interrupts Halil Pasic
2019-06-12 14:35 ` Cornelia Huck
2019-06-12 15:11 ` Halil Pasic
2019-06-13 8:25 ` Michael Mueller
2019-06-12 11:12 ` [PATCH v5 5/8] virtio/s390: use cacheline aligned airq bit vectors Halil Pasic
2019-06-13 8:27 ` Michael Mueller
2019-06-12 11:12 ` [PATCH v5 6/8] virtio/s390: add indirection to indicators access Halil Pasic
2019-06-13 8:29 ` Michael Mueller
2019-06-12 11:12 ` [PATCH v5 7/8] virtio/s390: use DMA memory for ccw I/O and classic notifiers Halil Pasic
2019-06-13 8:32 ` Michael Mueller
2019-06-12 11:12 ` [PATCH v5 8/8] virtio/s390: make airq summary indicators DMA Halil Pasic
2019-06-13 8:35 ` Michael Mueller
2019-06-13 9:11 ` Michael Mueller [this message]
2019-06-13 11:14 ` [PATCH v5 0/8] s390: virtio: support protected virtualization Halil Pasic
2019-06-13 11:17 ` Michael Mueller
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=4d10d4f8-aeb0-a5bc-6900-ab7901c01cf2@linux.ibm.com \
--to=mimu@linux.ibm.com \
--cc=alifm@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hch@infradead.org \
--cc=heiko.carstens@de.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mihajlov@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=sebott@linux.ibm.com \
--cc=thuth@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).