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.
--
Andrea Bolognani / Red Hat / Virtualization
