On Tue, Mar 21, 2023 at 16:13:22 +0100, Martin Kletzander wrote:
> On Thu, Mar 16, 2023 at 05:11:46PM +0100, Peter Krempa wrote:
> > The data is based on the generic variant of the 7.2.0 data on x86_64.
> >
> > Only modification to the '.replies' file is that KVM is reported as
> > unavailable/unsupported.
> >
> > Ideally this will be replaced by a dump captured from a real system.
> >
> > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> > ---
> > .../qemu_7.2.0-hvf.x86_64+hvf.xml | 183 +
> > .../qemu_7.2.0-tcg.x86_64+hvf.xml | 264 +
> > .../caps_7.2.0_x86_64+hvf.replies | 39399 ++++++++++++++++
> > .../caps_7.2.0_x86_64+hvf.xml | 3250 ++
> > tests/qemucaps2xmloutdata/caps.x86_64+hvf.xml | 28 +
> > 5 files changed, 43124 insertions(+)
> > create mode 100644 tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml
> > create mode 100644 tests/domaincapsdata/qemu_7.2.0-tcg.x86_64+hvf.xml
> > create mode 100644 tests/qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.replies
> > create mode 100644 tests/qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml
> > create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+hvf.xml
> >
> > diff --git a/tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml b/tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml
> > new file mode 100644
> > index 0000000000..d6dc93d957
> > --- /dev/null
> > +++ b/tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml
> > @@ -0,0 +1,183 @@
> > +<domainCapabilities>
> > + <path>/usr/bin/qemu-system-x86_64</path>
> > + <domain>hvf</domain>
> > + <machine>pc-i440fx-7.2</machine>
> > + <arch>x86_64</arch>
>
> Wow, x86_64 with ...
>
> > + <iothreads supported='yes'/>
> > + <os supported='yes'>
> > + <enum name='firmware'>
> > + <value>bios</value>
> > + <value>efi</value>
> > + </enum>
> > + <loader supported='yes'>
> > + <value>/usr/share/AAVMF/AAVMF_CODE.fd</value>
> > + <value>/usr/share/AAVMF/AAVMF32_CODE.fd</value>
>
> ... AAVMF =)
Note that this is a real caps dump we have for 7.2. If you install
qemu-system-aarch64 on your x86 box it comes with the firmware which we
display here.
>
> [...]
>
> > +{
> > + "execute": "query-kvm",
> > + "id": "libvirt-6"
> > +}
> > +
> > +{
> > + "return": {
> > + "enabled": false,
> > + "present": false
>
> Here you say it is not present, but ...
>
> > + },
> > + "id": "libvirt-6"
> > +}
> > +
> > +{
> > + "execute": "qom-list-types",
> > + "id": "libvirt-7"
> > +}
> > +
> > +{
> > + "return": [
>
> [...]
>
> > + {
> > + "name": "kvm-accel",
> > + "parent": "accel"
> > + },
>
> ... this is still kept in. Thankfully we do not base anything on it, I
> don't think.
>
> Anyway, enough of the silliness. Could we get the real dump from CI
> somehow? Or is there a need to build the qemu there just for this?
I made a (poor) attempt at grabbing it from the CI but failed. Possibly
we don't have access to the hypervisor in cirrus. I can give it another
try, but otherwise I don't have a OSX machine around.
