https://wiki.qemu.org/api.php?action=feedcontributions&user=Dongjia.shi&feedformat=atomQEMU - User contributions [en]2024-03-28T14:57:53ZUser contributionsMediaWiki 1.39.1https://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=7589Features/Channel I/O Passthrough2018-05-04T02:21:30Z<p>Dongjia.shi: </p>
<hr />
<div><br />
<br />
Channel I/O is a high-performance input/output (I/O) architecture that is implemented (especially) on s390 (see [https://en.wikipedia.org/wiki/Channel_I/O the wikipedia article]).<br />
<br />
== Motivation ==<br />
<br />
In the past, a guest virtualized via QEMU/KVM on s390 only sees paravirtualized virtio devices via the "Virtio Over Channel I/O (virtio-ccw)" transport. This makes virtio devices discoverable via<br />
standard operating system algorithms for handling channel devices.<br />
<br />
However this is not enough. To make the majority of devices on s390, which use the standard Channel I/O based mechanism, usable in a QEMU virtual machine, a passthrough mechanism is needed. This includes devices that don't have a virtio counterpart (e.g. tape drives) or that have specific characteristics which guests want to exploit.<br />
<br />
For passing a device to a guest, this uses the same interface as everybody else, namely vfio. Thus, the vfio support for channel devices is introduced, and this new vfio device is named "vfio-ccw".<br />
<br />
== Implementation ==<br />
<br />
vfio-ccw is realized with a mdev implementation. It has two drivers for two types of<br />
devices in the kernel:<br />
* The vfio_ccw driver for the physical subchannel device.<br />
* The vfio_mdev driver for the mediated vfio ccw device.<br />
<br />
The QEMU part introduces a basic Channel I/O passthrough infrastructure based on vfio. It focuses on supporting dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device currently.<br />
<br />
=== QEMU (since 2.10) ===<br />
<br />
It supports the new QEMU parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
<br />
At that time, the default css 0xFE was restricted to virtual subchannel devices. So the new machine option s390-squash-mcss was added to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, as all virtio-ccw devices are in css 0xFE (and show up in the default css 0 for guests not activating MCSS-E).<br />
<br />
=== QEMU (since 2.12) ===<br />
<br />
The hope when the decision (css 0xFE restriction) was made was, that non-virtual subchannel devices will come around when guest can exploit multiple channel subsystems. Using css 0xFE seemed like a good idea; but as things worked out differently in the meantime (MCSS-E will not come in the foreseeable future), it causes more problems right now than it avoids.<br />
<br />
A recent discussion about unrestricted cssid resulted in a decision to remove the restriction of putting non-virtual devices in non-0xFE css, and thus to deprecate the s390-squash-mcss property (since 2.12). So, users should not use this property anymore.<br />
<br />
One pain-point of this change is downgrade or upgrade of QEMU for command line users. The old way and the new way of doing vfio-ccw are mutually incompatible.<br />
<br />
Libvirt is only going to support the new way, so for libvirt users, the possible problems at QEMU downgrade are the following. If a domain contains virtual devices placed into a css different than 0xFE the domain will refuse to start with an older QEMU. Putting devices into a css different than 0xFE however won't make much sense in the near future (guest support). Libvirt will refuse to do vfio-ccw with an older QEMU. This is business as usual.<br />
<br />
Reference of the discussions could be found:<br />
* Questions about usability mess that caused by differentiating address based on devices types (see [https://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg02495.html])<br />
* [PATCH 0/3] unrestrict cssids related patches (see [https://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg00031.html])<br />
<br />
=== LGM consideration ===<br />
<br />
The adverse effect of getting rid of the css 0xFE restriction on migration should not be too severe. vfio-ccw devices are not live-migratable yet, and for virtual devices using the extra freedom would only make sense with the MCSS-E guest support in place.<br />
<br />
The auto-generated bus ids are also affected. We hope to not encounter any auto-generated bus ids in production as Libvirt is always explicit about the bus id. Since 8ed179c937 ("s390x/css: catch section mismatch on load", 2017-05-18) the worst that can happen because the same device ended up having a different bus id is a cleanly failed migration. Guests supposed to be migrated should make sure that they use explicit devnos.<br />
<br />
The following shows LGM behaviors for both QEMU 2.10 and QEMU 2.12 (and higher, theoretically) for reference.<br />
<br />
==== QEMU 2.10 ====<br />
------------+---------------+-------------<br />
| squashing off | squashing on<br />
------------+---------------+-------------<br />
auto id | F | F <br />
------------+---------------+-------------<br />
explicit id | F | S <br />
------------+---------------+-------------<br />
<br />
*T1. squashing off + auto id<br />
<br />
Fail due to css mismatch - there is no css 0 in the new vm.<br />
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER<br />
qemu-system-s390x: Failed to load s390_css:css<br />
qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T2. squashing off + explicit given id<br />
<br />
Fail due to css mismatch - there is no css 0 in the new vm.<br />
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER<br />
qemu-system-s390x: Failed to load s390_css:css<br />
qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T3. squashing on + auto id<br />
<br />
Fail due to busid mismatch.<br />
qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T4. squashing on + explicit given id<br />
<br />
Succeed.<br />
<br />
==== QEMU 2.12 ====<br />
<br />
------------+---------------+-------------<br />
| squashing off | squashing on<br />
------------+---------------+-------------<br />
auto id | F | F <br />
------------+---------------+-------------<br />
explicit id | S' | S <br />
------------+---------------+-------------<br />
<br />
*T5. squashing off + auto id<br />
<br />
Fail due to busid mismatch.<br />
qemu-system-s390x: Unknown savevm section or instance '/fe.0.0003/virtio-rng' 0<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T6. squashing off + explicit given id<br />
<br />
Setting vfio-ccw.devno=non-fe.x.xxxx (same as T2). Fail due to css mismatch - there is no css 0 in the new vm.<br />
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER<br />
qemu-system-s390x: Failed to load s390_css:css<br />
qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
Setting vfio-ccw.devno=fe.x.xxxx.<br />
Succeed. <br />
<br />
*T7. squashing on + auto id<br />
<br />
Fail due to busid mismatch.<br />
qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T8. squashing on + explicit given id<br />
<br />
Succeed.<br />
<br />
=== Libvirt ===<br />
<br />
The libvirt support is under development.<br />
<br />
== Setup ==<br />
<br />
This example setup is done for a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Host ===<br />
<br />
* Kernel Configuration<br />
CONFIG_S390_CCW_IOMMU=y<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
* Modules Required<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
* You need to have a [https://en.wikipedia.org/wiki/Direct-access_storage_device DASD/ECKD] device as the target device.<br />
Find the subchannel (0."$ssid"."$schid") of your target DASD/ECKD device and bind the subchannel to the vfio_ccw driver.<br />
#find the DASD you can use with lsdasd on your host, e.g.:<br />
#devno="7e52"<br />
#schid="16ca"<br />
#ssid="0"<br />
#for device 0.0.7e52 on subchannel 0.0.16ca.<br />
#unbind the CCW device from its subchannel<br />
echo 0."$ssid"."$devno" > /sys/bus/ccw/devices/0."$ssid"."$devno"/driver/unbind<br />
#unbind the subchannel from the I/O subchannel driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/devices/0."$ssid"."$schid"/driver/unbind<br />
#bind the subchannel to the vfio_ccw driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
* Create a Mediated Device for the physical device<br />
#generate a uuid with uuidgen. e.g.:<br />
#uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > /sys/bus/css/devices/0."$ssid"."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
=== Starting QEMU ===<br />
<br />
* Add a vfio-ccw device to your QEMU command line (machine needs to be <code>s390x-ccw-virtio</code><s>, with <code>s390-squash-mcss=on</code></s>). Example:<br />
-M s390-ccw-virtio<s>,s390-squash-mcss=on</s> \<br />
-device vfio-ccw,devno=fe.0.1234,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...<br />
* Start QEMU. Your guest will be presented with a real Channel I/O device, with the example above, to be more specific, a DASD/ECKD device.<br />
<br />
=== Try the device on your Guest ===<br />
<br />
* The guest will see the DASD/ECKD as a channel-attached device. With the example above, the device will show up as 0.0.1234 (verify e.g. via the lscss tool).<br />
<br />
* You can online the device by calling <code>chccwdev -e 0.0.1234</code> and use it as a block device.<br />
<br />
== Restrictions ==<br />
<br />
* Only target I/O subchannels.<br />
* Only basic commands (read/write) have been tested.<br />
* Some commands may need special handling in the future, for example, anything related to path grouping.</div>Dongjia.shihttps://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=7270Features/Channel I/O Passthrough2017-12-12T13:57:23Z<p>Dongjia.shi: </p>
<hr />
<div><br />
<br />
Channel I/O is a high-performance input/output (I/O) architecture that is implemented (especially) on s390 (see [https://en.wikipedia.org/wiki/Channel_I/O the wikipedia article]).<br />
<br />
== Motivation ==<br />
<br />
In the past, a guest virtualized via QEMU/KVM on s390 only sees paravirtualized virtio devices via the "Virtio Over Channel I/O (virtio-ccw)" transport. This makes virtio devices discoverable via<br />
standard operating system algorithms for handling channel devices.<br />
<br />
However this is not enough. To make the majority of devices on s390, which use the standard Channel I/O based mechanism, usable in a QEMU virtual machine, a passthrough mechanism is needed. This includes devices that don't have a virtio counterpart (e.g. tape drives) or that have specific characteristics which guests want to exploit.<br />
<br />
For passing a device to a guest, this uses the same interface as everybody else, namely vfio. Thus, the vfio support for channel devices is introduced, and this new vfio device is named "vfio-ccw".<br />
<br />
== Implementation ==<br />
<br />
vfio-ccw is realized with a mdev implementation. It has two drivers for two types of<br />
devices in the kernel:<br />
* The vfio_ccw driver for the physical subchannel device.<br />
* The vfio_mdev driver for the mediated vfio ccw device.<br />
<br />
The QEMU part introduces a basic Channel I/O passthrough infrastructure based on vfio. It focuses on supporting dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device currently.<br />
<br />
=== QEMU (since 2.10) ===<br />
<br />
It supports the new QEMU parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
<br />
At that time, the default css 0xFE was restricted to virtual subchannel devices. So the new machine option s390-squash-mcss is added to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, as all virtio-ccw devices are in css 0xFE (and show up in the default css 0 for guests not activating MCSS-E).<br />
<br />
=== QEMU (since 2.12) ===<br />
<br />
The hope when the decision (css 0xFE restriction) was made was, that non-virtual subchannel devices will come around when guest can exploit multiple channel subsystems. Using css 0xFE seemed like a good idea; but as things worked out differently in the meantime (MCSS-E will not come in the foreseable future), it causes more problems right now than it avoids.<br />
<br />
A recent discussion about unrestricted cssid resulted in a decision to remove the restriction of putting non-virtual devices in non-0xFE css, and thus to deprecate the s390-squash-mcss property (since 2.12). So, users should not use this property anymore.<br />
<br />
One pain-point of this change is downgrade or upgrade of QEMU for command line users. The old way and the new way of doing vfio-ccw are mutually incompatible.<br />
<br />
Libvirt is only going to support the new way, so for libvirt users, the possible problems at QEMU downgrade are the following. If a domain contains virtual devices placed into a css different than 0xFE the domain will refuse to start with an older QEMU. Putting devices into a css different than 0xFE however won't make much sense in the near future (guest support). Libvirt will refuse to do vfio-ccw with an older QEMU. This is business as usual.<br />
<br />
Reference of the discussions could be found:<br />
* Questions about usability mess that caused by differentiating address based on devices types (see [https://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg02495.html])<br />
* [PATCH 0/3] unrestrict cssids related patches (see [https://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg00031.html])<br />
<br />
=== LGM consideration ===<br />
<br />
The adverse effect of getting rid of the css 0xFE restriction on migration should not be too severe. vfio-ccw devices are not live-migratable yet, and for virtual devices using the extra freedom would only make sense with the MCSS-E guest support in place.<br />
<br />
The auto-generated bus ids are also affected. We hope to not encounter any auto-generated bus ids in production as Libvirt is always explicit about the bus id. Since 8ed179c937 ("s390x/css: catch section mismatch on load", 2017-05-18) the worst that can happen because the same device ended up having a different bus id is a cleanly failed migration. Guests supposed to be migrated should make sure that they use explicit devnos.<br />
<br />
The following shows LGM behaviors for both QEMU 2.10 and QEMU 2.12 (and higher, theoretically) for reference.<br />
<br />
==== QEMU 2.10 ====<br />
------------+---------------+-------------<br />
| squashing off | squashing on<br />
------------+---------------+-------------<br />
auto id | F | F <br />
------------+---------------+-------------<br />
explicit id | F | S <br />
------------+---------------+-------------<br />
<br />
*T1. squashing off + auto id<br />
<br />
Fail due to css mismatch - there is no css 0 in the new vm.<br />
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER<br />
qemu-system-s390x: Failed to load s390_css:css<br />
qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T2. squashing off + explicit given id<br />
<br />
Fail due to css mismatch - there is no css 0 in the new vm.<br />
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER<br />
qemu-system-s390x: Failed to load s390_css:css<br />
qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T3. squashing on + auto id<br />
<br />
Fail due to busid mismatch.<br />
qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T4. squashing on + explicit given id<br />
<br />
Succeed.<br />
<br />
==== QEMU 2.12 ====<br />
<br />
------------+---------------+-------------<br />
| squashing off | squashing on<br />
------------+---------------+-------------<br />
auto id | F | F <br />
------------+---------------+-------------<br />
explicit id | S' | S <br />
------------+---------------+-------------<br />
<br />
*T5. squashing off + auto id<br />
<br />
Fail due to busid mismatch.<br />
qemu-system-s390x: Unknown savevm section or instance '/fe.0.0003/virtio-rng' 0<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T6. squashing off + explicit given id<br />
<br />
Setting vfio-ccw.devno=non-fe.x.xxxx (same as T2). Fail due to css mismatch - there is no css 0 in the new vm.<br />
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER<br />
qemu-system-s390x: Failed to load s390_css:css<br />
qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
Setting vfio-ccw.devno=fe.x.xxxx.<br />
Succeed. <br />
<br />
*T7. squashing on + auto id<br />
<br />
Fail due to busid mismatch.<br />
qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0<br />
qemu-system-s390x: load of migration failed: Invalid argument<br />
<br />
*T8. squashing on + explicit given id<br />
<br />
Succeed.<br />
<br />
=== Libvirt ===<br />
<br />
The libvirt support is under development.<br />
<br />
== Setup ==<br />
<br />
This example setup is done for a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Host ===<br />
<br />
* Kernel Configuration<br />
CONFIG_S390_CCW_IOMMU=m<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
* Modules Required<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
* You need to have a [https://en.wikipedia.org/wiki/Direct-access_storage_device DASD/ECKD] device as the target device.<br />
Find the subchannel (0."$ssid"."$schid") of your target DASD/ECKD device and bind the subchannel to the vfio_ccw driver.<br />
#find the DASD you can use with lsdasd on your host, e.g.:<br />
#devno="7e52"<br />
#schid="16ca"<br />
#ssid="0"<br />
#for device 0.0.7e52 on subchannel 0.0.16ca.<br />
#unbind the CCW device from its subchannel<br />
echo 0."$ssid"."$devno" > /sys/bus/ccw/devices/0."$ssid"."$devno"/driver/unbind<br />
#unbind the subchannel from the I/O subchannel driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/devices/0."$ssid"."$schid"/driver/unbind<br />
#bind the subchannel to the vfio_ccw driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
* Create a Mediated Device for the physical device<br />
#generate a uuid with uuidgen. e.g.:<br />
#uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > /sys/bus/css/devices/0."$ssid"."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
=== Starting QEMU ===<br />
<br />
* Add a vfio-ccw device to your QEMU command line (machine needs to be <code>s390x-ccw-virtio</code><s>, with <code>s390-squash-mcss=on</code></s>). Example:<br />
-M s390-ccw-virtio<s>,s390-squash-mcss=on</s> \<br />
-device vfio-ccw,devno=fe.0.1234,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...<br />
* Start QEMU. Your guest will be presented with a real Channel I/O device, with the example above, to be more specific, a DASD/ECKD device.<br />
<br />
=== Try the device on your Guest ===<br />
<br />
* The guest will see the DASD/ECKD as a channel-attached device. With the example above, the device will show up as 0.0.1234 (verify e.g. via the lscss tool).<br />
<br />
* You can online the device by calling <code>chccwdev -e 0.0.1234</code> and use it as a block device.<br />
<br />
== Restrictions ==<br />
<br />
* Only target I/O subchannels.<br />
* Only basic commands (read/write) have been tested.<br />
* Some commands may need special handling in the future, for example, anything related to path grouping.</div>Dongjia.shihttps://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=7192Features/Channel I/O Passthrough2017-11-09T02:58:35Z<p>Dongjia.shi: </p>
<hr />
<div>Channel I/O is a high-performance input/output (I/O) architecture that is implemented (especially) on s390 (see [https://en.wikipedia.org/wiki/Channel_I/O the wikipedia article]).<br />
<br />
== Motivation ==<br />
<br />
In the past, a guest virtualized via QEMU/KVM on s390 only sees paravirtualized virtio devices via the "Virtio Over Channel I/O (virtio-ccw)" transport. This makes virtio devices discoverable via<br />
standard operating system algorithms for handling channel devices.<br />
<br />
However this is not enough. To make the majority of devices on s390, which use the standard Channel I/O based mechanism, usable in a QEMU virtual machine, a passthrough mechanism is needed. This includes devices that don't have a virtio counterpart (e.g. tape drives) or that have specific characteristics which guests want to exploit.<br />
<br />
For passing a device to a guest, this uses the same interface as everybody else, namely vfio. Thus, the vfio support for channel devices is introduced, and this new vfio device is named "vfio-ccw".<br />
<br />
== Implementation ==<br />
<br />
vfio-ccw is realized with a mdev implementation. It has two drivers for two types of<br />
devices in the kernel:<br />
* The vfio_ccw driver for the physical subchannel device.<br />
* The vfio_mdev driver for the mediated vfio ccw device.<br />
<br />
The QEMU part introduces a basic Channel I/O passthrough infrastructure based on vfio.<br />
* Focus on supporting dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device currently. <br />
* Support new QEMU parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
<br />
The new machine option s390-squash-mcss is added to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, as all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E).<br />
<br />
== Setup ==<br />
<br />
This example setup is done for a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Host ===<br />
<br />
* Kernel Configuration<br />
CONFIG_S390_CCW_IOMMU=m<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
* Modules Required<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
* You need to have a [https://en.wikipedia.org/wiki/Direct-access_storage_device DASD/ECKD] device as the target device.<br />
Find the subchannel (0."$ssid"."$schid") of your target DASD/ECKD device and bind the subchannel to the vfio_ccw driver.<br />
#find the DASD you can use with lsdasd on your host, e.g.:<br />
#devno="7e52"<br />
#schid="16ca"<br />
#ssid="0"<br />
#for device 0.0.7e52 on subchannel 0.0.16ca.<br />
#unbind the CCW device from its subchannel<br />
echo 0."$ssid"."$devno" > /sys/bus/ccw/devices/0."$ssid"."$devno"/driver/unbind<br />
#unbind the subchannel from the I/O subchannel driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/devices/0."$ssid"."$schid"/driver/unbind<br />
#bind the subchannel to the vfio_ccw driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
* Create a Mediated Device for the physical device<br />
#generate a uuid with uuidgen. e.g.:<br />
#uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > /sys/bus/css/devices/0."$ssid"."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
=== Starting QEMU ===<br />
<br />
* Add a vfio-ccw device to your QEMU command line (machine needs to be <code>s390x-ccw-virtio</code>, with <code>s390-squash-mcss=on</code>). Example:<br />
-M s390-ccw-virtio,s390-squash-mcss=on \<br />
-device vfio-ccw,devno=0.0.1234,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...<br />
* Start QEMU. Your guest will be presented with a real Channel I/O device, with the example above, to be more specific, a DASD/ECKD device.<br />
<br />
=== Try the device on your Guest ===<br />
<br />
* The guest will see the DASD/ECKD as a channel-attached device. With the example above, the device will show up as 0.0.1234 (verify e.g. via the lscss tool).<br />
<br />
* You can online the device by calling <code>chccwdev -e 0.0.1234</code> and use it as a block device.<br />
<br />
== Restrictions ==<br />
<br />
* Only target I/O subchannels.<br />
* Only basic commands (read/write) have been tested.<br />
* Some commands may need special handling in the future, for example, anything related to path grouping.</div>Dongjia.shihttps://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=7186Features/Channel I/O Passthrough2017-11-08T01:12:37Z<p>Dongjia.shi: /* Starting QEMU */</p>
<hr />
<div>Channel I/O is a high-performance input/output (I/O) architecture that is implemented (especially) on s390 (see [https://en.wikipedia.org/wiki/Channel_I/O the wikipedia article]).<br />
<br />
== Motivation ==<br />
<br />
In the past, a guest virtualized via QEMU/KVM on s390 only sees paravirtualized virtio devices via the "Virtio Over Channel I/O (virtio-ccw)" transport. This makes virtio devices discoverable via<br />
standard operating system algorithms for handling channel devices.<br />
<br />
However this is not enough. To make the majority of devices on s390, which use the standard Channel I/O based mechanism, usable in a QEMU virtual machine, a passthrough mechanism is needed. This includes devices that don't have a virtio counterpart (e.g. tape drives) or that have specific characteristics which guests want to exploit.<br />
<br />
For passing a device to a guest, this uses the same interface as everybody else, namely vfio. Thus, the vfio support for channel devices is introduced, and this new vfio device is named "vfio-ccw".<br />
<br />
== Implementation ==<br />
<br />
vfio-ccw is realized with a mdev implementation. It has two drivers for two types of<br />
devices in the kernel:<br />
* The vfio_ccw driver for the physical subchannel device.<br />
* The vfio_mdev driver for the mediated vfio ccw device.<br />
<br />
The QEMU part introduces a basic Channel I/O passthrough infrastructure based on vfio.<br />
* Focus on supporting dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device currently. <br />
* Support new QEMU parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
<br />
The new machine option s390-squash-css is added to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, as all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E).<br />
<br />
== Setup ==<br />
<br />
This example setup is done for a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Host ===<br />
<br />
* Kernel Configuration<br />
CONFIG_S390_CCW_IOMMU=m<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
* Modules Required<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
* You need to have a [https://en.wikipedia.org/wiki/Direct-access_storage_device DASD/ECKD] device as the target device.<br />
Find the subchannel (0."$ssid"."$schid") of your target DASD/ECKD device and bind the subchannel to the vfio_ccw driver.<br />
#find the DASD you can use with lsdasd on your host, e.g.:<br />
#devno="7e52"<br />
#schid="16ca"<br />
#ssid="0"<br />
#for device 0.0.7e52 on subchannel 0.0.16ca.<br />
#unbind the CCW device from its subchannel<br />
echo 0."$ssid"."$devno" > /sys/bus/ccw/devices/0."$ssid"."$devno"/driver/unbind<br />
#unbind the subchannel from the I/O subchannel driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/devices/0."$ssid"."$schid"/driver/unbind<br />
#bind the subchannel to the vfio_ccw driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
* Create a Mediated Device for the physical device<br />
#generate a uuid with uuidgen. e.g.:<br />
#uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > /sys/bus/css/devices/0."$ssid"."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
=== Starting QEMU ===<br />
<br />
* Add a vfio-ccw device to your QEMU command line (machine needs to be <code>s390x-ccw-virtio</code>, with <code>s390-squash-mcss=on</code>). Example:<br />
-M s390-ccw-virtio,s390-squash-mcss=on \<br />
-device vfio-ccw,devno=0.0.1234,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...<br />
* Start QEMU. Your guest will be presented with a real Channel I/O device, with the example above, to be more specific, a DASD/ECKD device.<br />
<br />
=== Try the device on your Guest ===<br />
<br />
* The guest will see the DASD/ECKD as a channel-attached device. With the example above, the device will show up as 0.0.1234 (verify e.g. via the lscss tool).<br />
<br />
* You can online the device by calling <code>chccwdev -e 0.0.1234</code> and use it as a block device.<br />
<br />
== Restrictions ==<br />
<br />
* Only target I/O subchannels.<br />
* Only basic commands (read/write) have been tested.<br />
* Some commands may need special handling in the future, for example, anything related to path grouping.</div>Dongjia.shihttps://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=6880Features/Channel I/O Passthrough2017-05-22T14:43:14Z<p>Dongjia.shi: s/%/$/</p>
<hr />
<div>Channel I/O is a high-performance input/output (I/O) architecture that is implemented (especially) on s390 (see [https://en.wikipedia.org/wiki/Channel_I/O the wikipedia article]).<br />
<br />
== Motivation ==<br />
<br />
In the past, a guest virtualized via QEMU/KVM on s390 only sees paravirtualized virtio devices via the "Virtio Over Channel I/O (virtio-ccw)" transport. This makes virtio devices discoverable via<br />
standard operating system algorithms for handling channel devices.<br />
<br />
However this is not enough. To make the majority of devices on s390, which use the standard Channel I/O based mechanism, usable in a QEMU virtual machine, a passthrough mechanism is needed. This includes devices that don't have a virtio counterpart (e.g. tape drives) or that have specific characteristics which guests want to exploit.<br />
<br />
For passing a device to a guest, this uses the same interface as everybody else, namely vfio. Thus, the vfio support for channel devices is introduced, and this new vfio device is named "vfio-ccw".<br />
<br />
== Implementation ==<br />
<br />
vfio-ccw is realized with a mdev implementation. It has two drivers for two types of<br />
devices in the kernel:<br />
* The vfio_ccw driver for the physical subchannel device.<br />
* The vfio_mdev driver for the mediated vfio ccw device.<br />
<br />
The QEMU part introduces a basic Channel I/O passthrough infrastructure based on vfio.<br />
* Focus on supporting dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device currently. <br />
* Support new QEMU parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
<br />
The new machine option s390-squash-css is added to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, as all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E).<br />
<br />
== Setup ==<br />
<br />
This example setup is done for a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Host ===<br />
<br />
* Kernel Configuration<br />
CONFIG_S390_CCW_IOMMU=m<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
* Modules Required<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
* You need to have a [https://en.wikipedia.org/wiki/Direct-access_storage_device DASD/ECKD] device as the target device.<br />
Find the subchannel (0."$ssid"."$schid") of your target DASD/ECKD device and bind the subchannel to the vfio_ccw driver.<br />
#find the DASD you can use with lsdasd on your host, e.g.:<br />
#devno="7e52"<br />
#schid="16ca"<br />
#ssid="0"<br />
#for device 0.0.7e52 on subchannel 0.0.16ca.<br />
#unbind the CCW device from its subchannel<br />
echo 0."$ssid"."$devno" > /sys/bus/ccw/devices/0."$ssid"."$devno"/driver/unbind<br />
#unbind the subchannel from the I/O subchannel driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/devices/0."$ssid"."$schid"/driver/unbind<br />
#bind the subchannel to the vfio_ccw driver<br />
echo 0."$ssid"."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
* Create a Mediated Device for the physical device<br />
#generate a uuid with uuidgen. e.g.:<br />
#uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > /sys/bus/css/devices/0."$ssid"."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
=== Starting QEMU ===<br />
<br />
* Add a vfio-ccw device to your QEMU command line (machine needs to be <code>s390x-ccw-virtio</code>, with <code>s390-squash-css=on</code>). Example:<br />
-M s390-ccw-virtio,s390-squash-css=on \<br />
-device vfio-ccw,devno=0.0.1234,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...<br />
* Start QEMU. Your guest will be presented with a real Channel I/O device, with the example above, to be more specific, a DASD/ECKD device.<br />
<br />
=== Try the device on your Guest ===<br />
<br />
* The guest will see the DASD/ECKD as a channel-attached device. With the example above, the device will show up as 0.0.1234 (verify e.g. via the lscss tool).<br />
<br />
* You can online the device by calling <code>chccwdev -e 0.0.1234</code> and use it as a block device.<br />
<br />
== Restrictions ==<br />
<br />
* Only target I/O subchannels.<br />
* Only basic commands (read/write) have been tested.<br />
* Some commands may need special handling in the future, for example, anything related to path grouping.</div>Dongjia.shihttps://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=6879Features/Channel I/O Passthrough2017-05-22T14:37:03Z<p>Dongjia.shi: </p>
<hr />
<div>Channel I/O is a high-performance input/output (I/O) architecture that is implemented (especially) on s390 (see [https://en.wikipedia.org/wiki/Channel_I/O the wikipedia article]).<br />
<br />
== Motivation ==<br />
<br />
In the past, a guest virtualized via QEMU/KVM on s390 only sees paravirtualized virtio devices via the "Virtio Over Channel I/O (virtio-ccw)" transport. This makes virtio devices discoverable via<br />
standard operating system algorithms for handling channel devices.<br />
<br />
However this is not enough. To make the majority of devices on s390, which use the standard Channel I/O based mechanism, usable in a QEMU virtual machine, a passthrough mechanism is needed. This includes devices that don't have a virtio counterpart (e.g. tape drives) or that have specific characteristics which guests want to exploit.<br />
<br />
For passing a device to a guest, this uses the same interface as everybody else, namely vfio. Thus, the vfio support for channel devices is introduced, and this new vfio device is named "vfio-ccw".<br />
<br />
== Implementation ==<br />
<br />
vfio-ccw is realized with a mdev implementation. It has two drivers for two types of<br />
devices in the kernel:<br />
* The vfio_ccw driver for the physical subchannel device.<br />
* The vfio_mdev driver for the mediated vfio ccw device.<br />
<br />
The QEMU part introduces a basic Channel I/O passthrough infrastructure based on vfio.<br />
* Focus on supporting dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device currently. <br />
* Support new QEMU parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
<br />
The new machine option s390-squash-css is added to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, as all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E).<br />
<br />
== Setup ==<br />
<br />
This example setup is done for a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Host ===<br />
<br />
* Kernel Configuration<br />
CONFIG_S390_CCW_IOMMU=m<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
* Modules Required<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
* You need to have a [https://en.wikipedia.org/wiki/Direct-access_storage_device DASD/ECKD] device as the target device.<br />
Find the subchannel (0."%ssid"."%schid") of your target DASD/ECKD device and bind the subchannel to the vfio_ccw driver.<br />
#find the DASD you can use with lsdasd on your host, e.g.:<br />
#devno="7e52"<br />
#schid="16ca"<br />
#ssid="0"<br />
#for device 0.0.7e52 on subchannel 0.0.16ca.<br />
#unbind the CCW device from its subchannel<br />
echo 0."%ssid"."$devno" > /sys/bus/ccw/devices/0."%ssid"."$devno"/driver/unbind<br />
#unbind the subchannel from the I/O subchannel driver<br />
echo 0."%ssid"."$schid" > /sys/bus/css/devices/0."%ssid"."$schid"/driver/unbind<br />
#bind the subchannel to the vfio_ccw driver<br />
echo 0."%ssid"."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
* Create a Mediated Device for the physical device<br />
#generate a uuid with uuidgen. e.g.:<br />
#uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > /sys/bus/css/devices/0."%ssid"."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
=== Starting QEMU ===<br />
<br />
* Add a vfio-ccw device to your QEMU command line (machine needs to be <code>s390x-ccw-virtio</code>, with <code>s390-squash-css=on</code>). Example:<br />
-M s390-ccw-virtio,s390-squash-css=on \<br />
-device vfio-ccw,devno=0.0.1234,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...<br />
* Start QEMU. Your guest will be presented with a real Channel I/O device, with the example above, to be more specific, a DASD/ECKD device.<br />
<br />
=== Try the device on your Guest ===<br />
<br />
* The guest will see the DASD/ECKD as a channel-attached device. With the example above, the device will show up as 0.0.1234 (verify e.g. via the lscss tool).<br />
<br />
* You can online the device by calling <code>chccwdev -e 0.0.1234</code> and use it as a block device.<br />
<br />
== Restrictions ==<br />
<br />
* Only target I/O subchannels.<br />
* Only basic commands (read/write) have been tested.<br />
* Some commands may need special handling in the future, for example, anything related to path grouping.</div>Dongjia.shihttps://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=6877Features/Channel I/O Passthrough2017-05-22T01:47:39Z<p>Dongjia.shi: </p>
<hr />
<div>'''''Notice: this page is still under construction'''''<br />
<br />
Channel I/O is a high-performance input/output (I/O) architecture that is implemented (especially) on s390 (see [https://en.wikipedia.org/wiki/Channel_I/O the wikipedia article]).<br />
<br />
== Motivation ==<br />
<br />
In the past, a guest virtualized via QEMU/KVM on s390 only sees paravirtualized virtio devices via the "Virtio Over Channel I/O (virtio-ccw)" transport. This makes virtio devices discoverable via<br />
standard operating system algorithms for handling channel devices.<br />
<br />
However this is not enough. On s390 for the majority of devices, which use the standard Channel I/O based mechanism, it also needs to provide the functionality of passing through them to a QEMU virtual machine. This includes devices that don't have a virtio counterpart (e.g. tape drives) or that have specific characteristics which guests want to exploit.<br />
<br />
For passing a device to a guest, this uses the same interface as everybody else, namely vfio. Thus, the vfio support for channel devices is introduced , and this new vfio device is named "vfio-ccw".<br />
<br />
== Implementation ==<br />
<br />
vfio-ccw is realized with a mdev implementation. It has two drivers for two types of<br />
devices in the kernel:<br />
* The vfio_ccw driver for the physical subchannel device.<br />
* The vfio_mdev driver for the mediated vfio ccw device.<br />
<br />
The QEMU part introduces a basic Channel I/O passthrough infrastructure based on vfio.<br />
* Focus on supporting dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device currently. <br />
* Support new QEMU parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
<br />
The new machine option s390-squash-css is added to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, as all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E).<br />
<br />
== Setup ==<br />
<br />
This example setup is done with a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Host ===<br />
<br />
* Kernel Configuration<br />
CONFIG_S390_CCW_IOMMU=m<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
* Modules Required<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
* You need to have a [https://en.wikipedia.org/wiki/Direct-access_storage_device DASD/ECKD] device as the target device.<br />
Find the subchannel (0.0."%schid") of your target DASD/ECKD device and bind the subchannel to the vfio_ccw driver.<br />
#find the DASD you can use with lsdasd on your host. e.g.:<br />
devno="7e52"<br />
schid="16ca"<br />
#unbind the CCW device from its subchannel<br />
echo 0.0."$devno" > /sys/bus/ccw/devices/0.0."$devno"/driver/unbind<br />
#unbind the subchannel from the I/O subchannel driver<br />
echo 0.0."$schid" > /sys/bus/css/devices/0.0."$schid"/driver/unbind<br />
#bind the subchannel to the vfio_ccw driver<br />
echo 0.0."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
* Create a Mediated Device for the phsical device<br />
#generate a uuid with uuidgen. e.g.:<br />
uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > /sys/bus/css/devices/0.0."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
=== Starting QEMU ===<br />
<br />
* Add a vfio-ccw device to your QEMU command line (machine needs to be <code>s390x-ccw-virtio</code>, with <code>s390-squash-css=on</code>). Example:<br />
-M s390-ccw-virtio,s390-squash-css=on \<br />
-device vfio-ccw,devno=0.0.1234,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...<br />
* Start QEMU. Your guest will be presented with a real Channel I/O device, with the example above, to be more specific, a DASD/ECKD device.<br />
<br />
=== Try the device on your Guest ===<br />
<br />
* The guest will see the DASD/ECKD as a channel-attached device. With the example above, the device will show up as 0.0.1234.<br />
<br />
* You can online the device by calling <code>chccwdev -e 0.0.1234</code> and use it as a block device.<br />
<br />
== Restrictions ==<br />
<br />
* Only target the I/O subchannels.<br />
* Only basic commands (read/write) are supported.<br />
* Some commands may need special handling in the future, for example, anything related to path grouping.</div>Dongjia.shihttps://wiki.qemu.org/index.php?title=Features/Channel_I/O_Passthrough&diff=6874Features/Channel I/O Passthrough2017-05-19T08:51:39Z<p>Dongjia.shi: Created page with "'''Notice: this page is still under construction''' The patch series introduce a basic channel I/O passthrough infrastructure based on vfio. * Focus on supporting dasd-eckd(c..."</p>
<hr />
<div>'''Notice: this page is still under construction'''<br />
<br />
The patch series introduce a basic channel I/O passthrough infrastructure based on vfio.<br />
* Focus on supporting dasd-eckd(cu_type/dev_type = 0x3990/0x3390) as the target device. <br />
* Support new qemu parameters in the style of:<br />
-machine s390-ccw-virtio(,s390-squash-mcss=on|off) \<br />
-device vfio-ccw,sysfsdev=$MDEV_PATH<br />
We want to support real (i.e. not virtual) channel devices even for guests that do not support MCSS-E (where guests may see devices from any channel subsystem image at once). As all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E), we need an option to squash e.g. passed-through channel devices from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css, that is what the new machine option s390-squash-css is added.<br />
<br />
== Setup ==<br />
<br />
This example setup is done with a Linux guest running in an s390x-ccw-virtio machine.<br />
<br />
=== Prereqs ===<br />
<br />
==== Kernel Configuration ====<br />
<br />
CONFIG_S390_CCW_IOMMU=m<br />
CONFIG_VFIO=m<br />
CONFIG_VFIO_MDEV=m<br />
CONFIG_VFIO_MDEV_DEVICE=m<br />
CONFIG_VFIO_CCW=m<br />
<br />
==== Modules Required ====<br />
<br />
modprobe vfio.ko<br />
modprobe mdev.ko<br />
modprobe vfio_mdev.ko<br />
modprobe vfio_iommu_type1.ko<br />
modprobe vfio_ccw.ko<br />
<br />
==== Prepare a Subchannel ====<br />
<br />
Find a subchannel(0.0."%schid") of a DASD-ECKD device and bind it to vfio_ccw driver.<br />
#find the dasd you can use with lsdasd on your host. e.g.:<br />
devno="7e52"<br />
schid="16ca"<br />
#unbind the ccw device from the subchannel<br />
echo 0.0."$devno" > /sys/bus/ccw/devices/0.0."$devno"/driver/unbind<br />
#unbind the subchannel from io_subchannel driver<br />
echo 0.0."$schid" > /sys/bus/css/devices/0.0."$schid"/driver/unbind<br />
#bind the subchannel with vfio_ccw driver<br />
echo 0.0."$schid" > /sys/bus/css/drivers/vfio_ccw/bind<br />
<br />
<br />
==== Create a Mediated Device ====<br />
<br />
#generate a uuid with uuidgen. e.g.:<br />
uuid="6dfd3ec5-e8b3-4e18-a6fe-57bc9eceb920"<br />
echo "$uuid" > \<br />
/sys/bus/css/devices/0.0."$schid"/mdev_supported_types/vfio_ccw-io/create<br />
<br />
<br />
=== Starting QEMU ===<br />
<br />
Pass-through this device to a vm:<br />
-M s390-ccw-virtio,s390-squash-css=on \<br />
-device vfio-ccw,sysfsdev=/sys/bus/mdev/devices/$uuid \<br />
... ...</div>Dongjia.shi