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.
Yes, I assume those are mainly useful with very large numbers of vCPUs and/or PCI device passthrough? Neither of those are relevant on macOS hosts. (One other thing they're useful with is device driver development/testing/debugging - real Macs come with IOMMUs so PCI/Thunderbolt device drivers MUST translate addresses for DMA correctly - but that's very niche indeed.)
> 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...
I encountered it while trying the aforementioned vIOMMU; macOS guests seemed to use 64-bit instructions for accessing some of the registers.
I've just checked, and there actually seem to be some instruction emulation tests in the kvm-unit-tests project; those are designed for KVM, but I expect it should be possible to tweak some of them so they're useful for testing HVF. kvm-unit-tests don't seem to be part of QEMU's regular test suite at the moment though, as far as I can tell?
> 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.
Thanks for confirming.
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.
OK, that makes sense, thanks. At least this gives me a better idea of what will be covered by CI and what won't when I'm reviewing patches.
Phil