[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 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.

> 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.

> 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
 */

_______________________________________________
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®.