Re: [PATCH 5/5] KVM: s390: Split out early console code.

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Tue, 30 Oct 2012 16:12:47 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> 
> On 30.10.2012, at 15:29, Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> 
> > On Tue, 30 Oct 2012 14:43:10 +0100
> > Alexander Graf <agraf@suse.de> wrote:
> > 
> >> On 10/30/2012 01:59 PM, Cornelia Huck wrote:
> >>> On Mon, 29 Oct 2012 19:14:19 +0100
> >>> Alexander Graf<agraf@suse.de>  wrote:
> >>> 
> >>>> On 29.10.2012, at 14:07, Cornelia Huck wrote:
> >>>> 
> >>>>> This code is transport agnostic and can be used by both the legacy
> >>>>> virtio code and virtio_ccw.
> >>>> Would it be possible to actually send real virtio or sclp console commands for early printk? That'd make things a lot easier on the user space end. Combining two completely separate character channels (early printk + sclp or early printk + virtio-console) is really tricky.
> >>>> 
> >>> This code is only used if we use a virtio console device. The sclp
> >>> code path is completely different.
> >> 
> >> Ah, so the sclp early console works differently?
> > 
> > sclp consoles are registered via console_initcall(). I'm not aware of
> > 'early' handling there (although I don't really know the code well.)
> > 
> >> 
> >>> What do you mean with "real virtio console commands"? The message is
> >>> just put on the output queue anyway.
> >> 
> >> For virtio-console, yes. For the early printk it is sent to the 
> >> hypervisor using a hypercall, not through the virtio queue. So it 
> >> arrives at a completely different end point that usually has no 
> >> knowledge of the virtio-console output driver.
> > 
> > virtio setup is a core_initcall, which is done way later than the
> > console_initcalls (including s390_virtio_console_init). According to
> > the comments, virtio_cons_early_init is there exactly for that reason.
> 
> It's never worked on upstream QEMU. 

It did on kuli ;)

> Can we just drop kvm specific early printk support then?

I'd prefer to leave this cleanup in the series for now. Whether we want
to do something in qemu or remove this is something we can discuss
later. In the meantime, there's sclp :)