[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



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 ?

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



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.