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. Jan
