Cornelia Huck
2019-May-27 13:31 UTC
[PATCH v2 3/8] s390/cio: add basic protected virtualization support
On Mon, 27 May 2019 14:30:14 +0200 Halil Pasic <pasic at linux.ibm.com> wrote:> On Mon, 27 May 2019 12:38:02 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Thu, 23 May 2019 18:22:04 +0200 > > Michael Mueller <mimu at linux.ibm.com> wrote: > > > > > From: Halil Pasic <pasic at 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 at 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? > > 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 don't think we need extensive testing here; just checking that the sequence is not fundamentally broken.
Michael Mueller
2019-May-29 12:24 UTC
[PATCH v2 3/8] s390/cio: add basic protected virtualization support
On 27.05.19 15:31, Cornelia Huck wrote:> On Mon, 27 May 2019 14:30:14 +0200 > Halil Pasic <pasic at linux.ibm.com> wrote: > >> On Mon, 27 May 2019 12:38:02 +0200 >> Cornelia Huck <cohuck at redhat.com> wrote: >> >>> On Thu, 23 May 2019 18:22:04 +0200 >>> Michael Mueller <mimu at linux.ibm.com> wrote: >>> >>>> From: Halil Pasic <pasic at 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 at 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? >> >> 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 at 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. >
Cornelia Huck
2019-May-29 12:30 UTC
[PATCH v2 3/8] s390/cio: add basic protected virtualization support
On Wed, 29 May 2019 14:24:39 +0200 Michael Mueller <mimu at linux.ibm.com> wrote:> On 27.05.19 15:31, Cornelia Huck wrote:> > 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 at 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.Oh, cool. I'm actually a bit surprised this works without additional changes to the 3270 code :)
Apparently Analagous Threads
- [PATCH v2 3/8] s390/cio: add basic protected virtualization support
- [PATCH v2 3/8] s390/cio: add basic protected virtualization support
- [PATCH v2 3/8] s390/cio: add basic protected virtualization support
- [PATCH v2 3/8] s390/cio: add basic protected virtualization support
- [PATCH v2 3/8] s390/cio: add basic protected virtualization support