All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Michael Mueller <mimu@linux.ibm.com>
Cc: 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>,
	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 13:14:33 +0200	[thread overview]
Message-ID: <20190613131433.014f2380.pasic@linux.ibm.com> (raw)
In-Reply-To: <4d10d4f8-aeb0-a5bc-6900-ab7901c01cf2@linux.ibm.com>

On Thu, 13 Jun 2019 11:11:13 +0200
Michael Mueller <mimu@linux.ibm.com> wrote:

> Halil,
> 
> I just ran my toleration tests successfully on current HW for
> this series.
> 
> Michael

Thanks Michael! May I add a
Tested-by: Michael Mueller <mimu@linux.ibm.com>
for each patch?

> 
> 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
> > 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: Michael Mueller <mimu@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, Thomas Huth <thuth@redhat.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	kvm@vger.kernel.org, Sebastian Ott <sebott@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	virtualization@lists.linux-foundation.org,
	Christoph Hellwig <hch@infradead.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	"Jason J. Herne" <jjherne@linux.ibm.com>,
	Farhan Ali <alifm@linux.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>
Subject: Re: [PATCH v5 0/8] s390: virtio: support protected virtualization
Date: Thu, 13 Jun 2019 13:14:33 +0200	[thread overview]
Message-ID: <20190613131433.014f2380.pasic@linux.ibm.com> (raw)
In-Reply-To: <4d10d4f8-aeb0-a5bc-6900-ab7901c01cf2@linux.ibm.com>

On Thu, 13 Jun 2019 11:11:13 +0200
Michael Mueller <mimu@linux.ibm.com> wrote:

> Halil,
> 
> I just ran my toleration tests successfully on current HW for
> this series.
> 
> Michael

Thanks Michael! May I add a
Tested-by: Michael Mueller <mimu@linux.ibm.com>
for each patch?

> 
> 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
> > 
> 

  reply	other threads:[~2019-06-13 11:14 UTC|newest]

Thread overview: 48+ 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 ` Halil Pasic
2019-06-12 11:12 ` [PATCH v5 1/8] s390/mm: force swiotlb for " Halil Pasic
2019-06-12 11:12   ` Halil Pasic
2019-06-13  8:09   ` Michael Mueller
2019-06-13  8:09     ` Michael Mueller
2019-07-11 21:48   ` Thiago Jung Bauermann
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 11:12   ` Halil Pasic
2019-06-12 14:23   ` Cornelia Huck
2019-06-12 14:23     ` Cornelia Huck
2019-06-13  8:13   ` Michael Mueller
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-12 11:12   ` Halil Pasic
2019-06-13  8:21   ` Michael Mueller
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 11:12   ` Halil Pasic
2019-06-12 14:35   ` Cornelia Huck
2019-06-12 14:35     ` Cornelia Huck
2019-06-12 15:11     ` Halil Pasic
2019-06-12 15:11       ` Halil Pasic
2019-06-13  8:25   ` Michael Mueller
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-12 11:12   ` Halil Pasic
2019-06-13  8:27   ` Michael Mueller
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-12 11:12   ` Halil Pasic
2019-06-13  8:29   ` Michael Mueller
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-12 11:12   ` Halil Pasic
2019-06-13  8:32   ` Michael Mueller
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-12 11:12   ` Halil Pasic
2019-06-13  8:35   ` Michael Mueller
2019-06-13  8:35     ` Michael Mueller
2019-06-13  9:11 ` [PATCH v5 0/8] s390: virtio: support protected virtualization Michael Mueller
2019-06-13  9:11   ` Michael Mueller
2019-06-13 11:14   ` Halil Pasic [this message]
2019-06-13 11:14     ` Halil Pasic
2019-06-13 11:17     ` Michael Mueller
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=20190613131433.014f2380.pasic@linux.ibm.com \
    --to=pasic@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=mimu@linux.ibm.com \
    --cc=mst@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.