[Top][All Lists]

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

Re: [Qemu-riscv] [Qemu-devel] [PATCH v2 00/23] Add RISC-V TCG backend su

From: Palmer Dabbelt
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v2 00/23] Add RISC-V TCG backend support
Date: Thu, 20 Dec 2018 11:10:24 -0800 (PST)

On Thu, 20 Dec 2018 11:04:41 PST (-0800), address@hidden wrote:
On Thu, Dec 20, 2018 at 10:45 AM Palmer Dabbelt <address@hidden> wrote:

On Thu, 20 Dec 2018 09:20:05 PST (-0800), address@hidden wrote:
> On Wed, Dec 19, 2018 at 10:07 PM Richard Henderson
> <address@hidden> wrote:
>> On 12/19/18 11:16 AM, Alistair Francis wrote:
>> > This patch set adds RISC-V backend support to QEMU. This is based on
>> > Michael Clark's original work with extra work on top.
>> >
>> > This has been somewhat tested and can run other architecture softmmu
>> > code. It seems that any complex OS will eventually hang, but we can
>> > run the BIOS and OS startup code for a number of different operating
>> > systems.
>> >
>> > I haven't tested linux user support at all yet. I think Michael had that
>> > working reliably though and hopefully my changes haven't broken it.
>> >
>> > There are still some todos in the code (there are missing instructions
>> > and byte swapping) but these should assert instead of generating invalid
>> > code.
>> Queued to tcg-next, with the extrh fix.
> Thanks Richard!

Sounds good to me.  I'm still attempting to collect the RISC-V patches to get a
PR out, a few things came up but I should have time now.  This was the biggest
patch set, so it should be a lot easier now.

Thanks for picking this up!

>> Some of those todos are no longer todos, since e.g. bswap is now optional.
>> Those asserts should never fire (as a good assert should do, I suppose).
>> The missing instructions are only for riscv32, which afaik is just now making
>> its way to glibc.  So a chroot complete enough to build qemu is a ways away.
>> I'm ok with leaving that incomplete for now.

We've decided to delay the rv32i glibc port until after the next glibc release,
which is targeted for the beginning of February.  glibc should freeze at the
end of the year, at which point we're going to do a rv32i glibc prerelease and
try to build a proper userspace with the theory being that we'll shake out ABI
bugs that way.

Yocto/OE has full support for building 32-bit userspaces with the
latest 32-bit glibc patchset so that is probably a good place to start
testing. It even runs QEMU!

That's my plan. The issue is less on the distro side and more on the "go through the whole rv32i glibc ABI to make sure it's sane" side.

reply via email to

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