Re: [Xen-devel] [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@xxxxxxxxxxxxxxx>]

On 6/24/2016 4:01 PM, Jan Beulich wrote:
> > > > On 24.06.16 at 09:12, <yu.c.zhang@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel