Re: [Xen-devel] [RFC PATCH 4/6] vm_event: Use slotted channels for sync requests.

[Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>]

On Thu, 2018-12-20 at 12:05 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > 
> > The memory for the asynchronous ring and the synchronous channels
> > will
> > be allocated from domheap and mapped to the controlling domain
> > using the
> > foreignmemory_map_resource interface. Unlike the current
> > implementation,
> > the allocated pages are not part of the target DomU, so they will
> > not be
> > reclaimed when the vm_event domain is disabled.
> 
> Why re-invent the wheel here? The ioreq infrastructure already does
> pretty much everything you need AFAICT.
> 
>   Paul
> 

To my understanding, the current implementation of the ioreq server is
limited to just 2 allocated pages (ioreq and bufioreq). 
The main goal of the new vm_event implementation proposal is to be more
flexible in respect of the number of pages necessary for the
request/response buffers ( the slotted structure which holds one
request/response per vcpu or the ring spanning multiple pages in the
previous proposal).
Is it feasible to extend the current ioreq server implementation
allocate dynamically a specific number of pages?

Also, for the current vm_event implementation, other than using the
hvm_params to specify the ring page gfn, I couldn't see any reason why
it should be limited to HVM guests only. Is it feasible to assume the
vm_event mechanism will not ever be extended to PV guests?

Many thanks,
Petre


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel