On 09.02.2026 11:05, Alejandro Vallejo wrote: > On Mon Feb 9, 2026 at 10:21 AM CET, Jan Beulich wrote: >> On 06.02.2026 17:15, Alejandro Vallejo wrote: >>> High level description >>> ====================== >>> >>> When compared to the RFC this makes a different approach The series >>> introduces >>> cpu_vendor() which maps to a constant in the single vendor case and to >>> (boot_cpu_data.vendor & X86_ENABLED_VENDORS), where X86_ENABLED_VENDORS is a >>> mask of the compile-time chosen vendors. This enables the compiler to detect >>> dead-code at the uses and remove all unreachable branches, including in >>> switches. >>> >>> When compared to the x86_vendor_is() macro introduced in the RFC, this is >>> simpler. It achieves MOST of what the older macro did without touching the >>> switches, with a few caveats: >>> >>> 1. Compiled-out vendors cause a panic, they don't fallback onto the >>> unknown >>> vendor case. In retrospect, this is a much saner thing to do. >> >> I'm unconvinced here. Especially our Centaur and Shanghai support is at best >> rudimentary. Treating those worse when configured-out than when configured-in >> feels questionable. > > Isn't that the point of configuring out?
That's what I'm unsure about. > Besides the philosophical matter of whether or not a compiled-out vendor > should be allowed to run there's the more practical matter of what to do > with the x86_vendor field of boot_cpu_data. Because at that point our take > that cross-vendor support is forbidden is a lot weaker. If I can run an > AMD-hypervisor on an Intel host, what then? What policies would be allowed? > If I > wipe x86_vendor then policies with some unknown vendor would be fine. Should > the > leaves match too? If I do not wipe the field, should I do black magic to > ensure > the behaviour is different depending on whether the vendor is compiled in or > not? What if I want to migrate a VM currently running in this hypothetical > hypervisor? The rules becomes seriously complex. > > It's just a lot cleaner to take the stance that compiled out vendors can't > run. > Then everything else is crystal clear and we avoid a universe's worth of > corner > cases. I expect upstream Xen to support all cases (I'm skeptical about the > utility of the unknown vendor path, but oh well), but many downstreams might > benefit from killing off support for vendors they really will never touch. To them, will panic()ing (or not) make a difference? >>> 2. equalities and inequalities have been replaced by equivalent >>> (cpu_vendor() & ...) >>> forms. This isn't stylistic preference. This form allows the compiler >>> to merge the compared-against constant with X86_ENABLED_VENDORS, >>> yielding >>> much better codegen throughout the tree. >>> >>> The effect of (2) triples the delta in the full build below. >>> >>> Some differences might be attributable to the change from policy vendor >>> checks >>> to boot_cpu_data. In the case of the emulator it caused a 400 bytes increase >>> due to the way it checks using LOTS of macro invocations, so I left that one >>> piece using the policy vendor except for the single vendor case. >> >> For the emulator I'd like to point out this question that I raised in the >> AVX10 series: > > There's no optimisation shortage for the emulator. For that patch I just > ensure I didn't make a tricky situation worse. It is much better in the > single-vendor case. > >> "Since it'll be reducing code size, we may want to further convert >> host_and_vcpu_must_have() to just vcpu_must_have() where appropriate >> (should be [almost?] everywhere)." >> >> Sadly there was no feedback an that (or really on almost all of that work) at >> all so far. > > It sounds fairly orthogonal to this, unless I'm missing the point. It's largely orthogonal, except that if we had gone that route already, your codegen diff might look somewhat different. > In principle that would be fine. the vCPU features whose emulation requires > special instructions are most definitely a subset of those of the host anyway. > > I agree many cases could be simplified as you describe. > > I do see a worrying danger of XSA should the max policy ever exceed the > capabilities of the host on a feature required for emulating some instruction > for that very feature. Then the guest could abuse the emulator to trigger #UD > inside the hypervisor's emulation path. Well, that max-policy related question is why I've raised the point, rather than making (more) patches right away. Jan
