Re: [Qemu-devel] [PATCH 4/7] s390: sclp event support

[Christian Borntraeger <borntraeger@de.ibm.com>]

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