qemu-ppc
[Top][All Lists]
Advanced

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

Re: [PATCH v2 00/16] target: Make 'cpu-qom.h' really target agnostic


From: Zhao Liu
Subject: Re: [PATCH v2 00/16] target: Make 'cpu-qom.h' really target agnostic
Date: Sat, 21 Oct 2023 00:08:31 +0800

Hi Philippe,

On Fri, Oct 20, 2023 at 01:30:50PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Fri, 20 Oct 2023 13:30:50 +0200
> From: Philippe Mathieu-Daudé <philmd@linaro.org>
> Subject: Re: [PATCH v2 00/16] target: Make 'cpu-qom.h' really target
>  agnostic
> 
> Hi Zhao,
> 
> On 20/10/23 07:50, Zhao Liu wrote:
> > Hi Philippe,
> > 
> > On Fri, Oct 13, 2023 at 04:00:59PM +0200, Philippe Mathieu-Daudé wrote:
> > > Date: Fri, 13 Oct 2023 16:00:59 +0200
> > > From: Philippe Mathieu-Daudé <philmd@linaro.org>
> > > Subject: [PATCH v2 00/16] target: Make 'cpu-qom.h' really target agnostic
> > > X-Mailer: git-send-email 2.41.0
> > > 
> > > Since v1:
> > > - Added R-b tags
> > > - Addressed Richard comments
> > > - Postponed OBJECT_DECLARE_CPU_TYPE() changes
> > > 
> > > A heterogeneous machine must be able to instantiate CPUs
> > > from different architectures.
> > 
> > Does this mean the different ISA cores in heterogeneous machine?
> 
> Yes. Currently the ARM target already allows you to do that
> (multiple ISA cores within the same architecture), see the
> xlnx-zcu102 and fby35 machines.

Okay, I'll have a look at it.

> 
> > And is this case for TCG?
> 
> This is *only* for TCG. I expect hardware accel + TCG to be
> theoretically possible, but no interest has been shown for
> it. Anyhow this requires heterogeneous TCG as a first step.

Thanks, got it.

> 
> > > In order to do that, the
> > > common hw/ code has to access to the QOM CPU definitions
> > > from various architecture.
> > 
> > About this kind of heterogeneous machine with multiple CPUs, is there
> > any initial configuration command line example?
> 
> I'm prototyping in plain C but our plan is to start with a
> QMP prototype. Command line configuration is not an option,
> we decided to ignore it. I'll describe that better in a RFC
> document I should post soon.

Looking forward to your RFC!

For accel, I am currently working in this direction (to convert all CPU
topology levels to devices and to create heterogeneous topology via
"-device") as the following:

-device cpu-socket,id=sock0 \
-device cpu-die,id=die0,parent=sock0 \
-device cpu-die,id=die1,parent=sock0 \
-device cpu-cluster,id=cluster0,parent=die0 \
-device cpu-cluster,id=cluster1,parent=die0 \
-device x86-intel-core,id=core0,parent=cluster0,threads=3 \
-device x86-intel-atom,id=core1,parent=cluster1,threads=2 \
-device x86-intel-core,id=core2,parent=cluster0,threads=3

At present, I have a prototype and am sorting out the RFC.

>From your description, I understand that we have no conflict.
Also welcome your thoughts and hope that I can go in the same
direction with you. ;-)

Regards,
Zhao




reply via email to

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