Re: Pointer Masking prototype for RISC-V QEMU

[Alexey Baturo]

Richard, thank you for the reply!

>See https://wiki.qemu.org/Contribute/SubmitAPatch
>Experimental features (i.e. non-ratified isa extensions) are acceptable, but they need to be off by default
So, if I got you right, I could put my changes under an experimental extension knob and submit a patch into the mailing list, and it could be accepted, while the extension itself is under development?

>But for acceptance of experimental features, a small "smoke test" is sufficient.
Thanks, I do have such kind of simple tests to ensure the feature works.

Thanks

пн, 5 окт. 2020 г. в 06:52, Richard Henderson <richard.henderson@linaro.org>:

On 10/4/20 12:50 PM, Alexey Baturo wrote:
> Hi folks,
>
> I've implemented support for RISC-V Pointer Masking proposal developed by J-ext
> workgroup. The initial prototype was for QEMU 4.1 and later I moved it to the
> current vesrsion(5.1).
> Could you please help me to clarify some things:
> - I'd like to commit this functionality to the QEMU(mainline or separate
> branch), do you think it's possible at this stage?
> - Could you please describe the proper process of commiting such new
> functionality to QEMU?

See https://wiki.qemu.org/Contribute/SubmitAPatch

> - What are the requirements for test coverage of this new functionality and
> what test infra should be used to measure it?

It can be tricky for these kind, because often "proper" use of the
functionality is quite a lot of code going into another project, e.g. asan.

But for acceptance of experimental features, a small "smoke test" is
sufficient.  Leastwise, that's all I've written for ARMv8.5-MTE. ;-)

> - If this functionality is deemed to be acceptable for QEMU, how does the
> review process looks like?

Well, hopefully the risc-v maintainers will have a look.  I will often look at
stuff based on TCG maintainership.

> - Also it's possible to implement Memory Tagging extension similarly as ARMv8.5
> has: it would reuse a lot of part from Pointer Masking. I've done initial
> prototype of such extension, does it make sence to try to push such experimetal
> features to qemu? If yes, what are the prerequisites?

Experimental features (i.e. non-ratified isa extensions) are acceptable, but
they need to be off by default, and enabled by a cpu property that begins with
"x-", so that it's clear to users that it's experimental.  So, currently, the
vector extension is enabled via "-cpu max,x-v=on".


r~