Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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.
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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.
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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.
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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 ag...@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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
Re: [Qemu-devel] [PATCH 10/13] Implement early printk in virtio-console
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
