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