Re: [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[George Dunlap <george.dunlap@citrix.com>]

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