qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v14 3/4] introduce pvevent device to deal with panicked event
Date: Wed, 20 Mar 2013 10:24:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Alexander Graf <address@hidden> writes:

> 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?).

As Paolo and Gleb observed, this is the most natural way to do such a
device on x86.  Other systems may want different connectors,
e.g. sysbus/MMIO.

We already have devices coming in variants with different connectors,
e.g. serial and fdc.  They share core code just fine.  Some boilerplate
gets duplicated, but it's not horrible.

There has been talk about modelling such things more nicely in QOM.
Opportunity for a QOM expert to tell us more about it :)

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]