Greg Kurz's on April 17, 2019 10:01 pm: > On Wed, 17 Apr 2019 21:20:00 +1000 > Nicholas Piggin <npig...@gmail.com> wrote: >> [...] >> >> @@ -1860,6 +1928,9 @@ static void hypercall_register_types(void) >> >> /* hcall-splpar */ >> >> spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa); >> >> spapr_register_hypercall(H_CEDE, h_cede); >> >> + spapr_register_hypercall(H_CONFER, h_confer); >> >> + spapr_register_hypercall(H_PROD, h_prod); >> >> + >> >> spapr_register_hypercall(H_SIGNAL_SYS_RESET, h_signal_sys_reset); >> > >> > You're no longer enabling the KVM CONFER and PROD hypercalls. Are >> > they enabled by default, or is that an intentional change? >> > > AFAICT they seem to be enabled by default in HV KVM. > >> Oh, it was not intentional, I must not understand how this works. Why >> is this no longer enabling the those hcalls? >> > > Since linux commit 699a0ea0823d ("KVM: PPC: Book3S: Controls for in-kernel > sPAPR hypercall handling"), in-kernel hypercalls are disabled by default > and must be explicitely enabled by userspace. QEMU does that for some > hypercalls already (search kvmppc_enable_set_mode_hcall() in QEMU for an > example).
Thanks for the explanation, that's a nice feature. > Since H_CONFER and H_PROD are listed in default_hcall_list[] in book3s_hv.c, > no need for QEMU to enable them in KVM. It looks like we can disable even hcalls that are in the default list which might help with qemu H_JOIN implementation if we need to send H_PROD to qemu to do the wake-up. Thanks, Nick