On Mon, 2023-01-09 at 16:20 +1100, Andrew Donnellan wrote:
> On Mon, 2023-01-09 at 14:34 +1100, Russell Currey wrote:
> >
> > > > +static int plpks_secvar_init(void)
> > > > +{
> > > > + if (!plpks_is_available())
> > > > + return -ENODEV;
> > > > +
> > > > + set_secvar_ops(&plpks_secvar_ops);
> > > > + set_secvar_config_attrs(config_attrs);
> > > > + return 0;
> > > > +}
> > > > +device_initcall(plpks_secvar_init);
> > >
> > > That must be a machine_device_initcall(pseries, ...), otherwise
> > > we
> > > will
> > > blow up doing a hcall on powernv in plpks_is_available().
> >
> > OK, can do. I don't understand your case of how powernv could hit
> > this, but I think I to have to move plpks_is_available() into
> > include/,
> > so it's going to be even more possible anyway.
>
> Kernels can be compiled with both pseries and powernv support, in
> which
> case plpks_secvar_init() will be called unconditionally even when
> booting on a powernv machine.
>
> I can confirm that as it is, booting this on powernv qemu causes a
> panic.
Of course, I'm not sure why I thought an initcall in a platform that
wasn't active would magically not run on other platforms.
>
