On 16/06/16 10:55, Jan Beulich wrote: >> Previously in the 2nd version, I used p2m_change_entry_type_global() to >> reset the >> outstanding p2m_ioreq_server entries back to p2m_ram_rw asynchronously after >> the de-registration. But we realized later that this approach means we >> can not support >> live migration. And to recalculate the whole p2m table forcefully when >> de-registration >> happens means too much cost. >> >> And further discussion with Paul was that we can leave the >> responsibility to reset p2m type >> to the device model side, and even a device model fails to do so, the >> affected one will only >> be the current VM, neither other VM nor hypervisor will get hurt. >> >> I thought we have reached agreement in the review process of version 2, >> so I removed >> this part from version 3. > > In which case I would appreciate the commit message to explain > this (in particular I admit I don't recall why live migration would > be affected by the p2m_change_entry_type_global() approach, > but the request is also so that later readers have at least some > source of information other than searching the mailing list).
Yes, I don't see why either. You wouldn't de-register the ioreq server until after the final sweep after the VM has been paused, right? At which point the lazy p2m re-calculation shouldn't really matter much I don't think. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
