| 2019-11-20 14:19:53 |
bugproxy |
bug |
|
|
added bug |
| 2019-11-20 14:19:56 |
bugproxy |
tags |
|
architecture-s39064 bugnameltc-182255 severity-high targetmilestone-inin2004 |
|
| 2019-11-20 14:19:58 |
bugproxy |
ubuntu: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2019-11-20 14:20:00 |
bugproxy |
affects |
ubuntu |
qemu (Ubuntu) |
|
| 2019-11-20 14:20:02 |
bugproxy |
bug |
|
|
added subscriber CDE Administration |
| 2019-11-20 14:20:03 |
bugproxy |
bug |
|
|
added subscriber Heinz-Werner Seeck |
| 2019-11-20 14:20:05 |
bugproxy |
bug |
|
|
added subscriber Frank Heimes |
| 2019-11-20 14:20:06 |
bugproxy |
bug |
|
|
added subscriber Lou Peers |
| 2019-11-20 16:09:24 |
Frank Heimes |
bug task added |
|
ubuntu-z-systems |
|
| 2019-11-20 16:09:30 |
Frank Heimes |
qemu (Ubuntu): status |
New |
Incomplete |
|
| 2019-11-20 16:09:33 |
Frank Heimes |
ubuntu-z-systems: status |
New |
Incomplete |
|
| 2019-11-20 16:09:39 |
Frank Heimes |
ubuntu-z-systems: importance |
Undecided |
Medium |
|
| 2019-11-20 16:09:50 |
Frank Heimes |
ubuntu-z-systems: assignee |
|
Canonical Server Team (canonical-server) |
|
| 2019-11-20 16:09:59 |
Frank Heimes |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2019-11-25 09:53:08 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-182255 severity-high targetmilestone-inin2004 |
architecture-s39064 bugnameltc-182255 qemu-20.04 severity-high targetmilestone-inin2004 |
|
| 2020-01-12 21:12:56 |
Paul Collins |
removed subscriber Lou Peers |
|
|
|
| 2020-01-28 09:13:55 |
Heinz-Werner Seeck |
summary |
[20.04 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
[20.10 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
|
| 2020-01-28 09:18:30 |
bugproxy |
tags |
architecture-s39064 bugnameltc-182255 qemu-20.04 severity-high targetmilestone-inin2004 |
architecture-s39064 bugnameltc-182255 qemu-20.04 severity-high targetmilestone-inin2010 |
|
| 2020-01-28 10:02:16 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-182255 qemu-20.04 severity-high targetmilestone-inin2010 |
architecture-s39064 bugnameltc-182255 qemu-20.10 severity-high targetmilestone-inin2010 |
|
| 2020-08-27 06:27:03 |
Heinz-Werner Seeck |
summary |
[20.10 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
[21.04 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
|
| 2020-08-27 06:30:25 |
bugproxy |
tags |
architecture-s39064 bugnameltc-182255 qemu-20.10 severity-high targetmilestone-inin2010 |
architecture-s39064 bugnameltc-182255 qemu-20.10 severity-high targetmilestone-inin2104 |
|
| 2020-08-27 06:49:57 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-182255 qemu-20.10 severity-high targetmilestone-inin2104 |
architecture-s39064 bugnameltc-182255 qemu-21.04 severity-high targetmilestone-inin2104 |
|
| 2021-02-23 08:54:23 |
Heinz-Werner Seeck |
summary |
[21.04 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
[21.10 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
|
| 2021-02-23 08:59:03 |
bugproxy |
tags |
architecture-s39064 bugnameltc-182255 qemu-21.04 severity-high targetmilestone-inin2104 |
architecture-s39064 bugnameltc-182255 qemu-21.04 severity-high targetmilestone-inin2110 |
|
| 2021-02-23 09:03:56 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-182255 qemu-21.04 severity-high targetmilestone-inin2110 |
architecture-s39064 bugnameltc-182255 qemu-21.10 severity-high targetmilestone-inin2110 |
|
| 2021-06-18 09:25:08 |
Frank Heimes |
bug |
|
|
added subscriber Boris Barth |
| 2021-08-31 16:29:44 |
bugproxy |
tags |
architecture-s39064 bugnameltc-182255 qemu-21.10 severity-high targetmilestone-inin2110 |
architecture-s39064 bugnameltc-182255 qemu-21.10 severity-high targetmilestone-inin2204 |
|
| 2021-08-31 16:56:04 |
Frank Heimes |
summary |
[21.10 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
[22.04 FEAT] Enhanced Interpretation for PCI Functions - qemu part |
|
| 2021-09-01 14:14:12 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-182255 qemu-21.10 severity-high targetmilestone-inin2204 |
architecture-s39064 bugnameltc-182255 qemu-22.04 severity-high targetmilestone-inin2204 |
|
| 2022-08-22 14:31:53 |
Frank Heimes |
qemu (Ubuntu): status |
Incomplete |
New |
|
| 2022-08-22 14:31:54 |
Frank Heimes |
ubuntu-z-systems: status |
Incomplete |
New |
|
| 2022-09-05 05:00:56 |
Christian Ehrhardt |
tags |
architecture-s39064 bugnameltc-182255 qemu-22.04 severity-high targetmilestone-inin2204 |
architecture-s39064 bugnameltc-182255 qemu-23.04 severity-high targetmilestone-inin2204 |
|
| 2023-01-05 07:46:55 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
In Progress |
|
| 2023-01-05 09:34:13 |
Christian Ehrhardt |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/435185 |
|
| 2023-01-09 09:52:17 |
Frank Heimes |
ubuntu-z-systems: status |
New |
In Progress |
|
| 2023-01-09 09:52:51 |
Frank Heimes |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-01-09 09:52:51 |
Frank Heimes |
bug task added |
|
qemu (Ubuntu Lunar) |
|
| 2023-01-09 09:52:51 |
Frank Heimes |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-01-09 09:52:51 |
Frank Heimes |
bug task added |
|
qemu (Ubuntu Kinetic) |
|
| 2023-01-09 09:52:51 |
Frank Heimes |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-01-09 09:52:51 |
Frank Heimes |
bug task added |
|
qemu (Ubuntu Jammy) |
|
| 2023-01-09 09:53:09 |
Frank Heimes |
qemu (Ubuntu Lunar): assignee |
Skipper Bug Screeners (skipper-screen-team) |
Canonical Server (canonical-server) |
|
| 2023-01-09 09:53:22 |
Frank Heimes |
ubuntu-z-systems: assignee |
Canonical Server (canonical-server) |
Skipper Bug Screeners (skipper-screen-team) |
|
| 2023-02-15 12:44:23 |
Frank Heimes |
qemu (Ubuntu Lunar): status |
In Progress |
Fix Committed |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
qemu (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
bug watch added |
|
https://sourceware.org/bugzilla/show_bug.cgi?id=29514 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2020-14394 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2021-3507 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2022-0216 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2022-1050 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2022-2962 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2022-3165 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2022-35414 |
|
| 2023-03-06 17:25:14 |
Launchpad Janitor |
cve linked |
|
2022-4172 |
|
| 2023-03-06 19:52:44 |
Frank Heimes |
information type |
Private |
Public |
|
| 2023-05-17 14:30:54 |
bugproxy |
attachment added |
|
backport of 105bb7cdbe kvm: add support for boolean statistics https://bugs.launchpad.net/bugs/1853307/+attachment/5673570/+files/0001-kvm-add-support-for-boolean-statistics.patch |
|
| 2023-05-17 14:30:56 |
bugproxy |
attachment added |
|
backport of 67f7e426e5 hw/i386: pass RNG seed via setup_data entry https://bugs.launchpad.net/bugs/1853307/+attachment/5673571/+files/0002-hw-i386-pass-RNG-seed-via-setup_data-entry.patch |
|
| 2023-05-22 08:06:53 |
Christian Ehrhardt |
tags |
architecture-s39064 bugnameltc-182255 qemu-23.04 severity-high targetmilestone-inin2204 |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 |
|
| 2023-05-22 08:08:03 |
Christian Ehrhardt |
qemu (Ubuntu Kinetic): status |
New |
Won't Fix |
|
| 2023-05-22 08:08:09 |
Christian Ehrhardt |
qemu (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2023-07-03 08:13:53 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2023-07-03 08:14:52 |
Christian Ehrhardt |
qemu (Ubuntu Lunar): assignee |
Canonical Server (canonical-server) |
|
|
| 2023-07-04 13:34:28 |
Sergio Durigan Junior |
qemu (Ubuntu Jammy): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2023-07-05 14:44:44 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/qemu/+git/qemu/+merge/446081 |
|
| 2023-07-06 21:18:29 |
Sergio Durigan Junior |
description |
The PCI Passthrough implementation is based on intercepting PCI I/O instructions which leads to a reduced I/O performance compared to execution of PCI instructions in LPAR.
For improved performance the interpretive execution of the PCI store and PCI load instructions get enabled.
Further improvement is achieved by enabling the Adapter-Event-Notification Interpretation |
[ Impact ]
When using QEMU on s390x, the PCI passthrough feature is implemented by intercepting the PCI I/O operations (load/store), which ends up being less performant than executing those same instructions in an LPAR. The set of upstream patches being backported addresses this limitation by enabling interpretive execution of the PCI I/O instructions.
[ Test Plan ]
The test and verification steps will be performed by our partners at IBM.
[ Where problems could occur ]
The first potential problem here is the fact that we are backporting 22 upstream patches. Most of them relate solely to s390x, so there is some degree of confinement if a regression were to occur.
The patches have all been part of the upstream codebase for at least almost one year; some of them for even more time.
Another noteworthy point to make is the fact that the feature will be tested by IBM themselves, who authored the most important patches in the series. This gives us an extra level of confidence because of the expertise involved.
[ Other Info ]
This SRU implements support for a hardware feature on s390x in Jammy, and as such falls under the Hardware Enablement SRU exception.
[ Original Description ]
The PCI Passthrough implementation is based on intercepting PCI I/O instructions which leads to a reduced I/O performance compared to execution of PCI instructions in LPAR.
For improved performance the interpretive execution of the PCI store and PCI load instructions get enabled.
Further improvement is achieved by enabling the Adapter-Event-Notification Interpretation |
|
| 2023-07-08 03:43:53 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Sergio Durigan Junior |
| 2023-07-12 13:37:18 |
Robie Basak |
qemu (Ubuntu Jammy): status |
Confirmed |
Incomplete |
|
| 2023-07-18 14:29:29 |
Frank Heimes |
description |
[ Impact ]
When using QEMU on s390x, the PCI passthrough feature is implemented by intercepting the PCI I/O operations (load/store), which ends up being less performant than executing those same instructions in an LPAR. The set of upstream patches being backported addresses this limitation by enabling interpretive execution of the PCI I/O instructions.
[ Test Plan ]
The test and verification steps will be performed by our partners at IBM.
[ Where problems could occur ]
The first potential problem here is the fact that we are backporting 22 upstream patches. Most of them relate solely to s390x, so there is some degree of confinement if a regression were to occur.
The patches have all been part of the upstream codebase for at least almost one year; some of them for even more time.
Another noteworthy point to make is the fact that the feature will be tested by IBM themselves, who authored the most important patches in the series. This gives us an extra level of confidence because of the expertise involved.
[ Other Info ]
This SRU implements support for a hardware feature on s390x in Jammy, and as such falls under the Hardware Enablement SRU exception.
[ Original Description ]
The PCI Passthrough implementation is based on intercepting PCI I/O instructions which leads to a reduced I/O performance compared to execution of PCI instructions in LPAR.
For improved performance the interpretive execution of the PCI store and PCI load instructions get enabled.
Further improvement is achieved by enabling the Adapter-Event-Notification Interpretation |
[ Impact ]
When using QEMU on s390x, the PCI passthrough feature is implemented by intercepting the PCI I/O operations (load/store), which ends up being less performant than executing those same instructions in an LPAR. The set of upstream patches being backported addresses this limitation by enabling interpretive execution of the PCI I/O instructions.
[ Test Plan ]
* Hardware used: z14 or greater LPAR, PCI-attached devices
(RoCE VFs, ISM devices, NVMe drive)
* Setup: Both the kernel and QEMU features are needed for the feature
to function (an upstream QEMU can be used to verify the kernel early),
and the facility is only avaialble on z14 or newer.
When any of those pieces is missing,
the interpretation facility will not be used.
When both the kernel and QEMU features are included in their respective
packages, and running in an LPAR on a z14 or newer machine,
this feature will be enabled automatically.
Existing supported devices should behave as before with no changes
required by an end-user (e.g. no changes to libvirt domain definitions)
-- but will now make use of the interpretation facility.
Additionally, ISM devices will now be eligible for vfio-pci passthrough
(where before QEMU would exit on error if attempting to provide an ISM
device for vfio-pci passthrough, preventing the guest from starting)
* Testing will include the following scenarios, repeated each for RoCE,
ISM and NVMe:
1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusuable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)
Testing will include the following scenarios specifically for ISM devices:
1) Testing of SMC-D v1 fallback: Using 2 ISM devices on the same VCHID
that share a PNETID, create 2 guests and pass one ISM device
via vfio-pci device to each guest.
Establish TCP connectivity between the 2 guests using the libvirt
default network, and then use smc_run
(https://manpages.ubuntu.com/manpages/jammy/man8/smc_run.8.html)
to run an iperf workload between the 2 guests (will include both
short workloads and longer-running workloads).
Verify that SMC-D transfer was used between the guests instead
of TCP via 'smcd stats'
(https://manpages.ubuntu.com/manpages/jammy/man8/smcd.8.html)
2) Testing of SMC-D v2: Same as above,
but using 2 ISM devices on the same VCHID that have no PNETID specified
Testing will include the following scenarios specifically for RoCE devices:
1) Ping testing: Using 2 RoCE VFs that share a common network,
create 2 guests and pass one RoCE device to each guest.
Assign IP addresses within each guest to the associated TCP interface,
perform a ping between the guests to verify connectivity.
2) Iperf testing: Similar to the above, but instead establish an iperf
connection between the 2 guests and verify that the workload
is successful / no errors.
Will include both short workloads and longer-running workloads.
Testing will include the following scenario specifically for NVMe devices:
1) Fio testing: Using a NVMe drive passed to the guest via vfio-pci,
run a series of fio tests against the device from within the guest,
verifying that the workload is successful / no errors.
Will include both short workloads and longer-running workloads.
[ Where problems could occur ]
The first potential problem here is the fact that we are backporting 22 upstream patches. Most of them relate solely to s390x, so there is some degree of confinement if a regression were to occur.
The patches have all been part of the upstream codebase for at least almost one year; some of them for even more time.
Another noteworthy point to make is the fact that the feature will be tested by IBM themselves, who authored the most important patches in the series. This gives us an extra level of confidence because of the expertise involved.
[ Other Info ]
This SRU implements support for a hardware feature on s390x in Jammy, and as such falls under the Hardware Enablement SRU exception.
[ Original Description ]
The PCI Passthrough implementation is based on intercepting PCI I/O instructions which leads to a reduced I/O performance compared to execution of PCI instructions in LPAR.
For improved performance the interpretive execution of the PCI store and PCI load instructions get enabled.
Further improvement is achieved by enabling the Adapter-Event-Notification Interpretation |
|
| 2023-07-18 14:43:09 |
Sergio Durigan Junior |
qemu (Ubuntu Jammy): status |
Incomplete |
In Progress |
|
| 2023-07-18 14:49:01 |
Frank Heimes |
qemu (Ubuntu Jammy): status |
In Progress |
Confirmed |
|
| 2023-07-18 14:49:09 |
Frank Heimes |
qemu (Ubuntu Jammy): status |
Confirmed |
In Progress |
|
| 2023-08-03 19:58:01 |
Sergio Durigan Junior |
description |
[ Impact ]
When using QEMU on s390x, the PCI passthrough feature is implemented by intercepting the PCI I/O operations (load/store), which ends up being less performant than executing those same instructions in an LPAR. The set of upstream patches being backported addresses this limitation by enabling interpretive execution of the PCI I/O instructions.
[ Test Plan ]
* Hardware used: z14 or greater LPAR, PCI-attached devices
(RoCE VFs, ISM devices, NVMe drive)
* Setup: Both the kernel and QEMU features are needed for the feature
to function (an upstream QEMU can be used to verify the kernel early),
and the facility is only avaialble on z14 or newer.
When any of those pieces is missing,
the interpretation facility will not be used.
When both the kernel and QEMU features are included in their respective
packages, and running in an LPAR on a z14 or newer machine,
this feature will be enabled automatically.
Existing supported devices should behave as before with no changes
required by an end-user (e.g. no changes to libvirt domain definitions)
-- but will now make use of the interpretation facility.
Additionally, ISM devices will now be eligible for vfio-pci passthrough
(where before QEMU would exit on error if attempting to provide an ISM
device for vfio-pci passthrough, preventing the guest from starting)
* Testing will include the following scenarios, repeated each for RoCE,
ISM and NVMe:
1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusuable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)
Testing will include the following scenarios specifically for ISM devices:
1) Testing of SMC-D v1 fallback: Using 2 ISM devices on the same VCHID
that share a PNETID, create 2 guests and pass one ISM device
via vfio-pci device to each guest.
Establish TCP connectivity between the 2 guests using the libvirt
default network, and then use smc_run
(https://manpages.ubuntu.com/manpages/jammy/man8/smc_run.8.html)
to run an iperf workload between the 2 guests (will include both
short workloads and longer-running workloads).
Verify that SMC-D transfer was used between the guests instead
of TCP via 'smcd stats'
(https://manpages.ubuntu.com/manpages/jammy/man8/smcd.8.html)
2) Testing of SMC-D v2: Same as above,
but using 2 ISM devices on the same VCHID that have no PNETID specified
Testing will include the following scenarios specifically for RoCE devices:
1) Ping testing: Using 2 RoCE VFs that share a common network,
create 2 guests and pass one RoCE device to each guest.
Assign IP addresses within each guest to the associated TCP interface,
perform a ping between the guests to verify connectivity.
2) Iperf testing: Similar to the above, but instead establish an iperf
connection between the 2 guests and verify that the workload
is successful / no errors.
Will include both short workloads and longer-running workloads.
Testing will include the following scenario specifically for NVMe devices:
1) Fio testing: Using a NVMe drive passed to the guest via vfio-pci,
run a series of fio tests against the device from within the guest,
verifying that the workload is successful / no errors.
Will include both short workloads and longer-running workloads.
[ Where problems could occur ]
The first potential problem here is the fact that we are backporting 22 upstream patches. Most of them relate solely to s390x, so there is some degree of confinement if a regression were to occur.
The patches have all been part of the upstream codebase for at least almost one year; some of them for even more time.
Another noteworthy point to make is the fact that the feature will be tested by IBM themselves, who authored the most important patches in the series. This gives us an extra level of confidence because of the expertise involved.
[ Other Info ]
This SRU implements support for a hardware feature on s390x in Jammy, and as such falls under the Hardware Enablement SRU exception.
[ Original Description ]
The PCI Passthrough implementation is based on intercepting PCI I/O instructions which leads to a reduced I/O performance compared to execution of PCI instructions in LPAR.
For improved performance the interpretive execution of the PCI store and PCI load instructions get enabled.
Further improvement is achieved by enabling the Adapter-Event-Notification Interpretation |
[ Impact ]
When using QEMU on s390x, the PCI passthrough feature is implemented by intercepting the PCI I/O operations (load/store), which ends up being less performant than executing those same instructions in an LPAR. The set of upstream patches being backported addresses this limitation by enabling interpretive execution of the PCI I/O instructions.
[ Test Plan ]
* Hardware used: z14 or greater LPAR, PCI-attached devices
(RoCE VFs, ISM devices, NVMe drive)
* Setup: Both the kernel and QEMU features are needed for the feature
to function (an upstream QEMU can be used to verify the kernel early),
and the facility is only avaialble on z14 or newer.
When any of those pieces is missing,
the interpretation facility will not be used.
When both the kernel and QEMU features are included in their respective
packages, and running in an LPAR on a z14 or newer machine,
this feature will be enabled automatically.
Existing supported devices should behave as before with no changes
required by an end-user (e.g. no changes to libvirt domain definitions)
-- but will now make use of the interpretation facility.
Additionally, ISM devices will now be eligible for vfio-pci passthrough
(where before QEMU would exit on error if attempting to provide an ISM
device for vfio-pci passthrough, preventing the guest from starting)
* Testing will include the following scenarios, repeated each for RoCE,
ISM and NVMe:
1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusuable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)
Testing will include the following scenarios specifically for ISM devices:
1) Testing of SMC-D v1 fallback: Using 2 ISM devices on the same VCHID
that share a PNETID, create 2 guests and pass one ISM device
via vfio-pci device to each guest.
Establish TCP connectivity between the 2 guests using the libvirt
default network, and then use smc_run
(https://manpages.ubuntu.com/manpages/jammy/man8/smc_run.8.html)
to run an iperf workload between the 2 guests (will include both
short workloads and longer-running workloads).
Verify that SMC-D transfer was used between the guests instead
of TCP via 'smcd stats'
(https://manpages.ubuntu.com/manpages/jammy/man8/smcd.8.html)
2) Testing of SMC-D v2: Same as above,
but using 2 ISM devices on the same VCHID that have no PNETID specified
Testing will include the following scenarios specifically for RoCE devices:
1) Ping testing: Using 2 RoCE VFs that share a common network,
create 2 guests and pass one RoCE device to each guest.
Assign IP addresses within each guest to the associated TCP interface,
perform a ping between the guests to verify connectivity.
2) Iperf testing: Similar to the above, but instead establish an iperf
connection between the 2 guests and verify that the workload
is successful / no errors.
Will include both short workloads and longer-running workloads.
Testing will include the following scenario specifically for NVMe devices:
1) Fio testing: Using a NVMe drive passed to the guest via vfio-pci,
run a series of fio tests against the device from within the guest,
verifying that the workload is successful / no errors.
Will include both short workloads and longer-running workloads.
Aside from the extensive test described above, we will also run the qemu-migration-test (<https://code.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/+git/qemu-migration-test>) to guarantee that non-s390x architectures aren't affected by the set of patches being backported.
[ Where problems could occur ]
The first potential problem here is the fact that we are backporting 22 upstream patches. Most of them relate solely to s390x, so there is some degree of confinement if a regression were to occur.
The patches have all been part of the upstream codebase for at least almost one year; some of them for even more time.
Another noteworthy point to make is the fact that the feature will be tested by IBM themselves, who authored the most important patches in the series. This gives us an extra level of confidence because of the expertise involved.
[ Other Info ]
This SRU implements support for a hardware feature on s390x in Jammy, and as such falls under the Hardware Enablement SRU exception.
[ Original Description ]
The PCI Passthrough implementation is based on intercepting PCI I/O instructions which leads to a reduced I/O performance compared to execution of PCI instructions in LPAR.
For improved performance the interpretive execution of the PCI store and PCI load instructions get enabled.
Further improvement is achieved by enabling the Adapter-Event-Notification Interpretation |
|
| 2023-08-03 20:02:14 |
Andreas Hasenack |
qemu (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2023-08-03 20:02:16 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-08-03 20:02:21 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2023-08-03 20:02:34 |
Andreas Hasenack |
tags |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-needed verification-needed-jammy |
|
| 2023-08-05 13:46:17 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Fix Committed |
|
| 2023-08-16 18:19:56 |
bugproxy |
tags |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-needed verification-needed-jammy |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-done-jammy verification-needed |
|
| 2023-08-16 21:09:53 |
bugproxy |
tags |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-done-jammy verification-needed |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-done verification-done-jammy |
|
| 2023-08-23 12:19:07 |
Andreas Hasenack |
tags |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-done verification-done-jammy |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-needed verification-needed-jammy |
|
| 2023-08-31 01:11:57 |
Sergio Durigan Junior |
tags |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-needed verification-needed-jammy |
architecture-s39064 bugnameltc-182255 qemu-23.04 server-todo severity-high targetmilestone-inin2204 verification-done verification-done-jammy |
|
| 2023-08-31 19:29:23 |
Launchpad Janitor |
qemu (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-08-31 19:29:28 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-08-31 19:49:07 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
Fix Released |
|
