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

[Yu Zhang <yu.c.zhang@linux.intel.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