>>> On 20.12.18 at 15:28, <paul.durr...@citrix.com> wrote: >> -----Original Message----- >> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com] >> Sent: 20 December 2018 14:26 >> To: Paul Durrant <paul.durr...@citrix.com>; xen-devel@lists.xenproject.org >> Cc: Stefano Stabellini <sstabell...@kernel.org>; Wei Liu >> <wei.l...@citrix.com>; Razvan Cojocaru <rcojoc...@bitdefender.com>; Konrad >> Rzeszutek Wilk <konrad.w...@oracle.com>; George Dunlap >> <george.dun...@citrix.com>; Andrew Cooper <andrew.coop...@citrix.com>; Ian >> Jackson <ian.jack...@citrix.com>; Tim (Xen.org) <t...@xen.org>; Julien >> Grall <julien.gr...@arm.com>; Tamas K Lengyel <ta...@tklengyel.com>; Jan >> Beulich <jbeul...@suse.com>; Roger Pau Monne <roger....@citrix.com> >> Subject: Re: [Xen-devel] [RFC PATCH 4/6] vm_event: Use slotted channels >> for sync requests. >> >> On Thu, 2018-12-20 at 12:05 +0000, Paul Durrant wrote: >> > > 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 >> >> I wanted preseve as much as possible from the existing vm_event DOMCTL >> interface and add only the necessary code to allocate and map the >> vm_event_pages. > > That means we have two subsystems duplicating a lot of functionality though. > It would be much better to use ioreq server if possible than provide a > compatibility interface via DOMCTL.
+1 from me, fwiw. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
