Hi ----- Original Message ----- > 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
I think there is no race if you communicate this information in the shared memory. > 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 It's not about me. Until now I was not aware of anyone complaining about the ivshmem interface, but by its implementation. I tried to adress all the issues and comments I have found, and I tried to make sure not to break stuff, because I usually receive huge complains whenever I do, and I have to throw up the work. So if there is a consensus to break things now, I think it's quite late for this cycle, but I am for it. > 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. It is just the way it was, isn't it? > 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 Afaik it's there since 1.2.10 > 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. 2.5 should not break the ivshmem interface.
