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

From: "Jan Beulich" <JBeulich@suse.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>,
	George Dunlap <george.dunlap@citrix.com>,
	xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	zhiyuan.lv@intel.com, JunNakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
Date: Fri, 24 Jun 2016 02:01:18 -0600	[thread overview]
Message-ID: <576D04EE02000078000F862A@prv-mh.provo.novell.com> (raw)
In-Reply-To: <576CDD65.1000903@linux.intel.com>

>>> On 24.06.16 at 09:12, <yu.c.zhang@linux.intel.com> wrote:
> On 6/24/2016 2:12 PM, Jan Beulich wrote:
>> In any event, I think log-dirty shouldn't be disabled when an
>> ioreq server binds the type, but as long as there are outstanding
>> entries of that type. That way, the "cannot be migrated" state
>> of a VM has a chance to clear.
> 
> Do you mean to disable log dirty by checking if there's outstanding 
> p2m_ioreq_server
> entries instead of the p2m->ioreq.server? How about we check both? 
> Because only
> checking the count of outstanding p2m_ioreq_server may prevent the live 
> migration
> when an ioreq server is unbound, but with p2m type not entirely synced.

Checking both would limit things further, which seems to
contradict your intention of relaxing things. What may be a
reasonable combination is to check for a registered ioreq server
when enabling log-dirty, and for outstanding pages when
registering a new ioreq server. Yet then again it feels like we're
moving in circles: Didn't we mean de-registration to fail when
there are outstanding pages? In which case checking for a
registered server would be slightly more tight than checking for
outstanding pages: The server could have removed all pages,
but not de-registered, which would - afaict - still allow log-dirty
to function (of course new registration of pages would need to
fail until log-dirty got disabled again).

>> And then, thinking about it again especially in the context of
>> the hvmctl series - the unbinding of the type is happening in a
>> hypercall with built-in preemption capability. Hence there's not
>> really an issue with how long that conversion may take, as
>> long as there's no need to pause the guest for that time period.
>> Which means you could first initiate conversion via the
>> misconfig mechanism, but then immediately go ahead and walk
>> the entire guest address space (or the relevant part of it, if
>> the bounds got tracked) with continuations used as necessary.
> 
> Sorry, what's the misconfig mechanism good for if I still need to sweep 
> the entire
> p2m table immediately?

To avoid the need to pause the guest for an extended time: At
least between scheduling a continuation and executing it, the
guest could happily run (and perhaps cause some of the
otherwise synchronous - to the hypercall - work to get carried
out already, with the involved execution time accounted to the
guest instead of the host).

Jan

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