Message ID | 20201126215017.41156-7-agraf@csgraf.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | hvf: Implement Apple Silicon Support | expand |
On Thu, Nov 26, 2020 at 10:50:15PM +0100, Alexander Graf wrote: > When kicking another vCPU, we get an OS function that explicitly does that for us > on Apple Silicon. That works better than the current signaling logic, let's make > use of it there. > > Signed-off-by: Alexander Graf <agraf@csgraf.de> > --- > accel/hvf/hvf-cpus.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c > index b9f674478d..74a272d2e8 100644 > --- a/accel/hvf/hvf-cpus.c > +++ b/accel/hvf/hvf-cpus.c > @@ -418,8 +418,20 @@ static void hvf_start_vcpu_thread(CPUState *cpu) > cpu, QEMU_THREAD_JOINABLE); > } > > +#ifdef __aarch64__ > +static void hvf_kick_vcpu_thread(CPUState *cpu) > +{ > + if (!qemu_cpu_is_self(cpu)) { > + hv_vcpus_exit(&cpu->hvf_fd, 1); > + } > +} > +#endif > + > static const CpusAccel hvf_cpus = { > .create_vcpu_thread = hvf_start_vcpu_thread, > +#ifdef __aarch64__ > + .kick_vcpu_thread = hvf_kick_vcpu_thread, > +#endif Interesting. We have considered the possibility of adding arch-specific TYPE_ACCEL subclasses when discussing Claudio's, series. Here we have another arch-specific hack that could be avoided if we had a TYPE_ARM_HVF_ACCEL QOM class. > > .synchronize_post_reset = hvf_cpu_synchronize_post_reset, > .synchronize_post_init = hvf_cpu_synchronize_post_init, > -- > 2.24.3 (Apple Git-128) >
On 26.11.20 23:18, Eduardo Habkost wrote: > On Thu, Nov 26, 2020 at 10:50:15PM +0100, Alexander Graf wrote: >> When kicking another vCPU, we get an OS function that explicitly does that for us >> on Apple Silicon. That works better than the current signaling logic, let's make >> use of it there. >> >> Signed-off-by: Alexander Graf <agraf@csgraf.de> >> --- >> accel/hvf/hvf-cpus.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c >> index b9f674478d..74a272d2e8 100644 >> --- a/accel/hvf/hvf-cpus.c >> +++ b/accel/hvf/hvf-cpus.c >> @@ -418,8 +418,20 @@ static void hvf_start_vcpu_thread(CPUState *cpu) >> cpu, QEMU_THREAD_JOINABLE); >> } >> >> +#ifdef __aarch64__ >> +static void hvf_kick_vcpu_thread(CPUState *cpu) >> +{ >> + if (!qemu_cpu_is_self(cpu)) { >> + hv_vcpus_exit(&cpu->hvf_fd, 1); >> + } >> +} >> +#endif >> + >> static const CpusAccel hvf_cpus = { >> .create_vcpu_thread = hvf_start_vcpu_thread, >> +#ifdef __aarch64__ >> + .kick_vcpu_thread = hvf_kick_vcpu_thread, >> +#endif > Interesting. We have considered the possibility of adding > arch-specific TYPE_ACCEL subclasses when discussing Claudio's, > series. Here we have another arch-specific hack that could be > avoided if we had a TYPE_ARM_HVF_ACCEL QOM class. I don't think that's necessary in this case. I don't see how you could ever have aarch64 and x86 HVF backends compiled into the same binary. The header files even have a lot of #ifdef's. Either way, I've changed it to a weak function in v2. That way it's a bit easier to read. Alex
On 11/30/20 3:42 AM, Alexander Graf wrote: > > On 26.11.20 23:18, Eduardo Habkost wrote: >> On Thu, Nov 26, 2020 at 10:50:15PM +0100, Alexander Graf wrote: >>> When kicking another vCPU, we get an OS function that explicitly does that for us >>> on Apple Silicon. That works better than the current signaling logic, let's make >>> use of it there. >>> >>> Signed-off-by: Alexander Graf <agraf@csgraf.de> >>> --- >>> accel/hvf/hvf-cpus.c | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c >>> index b9f674478d..74a272d2e8 100644 >>> --- a/accel/hvf/hvf-cpus.c >>> +++ b/accel/hvf/hvf-cpus.c >>> @@ -418,8 +418,20 @@ static void hvf_start_vcpu_thread(CPUState *cpu) >>> cpu, QEMU_THREAD_JOINABLE); >>> } >>> >>> +#ifdef __aarch64__ >>> +static void hvf_kick_vcpu_thread(CPUState *cpu) >>> +{ >>> + if (!qemu_cpu_is_self(cpu)) { >>> + hv_vcpus_exit(&cpu->hvf_fd, 1); >>> + } >>> +} >>> +#endif >>> + >>> static const CpusAccel hvf_cpus = { >>> .create_vcpu_thread = hvf_start_vcpu_thread, >>> +#ifdef __aarch64__ >>> + .kick_vcpu_thread = hvf_kick_vcpu_thread, >>> +#endif >> Interesting. We have considered the possibility of adding >> arch-specific TYPE_ACCEL subclasses when discussing Claudio's, >> series. Here we have another arch-specific hack that could be >> avoided if we had a TYPE_ARM_HVF_ACCEL QOM class. > > > I don't think that's necessary in this case. I don't see how you could > ever have aarch64 and x86 HVF backends compiled into the same binary. > The header files even have a lot of #ifdef's. > > Either way, I've changed it to a weak function in v2. That way it's a > bit easier to read. > > > Alex > > Ciao Alex! you're in the news, congrats for your hack! Ciao, Claudio
diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c index b9f674478d..74a272d2e8 100644 --- a/accel/hvf/hvf-cpus.c +++ b/accel/hvf/hvf-cpus.c @@ -418,8 +418,20 @@ static void hvf_start_vcpu_thread(CPUState *cpu) cpu, QEMU_THREAD_JOINABLE); } +#ifdef __aarch64__ +static void hvf_kick_vcpu_thread(CPUState *cpu) +{ + if (!qemu_cpu_is_self(cpu)) { + hv_vcpus_exit(&cpu->hvf_fd, 1); + } +} +#endif + static const CpusAccel hvf_cpus = { .create_vcpu_thread = hvf_start_vcpu_thread, +#ifdef __aarch64__ + .kick_vcpu_thread = hvf_kick_vcpu_thread, +#endif .synchronize_post_reset = hvf_cpu_synchronize_post_reset, .synchronize_post_init = hvf_cpu_synchronize_post_init,
When kicking another vCPU, we get an OS function that explicitly does that for us on Apple Silicon. That works better than the current signaling logic, let's make use of it there. Signed-off-by: Alexander Graf <agraf@csgraf.de> --- accel/hvf/hvf-cpus.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)