Hi Paul,
On 12/20/18 2:28 PM, Paul Durrant 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.
Also, to my knowledge, the ioreq server is only supported for x86 hvm
targets. I didn't want to add an extra limitation to the vm_event
system.
I believe Julien is already porting it to ARM.
FWIW, yes I have a port of ioreq for Arm. Still cleaning-up the code.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel