On 1/11/21 11:35 PM, Eduardo Habkost wrote:
> On Mon, Jan 11, 2021 at 05:13:27PM +0100, Claudio Fontana wrote:
>> Happy new year,
>
> Hi!
>
>>
>> picking up this topic again, i am looking at at now a different aspect of
>> this problem, of setting the right tcg ops for the right cpu class.
>>
On Mon, Jan 11, 2021 at 05:13:27PM +0100, Claudio Fontana wrote:
> Happy new year,
Hi!
>
> picking up this topic again, i am looking at at now a different aspect of
> this problem, of setting the right tcg ops for the right cpu class.
>
> This issue I am highlighting is present because
On 1/11/21 5:13 PM, Claudio Fontana wrote:
> On 12/19/20 12:00 AM, Claudio Fontana wrote:
>> On 12/18/20 11:30 PM, Claudio Fontana wrote:
>>> On 12/18/20 10:55 PM, Claudio Fontana wrote:
On 12/18/20 7:04 PM, Claudio Fontana wrote:
> On 12/18/20 7:01 PM, Paolo Bonzini wrote:
>> On
On 12/19/20 12:00 AM, Claudio Fontana wrote:
> On 12/18/20 11:30 PM, Claudio Fontana wrote:
>> On 12/18/20 10:55 PM, Claudio Fontana wrote:
>>> On 12/18/20 7:04 PM, Claudio Fontana wrote:
On 12/18/20 7:01 PM, Paolo Bonzini wrote:
> On 18/12/20 18:51, Claudio Fontana wrote:
>> But with
On 12/18/20 11:30 PM, Claudio Fontana wrote:
> On 12/18/20 10:55 PM, Claudio Fontana wrote:
>> On 12/18/20 7:04 PM, Claudio Fontana wrote:
>>> On 12/18/20 7:01 PM, Paolo Bonzini wrote:
On 18/12/20 18:51, Claudio Fontana wrote:
> But with things like cris/ for example,
> the tcg
On 12/18/20 10:55 PM, Claudio Fontana wrote:
> On 12/18/20 7:04 PM, Claudio Fontana wrote:
>> On 12/18/20 7:01 PM, Paolo Bonzini wrote:
>>> On 18/12/20 18:51, Claudio Fontana wrote:
But with things like cris/ for example,
the tcg functions to use are actually versioned per each subclass
On 12/18/20 7:04 PM, Claudio Fontana wrote:
> On 12/18/20 7:01 PM, Paolo Bonzini wrote:
>> On 18/12/20 18:51, Claudio Fontana wrote:
>>> But with things like cris/ for example,
>>> the tcg functions to use are actually versioned per each subclass of
>>> TYPE_CRIS_CPU.
>>>
>>> Different tcg_ops
On 12/18/20 7:01 PM, Paolo Bonzini wrote:
> On 18/12/20 18:51, Claudio Fontana wrote:
>> But with things like cris/ for example,
>> the tcg functions to use are actually versioned per each subclass of
>> TYPE_CRIS_CPU.
>>
>> Different tcg_ops need to be used for different subclasses of the
>>
On 18/12/20 18:51, Claudio Fontana wrote:
But with things like cris/ for example,
the tcg functions to use are actually versioned per each subclass of
TYPE_CRIS_CPU.
Different tcg_ops need to be used for different subclasses of the
CPU_RESOLVING_TYPE.
CRIS is not that bad since it's TCG
On 11/27/20 7:21 AM, Paolo Bonzini wrote:
> On 26/11/20 23:32, Claudio Fontana wrote:
>> +if (acc) {
>> +object_class_foreach(accel_init_cpu_int_aux, cpu_type, false, acc);
>> +}
>
> Any reason to do it for cpu_type only, rather than for all subclasses of
> CPU_RESOLVING_TYPE?
On 11/27/20 7:13 PM, Eduardo Habkost wrote:
> On Fri, Nov 27, 2020 at 06:58:22PM +0100, Claudio Fontana wrote:
>> On 11/27/20 6:06 PM, Eduardo Habkost wrote:
>>> On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
add a new optional interface to CPUClass,
which allows
On Fri, Nov 27, 2020 at 06:58:22PM +0100, Claudio Fontana wrote:
> On 11/27/20 6:06 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> >> add a new optional interface to CPUClass,
> >> which allows accelerators to extend the CPUClass
> >> with
On 11/27/20 6:06 PM, Eduardo Habkost wrote:
> On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
>> add a new optional interface to CPUClass,
>> which allows accelerators to extend the CPUClass
>> with additional accelerator-specific initializations.
>>
>> Signed-off-by: Claudio
On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> add a new optional interface to CPUClass,
> which allows accelerators to extend the CPUClass
> with additional accelerator-specific initializations.
>
> Signed-off-by: Claudio Fontana
> ---
[...]
> +static void
On 11/27/20 2:31 PM, Paolo Bonzini wrote:
> On 27/11/20 12:41, Claudio Fontana wrote:
>> This seems to be due to "-machine none", is machine none supposed to
>> have no default cpu_type? Is it expected that for machine none
>> current_machine->cpu_type is NULL, or is it a bug?
>
> "-machine none"
On 27/11/20 12:41, Claudio Fontana wrote:
This seems to be due to "-machine none", is machine none supposed to
have no default cpu_type? Is it expected that for machine none
current_machine->cpu_type is NULL, or is it a bug?
"-machine none" has no CPU at all, so I think anything is acceptable.
On 11/27/20 12:22 PM, Claudio Fontana wrote:
> On 11/27/20 9:59 AM, Claudio Fontana wrote:
>> On 11/27/20 7:21 AM, Paolo Bonzini wrote:
>>> On 26/11/20 23:32, Claudio Fontana wrote:
+if (acc) {
+object_class_foreach(accel_init_cpu_int_aux, cpu_type, false,
acc);
+
On 11/27/20 9:59 AM, Claudio Fontana wrote:
> On 11/27/20 7:21 AM, Paolo Bonzini wrote:
>> On 26/11/20 23:32, Claudio Fontana wrote:
>>> +if (acc) {
>>> +object_class_foreach(accel_init_cpu_int_aux, cpu_type, false, acc);
>>> +}
>>
>> Any reason to do it for cpu_type only, rather
On 11/27/20 7:21 AM, Paolo Bonzini wrote:
> On 26/11/20 23:32, Claudio Fontana wrote:
>> +if (acc) {
>> +object_class_foreach(accel_init_cpu_int_aux, cpu_type, false, acc);
>> +}
>
> Any reason to do it for cpu_type only, rather than for all subclasses of
> CPU_RESOLVING_TYPE?
On 26/11/20 23:32, Claudio Fontana wrote:
+if (acc) {
+object_class_foreach(accel_init_cpu_int_aux, cpu_type, false, acc);
+}
Any reason to do it for cpu_type only, rather than for all subclasses of
CPU_RESOLVING_TYPE? This would remove the cpu_type argument to
add a new optional interface to CPUClass,
which allows accelerators to extend the CPUClass
with additional accelerator-specific initializations.
Signed-off-by: Claudio Fontana
---
MAINTAINERS | 1 +
accel/accel-common.c| 43 +
21 matches
Mail list logo
