Re: [PATCH v2 3/8] s390/cio: add basic protected virtualization support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 27.05.19 15:31, Cornelia Huck wrote:
On Mon, 27 May 2019 14:30:14 +0200
Halil Pasic <pasic@xxxxxxxxxxxxx> wrote:

On Mon, 27 May 2019 12:38:02 +0200
Cornelia Huck <cohuck@xxxxxxxxxx> 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.]
---
  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?

I do things a bit different than x86: the SWIOTLB stuff is set up in
mem_init(). So I think we should be fine. If there is a down-side to
calling swiotlb_update_mem_attributes() earlier, honestly I'm
not sure.

Neither am I; do any of the folks who looked at the swiotlb patch have
an idea?



[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.]

I've already had some thoughts along these lines and slapped
-device x-terminal3270,chardev=char_0,devno=fe.0.000a,id=terminal_0 \
on my qemu command line. The ccw device does show up in the guest...

Device   Subchan.  DevType CU Type Use  PIM PAM POM  CHPIDs
----------------------------------------------------------------------
0.0.0000 0.0.0000  0000/00 3832/01 yes  80  80  ff   00000000 00000000
0.0.000a 0.0.0001  0000/00 3270/00      80  80  ff   01000000 00000000
0.0.0002 0.0.0002  0000/00 3832/09 yes  80  80  ff   00000000 00000000
0.0.0300 0.0.0003  0000/00 3832/02 yes  80  80  ff   00000000 00000000
0.0.0301 0.0.0004  0000/00 3832/02 yes  80  80  ff   00000000 00000000

But I would not call it a comprehensive test...

If you only add the device, it will show up as a normal ccw device in
the guest; i.e. device recognition is done at the same time as for the
other ccw devices. Still good to see that nothing breaks there :)

To actually make the guest use the 3270 as its console, I guess you
need to explicitly force it (see
https://wiki.qemu.org/Features/3270#Using_3270_as_the_console)...
actually starting the console will almost certainly fail; but you can
at least check whether device recognition in the console path works.


Mimu, do we have something more elaborate with regards to this?

I ran that with success

[root@ap01 ~]# lscss | grep 3270
0.0.002a 0.0.0008  0000/00 3270/00 yes  80  80  ff   01000000 00000000

and was able to connect and login.

Michael


I don't think we need extensive testing here; just checking that the
sequence is not fundamentally broken.


_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization



[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux