qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] ivshmem property size should be a size, not a string
Date: Mon, 23 Nov 2015 12:52:41 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]