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

From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>,
	George Dunlap <George.Dunlap@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Jan Beulich <JBeulich@suse.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	"jun.nakajima@intel.com" <jun.nakajima@intel.com>
Subject: Re: [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
Date: Tue, 19 Apr 2016 09:21:01 +0000	[thread overview]
Message-ID: <e76af8d219ef4de4845f9acc2a9cd503@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5715F659.6060600@linux.intel.com>

> -----Original Message-----
[snip]
> >> Does any other maintainers have any suggestions?
> >
> > Note that it is a requirement that an ioreq server be disabled before VM
> suspend. That means ioreq server pages essentially have to go back to
> ram_rw semantics.
> >
> >    Paul
> >
> 
> OK. So it should be hypervisor's responsibility to do the resetting.
> Now we probably have 2 choices:
> 1> we reset the p2m type synchronously when ioreq server unmapping
> happens, instead of deferring to the misconfig handling part. This
> means performance impact to traverse the p2m table.
> 

Do we need to reset at all. The p2m type does need to be transferred, it will just be unclaimed on the far end (i.e. the pages are treated as r/w ram) until the emulator starts up there. If that cannot be done without creating yet another p2m type to handle logdirty (which seems a suboptimal way of dealing with it) then I think migration needs to be disallowed on any domain than contains any ioreq_server type pages at this stage.

  Paul

> Or
> 2> we just disallow live migration when p2m->ioreq.server is not NULL.
> This is not quite accurate, because having p2m->ioreq.server mapped
> to p2m_ioreq_server does not necessarily means there would be such
> outstanding entries. To be more accurate, we can add some other rough
> check, e.g. both check if p2m->ioreq.server against NULL and check if
> the hvmop_set_mem_type has ever been triggered once for the
> p2m_ioreq_server type.
> 
> Both choice seems suboptimal for me. And I wonder if we have any
> better solutions?
> 
> Thanks
> Yu
> 
> >> Thanks in advance! :)
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> Regards
> >> Yu
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel