On 04.02.2025 09:19, Juergen Gross wrote: > On 03.02.25 23:43, Stefano Stabellini wrote: >> +Xen maintainers >> >> >> On Mon, 3 Feb 2025, Richard Henderson wrote: >>> On 2/3/25 04:54, Paolo Bonzini wrote: >>>> On 2/3/25 04:18, Richard Henderson wrote: >>>>> v1: 20250128004254.33442-1-richard.hender...@linaro.org >>>>> >>>>> For v2, immediately disable 64-on-32 TCG. >>>>> >>>>> I *suspect* that we should disable 64-on-32 for *all* accelerators. >>>>> The idea that an i686 binary on an x86_64 host may be used to spawn >>>>> an x86_64 guest via kvm is silly and a bit more than niche. >>>> >>>> At least Xen used to be commonly used with 32-bit dom0, because it saved >>>> memory and dom0 would map in guest buffers as needed. I'm not sure how >>>> common that is these days, perhaps Stefano knows. >>> >>> As a data-point, debian does not ship libxen-dev for i686. >>> We cannot build-test this configuration at all. >>> >>> I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's >>> unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful >>> for >>> an armhf host, or as an armhf binary running on an aarch64 host. >> >> >> On the Xen side, there are two different use cases: x86 32-bit and ARM >> 32-bit. >> >> For x86 32-bit, while it was a very important use case in the past, I >> believe it is far less so now. I will let the x86 maintainers comment on >> how important it is today. > > As dom0 on x86 is a PV guest per default and Linux doesn't support running as > a > 32-bit PV guest since a few years now, I guess there is no need to support > qemu > as 32-bit on x86 for Xen.
Yet then, just to mention it, you can run a 64-bit PV Dom0 kernel underneath an otherwise 32-bit distro. I've been doing this successfully for very many years (with a very small kernel adjustment, just to work around an apparent shortcoming in system init scripts). Jan
