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 <mark.rutland@xxxxxxx> 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 <mark.rutland@xxxxxxx> 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.
