qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PR RFC] RISC-V Patches for 3.1-rc2


From: Michael Clark
Subject: Re: [Qemu-devel] [PR RFC] RISC-V Patches for 3.1-rc2
Date: Wed, 14 Nov 2018 16:06:09 +1300

On Wed, Nov 14, 2018 at 12:52 PM Palmer Dabbelt <address@hidden> wrote:

> The following changes since commit
> cb968d275c145467c8b385a3618a207ec111eab1:
>
>   Update version for v3.1.0-rc1 release (2018-11-13 18:16:14 +0000)
>
> are available in the Git repository at:
>
>   git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-rc2
>
> for you to fetch changes up to 3502dc824a7b0218abb49f4350e80a49829748cf:
>
>   RISC-V: Respect fences for user-only emulators (2018-11-13 15:12:15
> -0800)
>
> ----------------------------------------------------------------
> RISC-V Patches for 3.1-rc2
>
> This pull request contains four patches that aren't really related to
> each other aside from all being bug fixes that I think should go in for
> 3.1.0:
>

Here's I again. I guess its a somewhat arbitrary set of fixes. Although one
could say the same about the set of fixes in the github repo.

At least you don't have review feedback asking you split a patch up to make
it easier to review, after its already been reviewed (what I would call
"make work").

No objections from me. We just have to get these patches into the other
tree which also has RISC-V bug fixes (but I don't have an opinion about
which bugs are more or less critical). There will be some minor merge
conflicts because the RISC-V tree has writable misa suppoer. I'm planning
to rebase at 3.1.0, just so we don't trample on each other. It's probably
going to be quite a lot of work to get the patches in that tree here
because my patches tend to attract a lot of pedantic feedback. i.e. !! to
normalize a scalar into a bool and ~ to broadcast bit 1 e.g. C bitwise
logic that you find frequently in spike; has to be dumbed down into macro
wrappers. Feedback. These changes to keep people happy are the reason why
we broke things for folk like changing gp$ to __globalPointer$ (in
GCC/binutils). Suddendly all earlier asm is broken because someone wants to
give feedback about how RISC-V should be; someone who does not need to bear
the burden of those changes.

Change simply because we can make you change stuff to break things for
RISC-V users because we think those changes are a good idea. Don't get me
wrong. We get good feedback (in QEMU, mostly from RIchard Henderson), but
its not always the case. VSPILL/VFILL and vaddsz sp is a good idea. I need
to find that email of Richard's on the GCC list and forward it to Krste. I
hope the feedback makes it to folk working on the Vector spec because as
far as I can tell it is a good idea.

Apologies for the cynicism. I'll get over it.

* The second half of Alistair's memory leak patch set that I missed last
>   week.
> * A fix to make fclass.d availiable only on RV64IFD systems (without
>   this it's availiable on RV32IFD systems, truncating the result).
> * A fix to make sfence.vm availiable only in priv-1.9.1, and sfence.vma
>   only availiable in priv-1.10.
> * A change to respect fences in user-mode emulators, which were
>   previously treated as NOPs.
>
> As usual, this builds and boot Linux for me.  I don't think I have
> anything else planned for 3.1.0, but I may be wrong as things are a bit
> hectic this week.
>
> ----------------------------------------------------------------
> Alistair Francis (1):
>       hw/riscv/virt: Free the test device tree node name
>
> Bastian Koppelmann (2):
>       target/riscv: Fix FCLASS_D being treated as RV64 only
>       target/riscv: Fix sfence.vm/a both available in any priv version
>
> Palmer Dabbelt (1):
>       RISC-V: Respect fences for user-only emulators
>
>  hw/riscv/virt.c          |  1 +
>  target/riscv/translate.c | 24 ++++++++++++++++--------
>  2 files changed, 17 insertions(+), 8 deletions(-)
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]