On Wed, 2011-12-14 at 16:30 +0100, Paolo Bonzini wrote:
> On 12/14/2011 10:22 AM, Benjamin Herrenschmidt wrote:
> > of course you can use -device
> > to manually instanciate individual devices.
>
> That's true, however...
>
> > @@ -563,7 +568,9 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
> > }
> > }
> >
> > - spapr_populate_chosen_stdout(fdt, spapr->vio_bus);
> > + if (!spapr_has_graphics) {
> > + spapr_populate_chosen_stdout(fdt, spapr->vio_bus);
> > + }
> >
> > _FDT((fdt_pack(fdt)));
> >
>
> ... the stdout-path would still point to the serial console. Can that
> be fixed somehow?
That's hard. We don't want to change it unless there is both a video
card and a keyboard and even then...
Ideally we'd want a way to specifiy what the stdout path is to qemu but
I don't see any clean way to do so.
Another option would be to remove setting of stdout path from qemu
completely and instead set it entirely in SLOF.
The problem with that is that we also have this thing where SLOF (and
the kenrel low level debug when enabled) output to hvterm 0, which we
"magically" route to the same hvterm that we chose for stdout-path in
qemu so things remain consistent.
I suppose a way to solve that would be to not set stdout path but
instead a different property (qemu,default-hvterm) which SLOF can use as
part of its algorithm to select a default console.
This wouldn't be ideal for non-SLOF boots (-kernel) but then I've been
thinking about getting rid of that feature anyway (always use SLOF, just
pass it the kernel image someway) since we want SLOF to setup the PCI
BARs (and now to initialize the video card) etc...
In any case, I'd like to do those changes as a separate patch on top of
this one which doesn't introduce a regression from what is there today.
At which point I can synchronize the SLOF and qemu updates.
(Note the patch I posted applies on top of David's internal -next
branch, it may not apply on top of what's out there today, David will
sort things out for me I expect :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
