Re: [Qemu-devel] [RFC PATCH v2 1/1] s390x/css: unrestrict cssids

[Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>]

* Halil Pasic <pasic@linux.vnet.ibm.com> [2017-11-28 14:07:58 +0100]:

[...]
> 
> The auto-generated bus ids are affected by both changes. 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.
> I find it hard to reason about the impact of changed auto-generated bus
> ids on migration for command line users as I don't know which rules is
> such an user supposed to follow.
For this paragraph, Halil pointed to me a case that he is thinking of.
1. VM configuration with 3 devices:
  -device virtio (e.g. virtio-blk-ccw,id=disk0)
  -device vfio-ccw (e.g. id=vfio0)
  -device virtio (e.g. virtio-rng-ccw,id=rng0)
2. Start the vm.
3. device_del vfio0
4. migrate "exec:gzip -c > /tmp/tmp_vmstate.gz"
5. modify cmd line from step 1 by removing the vfio0 device, and adding:
   -incoming "exec:gzip -c -d /tmp/tmp_vmstate.gz"

Let me list my test results here for everybody's reference.

W/o this patch
==============

------------+---------------+-------------
            | squashing off | squashing on
------------+---------------+-------------
    auto id |        F      |     F
------------+---------------+-------------
explicit id |        F      |     S
------------+---------------+-------------

T1. squashing off + auto id
  qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER
  qemu-system-s390x: Failed to load s390_css:css
  qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'
  qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to css mismatch - there is no css 0 in the new vm.]

T2. squashing off + explicit given id
  qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER
  qemu-system-s390x: Failed to load s390_css:css
  qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'
  qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to css mismatch - there is no css 0 in the new vm.]

T3. squashing on  + auto id
  qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0
  qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to busid mismatch.]

T4. squashing on  + explicit given id
  Succeed.

With this patch
===============

------------+---------------+-------------
            | squashing off | squashing on
------------+---------------+-------------
    auto id |        F      |     F
------------+---------------+-------------
explicit id |        S'     |     S
------------+---------------+-------------

T5. squashing off + auto id
  qemu-system-s390x: Unknown savevm section or instance '/fe.0.0003/virtio-rng' 0
  qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to busid mismatch.]

T6. squashing off + explicit given id
  qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER
  qemu-system-s390x: Failed to load s390_css:css
  qemu-system-s390x: error while loading state for instance 0x0 of device 's390_css'
  qemu-system-s390x: load of migration failed: Invalid argument
[Setting vfio-ccw.devno=non-fe.x.xxxx. (same as T1)
 Fail due to css mismatch - there is no css 0 in the new vm.]

  Succeed.
[Setting vfio-ccw.devno=fe.x.xxxx.]

T7. squashing on  + auto id
  qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0
  qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to busid mismatch.]

T8. squashing on  + explicit given id
  Succeed.


Notice:
The differences of the test results between w and w/o this patch are in
the "squashing off" cases. I think these are things that we can accept.

[...]

-- 
Dong Jia Shi