Closed YWHyuk closed 3 years ago
Great work!! We will review soon..
@ememos
I thought we are in the KVM mode. So, I considered tcg_enabled() as false without much thought. Is that wrong? --> QEMU can directly execute guest code using KVM, but it can also operate as an emulator without KVM. Therefore, it is expected that there will be no side effect in the general case if possible.
Okay, I see what you're worried about. I'm really sorry for bothering you and this will be a last question.
I touched qemu_kvm_cpu_thread_fn
function and this is called by qemu_kvm_start_vcpu
function. Also qemu_kvm_start_vcpu
is called when kvm_enabled().
void qemu_init_vcpu(CPUState *cpu)
{
cpu->nr_cores = smp_cores;
cpu->nr_threads = smp_threads;
cpu->stopped = true;
if (!cpu->as) {
/* If the target cpu hasn't set up any address spaces itself,
* give it the default one.
*/
AddressSpace *as = address_space_init_shareable(cpu->memory,
"cpu-memory");
cpu->num_ases = 1;
cpu_address_space_init(cpu, as, 0);
}
if (kvm_enabled()) {
qemu_kvm_start_vcpu(cpu);
} else if (tcg_enabled()) {
qemu_tcg_init_vcpu(cpu);
} else {
qemu_dummy_start_vcpu(cpu);
}
}
So, my question is "Should I still consider tcg even if the part I modified is dependent on kvm?"
Ok. You're right. Your modifications are limited to KVM, so let's proceed with the original proposal you suggested.
Race condition
There is a race condition between "wake_remote_cpu" caller thread and remtoe vCPU threads. Waker thread wake up remote vCPU threads. Then, it sets the value of "wake_remote_cpu_count" without any lock. So, make the value set before waking up the remote vCPU threads.
Waker Thread
Remote vCPU Thread
Unlock twice
Also, remote vCPU thread call "qemu_mutex_unlock_iothread" twice. For pthreads it will result in undefined behaviour. So Fix it by adding lock function.
Let me know if there's anything I missed 😉 Thanks!