Re: [Xen-devel] [PATCH 00/17 v5] SBSA UART emulation support in Xen

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 5 Jul 2017, Julien Grall wrote:
> On 07/04/2017 08:31 AM, Bhupinder Thakur wrote:
> > Hi Julien,
> 
> Hi Bhupinder,
> 
> Thank you for the summary!
> 
> [...]
> > 
> > Currently, UEFI firmware uses hvc as the console for input/output. Now
> > with the support
> > of SBSA UART in Xen, it is preferrable that UEFI firmware should be
> > able to the uart
> > as well.
> > 
> > One option which was discussed was to use pl011 purely as a debug
> > port. Currently the debug
> > prints are intermixed with the normal console output. Now with uart
> > port becoming available
> > the debug prints can be redirected to pl011 thus cleaning up the console
> > output.
> > 
> > Other option is to output everything on both HVC and pl011 both but it
> > takes away the advantage
> > of separating out the debug and normal console prints. However, pl011
> > can be used as debug
> > port based on a compile time flag. If this compile-time is off, then
> > the output can be sent to both
> > HVC and pl011.
> > 
> > Based on this discussion I feel that:
> > - the default behaviour should be writing the output to both HVC and pl011.
> 
> Hmmm. If I remember correctly this was suggested but ruled out. It was
> considered that pl011 and PV console should not be treated equal. PL011 would
> be used for boot diagnostics (i.e imagine an Image with no Xen support).

Actually I remember the opposite:
afd2e931-706b-6e25-1f0e-feee16e83c88@xxxxxxxxxx (this was a private
reply though).


> So we would continue to use Xen PV console for UEFI console and let the choice
> for the debug at compile to be either on PL011 or PV console.
> 
> Stefano, any opinions?

I would approach this issue by asking the following question: "what
behavior would be more beneficial to users?" Given the lack of concrete
data, we have to make guesses.

I think it would least suprise users if the output went to both
consoles. Also, it would be more beneficial, because one could fully run
operating systems without Xen support (think of a small baremetal app)
without having to switch back and forth between PV console (for the
firmware) and PL011 (for the app).

However, as I wrote before on this topic, baremetal apps are unlikely to
boot from UEFI in the near future, so I admit this is not a very strong
use-case.


> > - pl011 can be used as a pure debug port based on a compile-time flag.
> 
> Agree.
> 
> > 
> > > 
> > > > 2. Linux seems to have hvc console as the default console i.e. if no
> > > >     console is specified then it uses hvc as the console. How can an
> > > >     option be provided in Linux to select either hvc or pl011 as the
> > > >     default console.
> > > 
> > > 
> > > I am wondering what would happen if you use stdout-path in the
> > > device-tree.
> > > Does it override the default console?
> > > 
> > I tried adding a "chosen" node in the DT to select "sbsa-pl011" as the
> > stdout-path. I added the
> >   following code in make_chosen_node() function:
> > 
> >   fdt_property_string(fdt, "stdout-path", "sbsa-pl011");
> > 
> > However, I still see the initial console output going to hvc only.
> 
> What do you mean by inital console output? You mean the bootconsole?
> 
> > 
> > > IHMO, the best way to select the default console would be using either the
> > > SPCR (for ACPI) or stdout-path (for DT). But the HVC console does not have
> > > any description in the firmware. It might be worth considering adding
> > > description.
> > > 
> > > The drawback is the user would always have to specify the console on the
> > > command line. I think this is not too bad for a first approach.
> > > 
> > Do we plan to address this requirement in the current patch series?
> 
> I am ok with this to be deferred. This is not highly critical. We should
> probably log it on xenproject.atlassian.net to avoid loosing the item.
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel