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

From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Jan Beulich <JBeulich@suse.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 17:57:35 +0800	[thread overview]
Message-ID: <576D040F.7030001@linux.intel.com> (raw)
In-Reply-To: <576D04EE02000078000F862A@prv-mh.provo.novell.com>

On 6/24/2016 4:01 PM, Jan Beulich wrote:
>>>> 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).

OK. To disable logdirty, the judgement could be based on the existence of
outstanding p2m_ioreq_sever entries.

>>> 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).
>

By "scheduling a continuation and executing it", do you mean code like
hypercall_create_continuation? I'll need to study on this part. But one
difference I can imagine is that the hypercall_create_continuation is of
uncompleted hypercalls I guess, yet the p2m table sweeping may only
be a side effect of the unbound hypercall here.
I may have some misunderstandings here, so please correct me if so,
and I'll have try some investigation at the same time. Thanks!

Yu

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