If pvefi isn't being used (disabled or not dom0), this would seem to break stock efirt upon load/unload as we set efi_ops to the null-filled prev.

I originally had the check above returning ENXIO, but changed it as I didn't know whether that would be reported as an error. I guess returning ENXIO from load will prevent unload attempts?

Annoyingly enough, if you return ENXIO it will immediately be issued a MOD_UNLOAD anyways -- it's kind of a no-win situation. :-(

Can you please explain more how it breaks bare-metal efirt?

That said, I am not sure the prev business is useful at all.

Noting how it's implemented from the other review, we end up with an empty ops vector if prev is still .bss (early return in MOD_LOAD path)

It's likely not of much usage restoring active_efi_ops to prev on module unload, since you either use one of the two interfaces, but not both. I'm just doing it to prevent ending up with active_efi_ops == NULL which will trigger a page-fault.

I just added a prev != NULL check in this last version before attempting to set active_efi_ops = prev in the unload case. I'm not sure what's the best way to deal with this, should we have a nop_efi_ops that has all pointers set to NULL in order to set it here on module unload if the module was in-use?

nop_efi_ops is perhaps fine if the native vector is also in module with the same prev handling. But it is probably too much for useless scenarios.

efirt module is also where active_efi_ops is defined, so if the module is unloaded so is the symbol itself, hence not sure it makes much sense to set it to nop_efi_ops anyway.