* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote: > * Paolo Bonzini (pbonz...@redhat.com) wrote: > > > > > > On 09/12/2014 19:15, Dr. David Alan Gilbert (git) wrote: > > > (With the previous atapi_dma flag recovery) > > > If migration happens between the ATAPI command being written and the > > > bmdma being started, the DMA is dropped. Eventually the guest times > > > out and recovers, but that can take many seconds. > > > (This is rare, on a pingpong reading the CD continuously I hit > > > this about ~1/30-1/50 migrates) > > > > > > I don't think we've got enough state to be able to recover safely > > > at this point, so I throw a 'medium error, no seek complete' > > > that I'm assuming guests will try and recover from an apparently > > > dirty CD. > > > > > Also, what is the ATAPI command that is being run? > > The command in my test case is: > 28 00 00 06 df b8 00 00 40 00 00 00 > so just a standard READ (10); I guess it's possible that other OSs/operations > maybe doing different READ variants. > > > What is the part of the state that is not being migrated? > > I can't see lba, io_buffer_index, io_buffer_size or cd_sector_size being > passed > to a VMSTATE_ macro; and having noticed that those are missing I didn't dig > much > deeper. > (I'll admit to not really understanding the interaction between the core.c, > atapi.c > and pci.c dma code properly to know if it can be reconstructed).
Actually, another argument for this is that even if we come along and add the extra state as a subsection, we can still do this as a fallback when receiving older streams. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
