On 1/22/19 6:05 AM, Paul Mackerras wrote: > On Mon, Jan 07, 2019 at 07:43:17PM +0100, Cédric Le Goater wrote: >> This is the basic framework for the new KVM device supporting the XIVE >> native exploitation mode. The user interface exposes a new capability >> and a new KVM device to be used by QEMU. > > [snip] >> @@ -1039,7 +1039,10 @@ static int kvmppc_book3s_init(void) >> #ifdef CONFIG_KVM_XIVE >> if (xive_enabled()) { >> kvmppc_xive_init_module(); >> + kvmppc_xive_native_init_module(); >> kvm_register_device_ops(&kvm_xive_ops, KVM_DEV_TYPE_XICS); >> + kvm_register_device_ops(&kvm_xive_native_ops, >> + KVM_DEV_TYPE_XIVE); > > I think we want tighter conditions on initializing the xive_native > stuff and creating the xive device class. We could have > xive_enabled() returning true in a guest, and this code will get > called both by PR KVM and HV KVM (and HV KVM no longer implies that we > are running bare metal). So yes, I gave nested a try with kernel_irqchip=on and the nested hypervisor (L1) obviously crashes trying to call OPAL. I have tighten the test with : if (xive_enabled() && !kvmhv_on_pseries()) { for now. As this is a problem today in 5.0.x, I will send a patch for it if you think it is correct. I don't think we should bother taking care of the PR case on P9. Should we ? Thanks, C. >> @@ -1050,8 +1053,10 @@ static int kvmppc_book3s_init(void) >> static void kvmppc_book3s_exit(void) >> { >> #ifdef CONFIG_KVM_XICS >> - if (xive_enabled()) >> + if (xive_enabled()) { >> kvmppc_xive_exit_module(); >> + kvmppc_xive_native_exit_module(); > > Same comment here. > > Paul. >