Re: [Qemu-devel] ivshmem property size should be a size, not a string

[Marc-André Lureau]

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.