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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.18 at 15:28, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Petre Ovidiu PIRCALABU [mailto:ppircalabu@xxxxxxxxxxxxxxx]
>> Sent: 20 December 2018 14:26
>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx 
>> Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>; Wei Liu
>> <wei.liu2@xxxxxxxxxx>; Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>; Konrad
>> Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; George Dunlap
>> <George.Dunlap@xxxxxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Ian
>> Jackson <Ian.Jackson@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>; Julien
>> Grall <julien.grall@xxxxxxx>; Tamas K Lengyel <tamas@xxxxxxxxxxxxx>; Jan
>> Beulich <jbeulich@xxxxxxxx>; Roger Pau Monne <roger.pau@xxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel