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

[Heinrich Schuchardt <heinrich.schuchardt@canonical.com>]

On 22.01.24 13:59, Andrew Jones 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.

I just followed the style in riscv_cpu_validate_misa_mxl().

Best regards

Heinrich

> 
>>
>> 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?
>> 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