qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC v2 1/6] cpus: extract out TCG-specific code to accel/tcg


From: Claudio Fontana
Subject: Re: [RFC v2 1/6] cpus: extract out TCG-specific code to accel/tcg
Date: Wed, 8 Jul 2020 16:30:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 7/7/20 6:58 PM, Paolo Bonzini wrote:
> On 07/07/20 15:58, Claudio Fontana wrote:
>> +
>> +CpusAccel tcg_cpus = {
>> +    .create_vcpu_thread = tcg_start_vcpu_thread,
>> +    .kick_vcpu_thread = tcg_kick_vcpu_thread,
>> +
>> +    .synchronize_post_reset = tcg_cpu_synchronize_noop,
>> +    .synchronize_post_init = tcg_cpu_synchronize_noop,
>> +    .synchronize_state = tcg_cpu_synchronize_noop,
>> +    .synchronize_pre_loadvm = tcg_cpu_synchronize_noop,
>> +};
> 
> Could this struct reside in AccelClass instead, so that there's no need
> to register the operations explicitly?

This I tried a few times before, you can dig the history a bit of the comments.

The result of my attempts is that you end up replacing an "explicit 
registration", with an explicit internal copy from a structure defined in 
kvm-cpus.c
(for example) to the accelerator state, so you just switch one registration for 
another.

The result is a pile of boilerplate of no use that is just confusing for the 
reader. 

> We could still cache it in a
> global variable in accel_init_machine, in order to avoid pointer chasing.

Indeed, the "cache" though ends up being the only useful thing,
and it can be even more confusing for the reader to see the whole machinery in 
AccelClass.

> 
> Thanks,
> 
> Paolo
> 

Still if you are interested to see what the result ends up being I can share 
it, will need some fiddling..

Ciao,

Claudio




reply via email to

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