[PATCH 0/5] cpu_map: Add missing -v1 models

Jiri Denemark posted 5 patches 3 weeks, 6 days ago
There is a newer version of this series
src/cpu_map/index.xml                         |  2 +
src/cpu_map/meson.build                       | 18 +++---
src/cpu_map/sync_qemu_models_i386.py          | 58 +++++++++++++++++++
src/cpu_map/x86_EPYC-Genoa-v1.xml             |  6 ++
src/cpu_map/x86_KnightsMill-v1.xml            |  6 ++
.../domaincapsdata/qemu_5.2.0-q35.x86_64.xml  | 14 ++++-
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml  | 20 ++++++-
tests/domaincapsdata/qemu_5.2.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml  | 14 ++++-
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml  | 20 ++++++-
tests/domaincapsdata/qemu_6.0.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml  | 14 ++++-
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml  | 20 ++++++-
tests/domaincapsdata/qemu_6.1.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml  | 14 ++++-
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml  | 20 ++++++-
tests/domaincapsdata/qemu_6.2.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml  | 14 ++++-
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml  | 20 ++++++-
tests/domaincapsdata/qemu_7.0.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml  | 14 ++++-
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml  | 20 ++++++-
tests/domaincapsdata/qemu_7.1.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_7.2.0-q35.x86_64.xml  | 14 ++++-
.../qemu_7.2.0-tcg.x86_64+hvf.xml             | 16 ++++-
.../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml  | 16 ++++-
tests/domaincapsdata/qemu_7.2.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_8.0.0-q35.x86_64.xml  | 14 ++++-
.../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml  | 16 ++++-
tests/domaincapsdata/qemu_8.0.0.x86_64.xml    | 14 ++++-
.../domaincapsdata/qemu_8.1.0-q35.x86_64.xml  | 46 ++++++++++++++-
.../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml  | 56 +++++++++++++++++-
tests/domaincapsdata/qemu_8.1.0.x86_64.xml    | 46 ++++++++++++++-
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml  | 46 ++++++++++++++-
.../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml  | 55 +++++++++++++++++-
tests/domaincapsdata/qemu_8.2.0.x86_64.xml    | 46 ++++++++++++++-
.../domaincapsdata/qemu_9.0.0-q35.x86_64.xml  | 46 ++++++++++++++-
.../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
tests/domaincapsdata/qemu_9.0.0.x86_64.xml    | 46 ++++++++++++++-
.../domaincapsdata/qemu_9.1.0-q35.x86_64.xml  | 46 ++++++++++++++-
.../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
tests/domaincapsdata/qemu_9.1.0.x86_64.xml    | 46 ++++++++++++++-
.../domaincapsdata/qemu_9.2.0-q35.x86_64.xml  | 46 ++++++++++++++-
.../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
tests/domaincapsdata/qemu_9.2.0.x86_64.xml    | 46 ++++++++++++++-
45 files changed, 1152 insertions(+), 63 deletions(-)
create mode 100644 src/cpu_map/x86_EPYC-Genoa-v1.xml
create mode 100644 src/cpu_map/x86_KnightsMill-v1.xml
[PATCH 0/5] cpu_map: Add missing -v1 models
Posted by Jiri Denemark 3 weeks, 6 days ago
CPU models that do not have a list of versions attached are still
advertised as aliases to corresponding -v1 variants. We should add the
missing variants to the CPU map.

Available on gitlab:

    git fetch https://gitlab.com/jirkade/libvirt.git cpu-versions

Pipeline: https://gitlab.com/jirkade/libvirt/-/pipelines/1564399375

Jiri Denemark (5):
  cpu_map: Sort data files in meson.build
  sync_qemu_models_i386: Update meson.build
  sync_qemu_models_i386: Ignore old models
  sync_qemu_models_i386: Generate missing -v1 variants
  cpu_map: Add missing -v1 models

 src/cpu_map/index.xml                         |  2 +
 src/cpu_map/meson.build                       | 18 +++---
 src/cpu_map/sync_qemu_models_i386.py          | 58 +++++++++++++++++++
 src/cpu_map/x86_EPYC-Genoa-v1.xml             |  6 ++
 src/cpu_map/x86_KnightsMill-v1.xml            |  6 ++
 .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml  | 14 ++++-
 .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml  | 20 ++++++-
 tests/domaincapsdata/qemu_5.2.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml  | 14 ++++-
 .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml  | 20 ++++++-
 tests/domaincapsdata/qemu_6.0.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml  | 14 ++++-
 .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml  | 20 ++++++-
 tests/domaincapsdata/qemu_6.1.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml  | 14 ++++-
 .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml  | 20 ++++++-
 tests/domaincapsdata/qemu_6.2.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml  | 14 ++++-
 .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml  | 20 ++++++-
 tests/domaincapsdata/qemu_7.0.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml  | 14 ++++-
 .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml  | 20 ++++++-
 tests/domaincapsdata/qemu_7.1.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml  | 14 ++++-
 .../qemu_7.2.0-tcg.x86_64+hvf.xml             | 16 ++++-
 .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml  | 16 ++++-
 tests/domaincapsdata/qemu_7.2.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml  | 14 ++++-
 .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml  | 16 ++++-
 tests/domaincapsdata/qemu_8.0.0.x86_64.xml    | 14 ++++-
 .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml  | 46 ++++++++++++++-
 .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml  | 56 +++++++++++++++++-
 tests/domaincapsdata/qemu_8.1.0.x86_64.xml    | 46 ++++++++++++++-
 .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml  | 46 ++++++++++++++-
 .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml  | 55 +++++++++++++++++-
 tests/domaincapsdata/qemu_8.2.0.x86_64.xml    | 46 ++++++++++++++-
 .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml  | 46 ++++++++++++++-
 .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
 tests/domaincapsdata/qemu_9.0.0.x86_64.xml    | 46 ++++++++++++++-
 .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml  | 46 ++++++++++++++-
 .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
 tests/domaincapsdata/qemu_9.1.0.x86_64.xml    | 46 ++++++++++++++-
 .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml  | 46 ++++++++++++++-
 .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
 tests/domaincapsdata/qemu_9.2.0.x86_64.xml    | 46 ++++++++++++++-
 45 files changed, 1152 insertions(+), 63 deletions(-)
 create mode 100644 src/cpu_map/x86_EPYC-Genoa-v1.xml
 create mode 100644 src/cpu_map/x86_KnightsMill-v1.xml

-- 
2.47.0
Re: [PATCH 0/5] cpu_map: Add missing -v1 models
Posted by Han Han 3 weeks, 6 days ago
Tested on this branch with qemu-kvm-9.1.0-5.el9.x86_64:
# for i in $(/usr/libexec/qemu-kvm -cpu help|grep deprecated -v|awk
'/Available CPUs/,/Recognized CPUID flags/'|grep '^  '|awk '{print $1}');do
if ! virsh cpu-models x86_64|grep -q $i;then echo $i;fi;done
Opteron_G4-v1
Opteron_G5-v1
base
host
max

Opteron_G4-v1 and Opteron_G5-v1 are not deprecated. Expect to add them to
libvirt CPU models as well.
On Thu, Nov 28, 2024 at 9:47 PM Jiri Denemark <jdenemar@redhat.com> wrote:

> CPU models that do not have a list of versions attached are still
> advertised as aliases to corresponding -v1 variants. We should add the
> missing variants to the CPU map.
>
> Available on gitlab:
>
>     git fetch https://gitlab.com/jirkade/libvirt.git cpu-versions
>
> Pipeline: https://gitlab.com/jirkade/libvirt/-/pipelines/1564399375
>
> Jiri Denemark (5):
>   cpu_map: Sort data files in meson.build
>   sync_qemu_models_i386: Update meson.build
>   sync_qemu_models_i386: Ignore old models
>   sync_qemu_models_i386: Generate missing -v1 variants
>   cpu_map: Add missing -v1 models
>
>  src/cpu_map/index.xml                         |  2 +
>  src/cpu_map/meson.build                       | 18 +++---
>  src/cpu_map/sync_qemu_models_i386.py          | 58 +++++++++++++++++++
>  src/cpu_map/x86_EPYC-Genoa-v1.xml             |  6 ++
>  src/cpu_map/x86_KnightsMill-v1.xml            |  6 ++
>  .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml  | 14 ++++-
>  .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml  | 20 ++++++-
>  tests/domaincapsdata/qemu_5.2.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml  | 14 ++++-
>  .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml  | 20 ++++++-
>  tests/domaincapsdata/qemu_6.0.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml  | 14 ++++-
>  .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml  | 20 ++++++-
>  tests/domaincapsdata/qemu_6.1.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml  | 14 ++++-
>  .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml  | 20 ++++++-
>  tests/domaincapsdata/qemu_6.2.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml  | 14 ++++-
>  .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml  | 20 ++++++-
>  tests/domaincapsdata/qemu_7.0.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml  | 14 ++++-
>  .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml  | 20 ++++++-
>  tests/domaincapsdata/qemu_7.1.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml  | 14 ++++-
>  .../qemu_7.2.0-tcg.x86_64+hvf.xml             | 16 ++++-
>  .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml  | 16 ++++-
>  tests/domaincapsdata/qemu_7.2.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml  | 14 ++++-
>  .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml  | 16 ++++-
>  tests/domaincapsdata/qemu_8.0.0.x86_64.xml    | 14 ++++-
>  .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml  | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml  | 56 +++++++++++++++++-
>  tests/domaincapsdata/qemu_8.1.0.x86_64.xml    | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml  | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml  | 55 +++++++++++++++++-
>  tests/domaincapsdata/qemu_8.2.0.x86_64.xml    | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml  | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
>  tests/domaincapsdata/qemu_9.0.0.x86_64.xml    | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml  | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
>  tests/domaincapsdata/qemu_9.1.0.x86_64.xml    | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml  | 46 ++++++++++++++-
>  .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml  | 54 ++++++++++++++++-
>  tests/domaincapsdata/qemu_9.2.0.x86_64.xml    | 46 ++++++++++++++-
>  45 files changed, 1152 insertions(+), 63 deletions(-)
>  create mode 100644 src/cpu_map/x86_EPYC-Genoa-v1.xml
>  create mode 100644 src/cpu_map/x86_KnightsMill-v1.xml
>
> --
> 2.47.0
>
>
Re: [PATCH 0/5] cpu_map: Add missing -v1 models
Posted by Jiri Denemark 3 weeks, 6 days ago
On Fri, Nov 29, 2024 at 12:33:19 +0800, Han Han wrote:
> Tested on this branch with qemu-kvm-9.1.0-5.el9.x86_64:
> # for i in $(/usr/libexec/qemu-kvm -cpu help|grep deprecated -v|awk
> '/Available CPUs/,/Recognized CPUID flags/'|grep '^  '|awk '{print $1}');do
> if ! virsh cpu-models x86_64|grep -q $i;then echo $i;fi;done
> Opteron_G4-v1
> Opteron_G5-v1
> base
> host
> max
> 
> Opteron_G4-v1 and Opteron_G5-v1 are not deprecated. Expect to add them to
> libvirt CPU models as well.

I was not really sure which CPU models are deprecated. According to QEMU
none of them is really deprecated (the only CPU model that was ever
deprecated was Icelake-Client, which was later dropped completely). The
info you use is apparently coming from downstream QEMU, because upstream
shows nothing for "qemu-system-x86_64 -cpu help | grep deprecated".

I guess we can use the info to say Opteron_G4 and Opteron_G5 should not
be ignored by the script, I'm not sure we could use it the other way
around for selecting which models are considered deprecated.

Jirka
Re: [PATCH 0/5] cpu_map: Add missing -v1 models
Posted by Daniel P. Berrangé 3 weeks, 6 days ago
On Fri, Nov 29, 2024 at 09:50:01AM +0100, Jiri Denemark wrote:
> On Fri, Nov 29, 2024 at 12:33:19 +0800, Han Han wrote:
> > Tested on this branch with qemu-kvm-9.1.0-5.el9.x86_64:
> > # for i in $(/usr/libexec/qemu-kvm -cpu help|grep deprecated -v|awk
> > '/Available CPUs/,/Recognized CPUID flags/'|grep '^  '|awk '{print $1}');do
> > if ! virsh cpu-models x86_64|grep -q $i;then echo $i;fi;done
> > Opteron_G4-v1
> > Opteron_G5-v1
> > base
> > host
> > max
> > 
> > Opteron_G4-v1 and Opteron_G5-v1 are not deprecated. Expect to add them to
> > libvirt CPU models as well.
> 
> I was not really sure which CPU models are deprecated. According to QEMU
> none of them is really deprecated (the only CPU model that was ever
> deprecated was Icelake-Client, which was later dropped completely). The
> info you use is apparently coming from downstream QEMU, because upstream
> shows nothing for "qemu-system-x86_64 -cpu help | grep deprecated".

Correct, deprecation of CPUs is a decision RHEL makes downstream, and is
not relevant to libvirt's upstream  usage.

Libvirt queries QEMU deprecations, so if a user picks a deprecated CPU,
their VM will be tainted and show the deprecation message in logs, etc.

> I guess we can use the info to say Opteron_G4 and Opteron_G5 should not
> be ignored by the script, I'm not sure we could use it the other way
> around for selecting which models are considered deprecated.

We should always honour all CPUs QEMU reports as existing. Deprecated CPUs
are still supported for use, it is merely a warning that they /may/ go away
in future.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [PATCH 0/5] cpu_map: Add missing -v1 models
Posted by Jiri Denemark 3 weeks, 1 day ago
On Fri, Nov 29, 2024 at 09:03:11 +0000, Daniel P. Berrangé wrote:
> On Fri, Nov 29, 2024 at 09:50:01AM +0100, Jiri Denemark wrote:
> > On Fri, Nov 29, 2024 at 12:33:19 +0800, Han Han wrote:
> > > Tested on this branch with qemu-kvm-9.1.0-5.el9.x86_64:
> > > # for i in $(/usr/libexec/qemu-kvm -cpu help|grep deprecated -v|awk
> > > '/Available CPUs/,/Recognized CPUID flags/'|grep '^  '|awk '{print $1}');do
> > > if ! virsh cpu-models x86_64|grep -q $i;then echo $i;fi;done
> > > Opteron_G4-v1
> > > Opteron_G5-v1
> > > base
> > > host
> > > max
> > > 
> > > Opteron_G4-v1 and Opteron_G5-v1 are not deprecated. Expect to add them to
> > > libvirt CPU models as well.
> > 
> > I was not really sure which CPU models are deprecated. According to QEMU
> > none of them is really deprecated (the only CPU model that was ever
> > deprecated was Icelake-Client, which was later dropped completely). The
> > info you use is apparently coming from downstream QEMU, because upstream
> > shows nothing for "qemu-system-x86_64 -cpu help | grep deprecated".
> 
> Correct, deprecation of CPUs is a decision RHEL makes downstream, and is
> not relevant to libvirt's upstream  usage.
> 
> Libvirt queries QEMU deprecations, so if a user picks a deprecated CPU,
> their VM will be tainted and show the deprecation message in logs, etc.
> 
> > I guess we can use the info to say Opteron_G4 and Opteron_G5 should not
> > be ignored by the script, I'm not sure we could use it the other way
> > around for selecting which models are considered deprecated.
> 
> We should always honour all CPUs QEMU reports as existing. Deprecated CPUs
> are still supported for use, it is merely a warning that they /may/ go away
> in future.

So do you suggest we should not ignore even those ancient lower case CPU
models and add their -v1 variants as well? That would seems to me like a
lot of churn with no benefit. Although there's no technical reason for
ignoring them.

Jirka
Re: [PATCH 0/5] cpu_map: Add missing -v1 models
Posted by Daniel P. Berrangé 2 weeks, 6 days ago
On Tue, Dec 03, 2024 at 01:14:07PM +0100, Jiri Denemark wrote:
> On Fri, Nov 29, 2024 at 09:03:11 +0000, Daniel P. Berrangé wrote:
> > On Fri, Nov 29, 2024 at 09:50:01AM +0100, Jiri Denemark wrote:
> > > On Fri, Nov 29, 2024 at 12:33:19 +0800, Han Han wrote:
> > > > Tested on this branch with qemu-kvm-9.1.0-5.el9.x86_64:
> > > > # for i in $(/usr/libexec/qemu-kvm -cpu help|grep deprecated -v|awk
> > > > '/Available CPUs/,/Recognized CPUID flags/'|grep '^  '|awk '{print $1}');do
> > > > if ! virsh cpu-models x86_64|grep -q $i;then echo $i;fi;done
> > > > Opteron_G4-v1
> > > > Opteron_G5-v1
> > > > base
> > > > host
> > > > max
> > > > 
> > > > Opteron_G4-v1 and Opteron_G5-v1 are not deprecated. Expect to add them to
> > > > libvirt CPU models as well.
> > > 
> > > I was not really sure which CPU models are deprecated. According to QEMU
> > > none of them is really deprecated (the only CPU model that was ever
> > > deprecated was Icelake-Client, which was later dropped completely). The
> > > info you use is apparently coming from downstream QEMU, because upstream
> > > shows nothing for "qemu-system-x86_64 -cpu help | grep deprecated".
> > 
> > Correct, deprecation of CPUs is a decision RHEL makes downstream, and is
> > not relevant to libvirt's upstream  usage.
> > 
> > Libvirt queries QEMU deprecations, so if a user picks a deprecated CPU,
> > their VM will be tainted and show the deprecation message in logs, etc.
> > 
> > > I guess we can use the info to say Opteron_G4 and Opteron_G5 should not
> > > be ignored by the script, I'm not sure we could use it the other way
> > > around for selecting which models are considered deprecated.
> > 
> > We should always honour all CPUs QEMU reports as existing. Deprecated CPUs
> > are still supported for use, it is merely a warning that they /may/ go away
> > in future.
> 
> So do you suggest we should not ignore even those ancient lower case CPU
> models and add their -v1 variants as well? That would seems to me like a
> lot of churn with no benefit. Although there's no technical reason for
> ignoring them.

My inclination is that we should not special case anything.

If I look at -cpu help there are 143 CPus currently. 3 are special (base,
host, max). Of the 140, 24 are the old lowercase models you mention, 12
traditional names, and 12 -v1 names. IOW, we've currently got 128 CPUs,
and we're excluding 12. That doesn't seems like a worthwhile thing to
specialcase.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|