On 27.05.19 12:38, Cornelia Huck wrote:
On Thu, 23 May 2019 18:22:04 +0200
Michael Mueller <mimu@xxxxxxxxxxxxx> wrote:
From: Halil Pasic <pasic@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
[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.]
My real problem here is that Halil is writing comments and patches after
I have prepared all my changes. ;) And now this contnues...
Michael
---
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)
