[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
- To: 'Jan Beulich' <JBeulich@xxxxxxxx>, Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>
- From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
- Date: Wed, 17 Jul 2019 18:42:08 +0000
- Accept-language: en-GB, en-US
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=Paul.Durrant@xxxxxxxxxx; spf=Pass smtp.mailfrom=Paul.Durrant@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, "Tim \(Xen.org\)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, JulienGrall <julien.grall@xxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Delivery-date: Wed, 17 Jul 2019 18:42:16 +0000
- Ironport-sdr: KYsj0CCp+aEliXKYGaSEcVfEzro7tsb1Oog+OwBMCf3xBUWdIRhKgpGSS3T2LiiPobj5Uiu/wT vZzQry85YVSTaFGIYQ43CO4geZSLIyxcHLF2MVfEq8fhXCMXtbtZM7KXvkP4guZZ0mu4x/n6mw rnRDhcJ1Fho3khdeBojNdenADUVfzXaRXHhp3xH9fJzy6r4rsWGTa5kJ2k3P0UfvtvSm7qcjmE n+l6xvmsdjPmmSoTR0utCZlIb0qP7c8uzFCsok/SjqG/QOfgHIPHNkEFm1xZR/YkZ0asnctn8n els=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHVPIeuvysw+S0SxESjjWmMYVkcbqbOwNgAgAAfJACAAETYAA==
- Thread-topic: [PATCH v2 07/10] vm_event: Add vm_event_ng interface
> -----Original Message-----
[snip]
> >>> + }
> >>> +
> >>> + if ( !vm_event_check(ved) )
> >>> + return -EINVAL;
> >>> +
> >>> + if ( frame != 0 || nr_frames != to_channels(ved)->nr_frames )
> >>> + return -EINVAL;
> >>
> >> Is there a particular reason for this all-or-nothing model?
> >
> > I've added this extra check due to the way acquire_resource interface
> > is designed. In our case, the memory is allocated from
> > XEN_VM_EVENT_ENABLE and the size is known beforehand: the number of
> > pages needed to store (vcpus_count * sizeof vm_event_slot) bytes.
> > However the acquire_resource needs a "nr_frames" parameter which is
> > computed in a similar manner in the libxc wrapper.
>
> Hmm, maybe I'm not up to date here: Paul, is the general resource
> obtaining/mapping logic indeed meant to be an all-or-nothing thing
> only?
>
Not really, no. The intention is that any subsection of the resource space may
be mapped, so as frame + nr_frames doesn't exceed the size of the space then
there should be no reason to return an error.
Paul
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
