Am 30. Januar 2023 20:45:47 UTC schrieb "Alex Bennée"
<alex.bennee(a)linaro.org>:
Daniel P. Berrangé <berrange(a)redhat.com> 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(a)redhat.com> 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].
I'm asking because once we deeply bake in the assumption that host size >= guest
size then adding such architectures will become much harder.
Best regards,
Bernhard
[1]
https://github.com/CTSRD-CHERI/qemu
[2]
https://git.morello-project.org/university-of-cambridge/mirrors/qemu/-/tr...
>
> With regards,
> Daniel