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
signature.asc
Description: OpenPGP digital signature
