On 23/02/2023 23.10, Sean Christopherson wrote:
On Thu, Feb 23, 2023, Maxim Levitsky wrote:
On Thu, 2023-02-23 at 08:01 +0100, Thomas Huth wrote:
On 22/02/2023 23.27, Sean Christopherson wrote:
On Fri, Feb 17, 2023, Thomas Huth wrote:
On 29/09/2022 15.52, Maxim Levitsky wrote:
On Thu, 2022-09-29 at 15:26 +0200, Paolo Bonzini wrote:
On 9/28/22 19:55, Sean Christopherson wrote:
As far as my opinion goes I do volunteer to test this code more often,
and I do not want to see the 32 bit KVM support be removed*yet*.
Yeah, I 100% agree that it shouldn't be removed until we have equivalent test
coverage. But I do think it should an "off-by-default" sort of thing. Maybe
BROKEN is the wrong dependency though? E.g. would EXPERT be a better option?
Yeah, maybe EXPERT is better but I'm not sure of the equivalent test
coverage. 32-bit VMX/SVM kvm-unit-tests are surely a good idea, but
what's wrong with booting an older guest?
From my point of view, using the same kernel source for host and the guest
is easier because you know that both kernels behave the same.
About EXPERT, IMHO these days most distros already dropped 32 bit suport thus anyway
one needs to compile a recent 32 bit kernel manually - thus IMHO whoever
these days compiles a 32 bit kernel, knows what they are doing.
I personally would wait few more releases when there is a pressing reason to remove
this support.
FWIW, from the QEMU perspective, it would be very helpful to remove 32-bit
KVM support from the kernel. The QEMU project currently struggles badly with
keeping everything tested in the CI in a reasonable amount of time. The
32-bit KVM kernel support is the only reason to keep the qemu-system-i386
binary around - everything else can be covered with the qemu-system-x86_64
binary that is a superset of the -i386 variant (except for the KVM part as
far as I know).
Sure, we could also drop qemu-system-i386 from the CI without dropping the
32-bit KVM code in the kernel, but I guess things will rather bitrot there
even faster in that case, so I'd appreciate if the kernel could drop the
32-bit in the near future, too.
Ya, I would happily drop support for 32-bit kernels today, the only sticking point
is the lack of 32-bit shadow paging test coverage, which unfortunately is a rather
large point. :-(
From your point of view, would it be OK if QEMU dropped qemu-system-i386?
I.e. would it be fine to use older versions of QEMU only for that test
coverage (or do you even use a different userspace for testing that)?
For me personally, I have no objection to dropping qemu-system-i386 support in
future QEMU releases. I update my 32-bit images very, very infrequently, so I
probably wouldn't even notice for like 5 years :-)
From my point of view qemu-system-x86_64 does run 32 bit guests just fine.
Right, but unless I seriously misunderstand what qemu-system-x86_64 ecompasses,
it can't be used to run guests of 32-bit _hosts_, which is what we need to test
shadowing of 32-bit NPT.
That's what I've been told in the past, too, and that's why I asked. Thanks
for the clarification!
To summarize: My takeaway is that nobody really needs qemu-system-i386
anymore for recent development - the remaining 32-bit KVM use cases can be
done with older versions of QEMU instead, thus it should be fine for the
QEMU project to drop qemu-system-i386 nowadays.
Thanks,
Thomas
