Re: [PATCH v2 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 08/04/16 11:10, Yu, Zhang wrote:
[snip]
> BTW, I noticed your reply has not be CCed to mailing list, and I also
> wonder if we should raise this last question in community?

Oops -- that was a mistake on my part.  :-)  I appreciate the
discretion; just so you know in the future, if I'm purposely changing
the CC list (removing xen-devel and/or adding extra people), I'll almost
always say so at the top of the mail.

>> And then of course there's the p2m_ioreq_server -> p2m_ram_logdirty
>> transition -- I assume that live migration is incompatible with this
>> functionality?  Is there anything that prevents a live migration from
>> being started when there are outstanding p2m_ioreq_server entries?
>>
> 
> Another good question, and the answer is unfortunately yes. :-)
> 
> If live migration happens during the normal emulation process, entries
> marked with p2m_ioreq_server will be changed to p2m_log_dirty in
> resolve_misconfig(), and later write operations will change them to
> p2m_ram_rw, thereafter these pages can not be forwarded to device model.
> From this point of view, this functionality is incompatible with live
> migration.
> 
> But for XenGT, I think this is acceptable, because, if live migration
> is to be supported in the future, intervention from backend device
> model will be necessary. At that time, we can guarantee from the device
> model side that there's no outdated p2m_ioreq_server entries, hence no
> need to reset the p2m type back to p2m_ram_rw(and do not include
> p2m_ioreq_server in the P2M_CHANGEABLE_TYPES). By "outdated", I mean
> when an ioreq server is detached from p2m_ioreq_server, or before an
> ioreq server is attached to this type, entries marked with
> p2m_ioreq_server should be regarded as outdated.
> 
> Is this acceptible to you? Any suggestions?

So the question is, as of this series, what happens if someone tries to
initiate a live migration while there are outstanding p2m_ioreq_server
entries?

If the answer is "the ioreq server suddenly loses all control of the
memory", that's something that needs to be changed.

If the answer is, "everything just works", that's perfect.

If the answer is, "Before logdirty mode is set, the ioreq server has the
opportunity to detach, removing the p2m_ioreq_server entries, and
operating without that functionality", that's good too.

If the answer is, "the live migration request fails and the guest
continues to run", that's also acceptable.  If you want this series to
be checked in today (the last day for 4.7), this is probably your best bet.

 -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel