Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-30 Thread Paolo Bonzini
On 30/08/20 15:34, Claudio Fontana wrote: > Ciao Paolo, > > just a ping on this one, it would seem that qemu_clock_get_ns needs to be > called before > any accelerator is initialized, before ticks are enabled, as part of qcow2 > initialization. > > I could add a check specifically for this and

Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-30 Thread Claudio Fontana
Ciao Paolo, just a ping on this one, it would seem that qemu_clock_get_ns needs to be called before any accelerator is initialized, before ticks are enabled, as part of qcow2 initialization. I could add a check specifically for this and a comment in the cpus_get_virtual_clock(), but do you

Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-20 Thread Claudio Fontana
Hi Paolo and all, back in RFC v3 I introduced cpus_get_virtual_clock in this patch. I observed an issue when adding the get_virtual_clock to the CpusAccel interface, ie it seems that qemu_clock_get_ns() is called in some io-tests before the accelerator is initialized, which seems to collide

Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-11 Thread Claudio Fontana
On 8/11/20 10:59 AM, Roman Bolshakov wrote: > On Mon, Aug 03, 2020 at 11:05:27AM +0200, Claudio Fontana wrote: >> The new interface starts unused, will start being used by the >> next patches. >> >> It provides methods for each accelerator to start a vcpu, kick a vcpu, >> synchronize state, get

Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-11 Thread Roman Bolshakov
On Mon, Aug 03, 2020 at 11:05:27AM +0200, Claudio Fontana wrote: > The new interface starts unused, will start being used by the > next patches. > > It provides methods for each accelerator to start a vcpu, kick a vcpu, > synchronize state, get cpu virtual clock and elapsed ticks. > >

Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-05 Thread Claudio Fontana
On 8/5/20 10:47 AM, Paolo Bonzini wrote: > On 05/08/20 10:40, Claudio Fontana wrote: >>> #ifdef _WIN32 >>> -/* Eat dummy APC queued by qemu_cpu_kick_thread. */ >>> +/* Eat dummy APC queued by qemu_cpu_kick_thread. */ >>> +/* NB!!! Should not this be if (hax_enabled)? Is this wrong

Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-05 Thread Paolo Bonzini
On 05/08/20 10:40, Claudio Fontana wrote: >> #ifdef _WIN32 >> -/* Eat dummy APC queued by qemu_cpu_kick_thread. */ >> +/* Eat dummy APC queued by qemu_cpu_kick_thread. */ >> +/* NB!!! Should not this be if (hax_enabled)? Is this wrong for whpx? */ >> if (!tcg_enabled()) { >>

Re: [RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-05 Thread Claudio Fontana
Hi all, could you give a check to this detail, marked as a comment here? While doing the refactoring and looking at the history, I _think_ I noticed something that could be wrong related to whpx and hax, and I marked this as a comment. Maybe Paolo? On 8/3/20 11:05 AM, Claudio Fontana wrote:

[RFC v3 2/8] cpus: prepare new CpusAccel cpu accelerator interface

2020-08-03 Thread Claudio Fontana
The new interface starts unused, will start being used by the next patches. It provides methods for each accelerator to start a vcpu, kick a vcpu, synchronize state, get cpu virtual clock and elapsed ticks. Signed-off-by: Claudio Fontana --- hw/core/cpu.c | 1 +