Comment 7 for bug 1800649

Hi,
we can certainly help trying to make a test PPA available for your testing backporting what you provided here.

I wonder about the git tree at [1]. It is already further than what was reported a few days before. It is based on qemu v3.1.0-rc0 at the moment and has 11 patches . Some of the series listed here, some new ones. In any case it does not seem complete or fully upstreamed yet.
But eventually these things should be upstream in qemu before being picked into the current Ubuntu development release (19.04) and then planning SRUs from there.

Since I don't know about the interim state of the repo I'll pick the listed changes for now.

I was told that your target is Ubuntu 18.04 which means qemu 2.11 has to be the target unless you are fine with e.g. Ubuntu Cloud Archive Stein [3] which would eventually if the current plan holds true be on qemu 3.1 at least - much closer for the backports.
Or if it will be a PPA based solution anyway something like qemu 3.1 + changes in that PPA.

The backports of that series provided here to qemu 2.11 which would be needed for a real SRU release into Ubuntu 18.04:

OK 0001-qdev-Use-string-for-QOM-string-properties.patch

NOISE in 0002-ppc-spapr-Receive-and-store-device-tree-blob-from-SL.patch
  spapr_machine_reset was still ppc_spapr_reset
  Also this changes vmstate which I think would create a migration issue, so we'd need an extra
  machine type I think.
  This always as a big NONO for real SRUs - this makes this even more an only-PPA solution IMHO.

OK 0003-DBG-store-fdt.patch

Minor Noise 0004-vfio-spapr-Fix-indirect-levels-calculation.patch

Noise 0005-headers-update.patch
Noise 0006-pci-Move-NVIDIA-vendor-id-to-the-rest-of-ids.patch
Noise 0007-RFC-vfio-nvidia-v100-Disable-VBIOS-update.patch
Noise 0008-spapr-iommu-Always-advertise-the-maximum-possible-DM.patch
  The noise for all these is not too much form a code level, the context can be found.
  But I get the feeling I'll see this as a compile fail missing
  some other changes it depends on.

OK 0009-FIXME-vfio-Do-not-replay-IOMMU-mappings.patch

Minor Noise 0010-vfio-Make-vfio_get_region_info_cap-public.patch

OK - 0011-vfio-spapr-Try-allocating-less-levels-if-failed-with.patch

Noise - 0012-spapr-Add-NVLink2-memory-to-PHB-placement.patch

OK - 0013-spapr-Create-ibm-gpu-and-ibm-npu-cross-links-in-the-.patch

Noise - 0014-spapr-vfio-Map-GPU-RAM-and-advertise-to-the-guest.patch

Noise - 0015-debug-Disables-KVM-TCE-acceleration-and-direct-ATSD-.patch
  In general this is WIP still, because that makes not much sense:
  6 cap_spapr_vfio = kvm_vm_check_extension(s, KVM_CAP_SPAPR_TCE_VFIO);
  7 + cap_spapr_vfio = false;

With the related kernel being a special kernel I can't SRU it generally anyway.
And all the problems outlined above emphasize that.
So I wonder what is the actual delivery mechanism and content expected here?
Would a qemu 3.1 in a PP alongside the kernel do it - there the backport distance certainly would be much less?
That could eventually be replaced in the PPA with the more polished final qmeu 3.1 we will create for Ubuntu 19.04.

I have pushed a packetized and backported version of this at [4] but I'm 98% sure it will fail to build [5] as it is right now.

TL;DR:
- From what I see in the code this will most likely never be SRUable to 18.04
- as-is this won't go further on 18.04 (Bionic) qemu
- I need more details about the required delivery content (minimum qemu x.y?)
- I need more details about the required delivery content (version&state of patches git vs bug attachment)
- I need more details about the required delivery path (PPA along kernel?)
- I need more details about the required delivery path (Later update policy?)

[1]: https://github.com/aik/qemu/tree/nv2
[2]: https://wiki.ubuntu.com/StableReleaseUpdates
[3]: https://wiki.ubuntu.com/OpenStack/CloudArchive
[4]: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+ref/test-backport-1800649-nvlink2-ppc
[5]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3518/+packages