David Gibson's on April 17, 2019 10:47 pm: > On Wed, Apr 17, 2019 at 02:01:29PM +0200, Greg Kurz wrote: >> 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). >> >> 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. > > Ah, ok. Oops, that means the guest environment has been visibly > different for KVM and TCG all this time, which isn't great. > >> Not sure about David's "no longer" wording though. > > > "no longer" meaning the previous patch version had some > kvmppc_enable_hcall(), but this version doesn't.
Let me do one more iteration with the comment fixed up at least, and I'll do a bit of testing with KVM vs TCG behaviour and see if there are any problems around this. Thanks, Nick