qemu-riscv
[Top][All Lists]
Advanced

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

Re: Re: [PATCH v2 3/4] target/riscv: SMBIOS support for RISC-V virt mach


From: Alistair Francis
Subject: Re: Re: [PATCH v2 3/4] target/riscv: SMBIOS support for RISC-V virt machine
Date: Thu, 25 Jan 2024 13:16:53 +1000

On Tue, Jan 23, 2024 at 12:19 AM Andrew Jones <ajones@ventanamicro.com> wrote:
>
> On Mon, Jan 22, 2024 at 01:28:18PM +0100, Heinrich Schuchardt wrote:
> > On 22.01.24 10:57, Andrew Jones wrote:
> > > On Fri, Dec 29, 2023 at 01:07:23PM +0100, Heinrich Schuchardt wrote:
> ...
> > > > +#if defined(TARGET_RISCV32)
> > > > +    smbios_set_default_processor_family(0x200);
> > > > +#elif defined(TARGET_RISCV64)
> > > > +    smbios_set_default_processor_family(0x201);
> > > > +#endif
> > >
> > > I think we should use misa_mxl_max to determine the family, rather than
> > > TARGET_*, because, iirc, we're slowly working our ways towards allowing
> > > rv32 cpus to be instantiated with qemu-system-riscv64.
> >
> > Hello Andrew,
> >
> > thank you for reviewing. I guess you mean something like:
> >
> >     if (riscv_is_32bit(&s->soc[0])) {
> >         smbios_set_default_processor_family(0x200);
> > #if defined(TARGET_RISCV64)
> >     } else {
> >         smbios_set_default_processor_family(0x201);
> > #endif
> >     }
>
> Yes, but I'm not sure we need the #ifdef around the 64-bit part.
>
> >
> > riscv_is_32bit returns harts->harts[0].env.misa_mxl_max == MXL_RV32.
> >
> > Some real hardware has a 32bit hart and multiple 64bit harts. Will QEMU
> > support mixing harts with different bitness on the virt machine in future?

That is the hope. Although no one is directly working on it at the
moment. We want to try and keep the RISC-V target setup to do this.

The first goal is to just create and use a 32-bit CPU on the 64-bit
build, which currently doesn't work but it's something that should
work.

Alistair

> > In that case we would have to revisit the code using misa_mxl_max in
> > multiple places.
> >
>
> Never say never, but I don't think there has been much effort to support
> these types of configurations with a single QEMU binary. My googling is
> failing me right now, but I seem to recall that there may have been
> efforts to implement Arm big.LITTLE with multiprocess QEMU [1]. IOW, I
> think we're safe to use misa_mxl_max, since we'll have one for each QEMU
> instance and we'll use a different QEMU instance for each hart bitness.
>
> [1] docs/system/multi-process.rst
>
> Thanks,
> drew
>



reply via email to

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