kvm: notify host when guest panicked

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    4 ++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 12 insertions(+), 2 deletions(-)

kvm-all.c +0 -0

index 77eadf6..01062af 100644

Quoted 16 lines

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    4 ++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 12 insertions(+), 2 deletions(-)

kvm-all.c int kvm_cpu_exec(CPUState *env) · line 1296

Quoted 12 lines

kvm-all.c +4 -0

index 77eadf6..01062af 100644
@@ -1290,6 +1290,10 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:
+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            break;

You're still lacking "ret = -1;".

Jan

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    5 +++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 13 insertions(+), 2 deletions(-)

kvm-all.c +0 -0

index 77eadf6..b3c9a83 100644

Quoted 25 lines · Wen Congyang

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    5 +++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 13 insertions(+), 2 deletions(-)

kvm-all.c +1 -0

index 77eadf6..b3c9a83 100644
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:

kvm-all.c int kvm_cpu_exec(CPUState *env)

Quoted 5 lines

kvm-all.c +4 -0

+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;
 

If the management application is not aware of this event, then it will never resume the guest, so it will appear hung.

Quoted 26 lines · Avi Kivity

Quoted 25 lines · Wen Congyang

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    5 +++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 13 insertions(+), 2 deletions(-)

kvm-all.c +1 -0

index 77eadf6..b3c9a83 100644
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:

Quoted 8 lines

kvm-all.c int kvm_cpu_exec(CPUState *env)

Quoted 5 lines

kvm-all.c +4 -0

+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;
 

If the management application is not aware of this event, then it will never resume the guest, so it will appear hung.

Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will know the guest CPUs have been stopped, even if it isn't aware of the reason why, which seems fine to me.

Quoted 36 lines · Daniel P. Berrange

Quoted 26 lines · Avi Kivity

Quoted 25 lines · Wen Congyang

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    5 +++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 13 insertions(+), 2 deletions(-)

kvm-all.c +1 -0

index 77eadf6..b3c9a83 100644
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:

Quoted 8 lines

kvm-all.c int kvm_cpu_exec(CPUState *env)

Quoted 5 lines

kvm-all.c +4 -0

+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;
 

If the management application is not aware of this event, then it will never resume the guest, so it will appear hung.

Quoted 4 lines

Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will know the guest CPUs have been stopped, even if it isn't aware of the reason why, which seems fine to me.

No. The guest is stopped, and there's no reason to suppose that the management app will restart it. Behaviour has changed.

Suppose the guest has reboot_on_panic set; now the behaviour change is even more visible - service will stop completely instead of being interrupted for a bit while the guest reboots.

Quoted 42 lines · Avi Kivity

Quoted 36 lines · Daniel P. Berrange

Quoted 26 lines · Avi Kivity

Quoted 25 lines · Wen Congyang

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    5 +++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 13 insertions(+), 2 deletions(-)

kvm-all.c +1 -0

index 77eadf6..b3c9a83 100644
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:

Quoted 8 lines

kvm-all.c int kvm_cpu_exec(CPUState *env)

Quoted 5 lines

kvm-all.c +4 -0

+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;
 

If the management application is not aware of this event, then it will never resume the guest, so it will appear hung.

Quoted 4 lines

Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will know the guest CPUs have been stopped, even if it isn't aware of the reason why, which seems fine to me.

Quoted 6 lines

No. The guest is stopped, and there's no reason to suppose that the management app will restart it. Behaviour has changed.

Suppose the guest has reboot_on_panic set; now the behaviour change is even more visible - service will stop completely instead of being interrupted for a bit while the guest reboots.

Hmm, so this calls for a new command line argument to control behaviour, similar to what we do for disk werror, eg something like

--onpanic "report|pause|stop|..."

where

report - emit QEVENT_GUEST_PANICKED only

pause - emit QEVENT_GUEST_PANICKED and pause VM
stop - emit QEVENT_GUEST_PANICKED and quit VM

This would map fairly well into libvirt, where we already have config parameters for controlling what todo with a guest when it panics.

Regards,
Daniel

Quoted 53 lines · Daniel P. Berrange

Quoted 42 lines · Avi Kivity

Quoted 36 lines · Daniel P. Berrange

Quoted 26 lines · Avi Kivity

Quoted 25 lines · Wen Congyang

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang<[email protected]>

---
  kvm-all.c        |    5 +++++
  monitor.c        |    3 +++
  monitor.h        |    1 +
  qapi-schema.json |    2 +-
  qmp.c            |    3 ++-
  vl.c             |    1 +
  6 files changed, 13 insertions(+), 2 deletions(-)

kvm-all.c +1 -0

index 77eadf6..b3c9a83 100644
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                      (uint64_t)run->hw.hardware_exit_reason);
              ret = -1;
              break;
+        case KVM_EXIT_GUEST_PANICKED:

Quoted 8 lines

kvm-all.c int kvm_cpu_exec(CPUState *env)

Quoted 5 lines

kvm-all.c +4 -0

+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;
 

If the management application is not aware of this event, then it will never resume the guest, so it will appear hung.

Quoted 4 lines

Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will know the guest CPUs have been stopped, even if it isn't aware of the reason why, which seems fine to me.

Quoted 6 lines

No. The guest is stopped, and there's no reason to suppose that the management app will restart it. Behaviour has changed.

Suppose the guest has reboot_on_panic set; now the behaviour change is even more visible - service will stop completely instead of being interrupted for a bit while the guest reboots.

Hmm, so this calls for a new command line argument to control behaviour, similar to what we do for disk werror, eg something like

Quoted 5 lines

   --onpanic "report|pause|stop|..."

where

report - emit QEVENT_GUEST_PANICKED only

Should be the default.

Quoted 3 lines

pause - emit QEVENT_GUEST_PANICKED and pause VM
stop - emit QEVENT_GUEST_PANICKED and quit VM

"quit" is a better name than "stop".

Quoted 5 lines

This would map fairly well into libvirt, where we already have config parameters for controlling what todo with a guest when it panics.

Regards,
Daniel

Quoted 42 lines · Daniel P. Berrange

Quoted 36 lines · Avi Kivity

Quoted 26 lines · Wen Congyang

Quoted 25 lines

When the host knows the guest is panicked, it will set exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive this exit_reason, we can send a event to tell management application that the guest is panicked and set the guest status to RUN_STATE_PANICKED.

Signed-off-by Wen Congyang <[email protected]>

---
 kvm-all.c        |    5 +++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 13 insertions(+), 2 deletions(-)

kvm-all.c +1 -0

index 77eadf6..b3c9a83 100644
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:

Quoted 8 lines

kvm-all.c int kvm_cpu_exec(CPUState *env)

Quoted 5 lines

kvm-all.c +4 -0

+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;
 

If the management application is not aware of this event, then it will never resume the guest, so it will appear hung.

Quoted 4 lines

Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will know the guest CPUs have been stopped, even if it isn't aware of the reason why, which seems fine to me.

Quoted 6 lines

No. The guest is stopped, and there's no reason to suppose that the management app will restart it. Behaviour has changed.

Suppose the guest has reboot_on_panic set; now the behaviour change is even more visible - service will stop completely instead of being interrupted for a bit while the guest reboots.

Hmm, so this calls for a new command line argument to control behaviour, similar to what we do for disk werror, eg something like

--onpanic "report|pause|stop|..."

where

report - emit QEVENT_GUEST_PANICKED only

 pause  - emit QEVENT_GUEST_PANICKED and pause VM
 stop   - emit QEVENT_GUEST_PANICKED and quit VM
 stop   - emit QEVENT_GUEST_PANICKED and quit VM

This would map fairly well into libvirt, where we already have config parameters for controlling what todo with a guest when it panics.

Regards,
Daniel

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values.

Quoted 13 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Quoted 6 lines

Changes from v2 to v3:
1. correct spelling

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values.

I see no Documentation/ changes.

At 03/08/2012 07:13 PM, Avi Kivity Wrote:

Quoted 22 lines · Wen Congyang

Quoted 13 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Quoted 6 lines

Changes from v2 to v3:
1. correct spelling

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values.

I see no Documentation/ changes.

What shoude be writen into Documentation/? I read the documents under Documentation/virtual/kvm, not all KVM_EXIT_* are writen in api.txt. In this patch set, I introduce a new exit_reason: KVM_EXIT_GUEST_PANICKED, but I donot know where I should write.

Thanks
Wen Congyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Do you have any other comments about this patch?

Quoted 2 lines

Do you have any other comments about this patch?

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

At 03/12/2012 06:33 PM, Avi Kivity Wrote:

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

Hmm, can we use virtio-serial to talk with not-linux OS? I guess the answer is no. If so, virtio-serial is also used by linux.

Another problem is: virtio-serial is available on many deployed versions but the guest must have virtio-serial device. So we cannot know the guest is panicked if it does not have virtio-serial device while the hypercall does not depend on any device.

Quoted 2 lines · Wen Congyang

Do you have any other comments about this patch?

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

Quoted 4 lines · Avi Kivity

Quoted 2 lines · Wen Congyang

Do you have any other comments about this patch?

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

Many management application won't know to make a vioserial device available to all guests they create.

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 6 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

Quoted 1 line

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Probably.

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 48 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 6 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

Quoted 3 lines

Quoted 1 line

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 49 lines

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 48 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 6 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

Right.

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Surely there's some kind of access control on channels.

Quoted 4 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 1 line

Surely there's some kind of access control on channels.

The virtio-serial depends on more things than touching the hypervisor. So I think touching the hypervisor is more reliable than using virtio-serial device, and it is very simple and easy to use.

If we pass something from guest userspace to host, we can use virtio-serial. But If we pass something from guest kernelspace to host, I still prefer to touch the hypervisor.

Quoted 4 lines · Wen Congyang

Quoted 4 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 8 lines

Quoted 1 line

Surely there's some kind of access control on channels.

The virtio-serial depends on more things than touching the hypervisor. So I think touching the hypervisor is more reliable than using virtio-serial device, and it is very simple and easy to use.

If we pass something from guest userspace to host, we can use virtio-serial. But If we pass something from guest kernelspace to host, I still prefer to touch the hypervisor.

There's no argument that it's easier. My concern is different, we're adding more and more stuff to the hypervisor because it's easier, which bloats it. Every time we do it we add to compatibility and security problems.

The panic notification is *really* simple, so I don't expect it to cause a lot of problems. But still, if it's possible not to change the hypervisor, we must make an effort in that direction.

Quoted 19 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 4 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 8 lines

Quoted 1 line

Surely there's some kind of access control on channels.

The virtio-serial depends on more things than touching the hypervisor. So I think touching the hypervisor is more reliable than using virtio-serial device, and it is very simple and easy to use.

If we pass something from guest userspace to host, we can use virtio-serial. But If we pass something from guest kernelspace to host, I still prefer to touch the hypervisor.

There's no argument that it's easier. My concern is different, we're adding more and more stuff to the hypervisor because it's easier, which bloats it. Every time we do it we add to compatibility and security problems.

Quoted 4 lines

The panic notification is *really* simple, so I don't expect it to cause a lot of problems. But still, if it's possible not to change the hypervisor, we must make an effort in that direction.

One more point against using virtio-serial is that it will be likely compiled as a module which means panic during early boot will not be reported.

Quoted 20 lines · Avi Kivity

Quoted 19 lines · Wen Congyang

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 8 lines

Quoted 1 line

Surely there's some kind of access control on channels.

The virtio-serial depends on more things than touching the hypervisor. So I think touching the hypervisor is more reliable than using virtio-serial device, and it is very simple and easy to use.

If we pass something from guest userspace to host, we can use virtio-serial. But If we pass something from guest kernelspace to host, I still prefer to touch the hypervisor.

There's no argument that it's easier. My concern is different, we're adding more and more stuff to the hypervisor because it's easier, which bloats it. Every time we do it we add to compatibility and security problems.

Quoted 7 lines

Quoted 4 lines

The panic notification is *really* simple, so I don't expect it to cause a lot of problems. But still, if it's possible not to change the hypervisor, we must make an effort in that direction.

One more point against using virtio-serial is that it will be likely compiled as a module which means panic during early boot will not be reported.

I don't think we want to use the driver. Instead, have a small piece of code that resets the device and pushes out a string (the panic message?) without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Quoted 6 lines

I don't think we want to use the driver. Instead, have a small piece of code that resets the device and pushes out a string (the panic message?) without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Do you still want to use complicated and less reliable way?

I think the other ones prefer to touch the hypervisor.

Quoted 7 lines · Wen Congyang

Quoted 6 lines

I don't think we want to use the driver. Instead, have a small piece of code that resets the device and pushes out a string (the panic message?) without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Quoted 1 line

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

Quoted 7 lines · Wen Congyang

Quoted 6 lines

I don't think we want to use the driver. Instead, have a small piece of code that resets the device and pushes out a string (the panic message?) without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Quoted 1 line

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

Quoted 1 line

I think the other ones prefer to touch the hypervisor.

I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes.

Quoted 10 lines · Avi Kivity

Quoted 8 lines · Wen Congyang

Quoted 6 lines

I don't think we want to use the driver. Instead, have a small piece of code that resets the device and pushes out a string (the panic message?) without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Do you still want to use complicated and less reliable way?

Quoted 7 lines

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

hypercall can take arguments to achieve the same.

Quoted 6 lines

Quoted 1 line

I think the other ones prefer to touch the hypervisor.

I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes.

Using virtio-serial will not reduce kernel complexity. Quite contrary since code that will use virtio-serial will be more complicated.

Quoted 18 lines · Gleb Natapov

Quoted 17 lines · Avi Kivity

Quoted 8 lines · Wen Congyang

Quoted 6 lines

I don't think we want to use the driver. Instead, have a small piece of code that resets the device and pushes out a string (the panic message?) without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

Quoted 1 line

hypercall can take arguments to achieve the same.

It has to be designed in advance; and every time we notice something's missing we have to update the host kernel.

Quoted 8 lines

Quoted 6 lines

Quoted 1 line

I think the other ones prefer to touch the hypervisor.

I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes.

Using virtio-serial will not reduce kernel complexity. Quite contrary since code that will use virtio-serial will be more complicated.

The host kernel is unmodified though.

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Gleb Natapov

Quoted 3 lines · Avi Kivity

Quoted 2 lines · Wen Congyang

Quoted 2 lines

I don't think we want to use the driver. Instead, have a small

piece of

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

code that resets the device and pushes out a string (the panic

message?)

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 5 lines

Quoted 3 lines

without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a

kdump

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

hypercall can take arguments to achieve the same.

Quoted 3 lines

It has to be designed in advance; and every time we notice something's missing we have to update the host kernel.

We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management.

Quoted 26 lines · Avi Kivity

Quoted 5 lines · Gleb Natapov

Quoted 4 lines · Avi Kivity

Quoted 3 lines · Wen Congyang

Quoted 2 lines

Quoted 2 lines

I don't think we want to use the driver. Instead, have a small

piece of

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

code that resets the device and pushes out a string (the panic

message?)

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 5 lines

Quoted 3 lines

without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a

kdump

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

hypercall can take arguments to achieve the same.

Quoted 8 lines

Quoted 3 lines

It has to be designed in advance; and every time we notice something's missing we have to update the host kernel.

We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management.

If a host kernel change is in the works, I think it might be cleanest to have the host kernel export a new kind of VCPU exit for unhandled-by-KVM hypercalls. Then usermode can respond to the hypercall as appropriate.
This would permit adding or changing future hypercalls without host kernel
changes.

"Guest panic" is almost the definition of not-a-fast-path, and so what's the reason to handle it in the host kernel.

Punting to user-space wouldn't be a magic bullet for getting good interfaces designed, but in my opinion it is a better place to be doing them.

Quoted 25 lines · Gleb Natapov

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Gleb Natapov

Quoted 3 lines · Avi Kivity

Quoted 2 lines · Wen Congyang

Quoted 2 lines

I don't think we want to use the driver. Instead, have a small

piece of

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

code that resets the device and pushes out a string (the panic

message?)

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 5 lines

Quoted 3 lines

without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a

kdump

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

hypercall can take arguments to achieve the same.

Quoted 8 lines

Quoted 3 lines

It has to be designed in advance; and every time we notice something's missing we have to update the host kernel.

We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management.

If a host kernel change is in the works, I think it might be cleanest to have the host kernel export a new kind of VCPU exit for unhandled-by-KVM hypercalls. Then usermode can respond to the hypercall as appropriate.
This would permit adding or changing future hypercalls without host kernel
changes.

"Guest panic" is almost the definition of not-a-fast-path, and so what's the reason to handle it in the host kernel.

Punting to user-space wouldn't be a magic bullet for getting good interfaces designed, but in my opinion it is a better place to be doing them.

Quoted 36 lines · Eric Northup

Quoted 33 lines · Gleb Natapov

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Gleb Natapov

Quoted 3 lines · Avi Kivity

Quoted 2 lines · Wen Congyang

Quoted 2 lines

I don't think we want to use the driver. Instead, have a small

piece of

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

code that resets the device and pushes out a string (the panic

message?)

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 5 lines

Quoted 3 lines

without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a

kdump

Quoted 8 lines

Quoted 4 lines

Quoted 3 lines

and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

hypercall can take arguments to achieve the same.

It has to be designed in advance; and every time we notice something's missing we have to update the host kernel.

We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management.

Quoted 6 lines

If a host kernel change is in the works, I think it might be cleanest to have the host kernel export a new kind of VCPU exit for unhandled-by-KVM hypercalls. Then usermode can respond to the hypercall as appropriate.
This would permit adding or changing future hypercalls without host kernel
changes.

There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea.

Quoted 3 lines

Quoted 1 line

There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea.

BTW, this would help a lot in emulating hypercalls of other hypervisors (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump through hoops therefore) in user space. Not all those hypercall handlers actually have to reside in the KVM module.

Quoted 4 lines

Quoted 3 lines

Quoted 1 line

There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea.

Quoted 5 lines

BTW, this would help a lot in emulating hypercalls of other hypervisors (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump through hoops therefore) in user space. Not all those hypercall handlers actually have to reside in the KVM module.

That is true. On the other hand the hypercall ABI might go to pieces if there was no central implementation.

Quoted 4 lines · Jan Kiszka

Quoted 3 lines

Quoted 1 line

There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea.

Quoted 5 lines

BTW, this would help a lot in emulating hypercalls of other hypervisors (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump through hoops therefore) in user space. Not all those hypercall handlers actually have to reside in the KVM module.

That is true. On the other hand the hypercall ABI might go to pieces if there was no central implementation.

Quoted 11 lines · Jan Kiszka

Quoted 9 lines

Quoted 3 lines

Quoted 1 line

There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea.

BTW, this would help a lot in emulating hypercalls of other hypervisors (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump through hoops therefore) in user space. Not all those hypercall handlers actually have to reside in the KVM module.

Quoted 2 lines

That is true. On the other hand the hypercall ABI might go to pieces if there was no central implementation.

Just declare that outl 0x505 is a megaultracall and s/vmcall/outb/g and call it a day.

The performance difference between vmcall and outl is so tiny compared to the cost of dropping to userspace that it really doesn't matter which instruction is used.

Regards,

Anthony Liguori

Quoted 1 line

Signature · 4 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 21 lines · Avi Kivity

Quoted 19 lines · Gleb Natapov

Quoted 8 lines · Avi Kivity

Quoted 7 lines · Wen Congyang

Quoted 6 lines

I don't think we want to use the driver.  Instead, have a small piece of code that resets the device and pushes out a string (the panic message?) without any interrupts etc.

It's still going to be less reliable than a hypercall, I agree.

Quoted 9 lines

Quoted 1 line

Do you still want to use complicated and less reliable way?

Are you willing to try it out and see how complicated it really is?

While it's more complicated, it's also more flexible.  You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses.

hypercall can take arguments to achieve the same.

Quoted 3 lines

It has to be designed in advance; and every time we notice something's missing we have to update the host kernel.

We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter.  This buffer can be read by QEMU and passed to management.

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 48 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 6 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

Quoted 3 lines

Quoted 1 line

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 51 lines

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 50 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 7 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 4 lines

Quoted 1 line

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel.

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

At 03/14/2012 06:37 PM, Amit Shah Wrote:

Quoted 52 lines · Wen Congyang

Quoted 51 lines

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 50 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 7 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel.

When the kernel is panicked, we cannot use userspace program.

Quoted 4 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 3 lines

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

We should also prevent root user writing message to this channel if it is used for panicked notification.

Quoted 68 lines

At 03/14/2012 06:37 PM, Amit Shah Wrote:

Quoted 52 lines · Wen Congyang

Quoted 51 lines

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 50 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 7 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel.

When the kernel is panicked, we cannot use userspace program.

Quoted 4 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 7 lines

Quoted 3 lines

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? Root user can also call panic hypercall if he wishes so.

--
Gleb.

At 03/14/2012 06:52 PM, Gleb Natapov Wrote:

Quoted 73 lines · Wen Congyang

Quoted 72 lines

At 03/14/2012 06:37 PM, Amit Shah Wrote:

Quoted 52 lines · Wen Congyang

Quoted 51 lines

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 50 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 7 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel.

When the kernel is panicked, we cannot use userspace program.

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Quoted 4 lines

Quoted 3 lines

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? Root user can also call panic hypercall if he wishes so.

IIRC, the instruction vmcall needs to run on ring0. The root user is in ring3.

Quoted 74 lines

At 03/14/2012 06:52 PM, Gleb Natapov Wrote:

Quoted 73 lines · Wen Congyang

Quoted 72 lines

At 03/14/2012 06:37 PM, Amit Shah Wrote:

Quoted 52 lines · Wen Congyang

Quoted 51 lines

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 50 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 7 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel.

When the kernel is panicked, we cannot use userspace program.

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Quoted 7 lines

Quoted 4 lines

Quoted 3 lines

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? Root user can also call panic hypercall if he wishes so.

IIRC, the instruction vmcall needs to run on ring0. The root user is in ring3.

And who will stop the root from loading kernel module?

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

We should also prevent root user writing message to this channel if it is used for panicked notification.

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Quoted 3 lines

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? root can easily cause a panic.

At 03/14/2012 06:52 PM, Avi Kivity Wrote:

Quoted 9 lines · Wen Congyang

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Quoted 6 lines

Quoted 3 lines

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? root can easily cause a panic.

root user can write the same message to virtio-serial while the guest is running...

Quoted 17 lines

At 03/14/2012 06:52 PM, Avi Kivity Wrote:

Quoted 15 lines · Wen Congyang

Quoted 11 lines

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? root can easily cause a panic.

Quoted 1 line

root user can write the same message to virtio-serial while the guest is running...

Unless you are running a MAC policy which strictly confines the root account, root can cause a kernel panic regardless of virtio-serial permissions in the guest:

echo c > /proc/sysrq-trigger

Regards,
Daniel

At 03/14/2012 06:59 PM, Daniel P. Berrange Wrote:

Quoted 20 lines · Wen Congyang

Quoted 18 lines

At 03/14/2012 06:52 PM, Avi Kivity Wrote:

Quoted 9 lines · Wen Congyang

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Quoted 6 lines

Quoted 3 lines

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? root can easily cause a panic.

root user can write the same message to virtio-serial while the guest is running...

Quoted 5 lines

Unless you are running a MAC policy which strictly confines the root account, root can cause a kernel panic regardless of virtio-serial permissions in the guest:

echo c > /proc/sysrq-trigger

Yes, root user can cause a kernel panic. But if he writes the same message to virtio-serial, the host will see the guest is panicked while the guest is not panicked. The host is cheated.

If we use vmcall, and the user causes a kernel panic, we can also know the guest is panicked. It is the thing what we need. We need to know the guest is panicked, and we donot aware why it is panicked. If the guest is not panicked, and the host think the guest is panicked, it is not the thing we need.

At 03/14/2012 06:59 PM, Daniel P. Berrange Wrote:

Quoted 20 lines · Wen Congyang

Quoted 18 lines

At 03/14/2012 06:52 PM, Avi Kivity Wrote:

Quoted 9 lines · Wen Congyang

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Quoted 6 lines

Quoted 3 lines

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? root can easily cause a panic.

root user can write the same message to virtio-serial while the guest is running...

Quoted 5 lines

Unless you are running a MAC policy which strictly confines the root account, root can cause a kernel panic regardless of virtio-serial permissions in the guest:

echo c > /proc/sysrq-trigger

Yes, root user can cause a kernel panic. But if he writes the same message to virtio-serial, the host will see the guest is panicked while the guest is not panicked. The host is cheated.

At 03/14/2012 06:52 PM, Avi Kivity Wrote:

Quoted 9 lines · Wen Congyang

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

Quoted 6 lines

Quoted 3 lines

We should also prevent root user writing message to this channel if it is used for panicked notification.

Why? root can easily cause a panic.

root user can write the same message to virtio-serial while the guest is running...

At 03/14/2012 06:37 PM, Amit Shah Wrote:

Quoted 52 lines · Wen Congyang

Quoted 51 lines

At 03/14/2012 05:24 PM, Avi Kivity Wrote:

Quoted 50 lines · Wen Congyang

Quoted 32 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 31 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 6 lines

Quoted 4 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I don't either, copying Amit.

Quoted 7 lines

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Probably.

Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right?

Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel.

When the kernel is panicked, we cannot use userspace program.

Quoted 4 lines

Quoted 3 lines

If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel.

Quoted 3 lines

Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user.

We should also prevent root user writing message to this channel if it is used for panicked notification.

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 27 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 8 lines

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

You said that there are too many channels. Does it mean /tmp/foo is a channel?

Quoted 37 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 27 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 8 lines

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

Quoted 7 lines

I donot know how to use virtio-serial.

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it.

See the following links for more details.

https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test
http://www.linux-kvm.org/page/Virtio-serial_API

Quoted 1 line

You said that there are too many channels. Does it mean /tmp/foo is a channel?

You can have several such -device virtserialport. The -device part describes what the guest will see. The -chardev part ties that to the host-side part of the channel.

/tmp/foo is the host end-point for the channel, in the example above, and /dev/virtio-ports/port1 is the guest-side end-point.

Amit

Quoted 4 lines

This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it.

I have two questions:
1. does it OK to open this device when the guest is panicked?

At 03/14/2012 05:51 PM, Amit Shah Wrote:

Quoted 46 lines · Wen Congyang

Quoted 44 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 27 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 8 lines

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

Quoted 3 lines

This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it.

I have two questions:
1. does it OK to open this device when the guest is panicked?

2. how to prevent the userspace's program using this device?

Quoted 47 lines · Wen Congyang

At 03/14/2012 05:51 PM, Amit Shah Wrote:

Quoted 46 lines · Wen Congyang

Quoted 44 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 27 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 8 lines

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

I donot know how to use virtio-serial.

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

Quoted 6 lines

Quoted 3 lines

This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it.

I have two questions:
1. does it OK to open this device when the guest is panicked?

Depends on what kind of panic it is. If the guest can continue operations inspite of the panic, it will be possible to write out the data.

Quoted 1 line

2. how to prevent the userspace's program using this device?

Mentioned in previous reply.

BTW: an in-kernel API for reading/writing to ports isn't implemented yet, because there's no user for it as of now. If you want to write from the kernel to the host, there are trivial additions to the code necessary.

(However, I think it's better to do the writing from userspace instead from the kernel itself).

Quoted 37 lines · Wen Congyang

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 27 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 8 lines

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

Quoted 7 lines

I donot know how to use virtio-serial.

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it.

See the following links for more details.

https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test
http://www.linux-kvm.org/page/Virtio-serial_API

Quoted 1 line

You said that there are too many channels. Does it mean /tmp/foo is a channel?

You can have several such -device virtserialport. The -device part describes what the guest will see. The -chardev part ties that to the host-side part of the channel.

/tmp/foo is the host end-point for the channel, in the example above, and /dev/virtio-ports/port1 is the guest-side end-point.

Quoted 61 lines · Wen Congyang

Quoted 37 lines

At 03/13/2012 06:47 PM, Avi Kivity Wrote:

Quoted 27 lines · Daniel P. Berrange

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Wen Congyang

Quoted 2 lines

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple & guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 8 lines

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

Quoted 7 lines

I donot know how to use virtio-serial.

I start vm like this:

qemu ...\
   -device virtio-serial \

-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=port1 ...

This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it.

See the following links for more details.

https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test
http://www.linux-kvm.org/page/Virtio-serial_API

Quoted 1 line

You said that there are too many channels. Does it mean /tmp/foo is a channel?

You can have several such -device virtserialport. The -device part describes what the guest will see. The -chardev part ties that to the host-side part of the channel.

Quoted 2 lines

/tmp/foo is the host end-point for the channel, in the example above, and /dev/virtio-ports/port1 is the guest-side end-point.

If we do choose to use virtio-serial for panics (which I don't think we should), then we should not expose it in the host filesystem. The host side should be a virtual chardev backend internal to QEMU, in the same way that 'spicevmc' is handled.

Regards,
Daniel

Quoted 5 lines · Daniel P. Berrange

Quoted 4 lines · Avi Kivity

Quoted 2 lines · Wen Congyang

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple& guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

Quoted 31 lines · Avi Kivity

Quoted 5 lines · Daniel P. Berrange

Quoted 4 lines · Avi Kivity

Quoted 2 lines · Wen Congyang

Do you have any other comments about this patch?

Quoted 8 lines

Quoted 4 lines

Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall.

As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple& guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest.

So what? It needs to be done anyway for the guest agent.

Quoted 2 lines

Many management application won't know to make a vioserial device available to all guests they create.

Then they won't know to deal with the panic event either.

Quoted 2 lines

Most administrators won't even configure kexec,
let alone virtio serial on top of it.

It should be done by the OS vendor, not the individual admin.

Quoted 3 lines

The hypercall requires zero host
side config, and zero guest side config, which IMHO is what we need for this feature.

Quoted 3 lines

If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it.

The problem is that virtio-serial sucks for something like this.

We have two options I think:

1) We could reserve a portion of the hypercall space to be deferred to userspace for stuff like this.

2) We could invent a new hypercall like facility that was less bloated than virtio-serial for stuff like this using MMIO/PIO.

Regards,

Anthony Liguori

Quoted 1 line

Quoted 8 lines

Quoted 7 lines

Changes from v2 to v3:
1. correct spelling

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values.

Quoted 1 line

I see no Documentation/ changes.

What shoude be writen into Documentation/? I read the documents under Documentation/virtual/kvm, not all KVM_EXIT_* are writen in api.txt. In this patch set, I introduce a new exit_reason: KVM_EXIT_GUEST_PANICKED, but I donot know where I should write.

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Thanks
Wen Congyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

At 03/19/2012 03:33 PM, Wen Congyang Wrote:

Quoted 35 lines

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

Quoted 2 lines

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Anybody can decide which solution to use?

Quoted 36 lines

At 03/19/2012 03:33 PM, Wen Congyang Wrote:

Quoted 35 lines

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

Quoted 5 lines

Quoted 2 lines

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Anybody can decide which solution to use?

To make an informed decision we need to have at least raw idea how virtio-serial variant will look.

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

At 03/20/2012 11:45 PM, Gleb Natapov Wrote:

Quoted 37 lines · Wen Congyang

Quoted 36 lines

At 03/19/2012 03:33 PM, Wen Congyang Wrote:

Quoted 35 lines

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Anybody can decide which solution to use?

To make an informed decision we need to have at least raw idea how virtio-serial variant will look.

Hmm, I think we can do this:
1. reset the virtio-serial device or reset the port we use to notice the host that guest is panicked.
2. write some specific messages to the port

So the port should have fixed name. If this port is opened by the userspace before the guest is paniced, I am not sure whether we can use it(because a port only can be opened once at the same time).

We cannot call any function in the module, so we may need to write a simple driver for virtio-serial(like diskdump's disk driver).

I donot know how to implement it now. But I guess that it may be complicated.

Quoted 46 lines

At 03/20/2012 11:45 PM, Gleb Natapov Wrote:

Quoted 37 lines · Wen Congyang

Quoted 36 lines

At 03/19/2012 03:33 PM, Wen Congyang Wrote:

Quoted 35 lines

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Anybody can decide which solution to use?

To make an informed decision we need to have at least raw idea how virtio-serial variant will look.

Quoted 8 lines

Hmm, I think we can do this:
1. reset the virtio-serial device or reset the port we use to notice the host that guest is panicked.
2. write some specific messages to the port

So the port should have fixed name. If this port is opened by the userspace before the guest is paniced, I am not sure whether we can use it(because a port only can be opened once at the same time).

Yes, IMO we should dedicate one virtio-serial port for panic notifications. Just like we dedicate one for a console.

Quoted 3 lines

We cannot call any function in the module, so we may need to write a simple driver for virtio-serial(like diskdump's disk driver).

netconsole uses standard NIC drivers in polling mode to send OOPSes over the network and it mostly works. So I think using virtio-serial driver is not out of question, but with IRQ disabled of course.

Quoted 3 lines

I donot know how to implement it now. But I guess that it may be complicated.

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

--
Gleb.

At 03/21/2012 05:11 PM, Gleb Natapov Wrote:

Quoted 58 lines · Wen Congyang

Quoted 46 lines

At 03/20/2012 11:45 PM, Gleb Natapov Wrote:

Quoted 37 lines · Wen Congyang

Quoted 36 lines

At 03/19/2012 03:33 PM, Wen Congyang Wrote:

Quoted 35 lines

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Anybody can decide which solution to use?

To make an informed decision we need to have at least raw idea how virtio-serial variant will look.

Quoted 8 lines

Hmm, I think we can do this:
1. reset the virtio-serial device or reset the port we use to notice the host that guest is panicked.
2. write some specific messages to the port

So the port should have fixed name. If this port is opened by the userspace before the guest is paniced, I am not sure whether we can use it(because a port only can be opened once at the same time).

Yes, IMO we should dedicate one virtio-serial port for panic notifications. Just like we dedicate one for a console.

Quoted 6 lines

Quoted 3 lines

We cannot call any function in the module, so we may need to write a simple driver for virtio-serial(like diskdump's disk driver).

netconsole uses standard NIC drivers in polling mode to send OOPSes over the network and it mostly works. So I think using virtio-serial driver is not out of question, but with IRQ disabled of course.

The code for netconsole is in which file?

Another question: we cannot call the function in the module directly in the kernel.

Quoted 9 lines

Quoted 3 lines

I donot know how to implement it now. But I guess that it may be complicated.

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

If we implement it by virtio-serial, I agree with passing more useful message to host.

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 13 lines · Corey Minyard

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

That already exists; virtio-console (or serial console emulation) can do the job.

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

Quoted 3 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

You can even go one better and search for the panic string in the guest memory directly, which is what virt-dmesg does :-)

http://people.redhat.com/~rjones/virt-dmesg/

Quoted 7 lines · Daniel P. Berrange

Quoted 3 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

You can even go one better and search for the panic string in the guest memory directly, which is what virt-dmesg does :-)

Quoted 2 lines

http://people.redhat.com/~rjones/virt-dmesg/

-ETOOHACKY

Any guest change will break this, no?

Quoted 13 lines · Corey Minyard

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

That already exists; virtio-console (or serial console emulation) can do the job.

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

Quoted 22 lines · Corey Minyard

Quoted 13 lines

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 2 lines

That already exists; virtio-console (or serial console emulation) can do the job.

I think the use case here is pretty straight forward: if the guest finds itself in bad place, it wants to indicate that to the host.

We shouldn't rely on any device drivers or complex code. It should be as close to a single instruction as possible that can run even if interrupts are disabled.

An out instruction fits this very well. I think a simple protocol like:

inl PORT -> returns a magic number indicating the presence of qemucalls

inl PORT+1 -> returns a bitmap of supported features

outl PORT+1 -> data reg1
outl PORT+2 -> data reg2
outl PORT+N -> data regN

outl PORT -> qemucall of index value with arguments 1..N

Regards,

Anthony Liguori

Quoted 4 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

Signature · 4 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

At 03/22/2012 03:19 AM, Anthony Liguori Wrote:

Quoted 26 lines · Avi Kivity

Quoted 22 lines · Corey Minyard

Quoted 13 lines

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 2 lines

That already exists; virtio-console (or serial console emulation) can do the job.

Quoted 8 lines

I think the use case here is pretty straight forward: if the guest finds itself in bad place, it wants to indicate that to the host.

We shouldn't rely on any device drivers or complex code. It should be as close to a single instruction as possible that can run even if interrupts are disabled.

An out instruction fits this very well. I think a simple protocol like:

This solution is more simple than using virtio-serial.

Quoted 2 lines

inl PORT -> returns a magic number indicating the presence of qemucalls

I donot understantd this instruction's purpose.

Quoted 1 line

inl PORT+1 -> returns a bitmap of supported features

Hmm, we can execute this instruction when guest starts. If the userspace does not process panicked event, there is no need to notify it.

Quoted 1 line

Quoted 3 lines

outl PORT+1 -> data reg1
outl PORT+2 -> data reg2
outl PORT+N -> data regN

We can get the register value from vmcs. So there is no need to tell the register value to the host.

If we decide to avoid touching hypervisor, I agree with this solution.

Thanks
Wen Congyang

Quoted 18 lines

outl PORT -> qemucall of index value with arguments 1..N

Regards,

Anthony Liguori

Quoted 4 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

Signature · 4 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 53 lines

At 03/22/2012 03:19 AM, Anthony Liguori Wrote:

Quoted 26 lines · Avi Kivity

Quoted 22 lines · Corey Minyard

Quoted 13 lines

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 2 lines

That already exists; virtio-console (or serial console emulation) can do the job.

Quoted 8 lines

I think the use case here is pretty straight forward: if the guest finds itself in bad place, it wants to indicate that to the host.

We shouldn't rely on any device drivers or complex code. It should be as close to a single instruction as possible that can run even if interrupts are disabled.

An out instruction fits this very well. I think a simple protocol like:

This solution is more simple than using virtio-serial.

Quoted 2 lines

inl PORT -> returns a magic number indicating the presence of qemucalls

I donot understantd this instruction's purpose.

Quoted 1 line

inl PORT+1 -> returns a bitmap of supported features

Hmm, we can execute this instruction when guest starts. If the userspace does not process panicked event, there is no need to notify it.

Quoted 4 lines

outl PORT+1 -> data reg1
outl PORT+2 -> data reg2
outl PORT+N -> data regN

Quoted 3 lines

We can get the register value from vmcs. So there is no need to tell the register value to the host.

No device should examine register value. Ideally QEMU would read registers only during migration.

Quoted 23 lines

If we decide to avoid touching hypervisor, I agree with this solution.

Thanks
Wen Congyang

Quoted 18 lines

outl PORT -> qemucall of index value with arguments 1..N

Regards,

Anthony Liguori

Quoted 4 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

Signature · 4 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

At 03/22/2012 03:31 PM, Gleb Natapov Wrote:

Quoted 57 lines · Wen Congyang

Quoted 56 lines

At 03/22/2012 03:19 AM, Anthony Liguori Wrote:

Quoted 26 lines · Avi Kivity

Quoted 22 lines · Corey Minyard

Quoted 13 lines

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 2 lines

That already exists; virtio-console (or serial console emulation) can do the job.

Quoted 8 lines

I think the use case here is pretty straight forward: if the guest finds itself in bad place, it wants to indicate that to the host.

We shouldn't rely on any device drivers or complex code. It should be as close to a single instruction as possible that can run even if interrupts are disabled.

An out instruction fits this very well. I think a simple protocol like:

This solution is more simple than using virtio-serial.

Quoted 2 lines

inl PORT -> returns a magic number indicating the presence of qemucalls

I donot understantd this instruction's purpose.

Quoted 1 line

inl PORT+1 -> returns a bitmap of supported features

Hmm, we can execute this instruction when guest starts. If the userspace does not process panicked event, there is no need to notify it.

Quoted 4 lines

outl PORT+1 -> data reg1
outl PORT+2 -> data reg2
outl PORT+N -> data regN

We can get the register value from vmcs. So there is no need to tell the register value to the host.

Quoted 2 lines

No device should examine register value. Ideally QEMU would read registers only during migration.

I mean: if the qemu(or other app) want to know the register value, it can get it from vmcs. So there is no need to pass register value from guest to host.

Another question: each outl will cause vmexit?

Thanks
Wen Congyang

Quoted 32 lines

Quoted 23 lines

If we decide to avoid touching hypervisor, I agree with this solution.

Thanks
Wen Congyang

Quoted 18 lines

outl PORT -> qemucall of index value with arguments 1..N

Regards,

Anthony Liguori

Quoted 4 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

Signature · 4 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 22 lines · Avi Kivity

Quoted 13 lines · Corey Minyard

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 2 lines

That already exists; virtio-console (or serial console emulation) can do the job.

I think the use case here is pretty straight forward: if the guest finds itself in bad place, it wants to indicate that to the host.

We shouldn't rely on any device drivers or complex code. It should be as close to a single instruction as possible that can run even if interrupts are disabled.

An out instruction fits this very well. I think a simple protocol like:

inl PORT -> returns a magic number indicating the presence of qemucalls inl PORT+1 -> returns a bitmap of supported features

outl PORT+1 -> data reg1
outl PORT+2 -> data reg2
outl PORT+N -> data regN

outl PORT -> qemucall of index value with arguments 1..N

Regards,

Anthony Liguori

Quoted 4 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

Quoted 29 lines · Avi Kivity

Quoted 22 lines · Corey Minyard

Quoted 13 lines

Quoted 7 lines

Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance.

I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before.

Quoted 7 lines

You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk.

Quoted 2 lines

That already exists; virtio-console (or serial console emulation) can do the job.

I think the use case here is pretty straight forward: if the guest finds itself in bad place, it wants to indicate that to the host.

Quoted 9 lines

We shouldn't rely on any device drivers or complex code. It should be as close to a single instruction as possible that can run even if interrupts are disabled.

An out instruction fits this very well. I think a simple protocol like:

inl PORT -> returns a magic number indicating the presence of qemucalls inl PORT+1 -> returns a bitmap of supported features

Sigh, one more PV isa device.

Quoted 5 lines

outl PORT+1 -> data reg1
outl PORT+2 -> data reg2
outl PORT+N -> data regN

outl PORT -> qemucall of index value with arguments 1..N

And you think you can trust panicked SMP guest to not call this on multiple cpus simultaneously?

Quoted 10 lines

Regards,

Anthony Liguori

Quoted 4 lines

In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs.

--
Gleb.

Quoted 36 lines

At 03/19/2012 03:33 PM, Wen Congyang Wrote:

Quoted 35 lines

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

Quoted 5 lines

Quoted 2 lines

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Anybody can decide which solution to use?

To make an informed decision we need to have at least raw idea how virtio-serial variant will look.

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From 2c819655982a0b3043892e994fb87fd44fdca686 Mon Sep 17 00:00:00 2001

From cb39cb1f36d4c37b3dc7942413550bb4b7c79a84 Mon Sep 17 00:00:00 2001

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 16 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Changes from v2 to v3:
1. correct spelling

Quoted 9 lines

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values. --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

I will not change this patch set before we decide how to do it. Can we make a decision recent days?

Thanks
Wen Congyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

At 03/19/2012 03:33 PM, Wen Congyang Wrote:

Quoted 21 lines

At 03/08/2012 03:57 PM, Wen Congyang Wrote:

Quoted 13 lines

We can know the guest is paniced 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 crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced.

I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may not have such device.

Quoted 6 lines

Changes from v2 to v3:
1. correct spelling

Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values.

Quoted 6 lines

Hi all:

we neet this feature, but we don't decide how to implement it. We have two solution:
1. use vmcall
2. use virtio-serial.

Hi, all

There are three solutions now:
1. use vmcall
2. use I/O port
3. use virtio-serial.

I think 1 and 2 are more simple than 3.

I am reading virtio-serial's driver recent days. It seems that if the virtio serial port is not opened at the host side, the data writen into this port will be discarded, and we will have no chance to know the guest is panicked.

To Amit:

Can we write message to a virtio serial port like this directly in the kernel space?

send_buf(panicked_port, message, message's length, true);

if port->outvq_full is true, is it OK to do this?