[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.