Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
At 08/15/2012 04:53 AM, Marcelo Tosatti Wrote:
> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>>> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>>
>> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>>
>>> On 2012-08-14 10:56, Daniel P. Berrange wrote:
On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>> We can know the guest is panicked when the guest runs on xen.
>> But we do not have such feature on kvm.
>>
>> Another purpose of this feature is: management app(for example:
>> libvirt) can do auto dump when the guest is panicked. If management
>> app does not do auto dump, the guest's user can do dump by hand if
>> he sees the guest is panicked.
>>
>> We have three solutions to implement this feature:
>> 1. use vmcall
>> 2. use I/O port
>> 3. use virtio-serial.
>>
>> We have decided to avoid touching hypervisor. The reason why I choose
>> choose the I/O port is:
>> 1. it is easier to implememt
>> 2. it does not depend any virtual device
>> 3. it can work when starting the kernel
>
> How about searching for the "Kernel panic - not syncing" string
> in the guests serial output? Say libvirtd could take an action upon
> that?
No, this is not satisfactory. It depends on the guest OS being
configured to use the serial port for console output which we
cannot mandate, since it may well be required for other purposes.
>>>
>> Please don't forget Windows guests, there is no console and no "Kernel
>> Panic" string ;)
>>
>> What I used for debugging purposes on Windows guest is to register a
>> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
>> register.
>>
>> Yan.
>
> Considering whether a "panic-device" should cover other OSes is also \
>>>
> something to consider. Even for Linux, is "panic" the only case which
> should be reported via the mechanism? What about oopses without panic?
>
> Is the mechanism general enough for supporting new events, etc.
Hi,
I think this discussion is gone of the deep end.
Forget about !x86 platforms. They have their own way to do this sort of
thing.
>>>
>>> The panic function in kernel/panic.c has the following options, which
>>> appear to be arch independent, on panic:
>>>
>>> - reboot
>>> - blink
>>
>> Not sure the semantics of blink but that might be a good place for a
>> pvops hook.
>>
>>>
>>> None are paravirtual interfaces however.
>>>
Think of this feature like a status LED on a motherboard. These
are very common and usually controlled by IO ports.
We're simply reserving a "status LED" for the guest to indicate that it
has paniced. Let's not over engineer this.
>>>
>>> My concern is that you end up with state that is dependant on x86.
>>>
>>> Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
>>>
>>> Having the ability to stop/restart the guest (and even introducing a
>>> new VM runstate) is more than a status LED analogy.
>>
>> I must admit, I don't know why a new runstate is necessary/useful. The
>> kernel shouldn't have to care about the difference between a halted guest
>> and a panicked guest. That level of information belongs in userspace IMHO.
>>
>>> Can this new infrastructure be used by other architectures?
>>
>> I guess I don't understand why the kernel side of this isn't anything
>> more than a paravirt op hook that does a single outb() with the
>> remaining logic handled 100% in QEMU.
>
>>From the patch description:
>
> "Another purpose of this feature is: management app(for example:
> libvirt) can do auto dump when the guest is panicked. If management
> app does not do auto dump, the guest's user can do dump by hand if
> he sees the guest is panicked."
>
> Wen, auto dump means dump of guest memory?
Yes.
>
> In that case, the notification should obviously stop the guest
> otherwise the guest might be reset by the time memdump from QEMU
> monitor runs.
Yes, the guest is stopped while auto dumping.
>
> But kexec supports dumping of memory already (i suppose it can
> do automatic dump+{reboot,shutdown}).
It can be easily done in management app.
Thanks
Wen Congyang
>
>>> Do you consider allowing support for Windows as overengineering?
>>
>> I don't think there is a way to hook BSOD on Windows so attempting to
>> engineer something that works with Windows seems odd, no?
>
> Unsure about hooking at BSOD time. But Windows has configurable
> memory dump/reset/reboot, so yes it should not necessary.
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
At 08/15/2012 04:53 AM, Marcelo Tosatti Wrote:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
On 2012-08-14 10:56, Daniel P. Berrange wrote:
On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
How about searching for the Kernel panic - not syncing string
in the guests serial output? Say libvirtd could take an action upon
that?
No, this is not satisfactory. It depends on the guest OS being
configured to use the serial port for console output which we
cannot mandate, since it may well be required for other purposes.
Please don't forget Windows guests, there is no console and no Kernel
Panic string ;)
What I used for debugging purposes on Windows guest is to register a
bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
register.
Yan.
Considering whether a panic-device should cover other OSes is also \
something to consider. Even for Linux, is panic the only case which
should be reported via the mechanism? What about oopses without panic?
Is the mechanism general enough for supporting new events, etc.
Hi,
I think this discussion is gone of the deep end.
Forget about !x86 platforms. They have their own way to do this sort of
thing.
The panic function in kernel/panic.c has the following options, which
appear to be arch independent, on panic:
- reboot
- blink
Not sure the semantics of blink but that might be a good place for a
pvops hook.
None are paravirtual interfaces however.
Think of this feature like a status LED on a motherboard. These
are very common and usually controlled by IO ports.
We're simply reserving a status LED for the guest to indicate that it
has paniced. Let's not over engineer this.
My concern is that you end up with state that is dependant on x86.
Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
Having the ability to stop/restart the guest (and even introducing a
new VM runstate) is more than a status LED analogy.
I must admit, I don't know why a new runstate is necessary/useful. The
kernel shouldn't have to care about the difference between a halted guest
and a panicked guest. That level of information belongs in userspace IMHO.
Can this new infrastructure be used by other architectures?
I guess I don't understand why the kernel side of this isn't anything
more than a paravirt op hook that does a single outb() with the
remaining logic handled 100% in QEMU.
From the patch description:
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
Wen, auto dump means dump of guest memory?
Yes.
In that case, the notification should obviously stop the guest
otherwise the guest might be reset by the time memdump from QEMU
monitor runs.
Yes, the guest is stopped while auto dumping.
But kexec supports dumping of memory already (i suppose it can
do automatic dump+{reboot,shutdown}).
It can be easily done in management app.
Thanks
Wen Congyang
Do you consider allowing support for Windows as overengineering?
I don't think there is a way to hook BSOD on Windows so attempting to
engineer something that works with Windows seems odd, no?
Unsure about hooking at BSOD time. But Windows has configurable
memory dump/reset/reboot, so yes it should not necessary.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
Well, we have more than a single serial port, even when leaving
virtio-serial aside...
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Aug 15, 2012, at 12:56 PM, Gleb Natapov wrote: > On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote: >>> Do you consider allowing support for Windows as overengineering? >> >> I don't think there is a way to hook BSOD on Windows so attempting to >> engineer something that works with Windows seems odd, no? >> > Yan says in other email that is is possible to register a bugcheck callback. > Here you go - http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx Already done in virtio-net for two reasons: 1. we could configure virtio-net to notify QEMU in a hacky way (write 1 to VIRTIO_PCI_ISR register) that there was a bugckeck .It was very useful debugging complex WHQL issues that involved host networking. 2. Store additional information (for example time stamps of last receive packet, last interrupt and etc) in crash dump. Yan. > -- > Gleb. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Aug 14, 2012, at 10:35 PM, Anthony Liguori wrote: > Marcelo Tosatti writes: > >> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: >>> Marcelo Tosatti writes: >>> On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: > > On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: > >> On 2012-08-14 10:56, Daniel P. Berrange wrote: >>> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > We can know the guest is panicked when the guest runs on xen. > But we do not have such feature on kvm. > > Another purpose of this feature is: management app(for example: > libvirt) can do auto dump when the guest is panicked. If management > app does not do auto dump, the guest's user can do dump by hand if > he sees the guest is panicked. > > We have three solutions to implement this feature: > 1. use vmcall > 2. use I/O port > 3. use virtio-serial. > > We have decided to avoid touching hypervisor. The reason why I choose > choose the I/O port is: > 1. it is easier to implememt > 2. it does not depend any virtual device > 3. it can work when starting the kernel How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that? >>> >>> No, this is not satisfactory. It depends on the guest OS being >>> configured to use the serial port for console output which we >>> cannot mandate, since it may well be required for other purposes. >> > Please don't forget Windows guests, there is no console and no "Kernel > Panic" string ;) > > What I used for debugging purposes on Windows guest is to register a > bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR > register. > > Yan. Considering whether a "panic-device" should cover other OSes is also \ >> something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic? Is the mechanism general enough for supporting new events, etc. >>> >>> Hi, >>> >>> I think this discussion is gone of the deep end. >>> >>> Forget about !x86 platforms. They have their own way to do this sort of >>> thing. >> >> The panic function in kernel/panic.c has the following options, which >> appear to be arch independent, on panic: >> >> - reboot >> - blink > > Not sure the semantics of blink but that might be a good place for a > pvops hook. > >> >> None are paravirtual interfaces however. >> >>> Think of this feature like a status LED on a motherboard. These >>> are very common and usually controlled by IO ports. >>> >>> We're simply reserving a "status LED" for the guest to indicate that it >>> has paniced. Let's not over engineer this. >> >> My concern is that you end up with state that is dependant on x86. >> >> Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED >> >> Having the ability to stop/restart the guest (and even introducing a >> new VM runstate) is more than a status LED analogy. > > I must admit, I don't know why a new runstate is necessary/useful. The > kernel shouldn't have to care about the difference between a halted guest > and a panicked guest. That level of information belongs in userspace IMHO. > >> Can this new infrastructure be used by other architectures? > > I guess I don't understand why the kernel side of this isn't anything > more than a paravirt op hook that does a single outb() with the > remaining logic handled 100% in QEMU. > >> Do you consider allowing support for Windows as overengineering? > > I don't think there is a way to hook BSOD on Windows so attempting to > engineer something that works with Windows seems odd, no? > Actually there is a way (http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx). That's what I just mentioned already done in Windows virtio-net driver. Best regards, Yan. > Regards, > > Anthony Liguori > >> >>> Regards, >>> >>> Anthony Liguori >>> > >> Well, we have more than a single serial port, even when leaving >> virtio-serial aside... >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE >> Corporate Competence Center Embedded Linux >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote: > > Do you consider allowing support for Windows as overengineering? > > I don't think there is a way to hook BSOD on Windows so attempting to > engineer something that works with Windows seems odd, no? > Yan says in other email that is is possible to register a bugcheck callback. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote: Do you consider allowing support for Windows as overengineering? I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no? Yan says in other email that is is possible to register a bugcheck callback. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Aug 14, 2012, at 10:35 PM, Anthony Liguori wrote: Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: On 2012-08-14 10:56, Daniel P. Berrange wrote: On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes. Please don't forget Windows guests, there is no console and no Kernel Panic string ;) What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register. Yan. Considering whether a panic-device should cover other OSes is also \ something to consider. Even for Linux, is panic the only case which should be reported via the mechanism? What about oopses without panic? Is the mechanism general enough for supporting new events, etc. Hi, I think this discussion is gone of the deep end. Forget about !x86 platforms. They have their own way to do this sort of thing. The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic: - reboot - blink Not sure the semantics of blink but that might be a good place for a pvops hook. None are paravirtual interfaces however. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports. We're simply reserving a status LED for the guest to indicate that it has paniced. Let's not over engineer this. My concern is that you end up with state that is dependant on x86. Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy. I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO. Can this new infrastructure be used by other architectures? I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU. Do you consider allowing support for Windows as overengineering? I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no? Actually there is a way (http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx). That's what I just mentioned already done in Windows virtio-net driver. Best regards, Yan. Regards, Anthony Liguori Regards, Anthony Liguori Well, we have more than a single serial port, even when leaving virtio-serial aside... Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Aug 15, 2012, at 12:56 PM, Gleb Natapov wrote: On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote: Do you consider allowing support for Windows as overengineering? I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no? Yan says in other email that is is possible to register a bugcheck callback. Here you go - http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx Already done in virtio-net for two reasons: 1. we could configure virtio-net to notify QEMU in a hacky way (write 1 to VIRTIO_PCI_ISR register) that there was a bugckeck .It was very useful debugging complex WHQL issues that involved host networking. 2. Store additional information (for example time stamps of last receive packet, last interrupt and etc) in crash dump. Yan. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked\
On Tue, Aug 14, 2012 at 05:59:06PM -0500, Anthony Liguori wrote: > Marcelo Tosatti writes: > > > On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote: > >> Marcelo Tosatti writes: > >> > >> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: > >> >> Marcelo Tosatti writes: > >> >> > >> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: > >> >> >> > >> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: > >> >> >> > >> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote: > >> >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: > >> >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > >> >> >> We can know the guest is panicked when the guest runs on xen. > >> >> >> But we do not have such feature on kvm. > >> >> >> > >> >> >> Another purpose of this feature is: management app(for example: > >> >> >> libvirt) can do auto dump when the guest is panicked. If > >> >> >> management > >> >> >> app does not do auto dump, the guest's user can do dump by hand > >> >> >> if > >> >> >> he sees the guest is panicked. > >> >> >> > >> >> >> We have three solutions to implement this feature: > >> >> >> 1. use vmcall > >> >> >> 2. use I/O port > >> >> >> 3. use virtio-serial. > >> >> >> > >> >> >> We have decided to avoid touching hypervisor. The reason why I > >> >> >> choose > >> >> >> choose the I/O port is: > >> >> >> 1. it is easier to implememt > >> >> >> 2. it does not depend any virtual device > >> >> >> 3. it can work when starting the kernel > >> >> >> >>> > >> >> >> >>> How about searching for the "Kernel panic - not syncing" string > >> >> >> >>> in the guests serial output? Say libvirtd could take an action > >> >> >> >>> upon > >> >> >> >>> that? > >> >> >> >> > >> >> >> >> No, this is not satisfactory. It depends on the guest OS being > >> >> >> >> configured to use the serial port for console output which we > >> >> >> >> cannot mandate, since it may well be required for other purposes. > >> >> >> > > >> >> >> Please don't forget Windows guests, there is no console and no > >> >> >> "Kernel Panic" string ;) > >> >> >> > >> >> >> What I used for debugging purposes on Windows guest is to register a > >> >> >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR > >> >> >> register. > >> >> >> > >> >> >> Yan. > >> >> > > >> >> > Considering whether a "panic-device" should cover other OSes is also \ > >> > > >> >> > something to consider. Even for Linux, is "panic" the only case which > >> >> > should be reported via the mechanism? What about oopses without > >> >> > panic? > >> >> > > >> >> > Is the mechanism general enough for supporting new events, etc. > >> >> > >> >> Hi, > >> >> > >> >> I think this discussion is gone of the deep end. > >> >> > >> >> Forget about !x86 platforms. They have their own way to do this sort of > >> >> thing. > >> > > >> > The panic function in kernel/panic.c has the following options, which > >> > appear to be arch independent, on panic: > >> > > >> > - reboot > >> > - blink > >> > >> Not sure the semantics of blink but that might be a good place for a > >> pvops hook. > >> > >> > > >> > None are paravirtual interfaces however. > >> > > >> >> Think of this feature like a status LED on a motherboard. These > >> >> are very common and usually controlled by IO ports. > >> >> > >> >> We're simply reserving a "status LED" for the guest to indicate that it > >> >> has paniced. Let's not over engineer this. > >> > > >> > My concern is that you end up with state that is dependant on x86. > >> > > >> > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED > >> > > >> > Having the ability to stop/restart the guest (and even introducing a > >> > new VM runstate) is more than a status LED analogy. > >> > >> I must admit, I don't know why a new runstate is necessary/useful. The > >> kernel shouldn't have to care about the difference between a halted guest > >> and a panicked guest. That level of information belongs in userspace IMHO. > >> > >> > Can this new infrastructure be used by other architectures? > >> > >> I guess I don't understand why the kernel side of this isn't anything > >> more than a paravirt op hook that does a single outb() with the > >> remaining logic handled 100% in QEMU. > > > > From the patch description: > > > > "Another purpose of this feature is: management app(for example: > > libvirt) can do auto dump when the guest is panicked. If management > > app does not do auto dump, the guest's user can do dump by hand if > > he sees the guest is panicked." > > Why does this mandated another runstate? Good question. > QEMU can simply mark the VCPUs as stopped and raise a QMP event. Yes. As long as management app is able to find out for what the reason the VM has been stopped (that is, its not an issue
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> >> Marcelo Tosatti writes:
>> >>
>> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> >> >>
>> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>> >> >>
>> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
>> >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>> >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>> >> >> We can know the guest is panicked when the guest runs on xen.
>> >> >> But we do not have such feature on kvm.
>> >> >>
>> >> >> Another purpose of this feature is: management app(for example:
>> >> >> libvirt) can do auto dump when the guest is panicked. If
>> >> >> management
>> >> >> app does not do auto dump, the guest's user can do dump by hand if
>> >> >> he sees the guest is panicked.
>> >> >>
>> >> >> We have three solutions to implement this feature:
>> >> >> 1. use vmcall
>> >> >> 2. use I/O port
>> >> >> 3. use virtio-serial.
>> >> >>
>> >> >> We have decided to avoid touching hypervisor. The reason why I
>> >> >> choose
>> >> >> choose the I/O port is:
>> >> >> 1. it is easier to implememt
>> >> >> 2. it does not depend any virtual device
>> >> >> 3. it can work when starting the kernel
>> >> >> >>>
>> >> >> >>> How about searching for the "Kernel panic - not syncing" string
>> >> >> >>> in the guests serial output? Say libvirtd could take an action upon
>> >> >> >>> that?
>> >> >> >>
>> >> >> >> No, this is not satisfactory. It depends on the guest OS being
>> >> >> >> configured to use the serial port for console output which we
>> >> >> >> cannot mandate, since it may well be required for other purposes.
>> >> >> >
>> >> >> Please don't forget Windows guests, there is no console and no "Kernel
>> >> >> Panic" string ;)
>> >> >>
>> >> >> What I used for debugging purposes on Windows guest is to register a
>> >> >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
>> >> >> register.
>> >> >>
>> >> >> Yan.
>> >> >
>> >> > Considering whether a "panic-device" should cover other OSes is also \
>> >
>> >> > something to consider. Even for Linux, is "panic" the only case which
>> >> > should be reported via the mechanism? What about oopses without panic?
>> >> >
>> >> > Is the mechanism general enough for supporting new events, etc.
>> >>
>> >> Hi,
>> >>
>> >> I think this discussion is gone of the deep end.
>> >>
>> >> Forget about !x86 platforms. They have their own way to do this sort of
>> >> thing.
>> >
>> > The panic function in kernel/panic.c has the following options, which
>> > appear to be arch independent, on panic:
>> >
>> > - reboot
>> > - blink
>>
>> Not sure the semantics of blink but that might be a good place for a
>> pvops hook.
>>
>> >
>> > None are paravirtual interfaces however.
>> >
>> >> Think of this feature like a status LED on a motherboard. These
>> >> are very common and usually controlled by IO ports.
>> >>
>> >> We're simply reserving a "status LED" for the guest to indicate that it
>> >> has paniced. Let's not over engineer this.
>> >
>> > My concern is that you end up with state that is dependant on x86.
>> >
>> > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
>> >
>> > Having the ability to stop/restart the guest (and even introducing a
>> > new VM runstate) is more than a status LED analogy.
>>
>> I must admit, I don't know why a new runstate is necessary/useful. The
>> kernel shouldn't have to care about the difference between a halted guest
>> and a panicked guest. That level of information belongs in userspace IMHO.
>>
>> > Can this new infrastructure be used by other architectures?
>>
>> I guess I don't understand why the kernel side of this isn't anything
>> more than a paravirt op hook that does a single outb() with the
>> remaining logic handled 100% in QEMU.
>
> From the patch description:
>
> "Another purpose of this feature is: management app(for example:
> libvirt) can do auto dump when the guest is panicked. If management
> app does not do auto dump, the guest's user can do dump by hand if
> he sees the guest is panicked."
Why does this mandated another runstate? QEMU can simply mark the VCPUs
as stopped and raise a QMP event. The kernel doesn't care if the VCPUs
are stopped or panicked.
> Wen, auto dump means dump of guest memory?
>
> In that case, the notification should obviously stop the guest
> otherwise the guest might be reset by the time memdump from QEMU
> monitor runs.
>
> But kexec supports dumping of memory already (i suppose it can
> do automatic dump+{reboot,shutdown}).
>
>> > Do you consider allowing support for Windows as overengineering?
>>
>> I don't think there is a
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti writes:
>
> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
> >> Marcelo Tosatti writes:
> >>
> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
> >> >>
> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
> >> >>
> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
> >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
> >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> >> >> We can know the guest is panicked when the guest runs on xen.
> >> >> But we do not have such feature on kvm.
> >> >>
> >> >> Another purpose of this feature is: management app(for example:
> >> >> libvirt) can do auto dump when the guest is panicked. If management
> >> >> app does not do auto dump, the guest's user can do dump by hand if
> >> >> he sees the guest is panicked.
> >> >>
> >> >> We have three solutions to implement this feature:
> >> >> 1. use vmcall
> >> >> 2. use I/O port
> >> >> 3. use virtio-serial.
> >> >>
> >> >> We have decided to avoid touching hypervisor. The reason why I
> >> >> choose
> >> >> choose the I/O port is:
> >> >> 1. it is easier to implememt
> >> >> 2. it does not depend any virtual device
> >> >> 3. it can work when starting the kernel
> >> >> >>>
> >> >> >>> How about searching for the "Kernel panic - not syncing" string
> >> >> >>> in the guests serial output? Say libvirtd could take an action upon
> >> >> >>> that?
> >> >> >>
> >> >> >> No, this is not satisfactory. It depends on the guest OS being
> >> >> >> configured to use the serial port for console output which we
> >> >> >> cannot mandate, since it may well be required for other purposes.
> >> >> >
> >> >> Please don't forget Windows guests, there is no console and no "Kernel
> >> >> Panic" string ;)
> >> >>
> >> >> What I used for debugging purposes on Windows guest is to register a
> >> >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
> >> >> register.
> >> >>
> >> >> Yan.
> >> >
> >> > Considering whether a "panic-device" should cover other OSes is also \
> >
> >> > something to consider. Even for Linux, is "panic" the only case which
> >> > should be reported via the mechanism? What about oopses without panic?
> >> >
> >> > Is the mechanism general enough for supporting new events, etc.
> >>
> >> Hi,
> >>
> >> I think this discussion is gone of the deep end.
> >>
> >> Forget about !x86 platforms. They have their own way to do this sort of
> >> thing.
> >
> > The panic function in kernel/panic.c has the following options, which
> > appear to be arch independent, on panic:
> >
> > - reboot
> > - blink
>
> Not sure the semantics of blink but that might be a good place for a
> pvops hook.
>
> >
> > None are paravirtual interfaces however.
> >
> >> Think of this feature like a status LED on a motherboard. These
> >> are very common and usually controlled by IO ports.
> >>
> >> We're simply reserving a "status LED" for the guest to indicate that it
> >> has paniced. Let's not over engineer this.
> >
> > My concern is that you end up with state that is dependant on x86.
> >
> > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
> >
> > Having the ability to stop/restart the guest (and even introducing a
> > new VM runstate) is more than a status LED analogy.
>
> I must admit, I don't know why a new runstate is necessary/useful. The
> kernel shouldn't have to care about the difference between a halted guest
> and a panicked guest. That level of information belongs in userspace IMHO.
>
> > Can this new infrastructure be used by other architectures?
>
> I guess I don't understand why the kernel side of this isn't anything
> more than a paravirt op hook that does a single outb() with the
> remaining logic handled 100% in QEMU.
>From the patch description:
"Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked."
Wen, auto dump means dump of guest memory?
In that case, the notification should obviously stop the guest
otherwise the guest might be reset by the time memdump from QEMU
monitor runs.
But kexec supports dumping of memory already (i suppose it can
do automatic dump+{reboot,shutdown}).
> > Do you consider allowing support for Windows as overengineering?
>
> I don't think there is a way to hook BSOD on Windows so attempting to
> engineer something that works with Windows seems odd, no?
Unsure about hooking at BSOD time. But Windows has configurable
memory dump/reset/reboot, so yes it should not necessary.
>
> Regards,
>
> Anthony Liguori
>
> >
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> >> >
> >> >>
> >>
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On 14 August 2012 19:53, Anthony Liguori wrote: > Forget about !x86 platforms. They have their own way to do this sort of > thing. Think of this feature like a status LED on a motherboard. These > are very common and usually controlled by IO ports. Please don't forget !x86 platforms, we are cute and loveable really :-) > We're simply reserving a "status LED" for the guest to indicate that it > has paniced. Let's not over engineer this. ...not that QEMU actually has any kind of "front panel lights and switches" interface at all, it might be nice to have one. I bet a lot of the embedded boards have function DIP switches, heartbeat LEDs, etc etc... -- PMM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti writes: > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: >> Marcelo Tosatti writes: >> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: >> >> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: >> >> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote: >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: >> >> We can know the guest is panicked when the guest runs on xen. >> >> But we do not have such feature on kvm. >> >> >> >> Another purpose of this feature is: management app(for example: >> >> libvirt) can do auto dump when the guest is panicked. If management >> >> app does not do auto dump, the guest's user can do dump by hand if >> >> he sees the guest is panicked. >> >> >> >> We have three solutions to implement this feature: >> >> 1. use vmcall >> >> 2. use I/O port >> >> 3. use virtio-serial. >> >> >> >> We have decided to avoid touching hypervisor. The reason why I choose >> >> choose the I/O port is: >> >> 1. it is easier to implememt >> >> 2. it does not depend any virtual device >> >> 3. it can work when starting the kernel >> >> >>> >> >> >>> How about searching for the "Kernel panic - not syncing" string >> >> >>> in the guests serial output? Say libvirtd could take an action upon >> >> >>> that? >> >> >> >> >> >> No, this is not satisfactory. It depends on the guest OS being >> >> >> configured to use the serial port for console output which we >> >> >> cannot mandate, since it may well be required for other purposes. >> >> > >> >> Please don't forget Windows guests, there is no console and no "Kernel >> >> Panic" string ;) >> >> >> >> What I used for debugging purposes on Windows guest is to register a >> >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR >> >> register. >> >> >> >> Yan. >> > >> > Considering whether a "panic-device" should cover other OSes is also \ > >> > something to consider. Even for Linux, is "panic" the only case which >> > should be reported via the mechanism? What about oopses without panic? >> > >> > Is the mechanism general enough for supporting new events, etc. >> >> Hi, >> >> I think this discussion is gone of the deep end. >> >> Forget about !x86 platforms. They have their own way to do this sort of >> thing. > > The panic function in kernel/panic.c has the following options, which > appear to be arch independent, on panic: > > - reboot > - blink Not sure the semantics of blink but that might be a good place for a pvops hook. > > None are paravirtual interfaces however. > >> Think of this feature like a status LED on a motherboard. These >> are very common and usually controlled by IO ports. >> >> We're simply reserving a "status LED" for the guest to indicate that it >> has paniced. Let's not over engineer this. > > My concern is that you end up with state that is dependant on x86. > > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED > > Having the ability to stop/restart the guest (and even introducing a > new VM runstate) is more than a status LED analogy. I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO. > Can this new infrastructure be used by other architectures? I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU. > Do you consider allowing support for Windows as overengineering? I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no? Regards, Anthony Liguori > >> Regards, >> >> Anthony Liguori >> >> > >> >> >> >> > Well, we have more than a single serial port, even when leaving >> >> > virtio-serial aside... >> >> > >> >> > Jan >> >> > >> >> > -- >> >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE >> >> > Corporate Competence Center Embedded Linux >> >> > -- >> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in >> >> > the body of a message to majord...@vger.kernel.org >> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: > Marcelo Tosatti writes: > > > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: > >> > >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: > >> > >> > On 2012-08-14 10:56, Daniel P. Berrange wrote: > >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: > >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > >> We can know the guest is panicked when the guest runs on xen. > >> But we do not have such feature on kvm. > >> > >> Another purpose of this feature is: management app(for example: > >> libvirt) can do auto dump when the guest is panicked. If management > >> app does not do auto dump, the guest's user can do dump by hand if > >> he sees the guest is panicked. > >> > >> We have three solutions to implement this feature: > >> 1. use vmcall > >> 2. use I/O port > >> 3. use virtio-serial. > >> > >> We have decided to avoid touching hypervisor. The reason why I choose > >> choose the I/O port is: > >> 1. it is easier to implememt > >> 2. it does not depend any virtual device > >> 3. it can work when starting the kernel > >> >>> > >> >>> How about searching for the "Kernel panic - not syncing" string > >> >>> in the guests serial output? Say libvirtd could take an action upon > >> >>> that? > >> >> > >> >> No, this is not satisfactory. It depends on the guest OS being > >> >> configured to use the serial port for console output which we > >> >> cannot mandate, since it may well be required for other purposes. > >> > > >> Please don't forget Windows guests, there is no console and no "Kernel > >> Panic" string ;) > >> > >> What I used for debugging purposes on Windows guest is to register a > >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR > >> register. > >> > >> Yan. > > > > Considering whether a "panic-device" should cover other OSes is also \ > > something to consider. Even for Linux, is "panic" the only case which > > should be reported via the mechanism? What about oopses without panic? > > > > Is the mechanism general enough for supporting new events, etc. > > Hi, > > I think this discussion is gone of the deep end. > > Forget about !x86 platforms. They have their own way to do this sort of > thing. The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic: - reboot - blink None are paravirtual interfaces however. > Think of this feature like a status LED on a motherboard. These > are very common and usually controlled by IO ports. > > We're simply reserving a "status LED" for the guest to indicate that it > has paniced. Let's not over engineer this. My concern is that you end up with state that is dependant on x86. Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy. Can this new infrastructure be used by other architectures? Do you consider allowing support for Windows as overengineering? > Regards, > > Anthony Liguori > > > > >> > >> > Well, we have more than a single serial port, even when leaving > >> > virtio-serial aside... > >> > > >> > Jan > >> > > >> > -- > >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE > >> > Corporate Competence Center Embedded Linux > >> > -- > >> > To unsubscribe from this list: send the line "unsubscribe kvm" in > >> > the body of a message to majord...@vger.kernel.org > >> > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti writes: > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote: >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: >> We can know the guest is panicked when the guest runs on xen. >> But we do not have such feature on kvm. >> >> Another purpose of this feature is: management app(for example: >> libvirt) can do auto dump when the guest is panicked. If management >> app does not do auto dump, the guest's user can do dump by hand if >> he sees the guest is panicked. >> >> We have three solutions to implement this feature: >> 1. use vmcall >> 2. use I/O port >> 3. use virtio-serial. >> >> We have decided to avoid touching hypervisor. The reason why I choose >> choose the I/O port is: >> 1. it is easier to implememt >> 2. it does not depend any virtual device >> 3. it can work when starting the kernel >> >>> >> >>> How about searching for the "Kernel panic - not syncing" string >> >>> in the guests serial output? Say libvirtd could take an action upon >> >>> that? >> >> >> >> No, this is not satisfactory. It depends on the guest OS being >> >> configured to use the serial port for console output which we >> >> cannot mandate, since it may well be required for other purposes. >> > >> Please don't forget Windows guests, there is no console and no "Kernel >> Panic" string ;) >> >> What I used for debugging purposes on Windows guest is to register a >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR >> register. >> >> Yan. > > Considering whether a "panic-device" should cover other OSes is also > something to consider. Even for Linux, is "panic" the only case which > should be reported via the mechanism? What about oopses without panic? > > Is the mechanism general enough for supporting new events, etc. Hi, I think this discussion is gone of the deep end. Forget about !x86 platforms. They have their own way to do this sort of thing. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports. We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this. Regards, Anthony Liguori > >> >> > Well, we have more than a single serial port, even when leaving >> > virtio-serial aside... >> > >> > Jan >> > >> > -- >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE >> > Corporate Competence Center Embedded Linux >> > -- >> > To unsubscribe from this list: send the line "unsubscribe kvm" in >> > the body of a message to majord...@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 12:29:38PM -0300, Marcelo Tosatti wrote: > On Tue, Aug 14, 2012 at 10:47:48AM +0300, Gleb Natapov wrote: > > On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote: > > > On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: > > > > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: > > > > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > > > > >> We can know the guest is panicked when the guest runs on xen. > > > > >> But we do not have such feature on kvm. > > > > >> > > > > >> Another purpose of this feature is: management app(for example: > > > > >> libvirt) can do auto dump when the guest is panicked. If management > > > > >> app does not do auto dump, the guest's user can do dump by hand if > > > > >> he sees the guest is panicked. > > > > >> > > > > >> We have three solutions to implement this feature: > > > > >> 1. use vmcall > > > > >> 2. use I/O port > > > > >> 3. use virtio-serial. > > > > >> > > > > >> We have decided to avoid touching hypervisor. The reason why I choose > > > > >> choose the I/O port is: > > > > >> 1. it is easier to implememt > > > > >> 2. it does not depend any virtual device > > > > >> 3. it can work when starting the kernel > > > > > > > > > > How about searching for the "Kernel panic - not syncing" string > > > > > in the guests serial output? Say libvirtd could take an action upon > > > > > that? > > > > > > > > > > Advantages: > > > > > - It works for all architectures. > > > > > - It does not depend on any virtual device. > > > > > > > > But it _does_ depend on a serial console, > > > > > > Which already exists and is supported. > > > > > > > and furthermore requires > > > > libvirt to tee the serial console (right now, libvirt can treat the > > > > console as an opaque pass-through to the end user, but if you expect > > > > libvirt to parse the serial console for a particular string, you've lost > > > > some efficiency). > > > > > > > > > - It works as early as serial console output does (panics before > > > > > that should be rare). > > > > > - It allows you to see why the guest panicked. > > > > > > > > I think your arguments for a serial console have already been made and > > > > refuted in earlier versions of this patch series, which is WHY this > > > > series is still applicable. > > > > > > Refuted why, exactly? Efficiency to parse serial console output in > > > libvirt should not be a major issue surely? > > > > > It is not zero config (guests do not send console output to serial by > > default). If vm users want to use serial for its working console panic > > notification will trigger every time user examines dmesg with "Kernel > > panic - not syncing" in it. > > Ok, then it would have to be a dedicated serial console which starts > to become funny. > We do have support for many virtio-serial channels. > Use a simple virtio device, then, it starts early enough (or can be made > to) during kernel init for most relevant production panics, and works > for all architectures. The only downside of using dedicated virtio-serial channel that I can see is that to catch early panic all of the virtio should be compiled in. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 10:47:48AM +0300, Gleb Natapov wrote: > On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote: > > On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: > > > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: > > > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > > > >> We can know the guest is panicked when the guest runs on xen. > > > >> But we do not have such feature on kvm. > > > >> > > > >> Another purpose of this feature is: management app(for example: > > > >> libvirt) can do auto dump when the guest is panicked. If management > > > >> app does not do auto dump, the guest's user can do dump by hand if > > > >> he sees the guest is panicked. > > > >> > > > >> We have three solutions to implement this feature: > > > >> 1. use vmcall > > > >> 2. use I/O port > > > >> 3. use virtio-serial. > > > >> > > > >> We have decided to avoid touching hypervisor. The reason why I choose > > > >> choose the I/O port is: > > > >> 1. it is easier to implememt > > > >> 2. it does not depend any virtual device > > > >> 3. it can work when starting the kernel > > > > > > > > How about searching for the "Kernel panic - not syncing" string > > > > in the guests serial output? Say libvirtd could take an action upon > > > > that? > > > > > > > > Advantages: > > > > - It works for all architectures. > > > > - It does not depend on any virtual device. > > > > > > But it _does_ depend on a serial console, > > > > Which already exists and is supported. > > > > > and furthermore requires > > > libvirt to tee the serial console (right now, libvirt can treat the > > > console as an opaque pass-through to the end user, but if you expect > > > libvirt to parse the serial console for a particular string, you've lost > > > some efficiency). > > > > > > > - It works as early as serial console output does (panics before > > > > that should be rare). > > > > - It allows you to see why the guest panicked. > > > > > > I think your arguments for a serial console have already been made and > > > refuted in earlier versions of this patch series, which is WHY this > > > series is still applicable. > > > > Refuted why, exactly? Efficiency to parse serial console output in > > libvirt should not be a major issue surely? > > > It is not zero config (guests do not send console output to serial by > default). If vm users want to use serial for its working console panic > notification will trigger every time user examines dmesg with "Kernel > panic - not syncing" in it. Ok, then it would have to be a dedicated serial console which starts to become funny. Use a simple virtio device, then, it starts early enough (or can be made to) during kernel init for most relevant production panics, and works for all architectures. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote: > On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: > > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: > > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > > >> We can know the guest is panicked when the guest runs on xen. > > >> But we do not have such feature on kvm. > > >> > > >> Another purpose of this feature is: management app(for example: > > >> libvirt) can do auto dump when the guest is panicked. If management > > >> app does not do auto dump, the guest's user can do dump by hand if > > >> he sees the guest is panicked. > > >> > > >> We have three solutions to implement this feature: > > >> 1. use vmcall > > >> 2. use I/O port > > >> 3. use virtio-serial. > > >> > > >> We have decided to avoid touching hypervisor. The reason why I choose > > >> choose the I/O port is: > > >> 1. it is easier to implememt > > >> 2. it does not depend any virtual device > > >> 3. it can work when starting the kernel > > > > > > How about searching for the "Kernel panic - not syncing" string > > > in the guests serial output? Say libvirtd could take an action upon > > > that? > > > > > > Advantages: > > > - It works for all architectures. > > > - It does not depend on any virtual device. > > > > But it _does_ depend on a serial console, > > Which already exists and is supported. > > > and furthermore requires > > libvirt to tee the serial console (right now, libvirt can treat the > > console as an opaque pass-through to the end user, but if you expect > > libvirt to parse the serial console for a particular string, you've lost > > some efficiency). > > > > > - It works as early as serial console output does (panics before > > > that should be rare). > > > - It allows you to see why the guest panicked. > > > > I think your arguments for a serial console have already been made and > > refuted in earlier versions of this patch series, which is WHY this > > series is still applicable. > > Refuted why, exactly? Efficiency to parse serial console output in > libvirt should not be a major issue surely? > It is not zero config (guests do not send console output to serial by default). If vm users want to use serial for its working console panic notification will trigger every time user examines dmesg with "Kernel panic - not syncing" in it. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote: On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? Advantages: - It works for all architectures. - It does not depend on any virtual device. But it _does_ depend on a serial console, Which already exists and is supported. and furthermore requires libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency). - It works as early as serial console output does (panics before that should be rare). - It allows you to see why the guest panicked. I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable. Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely? It is not zero config (guests do not send console output to serial by default). If vm users want to use serial for its working console panic notification will trigger every time user examines dmesg with Kernel panic - not syncing in it. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 10:47:48AM +0300, Gleb Natapov wrote: On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote: On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? Advantages: - It works for all architectures. - It does not depend on any virtual device. But it _does_ depend on a serial console, Which already exists and is supported. and furthermore requires libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency). - It works as early as serial console output does (panics before that should be rare). - It allows you to see why the guest panicked. I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable. Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely? It is not zero config (guests do not send console output to serial by default). If vm users want to use serial for its working console panic notification will trigger every time user examines dmesg with Kernel panic - not syncing in it. Ok, then it would have to be a dedicated serial console which starts to become funny. Use a simple virtio device, then, it starts early enough (or can be made to) during kernel init for most relevant production panics, and works for all architectures. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 12:29:38PM -0300, Marcelo Tosatti wrote: On Tue, Aug 14, 2012 at 10:47:48AM +0300, Gleb Natapov wrote: On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote: On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? Advantages: - It works for all architectures. - It does not depend on any virtual device. But it _does_ depend on a serial console, Which already exists and is supported. and furthermore requires libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency). - It works as early as serial console output does (panics before that should be rare). - It allows you to see why the guest panicked. I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable. Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely? It is not zero config (guests do not send console output to serial by default). If vm users want to use serial for its working console panic notification will trigger every time user examines dmesg with Kernel panic - not syncing in it. Ok, then it would have to be a dedicated serial console which starts to become funny. We do have support for many virtio-serial channels. Use a simple virtio device, then, it starts early enough (or can be made to) during kernel init for most relevant production panics, and works for all architectures. The only downside of using dedicated virtio-serial channel that I can see is that to catch early panic all of the virtio should be compiled in. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: On 2012-08-14 10:56, Daniel P. Berrange wrote: On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes. Please don't forget Windows guests, there is no console and no Kernel Panic string ;) What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register. Yan. Considering whether a panic-device should cover other OSes is also something to consider. Even for Linux, is panic the only case which should be reported via the mechanism? What about oopses without panic? Is the mechanism general enough for supporting new events, etc. Hi, I think this discussion is gone of the deep end. Forget about !x86 platforms. They have their own way to do this sort of thing. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports. We're simply reserving a status LED for the guest to indicate that it has paniced. Let's not over engineer this. Regards, Anthony Liguori Well, we have more than a single serial port, even when leaving virtio-serial aside... Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: On 2012-08-14 10:56, Daniel P. Berrange wrote: On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes. Please don't forget Windows guests, there is no console and no Kernel Panic string ;) What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register. Yan. Considering whether a panic-device should cover other OSes is also \ something to consider. Even for Linux, is panic the only case which should be reported via the mechanism? What about oopses without panic? Is the mechanism general enough for supporting new events, etc. Hi, I think this discussion is gone of the deep end. Forget about !x86 platforms. They have their own way to do this sort of thing. The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic: - reboot - blink None are paravirtual interfaces however. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports. We're simply reserving a status LED for the guest to indicate that it has paniced. Let's not over engineer this. My concern is that you end up with state that is dependant on x86. Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy. Can this new infrastructure be used by other architectures? Do you consider allowing support for Windows as overengineering? Regards, Anthony Liguori Well, we have more than a single serial port, even when leaving virtio-serial aside... Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: On 2012-08-14 10:56, Daniel P. Berrange wrote: On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes. Please don't forget Windows guests, there is no console and no Kernel Panic string ;) What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register. Yan. Considering whether a panic-device should cover other OSes is also \ something to consider. Even for Linux, is panic the only case which should be reported via the mechanism? What about oopses without panic? Is the mechanism general enough for supporting new events, etc. Hi, I think this discussion is gone of the deep end. Forget about !x86 platforms. They have their own way to do this sort of thing. The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic: - reboot - blink Not sure the semantics of blink but that might be a good place for a pvops hook. None are paravirtual interfaces however. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports. We're simply reserving a status LED for the guest to indicate that it has paniced. Let's not over engineer this. My concern is that you end up with state that is dependant on x86. Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy. I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO. Can this new infrastructure be used by other architectures? I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU. Do you consider allowing support for Windows as overengineering? I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no? Regards, Anthony Liguori Regards, Anthony Liguori Well, we have more than a single serial port, even when leaving virtio-serial aside... Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On 14 August 2012 19:53, Anthony Liguori anth...@codemonkey.ws wrote: Forget about !x86 platforms. They have their own way to do this sort of thing. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports. Please don't forget !x86 platforms, we are cute and loveable really :-) We're simply reserving a status LED for the guest to indicate that it has paniced. Let's not over engineer this. ...not that QEMU actually has any kind of front panel lights and switches interface at all, it might be nice to have one. I bet a lot of the embedded boards have function DIP switches, heartbeat LEDs, etc etc... -- PMM -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
On 2012-08-14 10:56, Daniel P. Berrange wrote:
On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I
choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
How about searching for the Kernel panic - not syncing string
in the guests serial output? Say libvirtd could take an action upon
that?
No, this is not satisfactory. It depends on the guest OS being
configured to use the serial port for console output which we
cannot mandate, since it may well be required for other purposes.
Please don't forget Windows guests, there is no console and no Kernel
Panic string ;)
What I used for debugging purposes on Windows guest is to register a
bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
register.
Yan.
Considering whether a panic-device should cover other OSes is also \
something to consider. Even for Linux, is panic the only case which
should be reported via the mechanism? What about oopses without panic?
Is the mechanism general enough for supporting new events, etc.
Hi,
I think this discussion is gone of the deep end.
Forget about !x86 platforms. They have their own way to do this sort of
thing.
The panic function in kernel/panic.c has the following options, which
appear to be arch independent, on panic:
- reboot
- blink
Not sure the semantics of blink but that might be a good place for a
pvops hook.
None are paravirtual interfaces however.
Think of this feature like a status LED on a motherboard. These
are very common and usually controlled by IO ports.
We're simply reserving a status LED for the guest to indicate that it
has paniced. Let's not over engineer this.
My concern is that you end up with state that is dependant on x86.
Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
Having the ability to stop/restart the guest (and even introducing a
new VM runstate) is more than a status LED analogy.
I must admit, I don't know why a new runstate is necessary/useful. The
kernel shouldn't have to care about the difference between a halted guest
and a panicked guest. That level of information belongs in userspace IMHO.
Can this new infrastructure be used by other architectures?
I guess I don't understand why the kernel side of this isn't anything
more than a paravirt op hook that does a single outb() with the
remaining logic handled 100% in QEMU.
From the patch description:
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
Wen, auto dump means dump of guest memory?
In that case, the notification should obviously stop the guest
otherwise the guest might be reset by the time memdump from QEMU
monitor runs.
But kexec supports dumping of memory already (i suppose it can
do automatic dump+{reboot,shutdown}).
Do you consider allowing support for Windows as overengineering?
I don't think there is a way to hook BSOD on Windows so attempting to
engineer something that works with Windows seems odd, no?
Unsure about hooking at BSOD time. But Windows has configurable
memory dump/reset/reboot, so yes it should not necessary.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
Well, we have more than a single serial port, even when leaving
virtio-serial aside...
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
On 2012-08-14 10:56, Daniel P. Berrange wrote:
On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If
management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I
choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
How about searching for the Kernel panic - not syncing string
in the guests serial output? Say libvirtd could take an action upon
that?
No, this is not satisfactory. It depends on the guest OS being
configured to use the serial port for console output which we
cannot mandate, since it may well be required for other purposes.
Please don't forget Windows guests, there is no console and no Kernel
Panic string ;)
What I used for debugging purposes on Windows guest is to register a
bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
register.
Yan.
Considering whether a panic-device should cover other OSes is also \
something to consider. Even for Linux, is panic the only case which
should be reported via the mechanism? What about oopses without panic?
Is the mechanism general enough for supporting new events, etc.
Hi,
I think this discussion is gone of the deep end.
Forget about !x86 platforms. They have their own way to do this sort of
thing.
The panic function in kernel/panic.c has the following options, which
appear to be arch independent, on panic:
- reboot
- blink
Not sure the semantics of blink but that might be a good place for a
pvops hook.
None are paravirtual interfaces however.
Think of this feature like a status LED on a motherboard. These
are very common and usually controlled by IO ports.
We're simply reserving a status LED for the guest to indicate that it
has paniced. Let's not over engineer this.
My concern is that you end up with state that is dependant on x86.
Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
Having the ability to stop/restart the guest (and even introducing a
new VM runstate) is more than a status LED analogy.
I must admit, I don't know why a new runstate is necessary/useful. The
kernel shouldn't have to care about the difference between a halted guest
and a panicked guest. That level of information belongs in userspace IMHO.
Can this new infrastructure be used by other architectures?
I guess I don't understand why the kernel side of this isn't anything
more than a paravirt op hook that does a single outb() with the
remaining logic handled 100% in QEMU.
From the patch description:
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
Why does this mandated another runstate? QEMU can simply mark the VCPUs
as stopped and raise a QMP event. The kernel doesn't care if the VCPUs
are stopped or panicked.
Wen, auto dump means dump of guest memory?
In that case, the notification should obviously stop the guest
otherwise the guest might be reset by the time memdump from QEMU
monitor runs.
But kexec supports dumping of memory already (i suppose it can
do automatic dump+{reboot,shutdown}).
Do you consider allowing support for Windows as overengineering?
I don't think there is a way to hook BSOD on Windows so attempting to
engineer something that works with Windows seems odd, no?
Unsure about hooking at BSOD time. But Windows has configurable
memory dump/reset/reboot, so yes it should not necessary.
Do you mean it's not necessary to hook BSOD?
I've very often gotten asked: We know 1 person is experiencing this
crash condition, can we figure out from the host how many other VMs are
experiencing this crash too instead of waiting for a user to complain?
That's the primary use-case for
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked\
On Tue, Aug 14, 2012 at 05:59:06PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
On 2012-08-14 10:56, Daniel P. Berrange wrote:
On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If
management
app does not do auto dump, the guest's user can do dump by hand
if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I
choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
How about searching for the Kernel panic - not syncing string
in the guests serial output? Say libvirtd could take an action
upon
that?
No, this is not satisfactory. It depends on the guest OS being
configured to use the serial port for console output which we
cannot mandate, since it may well be required for other purposes.
Please don't forget Windows guests, there is no console and no
Kernel Panic string ;)
What I used for debugging purposes on Windows guest is to register a
bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR
register.
Yan.
Considering whether a panic-device should cover other OSes is also \
something to consider. Even for Linux, is panic the only case which
should be reported via the mechanism? What about oopses without
panic?
Is the mechanism general enough for supporting new events, etc.
Hi,
I think this discussion is gone of the deep end.
Forget about !x86 platforms. They have their own way to do this sort of
thing.
The panic function in kernel/panic.c has the following options, which
appear to be arch independent, on panic:
- reboot
- blink
Not sure the semantics of blink but that might be a good place for a
pvops hook.
None are paravirtual interfaces however.
Think of this feature like a status LED on a motherboard. These
are very common and usually controlled by IO ports.
We're simply reserving a status LED for the guest to indicate that it
has paniced. Let's not over engineer this.
My concern is that you end up with state that is dependant on x86.
Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
Having the ability to stop/restart the guest (and even introducing a
new VM runstate) is more than a status LED analogy.
I must admit, I don't know why a new runstate is necessary/useful. The
kernel shouldn't have to care about the difference between a halted guest
and a panicked guest. That level of information belongs in userspace IMHO.
Can this new infrastructure be used by other architectures?
I guess I don't understand why the kernel side of this isn't anything
more than a paravirt op hook that does a single outb() with the
remaining logic handled 100% in QEMU.
From the patch description:
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
Why does this mandated another runstate?
Good question.
QEMU can simply mark the VCPUs as stopped and raise a QMP event.
Yes. As long as management app is able to find out for what the reason
the VM has been stopped (that is, its not an issue to lose the QMP
event).
The kernel doesn't care if the VCPUs
are stopped or panicked.
Wen, auto dump means dump of guest memory?
In that case, the notification should obviously stop the guest
otherwise the guest might be reset by the time memdump from QEMU
monitor runs.
But kexec supports dumping of memory already (i suppose it can
do automatic dump+{reboot,shutdown}).
Do you consider allowing support for Windows as overengineering?
I don't think there is a way to hook BSOD on Windows so attempting to
engineer something that works with Windows seems odd, no?
Unsure about hooking at BSOD time. But
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: > >> We can know the guest is panicked when the guest runs on xen. > >> But we do not have such feature on kvm. > >> > >> Another purpose of this feature is: management app(for example: > >> libvirt) can do auto dump when the guest is panicked. If management > >> app does not do auto dump, the guest's user can do dump by hand if > >> he sees the guest is panicked. > >> > >> We have three solutions to implement this feature: > >> 1. use vmcall > >> 2. use I/O port > >> 3. use virtio-serial. > >> > >> We have decided to avoid touching hypervisor. The reason why I choose > >> choose the I/O port is: > >> 1. it is easier to implememt > >> 2. it does not depend any virtual device > >> 3. it can work when starting the kernel > > > > How about searching for the "Kernel panic - not syncing" string > > in the guests serial output? Say libvirtd could take an action upon > > that? > > > > Advantages: > > - It works for all architectures. > > - It does not depend on any virtual device. > > But it _does_ depend on a serial console, Which already exists and is supported. > and furthermore requires > libvirt to tee the serial console (right now, libvirt can treat the > console as an opaque pass-through to the end user, but if you expect > libvirt to parse the serial console for a particular string, you've lost > some efficiency). > > > - It works as early as serial console output does (panics before > > that should be rare). > > - It allows you to see why the guest panicked. > > I think your arguments for a serial console have already been made and > refuted in earlier versions of this patch series, which is WHY this > series is still applicable. Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely? Either way: The device should be arch independent, as "panic" is not specific to a particular architecture. For example virtio which would also work on S390. Custom IO port == virtual device, so that depends on virtual device already. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: >> We can know the guest is panicked when the guest runs on xen. >> But we do not have such feature on kvm. >> >> Another purpose of this feature is: management app(for example: >> libvirt) can do auto dump when the guest is panicked. If management >> app does not do auto dump, the guest's user can do dump by hand if >> he sees the guest is panicked. >> >> We have three solutions to implement this feature: >> 1. use vmcall >> 2. use I/O port >> 3. use virtio-serial. >> >> We have decided to avoid touching hypervisor. The reason why I choose >> choose the I/O port is: >> 1. it is easier to implememt >> 2. it does not depend any virtual device >> 3. it can work when starting the kernel > > How about searching for the "Kernel panic - not syncing" string > in the guests serial output? Say libvirtd could take an action upon > that? > > Advantages: > - It works for all architectures. > - It does not depend on any virtual device. But it _does_ depend on a serial console, and furthermore requires libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency). > - It works as early as serial console output does (panics before > that should be rare). > - It allows you to see why the guest panicked. I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? Advantages: - It works for all architectures. - It does not depend on any virtual device. But it _does_ depend on a serial console, and furthermore requires libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency). - It works as early as serial console output does (panics before that should be rare). - It allows you to see why the guest panicked. I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote: On 08/13/2012 12:21 PM, Marcelo Tosatti wrote: On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked. We have three solutions to implement this feature: 1. use vmcall 2. use I/O port 3. use virtio-serial. We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is: 1. it is easier to implememt 2. it does not depend any virtual device 3. it can work when starting the kernel How about searching for the Kernel panic - not syncing string in the guests serial output? Say libvirtd could take an action upon that? Advantages: - It works for all architectures. - It does not depend on any virtual device. But it _does_ depend on a serial console, Which already exists and is supported. and furthermore requires libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency). - It works as early as serial console output does (panics before that should be rare). - It allows you to see why the guest panicked. I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable. Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely? Either way: The device should be arch independent, as panic is not specific to a particular architecture. For example virtio which would also work on S390. Custom IO port == virtual device, so that depends on virtual device already. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
