Re: [Xen-devel] [PATCH 1/5] xen: improve changes to xen_add_to_physmap

[Jean Guyader <jean.guyader@xxxxxxxxx>]

On 8 August 2012 10:51, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Wed, 8 Aug 2012, Jan Beulich wrote:
>> >>> On 08.08.12 at 09:45, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Wed, 2012-08-08 at 08:14 +0100, Jan Beulich wrote:
>> >> >>> On 07.08.12 at 19:07, Stefano Stabellini 
>> >> >>> <stefano.stabellini@xxxxxxxxxxxxx>
>> > wrote:
>> >> > Regarding the name, maybe it should be XEN_ADD_TO_PHYSMAP_FIELD?
>> >>
>> >> Sounds fine (and I like this better than the ..._ARG one you used
>> >> below.
>> >>
>> >> > #if (defined(__GNUC__) && !defined(__STRICT_ANSI__)) || 
>> >> > (__STDC_VERSION__ >=
>> > 201112L)
>> >>
>> >> #if (defined(__GNUC__) && !defined(__STRICT_ANSI__)) || \
>> >>     (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L)
>> >
>> > The downside of this is that users of this header might need to change
>> > their code depending on what compiler they actually build with today (or
>> > even what options).
>> >
>> > Is adding the ".u" throughout the Xen code base too intrusive?
>>
>> I don't know and didn't check; I think the goal was to avoid having
>> to change consumers that use gcc for compilation.
>
> For ARM is not an issue, but the size parameter can be used by out of
> tree code (V4V?).
> That's why I CC'ed Jean, I was hoping he was going to say that it is OK
> to add ".u".

I have introduced the size field for XENMAPSPACE_gmfn_range and that is used
by hvmload when we want to relocated the memory because the pci hole needs to be
bigger.

Maybe something else use it by now, if not you could get away by just
updating the Xen
code to use .u.

Jean

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