On 11/23/2015 07:46 AM, Markus Armbruster wrote:

>>> If it's not broken, please explain to me how the guest should find out
>>> whether its ivshmem device sports a doorbell.
>>
>> If you have received ID, you should be good to use the doorbell.
> 
> That's not a complete answer, so let me try a different tack.
> 
> What value will a read of register IVPosition yield
> 
> * if the device has no doorbell:
> 
>   I think the answer is -1.
> 
> * if the device has a doorbell, but it isn't ready, yet:
> 
>   I think the answer is -1.
> 
> * if the device has a doorbell, and it is ready.
> 
>   This is the part you answered already: >= 0.
> 
> Please correct mistakes.

For what it's worth, I'm agreeing with Markus here - we have a race in
the guest learning whether doorbell is supported, and it's better to do
a clean break in API for 2.5 along with ALL the other fixes into using a
sane union of types (splitting between ivshmem-plain and
ivshmem-doorbell).  If you absolutely want it, you can still maintain
'ivshmem' as a front-end that maps to either ivshmem-plain,
ivshmem-doorbell, or an error (nonsensical combination of requests), but
having a sane interface as your starting point, rather than an
amalgamation of cruft that exists only due to the early implementation,
seems like the way to go.

I'm still waiting for any evidence that we even care about backwards
compatibility - what apps are out there that are actively using ivshmem
with its horrible pre-2.5 interface, and why can they not be fixed to
use the sane 2.5 interface?  Libvirt is NOT exposing ivshmem yet, in
part because the 2.4 interface was not very robust.  We already have a
clean break now due to all your work for 2.5; let's take advantage of
it, and make 2.5 robust, rather than breaking things again in 2.6.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org