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.
