On Mon Jun 23, 2025 at 4:26 PM CEST, Jan Beulich wrote: > On 23.06.2025 16:19, Alejandro Vallejo wrote: >> On Mon Jun 23, 2025 at 3:44 PM CEST, Jan Beulich wrote: >>> On 23.06.2025 15:11, Alejandro Vallejo wrote: >>>> On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote: >>>>> On 20.06.2025 20:28, Alejandro Vallejo wrote: >>>>>> Moving forward the idea is for there to be: >>>>>> 1. Basic DT support: used by dom0less/hyperlaunch. >>>>>> 2. Full DT support: used for device discovery and HW setup. >>>>>> >>>>>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), >>>>>> while >>>>>> DOM0LESS_BOOT is left to describe (1). >>>>> >>>>> Considering hyperlaunch this feels wrong to me. Did you consider splitting >>>>> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY, >>>>> as I suggested on the committers call? You weren't there, but Stefano said >>>>> he was taking notes. >>>> >>>> Some might've been lost is transit, I admit. I don't remember hearing about >>>> a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spotty >>>> when >>>> syncing with Stefano. >>>> >>>> Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as every >>>> arch would have it set. >>> >>> Hmm, yes, we don't want or need that. But then what's option 1 about? That >>> shouldn't be "described" by DOM0LESS_BOOT. >> >> It's about x86 using device_tree/ for hyperlaunch. x86 is the single user >> that >> doesn't need (2) at all. In the x86 case the same selector that picks >> >>> >>>> I'd definitely like for the "enable support to boot >>>> several predefined domains from DTB descriptions" to be a single option >>>> for both >>>> dom0less and hyperlaunch. And be selectable rather than unconditionally >>>> selected >>>> And ideally move towards a future in which both dom0less and hyperlaunch >>>> are one >>>> and the same. >>>> >>>> I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/ >>>> DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to do >>>> so >>>> until x86 gains the ability to boot off a DTB to avoid having help messages >>>> describing things not yet on the tree. >>> >>> I have to admit that it's not clear to me if that would help. As you say, on >>> x86 that's not a thing just yet. What I think we need to aim for is to not >>> leave the tree in a state that's more confusing than anything else. Even if >>> later (which may be much later) things would get tidied again. >> >> Ok, how about turning it on its head? Seems like we're in agreement with >> HAS_DEVICE_TREE_DISCOVERY for Full DT support. There could be a >> DEVICE_TREE_PARSE >> (no HAS_) that's selected by HAS_DEVICE_TREE_DISCOVERY and DOM0LESS_BOOT. >> This >> allows x86 to deselect it by not picking DOM0LESS_BOOT. >> >> Note that x86 cannot select DOM0LESS_BOOT yet, but that's how it'd compile-in >> hyperlaunch. In the meantime, the tree depends on DEVICE_TREE_PARSE instead >> and >> device_tree/ is gated by DEVICE_TREE_PARSE only. >> >> Sounds better? > > Yes. Except that in the last sentence of the previous paragraph: What's "the > tree"?
By "the tree", I meant the hypervisor tree. I just mean that Kconfig would use DEVICEC_TREE_PARSE for selection purposes and the code would ifdef based on DEVICE_TREE_PARSE rather than DOM0LESS_BOOT rather than using the latter as a proxy. > And in device_tree/ wouldn't we end up with unreachable code on x86 > this way (the parts that are needed only by HAS_DEVICE_TREE_DISCOVERY)? They'd be compiled-out, just as they are now gated on HAS_DEVICE_TREE_DISCOVERY on this patch. device-tree/ as a whole would be gated by DEVICE_TREE_PARSE, and each individual file inside might optionally be gated by stronger options. Cheers, Alejandro
