[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 00/12] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM
On 21/08/2014 17:43, Andrii Tseglytskyi wrote: > Hi Arianna, > > Just one more question - how iomem mapping will be handled by XSM framework? > I'm using older revision of your patch series and I need to do the > following change to permit domU working with already mapped iomem, > (only if XSM is enabled and FLASK is enforsed) > > commit 3f35dae860bd0f566ca156608ec53e3240aacd5a > Author: Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx> > Date: Thu Aug 21 18:00:20 2014 +0300 > > xsm: arm: allow domU to use iomem > > Change-Id: I7eff12b127e0d32d97a67e77dbcca3a8326dfd22 > Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx> > > diff --git a/tools/flask/policy/policy/modules/xen/xen.te > b/tools/flask/policy/policy/modules/xen/xen.te > index d7147fb..ac4a01d 100644 > --- a/tools/flask/policy/policy/modules/xen/xen.te > +++ b/tools/flask/policy/policy/modules/xen/xen.te > @@ -108,6 +108,7 @@ admin_device(dom0_t, device_t) > admin_device(dom0_t, irq_t) > admin_device(dom0_t, ioport_t) > admin_device(dom0_t, iomem_t) > +admin_device(domU_t, iomem_t) > > domain_comms(dom0_t, dom0_t) > > Is this a point, or I missed something ? > I think this is a point, if I understood things well. Do you prefer to submit your patch personally if/after the memory_mapping patchset is eventually merged, or do you prefer that I send your patch with the memory_mapping patchset? Thank you, Arianna > Regards, > Andrii > > On Wed, Aug 20, 2014 at 10:15 PM, Andrii Tseglytskyi > <andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote: >> On Wed, Aug 20, 2014 at 9:50 PM, Arianna Avanzini >> <avanzini.arianna@xxxxxxxxx> wrote: >>> On 18/08/2014 21:50, Andrii Tseglytskyi wrote: >>>> Hi Arianna, >>>> >>>> On Tue, Jul 29, 2014 at 1:11 AM, Arianna Avanzini >>>> <avanzini.arianna@xxxxxxxxx> wrote: >>>>> Hello, >>>>> >>>>> here I am finally with the tenth version of my implementation proposal >>>>> for the >>>>> memory_mapping DOMCTL for the ARM architecture. As I did for the previous >>>>> versions, I'll try to keep this cover letter as short as I can by listing >>>>> here >>>>> only the most relevant changes, while a more detailed description can be >>>>> found >>>>> in the description and changelog that comes with each of the patches. More >>>>> detailed information about the patch series' genesis can be found in the >>>>> last >>>>> full cover letter ([1]). >>>>> Please note that the second and third patches of the v9 series have been >>>>> merged >>>>> by Ian Campbell ([2]) as they resulted in an interface change that would >>>>> have >>>>> clashed with other upcoming merges. >>>>> >>>>> Patch 0001 has been fixed according to directives given by Julien Grall >>>>> and >>>>> Ian Campbell; the main change is in the fact that now the ARM-related code >>>>> handling the removal of an I/O-memory mapping follows a behavior which >>>>> matches >>>>> the one introduced for x86 by patch 0003: in case the given machine frame >>>>> number is mapped to an unexpected guest frame number, it emits a warning >>>>> and >>>>> still destroys the mapping. >>>>> >>>>> Patch 0002 has been modified according to suggestions given by Ian >>>>> Campbell; >>>>> now in case that the insertion of a new I/O-memory mapping fails (even if >>>>> only >>>>> partially) the whole range is unmapped. >>>>> >>>>> Coding style issues existing in patch 0006 and pointed out by Jan Beulich >>>>> have >>>>> been hopefully addressed here. >>>>> >>>>> A patch 0010 has been added that moves libxl's PCI-related macros, >>>>> previously >>>>> kept in the libxl_pci.c file, to a header file. >>>>> >>>>> After some discussion involving Ian Campbell, Jan Beulich and Sander >>>>> Eikelenboom >>>>> patch 0011 has been changed according to directives from Ian Campbell. >>>>> Now the >>>>> I/O-memory areas needed to passthrough a VGA device in addition to >>>>> PCI-related >>>>> ones are made accessible to any guest having gfx_passthru set to true in >>>>> its >>>>> config and at least one passthru PCI device having a device class of >>>>> 0x030000 >>>>> (which should identify it as a VGA device). >>>>> >>>>> The code has again been tested on a cubieboard2, with Linux v3.15-rc3 as >>>>> a dom0 >>>>> and ERIKA Enterprise ([3]) as a domU. The x86 bits have been tested on an >>>>> x86_64 >>>>> machine with Linux 3.15.0-rc5 as both dom0 and domU. >>>>> Any feedback about this new version of the patchset is more than welcome, >>>>> Arianna >>>> >>>> Do you have any public repo, where can I cherry - pick your latest >>>> patch series ? >>> >>> Unfortunately as of now I don't have any. However (I'm hoping it helps) I >>> will >>> be sending a new version of the patchset, updated for the latest head of the >>> development repository, within this week. >>> >> >> Great. Thank you. >> >>>> This series is very useful for development we do in GlobalLogic - we >>>> have Android as domU, and we need iomem for such devices as GPU. >>>> For now we are using one of your previous series - is works fine for >>>> us. Platform is DRA7 (OMAP5) >>>> >>> >>> Thank you so much for providing feedback. Please do not hesitate to point >>> out >>> any issue you might have. >>> >> >> Sure. >> >> Regards, >> Andrii >> >>>> Also - I suppose - you are targeting this for Xen 4.5. Am I right ? >>>> >>> >>> Yes, you are right. I hope I'll be able to provide faster response to >>> comments >>> and reviews in the near future. >>> >>> Thank you, >>> Arianna >>> >>> >>> >>>> Regards, >>>> Andrii >>>> >>>> >>>>> -- >>>>> 2.0.3 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@xxxxxxxxxxxxx >>>>> http://lists.xen.org/xen-devel >>>> >>>> >>>> >>> >>> >>> -- >>> /* >>> * Arianna Avanzini >>> * avanzini.arianna@xxxxxxxxx >>> * 73628@xxxxxxxxxxxxxxxxxxx >>> */ >> >> >> >> -- >> >> Andrii Tseglytskyi | Embedded Dev >> GlobalLogic >> www.globallogic.com > > > -- /* * Arianna Avanzini * avanzini.arianna@xxxxxxxxx * 73628@xxxxxxxxxxxxxxxxxxx */ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |