----- Original Message ----- > Marc-André Lureau <mlur...@redhat.com> 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).
