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: Markus Armbruster
Subject: Re: [Qemu-devel] ivshmem property size should be a size, not a string
Date: Mon, 23 Nov 2015 16:17:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Marc-André Lureau <address@hidden> writes:

> ----- Original Message -----
>> Marc-André Lureau <address@hidden> writes:
>> 
>> > Hi
>> >
>> > ----- Original Message -----
>> >> >
>> >> > You can't migrate the peers.
>> >> 
>> >> Then explain the case N'=0 to me: how can you migrate the master so that
>> >> it's connected to a server afterwards?
>> >
>> > Dest qemu: -incoming.. -chardev socket,path=dest-server
>> >
>> > That is, start your destination qemu with a destination server. The master
>> > origin qemu will migrate the shared memory, and the dest memory will be
>> > sync
>> > when the migration is done.
>> 
>> Got it!
>> 
>> >> > It works fine in the tests. Feel free to point out races or other
>> >> > issues.
>> >> 
>> >> I think I did: doorbell detection is inherently racy.
>> >> 
>> >> If you think it isn't, please refute my reasoning.
>> >
>> > I gave you some clues on how I did it in ivshmem-test.c: waiting for a
>> > signature on the memory to be mapped (and also checking that peers
>> > received ids)
>> >
>> >> 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.
>> 
>
> Yes, I think it's correct. Arbitrary informations can be then shared
> via the shared memory (to say whether a doorbell will be present for
> ex).

Then there is no race-free way for the guest to distinguish between "no
doorbell" and "doorbell not ready" without some higher-level protocol.

Corollary: when IVPosition reads -1, BAR 2 may or may not be mapped, and
the only way to find out is accessing it.

Feels plenty broken to me.  Straight NAK in fact if it wasn't already in
the tree.



reply via email to

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