On Mon, 6 Jan 2025 at 19:43, Daniel P. Berrangé <berra...@redhat.com> wrote:
> 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é <berra...@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/z07yasl2pd3cp...@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
