Re: [Xen-devel] [PATCH v9 4/5] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Yu Zhang [mailto:yu.c.zhang@xxxxxxxxxxxxxxx]
> Sent: Wednesday, March 22, 2017 6:12 PM
> 
> On 3/22/2017 4:10 PM, Tian, Kevin wrote:
> >> From: Yu Zhang [mailto:yu.c.zhang@xxxxxxxxxxxxxxx]
> >> Sent: Tuesday, March 21, 2017 10:53 AM
> >>
> >> After an ioreq server has unmapped, the remaining p2m_ioreq_server
> >> entries need to be reset back to p2m_ram_rw. This patch does this
> >> asynchronously with the current p2m_change_entry_type_global()
> interface.
> >>
> >> This patch also disallows live migration, when there's still any
> >> outstanding p2m_ioreq_server entry left. The core reason is our
> >> current implementation of p2m_change_entry_type_global() can not tell
> >> the state of p2m_ioreq_server entries(can not decide if an entry is
> >> to be emulated or to be resynced).
> > Don't quite get this point. change_global is triggered only upon
> > unmap. At that point there is no ioreq server to emulate the write
> > operations on those entries. All the things required is just to change
> > the type. What's the exact decision required here?
> 
> Well, one situation I can recall is that if another ioreq server maps to this
> type, and live migration happens later. The resolve_misconfig() code cannot
> differentiate if an p2m_ioreq_server page is an obsolete to be synced, or a
> new one to be only emulated.

so if you disallow another mapping before obsolete pages are synced
as you just replied in another mail, then such limitation would be gone?

> 
> I gave some explanation on this issue in discussion during Jun 20 - 22 last
> year.
> 
> http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02426.html
> on Jun 20
> and
> http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02575.html
> on Jun 21
> 
> > btw does it mean that live migration can be still supported as long as
> > device model proactively unmaps write-protected pages before starting
> > live migration?
> >
> 
> Yes.

I'm not sure whether there'll be a sequence issue. I assume toolstack
will first request entering logdirty mode, do iterative memory copy,
and then stop VM including its virtual devices and then build final
image (including vGPU state). XenGT supports live migration today. 
vGPU device model is notified for do state save/restore only in the 
last step of that flow (as part of Qemu save/restore). If your design 
requires vGPU device model to first unmaps write-protected pages 
(which means incapable of serving more request from guest which 
is equivalently to stop vGPU) before toolstack enters logdirty mode, 
I'm worried the required changes to the whole live migration flow...

Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel