Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

[Gregory Haskins]

On 12/22/09 2:39 PM, Davide Libenzi wrote:
> On Tue, 22 Dec 2009, Gregory Haskins wrote:
> 
>> On 12/22/09 1:53 PM, Avi Kivity wrote:
>>> I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not reply.
>>>
>>
>> BTW: the ioeventfd issue just fell through the cracks, so sorry about
>> that.  Note that I have no specific issue with irqfd ever since the
>> lockless IRQ injection code was added.
>>
>> ioeventfd turned out to be suboptimal for me in the fast path for two
>> reasons:
>>
>> 1) the underlying eventfd is called in atomic context.  I had posted
>> patches to Davide to address that limitation, but I believe he rejected
>> them on the grounds that they are only relevant to KVM.
> 
> I thought we addressed this already, in the few hundreds of email we 
> exchanged back then :)

We addressed the race conditions, but not the atomic callbacks.  I can't
remember exactly what you said, but the effect was "no", so I dropped it. ;)

This was the thread.

http://www.archivum.info/linux-kernel@xxxxxxxxxxxxxxx/2009-06/08548/Re:_[KVM-RFC_PATCH_1_2]_eventfd:_add_an_explicit_srcu_based_notifier_interface

> 
> 
> 
>> 2) it cannot retain the data field passed in the PIO.  I wanted to have
>> one vector that could tell me what value was written, and this cannot be
>> expressed in ioeventfd.
> 
> Like might have hinted in his reply, couldn't you add data support to the 
> ioeventfd bits in KVM, instead of leaking them into mainline eventfd?
> 

Perhaps, or even easier I could extend xinterface.  Which is what I did ;)

The problem with the first proposal is that you would no longer actually
have an eventfd based mechanism...so any code using ioeventfd (like
Michael Tsirkin's for instance) would break.

Kind Regards,
-Greg

Attachment: signature.asc
Description: OpenPGP digital signature