On 08.01.2025 00:40, Stefano Stabellini wrote: > On Tue, 7 Jan 2025, Jan Beulich wrote: >> On 06.01.2025 19:48, Stefano Stabellini wrote: >>> On Mon, 6 Jan 2025, Jan Beulich wrote: >>>> On 04.01.2025 05:15, Denis Mukhin wrote: >>>>> >>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich >>>>> <jbeul...@suse.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote: >>>>>> >>>>>>> From: Denis Mukhin dmuk...@ford.com >>>>>>> >>>>>>> console_owner_domid() is introduced to obtain the "console owner" >>>>>>> domain ID. >>>>>>> >>>>>>> The call is used in NS8250 emulator to identify the case when physical >>>>>>> xen >>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which case, >>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix. >>>>>> >>>>>> >>>>>> Such messages ought to be processed through guest_printk(), which wants a >>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be >>>>>> current->domain anyway at the callsite, eliminating the need for such a >>>>>> >>>>>> helper altogether? >>>>> >>>>> If the current domain is owning the physical console and printing, say, >>>>> Linux >>>>> login prompt, there's no need to add "(XEN)" for every printout; adding >>>>> timestamps >>>>> can be disabled from Xen command line. >>>> >>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous in >>>> a log >>>> which domain a message came from. As long as only Dom0 messages are left >>>> un- >>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue >>>> such >>>> messages (and have console "focus") I think the prefix needs to be there. >>> >>> It looks like we are aligned on the desired behavior, >> >> Hmm, no, I don't think we are. I don't ... >> >>> but for clarity, >>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted >>> here: >>> >>> I think we should provide a consistent behavior across architectures. >>> The current behavior with vpl011 and dom0less on ARM is the following: >>> >>> - no prefix for Dom0 output >>> - DOM$NUM for DomUs when not in focus, otherwise no prefix >> >> ... view this model as a desirable one. It leaves room for ambiguity. > > Adding a few more people in CC for feedback. > > My priority is to keep the architectures aligned. It might be OK to > change output format, but then let's do it uniformly on ARM as well. > > Jan, please clarify what you think would be better than the above. Is it > the following? I don't think I understood your preference. > > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
No, I mean like we have it with guest_printk() today. (XEN) for Xen's own messages, (d<N>) for ordinary domains' ones, and no prefix exclusively for the hardware/control domain. What is best to do when hardware and control domains are distinct I'm uncertain - I'd be inclined to suggest that the hardware domain then stay the one without any prefix. Jan
