[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Arm64 FEAT_MOPS option B support for heterogeneous systems
From: |
Peter Maydell |
Subject: |
Re: Arm64 FEAT_MOPS option B support for heterogeneous systems |
Date: |
Thu, 6 Jun 2024 10:15:51 +0100 |
On Wed, 5 Jun 2024 at 18:49, Nikolay Gogsadze <koliagogsadze@gmail.com> wrote:
>
> Hello everyone,
>
> I have a question related to Arm64 FEAT_MOPS support in qemu
> https://github.com/qemu/qemu/commit/5d7b37b5f675d9cee0c9c1f8b386b3daa3cc2d9a
> https://lore.kernel.org/all/20230907160340.260094-1-peter.maydell@linaro.org/T/
>
> It looks like there is no possibility to emulate MOPS instructions with
> option B, only option A is supported.
> https://github.com/qemu/qemu/blob/master/target/arm/tcg/helper-a64.c#L1579-L1590
> https://github.com/qemu/qemu/blob/master/target/arm/tcg/helper-a64.c#L1681-L1684
That is correct. The architecture permits both options because
for some implementations option A will be easier and for some
option B will be easier. For QEMU, it was easiest for us to
implement option B, so that is what we have done.
> I checked linux kernel patch add support FEAT_MOPS
> https://lore.kernel.org/lkml/20230216160012.272345-1-kristina.martsenko@arm.com/T/
>
> and found an interesting thing: a memory exception can happen in a
> heterogeneous system if one processor implements option A and executes
> prologue or main cpy/set instructions, and if after that the kernel
> re-scheduled to another processor that implements option B, it will be memory
> operation exception.
Also true -- this is all architected to allow for heterogenous
systems or for VM migration between hosts which took different
implementation options. (QEMU should correctly implement the
"raise an exception if the CPU state indicates the MOPS sequence
was started on an option A implementation" handling.)
> It would be great to add support for virt board to choose which
> option of mops implements CPU to emulate and test such cases.
This is generally not something QEMU does. We aim to be a
(mostly) compliant implementation of the architecture, not
to provide a lot of configuration knobs to set our emulation
to multiple different points in the envelope of possibility
that the architecture allows. Trying to satisfy that use
case would be a lot of work (there are many many options
and impdef choices in the architecture) and I think the
audience for it is very limited.
If you want to do that sort of testing, one option is the
Arm AEM (part of Fast Models) -- it lets you select which
of the FEAT_MOPS options A and B it uses via a command line
argument.
thanks
-- PMM