Re: [libvirt PATCH 11/17] tests: Add HVF support to testutilsqemu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 05, 2022 at 03:02:07AM -0800, Andrea Bolognani wrote:
> On Wed, Jan 05, 2022 at 10:10:07AM +0000, Daniel P. Berrangé wrote:
> > On Tue, Jan 04, 2022 at 07:52:50PM +0100, Andrea Bolognani wrote:
> > > + if (hvf_machines[i] != NULL) {
> > > +     for (j = 0; hvf_machines[i][j] != NULL; j++) {
> > > +         virQEMUCapsAddMachine(tmpCaps,
> > > +                               VIR_DOMAIN_VIRT_HVF,
> > > +                               hvf_machines[i][j],
> > > +                               NULL,
> > > +                               NULL,
> > > +                               0,
> > > +                               false,
> > > +                               false,
> > > +                               true,
> > > +                               defaultRAMid,
> > > +                               false);
> > > +         virQEMUCapsSet(tmpCaps, QEMU_CAPS_HVF);
> > > +     }
> > > + }
> >
> > IIUC this means in tests we're going to build capabilities that
> > indicate support for KVM and HVF at the same time. This is not
> > a scenario that applies in the real world, so I'm a little
> > uncomfortable with this.  It is the simple option, though I
> > would prefer if the individual tests could express
> >
> >   "gimme capabilities for linux"
> >
> > vs
> >
> >   "gimme capabilities for macOS"
> >
> > Also relies on fact that we don't #ifdef any of the interesting
> > code in the QEMU driver related to KVM/HVF. Probably ok-ish
> > assumption in most cases, at least for unit tests.
> 
> Yeah, ideally we'd have that and also real replies files taken from
> QEMU running on macOS, but I don't currently have a way to generate
> the latter and the former would take more development time. In the
> interest of unblocking macOS users who are currently unable to run
> hardware accelerated VMs through libvirt at all, I'm personally okay
> with cutting some corners and improving things later.
> 
> What if I changed things so that both the HVF test cases and the
> testutilsqemu bit above are only built on macOS? We'd still have the
> weird mix of capabilities on that platform, but at least Linux would
> be unaffected. We run the test suite on macOS as part of our CI
> pipeline, so coverage wouldn't be any worse.

I was thinking more like
 
 - testQemuCapsInit  only adds TCG+KVM emulators
 - testQemuCapsInitMacOS only adds TCG+HVF emulators

In  qemuxml2argvtest.c do

    virCapsPtr linuxCaps = driver->caps
    driver->caps = testQemuCapsInitMacOS();
    DO_TEST("hvf-blah",
            QEMU_CAPS_HVF,
            QEMU_CAPS_PIIX3_USB_UHCI,
	    ....
            QEMU_CAPS_USB_HUB);

    virObjectUnref(driver->caps);
    driver->caps = linuxCaps;

feels like it ought to be reasonably simple to get working

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 :|




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux