| Message ID | 1259083781-14642-11-git-send-email-agraf@suse.de |
|---|---|
| State | New |
| Headers | show |
Alexander Graf wrote: > On our S390x Virtio machine we don't have anywhere to display early printks > on, because we don't know about VGA or serial ports. > > So instead we just forward everything to the virtio console that we created > anyways. > What is this used for? > Signed-off-by: Alexander Graf <agraf@suse.de> > --- > hw/virtio-console.c | 7 +++++++ > hw/virtio-console.h | 2 ++ > 2 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/hw/virtio-console.c b/hw/virtio-console.c > index 57f8f89..cd6cf20 100644 > --- a/hw/virtio-console.c > +++ b/hw/virtio-console.c > @@ -105,6 +105,13 @@ static void vcon_event(void *opaque, int event) > /* we will ignore any event for the time being */ > } > > +void virtio_console_print_early(VirtIODevice *vdev, uint8_t *buf) > +{ > + VirtIOConsole *s = to_virtio_console(vdev); > + > + qemu_chr_write(s->chr, buf, strlen((char*)buf)); > +} > + > static void virtio_console_save(QEMUFile *f, void *opaque) > { > VirtIOConsole *s = opaque; > diff --git a/hw/virtio-console.h b/hw/virtio-console.h > index 84d0717..f3ccc3c 100644 > --- a/hw/virtio-console.h > +++ b/hw/virtio-console.h > @@ -16,4 +16,6 @@ > /* The ID for virtio console */ > #define VIRTIO_ID_CONSOLE 3 > > +void virtio_console_print_early(VirtIODevice *vdev, uint8_t *buf); > + > #endif >
On 24.11.2009, at 19:55, Anthony Liguori wrote: > Alexander Graf wrote: >> On our S390x Virtio machine we don't have anywhere to display early printks >> on, because we don't know about VGA or serial ports. >> >> So instead we just forward everything to the virtio console that we created >> anyways. >> > > What is this used for? This is used for console output before virtio is initialized. I didn't invent it - that's the way it's implemented in the s390 kernels today. Alex
Alexander Graf wrote: > On 24.11.2009, at 19:55, Anthony Liguori wrote: > > >> Alexander Graf wrote: >> >>> On our S390x Virtio machine we don't have anywhere to display early printks >>> on, because we don't know about VGA or serial ports. >>> >>> So instead we just forward everything to the virtio console that we created >>> anyways. >>> >>> >> What is this used for? >> > > This is used for console output before virtio is initialized. I didn't invent it - that's the way it's implemented in the s390 kernels today. > I don't see any code that calls this function. Am I missing something obvious? > Alex Regards, Anthony Liguori
On 24.11.2009, at 20:25, Anthony Liguori wrote: > Alexander Graf wrote: >> On 24.11.2009, at 19:55, Anthony Liguori wrote: >> >> >>> Alexander Graf wrote: >>> >>>> On our S390x Virtio machine we don't have anywhere to display early printks >>>> on, because we don't know about VGA or serial ports. >>>> >>>> So instead we just forward everything to the virtio console that we created >>>> anyways. >>>> >>> What is this used for? >>> >> >> This is used for console output before virtio is initialized. I didn't invent it - that's the way it's implemented in the s390 kernels today. >> > > I don't see any code that calls this function. Am I missing something obvious? It gets called from target-s390x/kvm.c using a special hypercall instruction. Alex
Alexander Graf wrote: > On 24.11.2009, at 20:25, Anthony Liguori wrote: > > >> Alexander Graf wrote: >> >>> On 24.11.2009, at 19:55, Anthony Liguori wrote: >>> >>> >>> >>>> Alexander Graf wrote: >>>> >>>> >>>>> On our S390x Virtio machine we don't have anywhere to display early printks >>>>> on, because we don't know about VGA or serial ports. >>>>> >>>>> So instead we just forward everything to the virtio console that we created >>>>> anyways. >>>>> >>>>> >>>> What is this used for? >>>> >>>> >>> This is used for console output before virtio is initialized. I didn't invent it - that's the way it's implemented in the s390 kernels today. >>> >>> >> I don't see any code that calls this function. Am I missing something obvious? >> > > It gets called from target-s390x/kvm.c using a special hypercall instruction. > Oh, that's bad :-) That should really be it's own character device. We don't really have a way to connect two character devices like that. Maybe muxing? Regards, Anthony Liguori > Alex
On 24.11.2009, at 20:30, Anthony Liguori wrote: > Alexander Graf wrote: >> On 24.11.2009, at 20:25, Anthony Liguori wrote: >> >> >>> Alexander Graf wrote: >>> >>>> On 24.11.2009, at 19:55, Anthony Liguori wrote: >>>> >>>> >>>>> Alexander Graf wrote: >>>>> >>>>>> On our S390x Virtio machine we don't have anywhere to display early printks >>>>>> on, because we don't know about VGA or serial ports. >>>>>> >>>>>> So instead we just forward everything to the virtio console that we created >>>>>> anyways. >>>>>> >>>>> What is this used for? >>>>> >>>> This is used for console output before virtio is initialized. I didn't invent it - that's the way it's implemented in the s390 kernels today. >>>> >>> I don't see any code that calls this function. Am I missing something obvious? >>> >> >> It gets called from target-s390x/kvm.c using a special hypercall instruction. >> > > Oh, that's bad :-) > > That should really be it's own character device. We don't really have a way to connect two character devices like that. > Maybe muxing? So you want me to implement char muxing and a bootloader within a week? :) Alex
Alexander Graf wrote: >> Oh, that's bad :-) >> >> That should really be it's own character device. We don't really have a way to connect two character devices like that. >> Maybe muxing? >> > > So you want me to implement char muxing and a bootloader within a week? :) > Char muxing is already there. Don't know what to do about the bootloader bit. At this point, I'm curious about whether kboot would be a viable solution. > Alex Regards, Anthony Liguori
On 24.11.2009, at 20:48, Anthony Liguori wrote: > Alexander Graf wrote: >>> Oh, that's bad :-) >>> >>> That should really be it's own character device. We don't really have a way to connect two character devices like that. Maybe muxing? >>> >> >> So you want me to implement char muxing and a bootloader within a week? :) >> > > Char muxing is already there. Ah :-). I guess I could also just create a separate console. It's only for early printk anyways. > Don't know what to do about the bootloader bit. At this point, I'm curious about whether kboot would be a viable solution. My opinion would be to leave it as is for now and switch to a real bootloader that runs inside the guest later. Alex
Anthony Liguori wrote:
> What is this used for?
On x86 the kernel uses bios output for early prints. We don't have bios
and do therefore need to bring up a console device as early as possible
so that we can see kernel panics during I/O subsystem detection/startup.
All s390 console devices do support this function (3215/3270 and ASCII
console), and it is used only up to the point when the kernel has its
console subsystem ready to run.
Anthony Liguori wrote: > Oh, that's bad :-) > > That should really be it's own character device. We don't really have a > way to connect two character devices like that. Maybe muxing? It will be a character device, once the device tree is initialized. Better ideas are welcome, just keep in mind basic things like kmalloc don't work yet.
On Wednesday 25 November 2009, Carsten Otte wrote: > Anthony Liguori wrote: > > Oh, that's bad :-) > > > > That should really be it's own character device. We don't really have a > > way to connect two character devices like that. Maybe muxing? > It will be a character device, once the device tree is initialized. > Better ideas are welcome, just keep in mind basic things like kmalloc > don't work yet. > Can't you just leave it out for this release? Early printk is great for debugging, but not essential if you just want to run a guest as long as you get it past the virtio init phase. Arnd <><
Arnd Bergmann wrote: > Can't you just leave it out for this release? Early printk is great > for debugging, but not essential if you just want to run a guest > as long as you get it past the virtio init phase. The upstream kernel assumes to have this hypercall available when running on kvm. You won't get past the virtio init phase if you leave it out for kernels <= 2.6.32.
diff --git a/hw/virtio-console.c b/hw/virtio-console.c index 57f8f89..cd6cf20 100644 --- a/hw/virtio-console.c +++ b/hw/virtio-console.c @@ -105,6 +105,13 @@ static void vcon_event(void *opaque, int event) /* we will ignore any event for the time being */ } +void virtio_console_print_early(VirtIODevice *vdev, uint8_t *buf) +{ + VirtIOConsole *s = to_virtio_console(vdev); + + qemu_chr_write(s->chr, buf, strlen((char*)buf)); +} + static void virtio_console_save(QEMUFile *f, void *opaque) { VirtIOConsole *s = opaque; diff --git a/hw/virtio-console.h b/hw/virtio-console.h index 84d0717..f3ccc3c 100644 --- a/hw/virtio-console.h +++ b/hw/virtio-console.h @@ -16,4 +16,6 @@ /* The ID for virtio console */ #define VIRTIO_ID_CONSOLE 3 +void virtio_console_print_early(VirtIODevice *vdev, uint8_t *buf); + #endif
On our S390x Virtio machine we don't have anywhere to display early printks on, because we don't know about VGA or serial ports. So instead we just forward everything to the virtio console that we created anyways. Signed-off-by: Alexander Graf <agraf@suse.de> --- hw/virtio-console.c | 7 +++++++ hw/virtio-console.h | 2 ++ 2 files changed, 9 insertions(+), 0 deletions(-)