On Mon, Mar 7, 2016 at 8:25 PM, Markus Armbruster <arm...@redhat.com> wrote: > When configured for interrupts (property "chardev" given), we receive > the shared memory from an ivshmem server. We do so asynchronously > after realize() completes, by setting up callbacks with > qemu_chr_add_handlers(). > > Keeping server I/O out of realize() that way avoids delays due to a > slow server. This is probably relevant only for hot plug. > > However, this funny "no shared memory, yet" state of the device also > causes a raft of issues that are hard or impossible to work around: > > * The guest is exposed to this state: when we enter and leave it its > shared memory contents is apruptly replaced, and device register > IVPosition changes. > > This is a known issue. We document that guests should not access > the shared memory after device initialization until the IVPosition > register becomes non-negative. > > For cold plug, the funny state is unlikely to be visible in > practice, because we normally receive the shared memory long before > the guest gets around to mess with the device. > > For hot plug, the timing is tighter, but the relative slowness of > PCI device configuration has a good chance to hide the funny state. > > In either case, guests complying with the documented procedure are > safe. > > * Migration becomes racy. > > If migration completes before the shared memory setup completes on > the source, shared memory contents is silently lost. Fortunately, > migration is rather unlikely to win this race. > > If the shared memory's ramblock arrives at the destination before > shared memory setup completes, migration fails. > > There is no known way for a management application to wait for > shared memory setup to complete. > > All you can do is retry failed migration. You can improve your > chances by leaving more time between running the destination QEMU > and the migrate command. > > To mitigate silent memory loss, you need to ensure the server > initializes shared memory exactly the same on source and > destination. > > These issues are entirely undocumented so far. > > I'd expect the server to be almost always fast enough to hide these > issues. But then rare catastrophic races are in a way the worst kind. > > This is way more trouble than I'm willing to take from any device. > Kill the funny state by receiving shared memory synchronously in > realize(). If your hot plug hangs, go kill your ivshmem server. > > For easier review, this commit only makes the receive synchronous, it > doesn't add the necessary error propagation. Without that, the funny > state persists. The next commit will do that, and kill it off for > real. > > Signed-off-by: Markus Armbruster <arm...@redhat.com> > ---
Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com> -- Marc-André Lureau