qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC v9 27/32] accel: replace struct CpusAccel with AccelOpsClass


From: Claudio Fontana
Subject: Re: [RFC v9 27/32] accel: replace struct CpusAccel with AccelOpsClass
Date: Wed, 9 Dec 2020 18:28:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 12/9/20 1:54 PM, Alex Bennée wrote:
> 
> Claudio Fontana <cfontana@suse.de> writes:
> 
>> centralize the registration of the cpus.c module
>> accelerator operations in accel/accel-softmmu.c
>>
>> Signed-off-by: Claudio Fontana <cfontana@suse.de>
> <snip>
>> diff --git a/accel/tcg/tcg-cpus.c b/accel/tcg/tcg-cpus.c
>> index e335f9f155..38a58ab271 100644
>> --- a/accel/tcg/tcg-cpus.c
>> +++ b/accel/tcg/tcg-cpus.c
>> @@ -35,6 +35,9 @@
>>  #include "hw/boards.h"
>>  
>>  #include "tcg-cpus.h"
>> +#include "tcg-cpus-mttcg.h"
>> +#include "tcg-cpus-rr.h"
>> +#include "tcg-cpus-icount.h"
>>  
>>  /* common functionality among all TCG variants */
>>  
>> @@ -80,3 +83,43 @@ void tcg_cpus_handle_interrupt(CPUState *cpu, int mask)
>>          qatomic_set(&cpu_neg(cpu)->icount_decr.u16.high, -1);
>>      }
>>  }
>> +
>> +static void tcg_cpus_ops_init(AccelOpsClass *ops)
>> +{
>> +    if (qemu_tcg_mttcg_enabled()) {
>> +        ops->create_vcpu_thread = mttcg_start_vcpu_thread;
>> +        ops->kick_vcpu_thread = mttcg_kick_vcpu_thread;
>> +        ops->handle_interrupt = tcg_cpus_handle_interrupt;
>> +
>> +    } else if (icount_enabled()) {
>> +        ops->create_vcpu_thread = rr_start_vcpu_thread;
>> +        ops->kick_vcpu_thread = rr_kick_vcpu_thread;
>> +        ops->handle_interrupt = icount_handle_interrupt;
>> +        ops->get_virtual_clock = icount_get;
>> +        ops->get_elapsed_ticks = icount_get;
>> +
>> +    } else {
>> +        ops->create_vcpu_thread = rr_start_vcpu_thread;
>> +        ops->kick_vcpu_thread = rr_kick_vcpu_thread;
>> +        ops->handle_interrupt = tcg_cpus_handle_interrupt;
>> +    }
>> +}
> 
> Aren't we going backwards here by having a global function aware of the
> different accelerator types rather than encapsulating this is the
> particular accelerator machinery?
> 
> <snip>
> 

Now I got your point.

The ideal would be to have three classes. One called tcg-mttcg, one tcg-icount, 
one tcg-rr.
The problem: backward compatibility I think, since currently we have only one 
accel, "tcg".

But, hmm maybe fixable, I'll take a look.

Thanks!

Claudio





reply via email to

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