On 30.10.2012, at 15:29, Cornelia Huck <cornelia.huck@xxxxxxxxxx> wrote: > On Tue, 30 Oct 2012 14:43:10 +0100 > Alexander Graf <agraf@xxxxxxx> wrote: > >> On 10/30/2012 01:59 PM, Cornelia Huck wrote: >>> On Mon, 29 Oct 2012 19:14:19 +0100 >>> Alexander Graf<agraf@xxxxxxx> 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. Can we just drop kvm specific early printk support then? Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
