[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 24.06.16 at 11:57, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
> 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:
>>>> 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@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®.