[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH] cpus: Initialize current_cpu with the first vCPU created
From: |
Paolo Bonzini |
Subject: |
Re: [RFC PATCH] cpus: Initialize current_cpu with the first vCPU created |
Date: |
Tue, 8 Sep 2020 13:43:02 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 08/09/20 08:39, Philippe Mathieu-Daudé wrote:
> Le mar. 8 sept. 2020 08:33, Paolo Bonzini <pbonzini@redhat.com
> <mailto:pbonzini@redhat.com>> a écrit :
>
> On 07/09/20 22:35, Alexander Bulekov wrote:
> >>> RFC because I believe the correct fix is to NOT use current_cpu
> >>> out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU.
> >> Yes, I agree -- I don't think this is the correct fix.
> >> current_cpu is documented as "only valid inside cpu_exec()",
> >> ie if you're actually on a vcpu thread you can use it, but if
> >> you're not on a CPU thread, like the monitor, you need to
> >> say which vCPU you want to affect. For the monitor, that
> > Following up on this old thread.. Does qtest count as a pseudo-vCPU?
> > Since qtest already uses first_cpu for all of its address_space calls,
> > would it be appropriate to set current_cpu to first_cpu in qtest's
> > initialization?
>
>
> qtest doesn't provide vCPU so first_cpu = NULL, that wouldn't help.
Doesn't qtest use qemu_dummy_start_vcpu?
Paolo