Re: [RFC 1/4] New virtio bus driver

[Avi Kivity <avi@qumranet.com>]

Rusty Russell wrote:
> On Mon, 2007-07-09 at 15:09 +0300, Avi Kivity wrote:
>   
>> Arnd Bergmann wrote:
>>     
>>> Why do you think we want to have multiple outstanding read messages?
>>> I would guess that a single message is enough, you can always requeue
>>> it after one event gets processed.
>>>       
>> Suppose there is one message queued.  The host reconfigures and sends 
>> the message. A new reconfiguration event now cannot be propagated.
>>
>> If there are two messages queued, the host can post the updates in the 
>> second message.  The guest would then post two new messages (since it 
>> can't tell whether any reconfiguration events occured after the second 
>> message), the host would fill one, and everyone is happy.
>>     
>
> But there can always be another reconfig about to happen after whatever
> the guest is processing now.  Is there any point in the guest doing
> anything other than one at a time, in order?
>
>   

I thought that would help prevent races, but there's a much simpler way: 
the host sets an internal flag if an event happened since the last 
message was posted, etc.  So one message should suffice.


>> Rusty, If you agree with this, I think it needs to be added to the core 
>> protocol.
>>     
>
> Well, using an "events" virtqueue in the core means existing virtual I/O
> mechanisms need to fake one up on the guest.  Using a function-call
> interface is more natural (and doesn't stop a virtio layer from using an
> events virtqueue and demuxing).
>
> Also, are we sure about the assumption that events won't have ordering
> constraints wrt other queues?  For example, a media change event might;
> I don't know the semantics required there...

Yeah.  Maybe just allow configuration messages on the regular virtqueues 
(they can cause a callback to be called, which parses  the message and 
passes it to the function-call interface.

-- 
error compiling committee.c: too many arguments to function