Hi Christophe, > In the discussion we had long time ago, > https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190806233827.16454-5-dja@xxxxxxxxxx/#2321067 > , I challenged you on why it was not possible to implement things the same way as other > architectures, in extenso with an early mapping. > > Your first answer was that too many things were done in real mode at startup. After some discussion > you said that finally there was not that much things at startup but the issue was KVM. > > Now you say that instrumentation on KVM is fully disabled. > > So my question is, if KVM is not a problem anymore, why not go the standard way with an early shadow > ? Then you could also support inline instrumentation. Fair enough, I've had some trouble both understanding the problem myself and clearly articulating it. Let me try again. We need translations on to access the shadow area. We reach setup_64.c::early_setup() with translations off. At this point we don't know what MMU we're running under, or our CPU features. To determine our MMU and CPU features, early_setup() calls functions (dt_cpu_ftrs_init, early_init_devtree) that call out to generic code like of_scan_flat_dt. We need to do this before we turn on translations because we can't set up the MMU until we know what MMU we have. So this puts us in a bind: - We can't set up an early shadow until we have translations on, which requires that the MMU is set up. - We can't set up an MMU until we call out to generic code for FDT parsing. So there will be calls to generic FDT parsing code that happen before the early shadow is set up. The setup code also prints a bunch of information about the platform with printk() while translations are off, so it wouldn't even be enough to disable instrumentation for bits of the generic DT code on ppc64. Does that make sense? If you can figure out how to 'square the circle' here I'm all ears. Other notes: - There's a comment about printk() being 'safe' in early_setup(), that refers to having a valid PACA, it doesn't mean that it's safe in any other sense. - KVM does indeed also run stuff with translations off but we can catch all of that by disabling instrumentation on the real-mode handlers: it doesn't seem to leak out to generic code. So you are right that KVM is no longer an issue. Kind regards, Daniel > > Christophe
