On Fri, Oct 27, 2017 at 08:59:23AM +0100, Marc Zyngier wrote: > On Fri, Oct 27 2017 at 8:37:28 am BST, Mark Rutland <[email protected]> > wrote: > > On Fri, Oct 27, 2017 at 07:57:12AM +0100, Marc Zyngier wrote: > >> On Thu, Oct 26 2017 at 4:48:39 pm BST, Mark Rutland > >> <[email protected]> wrote: > >> > On Fri, Oct 06, 2017 at 04:34:00PM +0100, Marc Zyngier wrote: > > > >> >> @@ -485,8 +495,21 @@ int vgic_v3_probe(const struct gic_kvm_info *info) > >> >> kvm_vgic_global_state.can_emulate_gicv2 = false; > >> >> kvm_vgic_global_state.ich_vtr_el2 = ich_vtr_el2; > >> >> > >> >> - /* GICv4 support? */ > >> >> + /* > >> >> + * GICv4 support? We need to check on all CPUs in case of some > >> >> + * extremely creative form of big-little brain damage... > >> >> + */ > >> >> if (info->has_v4) { > >> >> + int cpu; > >> >> + > >> >> + for_each_online_cpu(cpu) { > >> >> + bool enable; > >> >> + > >> >> + smp_call_function_single(cpu, > >> >> vgic_check_v4_cpuif, > >> >> + &enable, 1); > >> >> + gicv4_enable = gicv4_enable && enable; > >> >> + } > >> > > >> > With maxcpus=N on the command line, CPUs can be brought online late, so > >> > we > >> > might need this in a hotplug callback (and/or in the arm64 cpufeature > >> > framework) to handle that case. > >> > >> I'm afraid that won't be enough. If the CPU is brought up once we've > >> already started a VM, we're screwed, as we cannot retroactively decide > >> to drop GICv4 on the floor and nuke the guest. Or did you have something > >> more radical in mind? Panic? > > > > If you teach the arm64 cpufeature framework about this, it can abort > > bringing a > > !GICv4 CPU online late. > > You wish. > > There is all kind of difficulties with that. This requires checking an > EL2 register (ICH_VTR_EL2) when we've not initialised KVM yet (so no HYP > call facility). We could make it an additional hyp-stub feature, but > that feels pretty involved.
Aargh; I'd assumed we could probe this from EL1 somewhow. > Effectively, GICv4 support having it supported on the redistributors, > the ITSs, and the CPUs. The cpufeature framework only addresses the > first one. So unless the solution encompasses all the elements in the > chain, any checking feels pretty pointless. Sure thing. :/ Thanks, Mark. _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
