From: Cornelia Huck <cohuck@redhat.com>
To: Michael Mueller <mimu@linux.ibm.com>
Cc: KVM Mailing List <kvm@vger.kernel.org>,
Linux-S390 Mailing List <linux-s390@vger.kernel.org>,
Sebastian Ott <sebott@linux.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Halil Pasic <pasic@linux.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>,
Pierre Morel <pmorel@linux.ibm.com>
Subject: Re: [PATCH v2 3/8] s390/cio: add basic protected virtualization support
Date: Mon, 27 May 2019 12:38:02 +0200 [thread overview]
Message-ID: <20190527123802.54cd3589.cohuck@redhat.com> (raw)
In-Reply-To: <20190523162209.9543-4-mimu@linux.ibm.com>
On Thu, 23 May 2019 18:22:04 +0200
Michael Mueller <mimu@linux.ibm.com> wrote:
> From: Halil Pasic <pasic@linux.ibm.com>
>
> As virtio-ccw devices are channel devices, we need to use the dma area
> for any communication with the hypervisor.
>
> It handles neither QDIO in the common code, nor any device type specific
> stuff (like channel programs constructed by the DASD driver).
>
> An interesting side effect is that virtio structures are now going to
> get allocated in 31 bit addressable storage.
>
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
[Side note: you really should add your s-o-b if you send someone else's
patches... if Halil ends up committing them, it's fine, though.]
> ---
> arch/s390/include/asm/ccwdev.h | 4 +++
> drivers/s390/cio/ccwreq.c | 9 +++---
> drivers/s390/cio/device.c | 64 +++++++++++++++++++++++++++++++++-------
> drivers/s390/cio/device_fsm.c | 53 ++++++++++++++++++++-------------
> 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 | 10 -------
> 10 files changed, 164 insertions(+), 83 deletions(-)
>
(...)
> @@ -1593,20 +1622,31 @@ struct ccw_device * __init ccw_device_create_console(struct ccw_driver *drv)
> return ERR_CAST(sch);
>
> io_priv = kzalloc(sizeof(*io_priv), GFP_KERNEL | GFP_DMA);
> - if (!io_priv) {
> - put_device(&sch->dev);
> - return ERR_PTR(-ENOMEM);
> - }
> + if (!io_priv)
> + goto err_priv;
> + io_priv->dma_area = dma_alloc_coherent(&sch->dev,
> + sizeof(*io_priv->dma_area),
> + &io_priv->dma_area_dma, GFP_KERNEL);
Even though we'll only end up here for 3215 or 3270 consoles, this sent
me looking.
This code is invoked via console_init(). A few lines down in
start_kernel(), we have
/*
* This needs to be called before any devices perform DMA
* operations that might use the SWIOTLB bounce buffers. It will
* mark the bounce buffers as decrypted so that their usage will
* not cause "plain-text" data to be decrypted when accessed.
*/
mem_encrypt_init();
So, I'm wondering if creating the console device interacts in any way
with the memory encryption interface?
[Does basic recognition work if you start a protected virt guest with a
3270 console? I realize that the console is unlikely to work, but that
should at least exercise this code path.]
> + if (!io_priv->dma_area)
> + goto err_dma_area;
> set_io_private(sch, io_priv);
> cdev = io_subchannel_create_ccwdev(sch);
> if (IS_ERR(cdev)) {
> put_device(&sch->dev);
> + dma_free_coherent(&sch->dev, sizeof(*io_priv->dma_area),
> + io_priv->dma_area, io_priv->dma_area_dma);
> kfree(io_priv);
> return cdev;
> }
> cdev->drv = drv;
> ccw_device_set_int_class(cdev);
> return cdev;
> +
> +err_dma_area:
> + kfree(io_priv);
> +err_priv:
> + put_device(&sch->dev);
> + return ERR_PTR(-ENOMEM);
> }
>
> void __init ccw_device_destroy_console(struct ccw_device *cdev)
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Michael Mueller <mimu@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
Linux-S390 Mailing List <linux-s390@vger.kernel.org>,
Thomas Huth <thuth@redhat.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
KVM Mailing List <kvm@vger.kernel.org>,
Sebastian Ott <sebott@linux.ibm.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Pierre Morel <pmorel@linux.ibm.com>,
Farhan Ali <alifm@linux.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Eric Farman <farman@linux.ibm.com>,
virtualization@lists.linux-foundation.org,
Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Christoph Hellwig <hch@infradead.org>,
Viktor Mihajlovski <mihajlov@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>
Subject: Re: [PATCH v2 3/8] s390/cio: add basic protected virtualization support
Date: Mon, 27 May 2019 12:38:02 +0200 [thread overview]
Message-ID: <20190527123802.54cd3589.cohuck@redhat.com> (raw)
In-Reply-To: <20190523162209.9543-4-mimu@linux.ibm.com>
On Thu, 23 May 2019 18:22:04 +0200
Michael Mueller <mimu@linux.ibm.com> wrote:
> From: Halil Pasic <pasic@linux.ibm.com>
>
> As virtio-ccw devices are channel devices, we need to use the dma area
> for any communication with the hypervisor.
>
> It handles neither QDIO in the common code, nor any device type specific
> stuff (like channel programs constructed by the DASD driver).
>
> An interesting side effect is that virtio structures are now going to
> get allocated in 31 bit addressable storage.
>
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
[Side note: you really should add your s-o-b if you send someone else's
patches... if Halil ends up committing them, it's fine, though.]
> ---
> arch/s390/include/asm/ccwdev.h | 4 +++
> drivers/s390/cio/ccwreq.c | 9 +++---
> drivers/s390/cio/device.c | 64 +++++++++++++++++++++++++++++++++-------
> drivers/s390/cio/device_fsm.c | 53 ++++++++++++++++++++-------------
> 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 | 10 -------
> 10 files changed, 164 insertions(+), 83 deletions(-)
>
(...)
> @@ -1593,20 +1622,31 @@ struct ccw_device * __init ccw_device_create_console(struct ccw_driver *drv)
> return ERR_CAST(sch);
>
> io_priv = kzalloc(sizeof(*io_priv), GFP_KERNEL | GFP_DMA);
> - if (!io_priv) {
> - put_device(&sch->dev);
> - return ERR_PTR(-ENOMEM);
> - }
> + if (!io_priv)
> + goto err_priv;
> + io_priv->dma_area = dma_alloc_coherent(&sch->dev,
> + sizeof(*io_priv->dma_area),
> + &io_priv->dma_area_dma, GFP_KERNEL);
Even though we'll only end up here for 3215 or 3270 consoles, this sent
me looking.
This code is invoked via console_init(). A few lines down in
start_kernel(), we have
/*
* This needs to be called before any devices perform DMA
* operations that might use the SWIOTLB bounce buffers. It will
* mark the bounce buffers as decrypted so that their usage will
* not cause "plain-text" data to be decrypted when accessed.
*/
mem_encrypt_init();
So, I'm wondering if creating the console device interacts in any way
with the memory encryption interface?
[Does basic recognition work if you start a protected virt guest with a
3270 console? I realize that the console is unlikely to work, but that
should at least exercise this code path.]
> + if (!io_priv->dma_area)
> + goto err_dma_area;
> set_io_private(sch, io_priv);
> cdev = io_subchannel_create_ccwdev(sch);
> if (IS_ERR(cdev)) {
> put_device(&sch->dev);
> + dma_free_coherent(&sch->dev, sizeof(*io_priv->dma_area),
> + io_priv->dma_area, io_priv->dma_area_dma);
> kfree(io_priv);
> return cdev;
> }
> cdev->drv = drv;
> ccw_device_set_int_class(cdev);
> return cdev;
> +
> +err_dma_area:
> + kfree(io_priv);
> +err_priv:
> + put_device(&sch->dev);
> + return ERR_PTR(-ENOMEM);
> }
>
> void __init ccw_device_destroy_console(struct ccw_device *cdev)
next prev parent reply other threads:[~2019-05-27 10:38 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 16:22 [PATCH v2 0/8] s390: virtio: support protected virtualization Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-23 16:22 ` [PATCH v2 1/8] s390/mm: force swiotlb for " Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-23 16:22 ` [PATCH v2 2/8] s390/cio: introduce DMA pools to cio Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-25 9:22 ` Sebastian Ott
2019-05-25 9:22 ` Sebastian Ott
2019-05-27 11:26 ` Michael Mueller
2019-05-27 11:26 ` Michael Mueller
2019-05-27 6:57 ` Cornelia Huck
2019-05-27 6:57 ` Cornelia Huck
2019-05-27 11:47 ` Halil Pasic
2019-05-27 11:47 ` Halil Pasic
2019-05-27 12:06 ` Cornelia Huck
2019-05-27 12:06 ` Cornelia Huck
2019-05-27 12:00 ` Michael Mueller
2019-05-27 12:00 ` Michael Mueller
2019-05-23 16:22 ` [PATCH v2 3/8] s390/cio: add basic protected virtualization support Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-25 9:44 ` Sebastian Ott
2019-05-25 9:44 ` Sebastian Ott
2019-05-27 15:01 ` Michael Mueller
2019-05-27 15:01 ` Michael Mueller
2019-05-27 10:38 ` Cornelia Huck [this message]
2019-05-27 10:38 ` Cornelia Huck
2019-05-27 12:15 ` Michael Mueller
2019-05-27 12:15 ` Michael Mueller
2019-05-27 12:30 ` Halil Pasic
2019-05-27 12:30 ` Halil Pasic
2019-05-27 13:31 ` Cornelia Huck
2019-05-27 13:31 ` Cornelia Huck
2019-05-29 12:24 ` Michael Mueller
2019-05-29 12:24 ` Michael Mueller
2019-05-29 12:30 ` Cornelia Huck
2019-05-29 12:30 ` Cornelia Huck
2019-05-23 16:22 ` [PATCH v2 4/8] s390/airq: use DMA memory for adapter interrupts Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-25 9:51 ` Sebastian Ott
2019-05-25 9:51 ` Sebastian Ott
2019-05-27 10:53 ` Cornelia Huck
2019-05-27 10:53 ` Cornelia Huck
2019-05-23 16:22 ` [PATCH v2 5/8] virtio/s390: use cacheline aligned airq bit vectors Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-27 10:55 ` Cornelia Huck
2019-05-27 10:55 ` Cornelia Huck
2019-05-27 12:03 ` Halil Pasic
2019-05-27 12:03 ` Halil Pasic
2019-05-23 16:22 ` [PATCH v2 6/8] virtio/s390: add indirection to indicators access Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-27 11:00 ` Cornelia Huck
2019-05-27 11:00 ` Cornelia Huck
2019-05-27 11:57 ` Halil Pasic
2019-05-27 11:57 ` Halil Pasic
2019-05-27 12:10 ` Cornelia Huck
2019-05-27 12:10 ` Cornelia Huck
2019-05-29 11:05 ` Michael Mueller
2019-05-29 11:05 ` Michael Mueller
2019-05-23 16:22 ` [PATCH v2 7/8] virtio/s390: use DMA memory for ccw I/O and classic notifiers Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-27 11:49 ` Cornelia Huck
2019-05-27 11:49 ` Cornelia Huck
2019-05-23 16:22 ` [PATCH v2 8/8] virtio/s390: make airq summary indicators DMA Michael Mueller
2019-05-23 16:22 ` Michael Mueller
2019-05-27 12:00 ` Cornelia Huck
2019-05-27 12:00 ` Cornelia Huck
2019-05-28 14:33 ` Halil Pasic
2019-05-28 14:33 ` Halil Pasic
2019-05-28 14:56 ` Cornelia Huck
2019-05-28 14:56 ` Cornelia Huck
2019-05-28 14:58 ` Michael Mueller
2019-05-28 14:58 ` 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=20190527123802.54cd3589.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=borntraeger@de.ibm.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=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=pasic@linux.ibm.com \
--cc=pmorel@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 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.