On Wed, Feb 22, 2023 at 09:11:13AM +0000, Bernhard Beschow wrote: > > > Am 30. Januar 2023 20:45:47 UTC schrieb "Alex Bennée" <alex.bennee@xxxxxxxxxx>: > > > >Daniel P. Berrangé <berrange@xxxxxxxxxx> writes: > > > >> On Mon, Jan 30, 2023 at 11:47:02AM +0000, Peter Maydell wrote: > >>> On Mon, 30 Jan 2023 at 11:44, Thomas Huth <thuth@xxxxxxxxxx> wrote: > >>> > > >>> > Testing 32-bit host OS support takes a lot of precious time during the QEMU > >>> > contiguous integration tests, and considering that many OS vendors stopped > >>> > shipping 32-bit variants of their OS distributions and most hardware from > >>> > the past >10 years is capable of 64-bit > >>> > >>> True for x86, not necessarily true for other architectures. > >>> Are you proposing to deprecate x86 32-bit, or all 32-bit? > >>> I'm not entirely sure about whether we're yet at a point where > >>> I'd want to deprecate-and-drop 32-bit arm host support. > >> > >> Do we have a feeling on which aspects of 32-bit cause us the support > >> burden ? The boring stuff like compiler errors from mismatched integer > >> sizes is mostly quick & easy to detect simply through a cross compile. > >> > >> I vaguely recall someone mentioned problems with atomic ops in the past, > >> or was it 128-bit ints, caused implications for the codebase ? > > > >Atomic operations on > TARGET_BIT_SIZE and cputlb when > >TCG_OVERSIZED_GUEST is set. Also the core TCG code and a bunch of the > >backends have TARGET_LONG_BITS > TCG_TARGET_REG_BITS ifdefs peppered > >throughout. > > Are there any plans or ideas to support 128 bit architectures > such as CHERI in the future? There is already a QEMU fork > implementing CHERI for RISC V [1]. Also ARM has developed an > experimental hardware implementation of CHERI within the Morello > project where Linaro is involved as well, although the QEMU > implementation is performed by the University of Cambridge [2]. If 128 bit hardware exists and has real world non-toy usage, then a request to support it in QEMU is essentially inevitable. > I'm asking because once we deeply bake in the assumption that > host size >= guest size then adding such architectures will > become much harder. Yep, that is a risk. 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 :|