On 08.01.2025 09:04, Roger Pau Monné wrote: > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote: >> 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. > > One concern I have with this approach is whether the addition of the > (d<N>) prefixes will skew output of interactive applications. So far > the prefix is added to output from all domains different than dom0 > because the console is not interactive for them, and hence no input > can be consumed.
Hmm, that's an aspect I have to admit I didn't think of. > If that changes however, and domains different than dom0 can get input > from the Xen console then I wonder how much the added prefix will skew > output. Another possible option would be to not print the prefix for > the domain that has the console input assigned (current target), and > print it for all other domains (even for dom0 when not in focus). That's largely what aiui was proposed. My extra requirement there would then be that we make sure a log message is always emitted when console focus shifts, so it's possible to identify the owner for any part of the log. Jan
