Re: [Qemu-devel] [PATCH v14 3/4] introduce pvevent device to deal with panicked event

[Gleb Natapov]

On Thu, Mar 14, 2013 at 12:23:01PM +0100, Alexander Graf wrote:
> 
> On 14.03.2013, at 12:03, Paolo Bonzini wrote:
> 
> > Il 14/03/2013 12:00, Alexander Graf ha scritto:
> >> 
> >> On 14.03.2013, at 10:43, Paolo Bonzini wrote:
> >> 
> >>> Il 14/03/2013 10:19, Gleb Natapov ha scritto:
> >>>> On Thu, Mar 14, 2013 at 10:14:12AM +0100, Paolo Bonzini wrote:
> >>>>> Il 14/03/2013 09:15, Hu Tao ha scritto:
> >>>>>> pvevent device is used to send guest panic event from guest to qemu.
> >>>>>> 
> >>>>>> When guest panic happens, pvevent device driver will write a event
> >>>>>> number to IO port 0x505(which is the IO port occupied by pvevent 
> >>>>>> device,
> >>>>>> by default). On receiving the event, pvevent device will pause guest
> >>>>>> cpu(s), and send a qmp event QEVENT_GUEST_PANICKED.  
> >>>>>> 
> >>>>>> TODO: make the IO port configurable
> >>>>> 
> >>>>> The port is already configurable as far as the device is concerned; when
> >>>>> you add the port to the PC boards you will have to wind up fw-cfg.
> >>>> 
> >>>> Why not add fw-cfg when device is created (with -device for instance)?
> >>> 
> >>> It depends on what we decide is the supported interface for the device:
> >>> 
> >>> * it can be an ISA device; the interface is the I/O port and ACPI
> >> 
> >> Is there any particular reason it's an ISA device with a PIO port,
> >> rather than a platform / sysbus device with MMIO access? With the
> >> latter, we could easily reuse the device on other platforms (ppc, arm)
> >> and even the guest driver code for platforms that do ACPI (arm?).
> > 
> > Where would you place the MMIO area on x86?  
> 
> Wherever the board thinks it makes sense.
> 
On x86 it makes sense to put it in IO space :)

> > But anyway you can easily
> > define an MMIO variant, the guest driver code will be shared (the ACPI
> > in the firmware no, of course).
> 
> Yes, at which point we have 2 variants where we could have had 1. I don't 
> know if it's worth caring about it, just wanted to bring it up.
> 
We can have the same device and control via properties what address
space to use for the device.

> > 
> >> Also, don't the Xen guys already have a similar interface? Could we at 
> >> least share the guest side implementation maybe?
> > 
> > I think Xen uses xenstore for this, or a hypercall I don't remember.
> > But not something that can be shared unfortunately.
> 
> At least the guest kernel hook could be shared. In fact, how does that one 
> work with this device? I've only seen an ACPI patch so far. Does ACPI already 
> support panic hooks?
> 
> 
No need for any special hook to use the device. There was a separate
patch with guest platform driver that uses the device. IN fact it should
work on XEN too.

--
                        Gleb.