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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 24.06.16 at 06:16, <yu.c.zhang@linux.intel.com> wrote:
> I'm now willing to take your suggestions:
> a> still need the p2m resetting when ioreq server is unbounded;
> b> disable log dirty feature if one ioreq server is bounded.
> 
> Does anyone else has different opinions? Thanks!

Hmm, in particular for a) I don't think I read that out of George's
descriptions. But of course much depends on what you really
mean by that: Do you want to say we need to guarantee all
entries get reverted back, or do you instead mean to just kick
off the conversion (via the misconfig mechanism)?

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.

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.

Jan


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