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

From: "Jan Beulich" <JBeulich@suse.com>
To: Yu Zhang <yu.c.zhang@linux.intel.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 04:27:52 -0600	[thread overview]
Message-ID: <576D274802000078000F86D6@prv-mh.provo.novell.com> (raw)
In-Reply-To: <576D040F.7030001@linux.intel.com>

>>> On 24.06.16 at 11:57, <yu.c.zhang@linux.intel.com> wrote:
> 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:
>>>> 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.

Side effect or not, it'll take long and hence you can't do it in one go.
Hence the need for a continuation. We have at least one other such
example - see paging_domctl(). I don't think you'll need an auxiliary
new hypercall here, though.

Jan

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