[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 4/7] s390: sclp event support
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [PATCH 4/7] s390: sclp event support |
Date: |
Fri, 03 Aug 2012 14:31:21 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 |
On 31/07/12 14:59, Andreas Färber wrote:
>> +typedef struct EventTypes {
>> + BusState qbus;
>> + SCLPEventFacility *event_facility;
>> +} EventTypes;
>> +
>> +struct SCLPEventFacility {
>> + EventTypes sbus;
>> + DeviceState *qdev;
>> + /* guest' receive mask */
>> + unsigned int receive_mask;
>> +};
>
> The naming here strikes me as particularly odd...
>
> IIUC this Event Facility is a device sitting on the SCLP bus.
>
> But why does it expose a bus named "EventTypes"? Busses are usually
> named ...Bus (PCIBus, IDEBus, etc.). So is this actually a bus? If not,
> and if all you need is an SCLP-specific list API, maybe compare the
> sPAPR hypercall registration API.
So let me explain it and then we can see what is the right thing to do:
The sclp itself is a service processor that will handle service calls and
can send service interrupts. Most service calls deal with one specific thing:
reading info, cpu hotplug, memory hotplug etc.
Some of the service calls are special, because they form an event subsystem:
Events are features that can notify the guest asynchronously.
(e.g. system_powerdown is wired to signal quiesce which will be seen as
ctrl-alt-del in the guest, or several console types where the input is sent
as an event).
The service calls are read_event_data, write_event_data and write_event_mask.
write_event_mask is used by the guest to notify the host
about its event capabilities and to the query the host events.
read_event_data allows a guest to get event data - iow host2guest data.
guest2host traffic also goes via the event mechanism, e.g. console output
is send via write_event_data.
So each event implements several callbacks: event_pending to tell that
this event is pending, read event data to fill in the buffer with the event
data,
write_event_data if the event allows guest2host traffic. There are also two bits
per event that tell if that specific event will allow read/write event data.
Since some of the events implement complex things (console) a bus seemed
appropriate,
but there are of course other ways of implementing.
Comments?
Christian
- Re: [Qemu-devel] [PATCH 4/7] s390: sclp event support,
Christian Borntraeger <=