On 09.02.2026 12:56, Alejandro Vallejo wrote: > On Mon Feb 9, 2026 at 11:15 AM CET, Jan Beulich wrote: >> 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. > > I'm really missing what you're trying to make, sorry. How, if at all, is it > helpful for a hypervisor with a compiled out vendor to be bootable on a > machine > of that vendor?
No more and no less than for a system with CPUs from a vendor we don't have support for at all. Let's assume someone wants to start adding support for a new vendor. They may first try Xen as-is. This wouldn't panic. Depending on how exactly they would start adding stuff, Xen might suddenly panic, despite functionally nothing having changed. >>> 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? > > One would hope not because the're compiling them out for a reason. > But for upstream, not panicking brings a sea of corner cases. The ones I > mentioned above is not the whole list. > > Turning the question around. Who benefits from not panicking? Certain things may work. But more generally - see above. Turning this question around also isn't quite appropriate imo: You want to introduce the panic(), so it's on you to justify doing so (which includes making clear why omitting that small piece of code would be a bad idea). Jan
