Re: [PATCH] system: Try hardware accelerators (KVM, HVF) before software one (TCG)

["Daniel P. Berrangé" <berrange@redhat.com>]

On Sat, Jan 04, 2025 at 12:28:14PM +0100, Phil Dennis-Jordan wrote:
> On Fri, 3 Jan 2025 at 16:16, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> > On Fri, Jan 03, 2025 at 04:05:58PM +0100, Philippe Mathieu-Daudé wrote:
> > > As Daniel suggested [*]:
> > >
> > > > We should consider to rank HVF above TCG, on the basis
> > > > that HW acceleration is faster and should provide a
> > > > host<->guest security boundary that we don't claim for TCG
> > >
> > > [*] https://lore.kernel.org/qemu-devel/Z07YASl2Pd3CPtjE@redhat.com/
> >
> > Note, my statement above was on the basis that HVF passes all our
> > functional tests, thus indicating a decent level of confidence
> > in the correctness of the HVF impl.
> >
> > If anyone knows any show stopper problems with HVF that would
> > justify blocking its promotion ahead of TCG.... say now.
> >
> 
> I don't know about showstoppers, but:
> 
> 1. As far as I'm aware there are/were problems with the virtual IOMMU
> devices in HVF. It's been a while (~half a year?) since I tried them, but I
> had problems getting guests booted with intel_iommu etc.

I think that vIOMMU is niche enough that we can merely consider it
a nice-to-fix bug, and not block promoting HVF.

> 2. I think there might also be a few remaining edge cases where the x86
> instruction emulation on fault/trap is incomplete. Most notably, MMIO using
> SSE/AVX/etc. instructions will, I think, fail. In practice this is a fairly
> obscure use case - I'm not aware of any guest OS that actually performs
> MMIO using these instructions. I have a patch kicking around that adds
> support for missing 64-bit variants of common scalar arithmetic
> instructions with memory operands. I can dig that up and post it - do we
> have a good way of adding tests for this kind of thing?

Not sure how best to test this, other than finding a guest OS that
exhibits this ? Others probably have better suggestions...

> 3. As far as I'm aware, there's no CI happening on HVF? Or has that
> changed? macOS is notoriously a pain in the rear in terms of CI thanks to
> its licensing, and the big cloud CI platforms tend to run it in a VM which
> in turn typically doesn't support nested HVF. I've been working on an
> on-prem solution to provisioning bare-metal Macs to run clean-slate OS
> images for CI. This has been a side project though and I haven't had the
> resources to focus on that project to see it through. It might be possible
> to do this in the cloud on Amazon's EC2 Mac Minis as well, but those aren't
> exactly cheap.

The only CI we have is running under Cirrus CI which uses VMs on
real mac aarch64 hardware, but I don't think we can test HVF there.

Mostly we rely on regular contributors periodically running tests
and reporting on problems. This is not ideal, but also not a blocker
for enabling HVF - it just means macOS isn't a full tier 1 platform
for us.

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