Re: [Xen-devel] [PATCH v10 00/12] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM

[Arianna Avanzini <avanzini.arianna@xxxxxxxxx>]

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