* 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). Dave > Paolo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
