On 31/10/2019 21:25, Julien Grall wrote: > Hi, > > On 31/10/2019 19:28, Andrew Cooper wrote: >> This code is especially tangled. VCPUOP_initialise calls into >> arch_initialise_vcpu() which calls back into default_initialise_vcpu() which >> is common code. >> >> This path is actually dead code on ARM, because VCPUOP_initialise is filtered >> out by do_arm_vcpu_op(). >> >> The only valid way to start a secondary CPU on ARM is via the PSCI interface. >> The same could in principle be said about INIT-SIPI-SIPI for x86 HVM, if HVM >> guests hadn't already interited a paravirt way of starting CPUs. >> >> Either way, it is quite likely that no future architectures implemented in >> Xen >> are going to want to use a PV interface, as some standardised (v)CPU bringup >> mechanism will already exist. > I am not sure I agree here. Looking at Linux RISCv code (see [1] and > [2]), it looks like the kernel has to deal with selecting one "lucky" > CPU/hart to deal with the boot and park all the others. > > So it looks like to me there are nothing at the moment on RISCv to do > (v)CPU bring-up. We might be able to use PSCI (although this is an ARM > specific way), but would rather wait and see what RISCv folks come up > with before deciding PV is never going to be used.
Nothing here prohibits other architectures from using a PV interface if they wish. However, your examples prove my point. There is an already-agreed way to start RISCv CPUs which is not a PV interface, and therefore is very unlikely to adopted to run differently under Xen. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
