On (Mon) 02 Apr 2012 [18:05:45], Wen Congyang wrote: > At 03/19/2012 03:33 PM, Wen Congyang Wrote: > > At 03/08/2012 03:57 PM, Wen Congyang Wrote: > >> 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. > > > > 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. The qemu-side implementation should exist within qemu itself; i.e. the consumer of the data from the kernel-side will always have a listener. In this case, you don't have to worry about port not being opened on the host side. > To Amit: > > Can we write message to a virtio serial port like this directly in > the kernel space? As I had mentioned earlier, an in-kernel API is currently missing, but it will be very simple to add one. > send_buf(panicked_port, message, message's length, true); > > if port->outvq_full is true, is it OK to do this? port->outvq_full means guest has sent out data to the host, but the host has not consumed the data yet, and has not released the buffers back to the guest. If you indeed reach such a situation (essentially you should never, there are enough buffers already to account for scheduling delays), then newer data will be discarded, or you will have to wait to write the newer data till the host-side frees up buffers in the virtqueues. This isn't really different from other approaches -- if you use a shared buffer between guest and host, and if the guest has new data before the host has had a chance to read off the older buffer contents, you either overwrite or wait for the host to read the older stuff. Amit -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
