[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 3/5] arm/dom0less: put dom0less feature code in a separate module
>>>> Given that code movement is painful from a git history perspective, and >>>> given that we have to move dom0less code to xen/common anyway to make >>>> it available to RISC-V and also x86, could we do it in one shot here? >>> >>> Looking at the name of the functions, I would expect that we would need >>> another code movement in the future to move back Arm specific function >>> under arch/arm/. So we would end up with two code movement as well. >>> >>> I would prefer if we wait until RISC-V/x86 needs it so we don't >>> unnecessarily move Arm specific code in common/. >> >> I agree with Julien here. >> Moving the code now will mean moving part of it back in arm in the future >> once we have a second user of this. >> I would rather wait for the need to come so that we do this cleanly. >> >> Also using hyperlaunch name now would be weird as there was no agreement on >> the naming (as far as I know) so far. > > RISC-V is already using dom0less code, however in a downstream > repository. To make progress faster the code was copied (not shared) > from arch/arm to arch/riscv. More details on the Xen community call this > week. > https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv_aia_support/xen/arch/riscv/domain_build.c?ref_type=heads > > Hyperlaunch also needs dom0less code to be made common to make progress: > https://marc.info/?l=xen-devel&m=169154172700539 > > So I think that there is an immediate RISC-V and X86 need. > > But the point about "moving the code now will mean moving part of it > back in arm in the future" is valid. How do we move forward? > > I don't think we want to block Luca's progress to wait for more > plumbings done on x86 or RISC-V. Also we don't want to scope creep > Luca's series too much. > > But I think the goal should be to move dom0less code to xen/common as > soon as possible and make it arch neutral. How do we get there? So here is why I felt painful doing now a move to the common code, but maybe you (maintainers) can give me some feedbacks. I see that the functions that might be put in common are these, some of them however have arm specific code in them: is_dom0less_mode allocate_bank_memory allocate_memory handle_passthrough_prop handle_prop_pfdt scan_pfdt_node check_partial_fdt domain_p2m_pages alloc_xenstore_evtchn domain_handle_dtb_bootmodule (contains reference to the gic) prepare_dtb_domU (have reference to psci, gic, vpl011) construct_domU (have reference to vpl011, static shared memory) create_domUs(have reference to vpl011, sve) Here the functions that can stay in arm code: make_gicv2_domU_node make_gicv3_domU_node make_gic_domU_node make_vpl011_uart_node Given that the status after the move to common of the above functions is not very clean, I’ve decided to don’t do that, however if you are fine with it, I can do the modification and who is going to work further on the subject can consolidate and make them build for other architecture. Cheers, Luca
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |