Re: [Xen-devel] [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Fri, Feb 13, 2015 at 7:09 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/02/15 18:03, Tamas K Lengyel wrote:
>> On Fri, Feb 13, 2015 at 6:23 PM, Andrew Cooper
>> <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 13/02/15 16:33, Tamas K Lengyel wrote:
>>>> The public mem_event structures used to communicate with helper 
>>>> applications via
>>>> shared rings have been used in different settings. However, the variable 
>>>> names
>>>> within this structure have not reflected this fact, resulting in the reuse 
>>>> of
>>>> variables to mean different things under different scenarios.
>>>>
>>>> This patch remedies the issue by clearly defining the structure members 
>>>> based on
>>>> the actual context within which the structure is used.
>>>>
>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
>>>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
>>>> ---
>>>> v5: Style fixes
>>>>     Convert gfn to uint32_t
>>> It is perfectly possible to have guests with more memory than is covered
>>> by 44 bits, or PV guests whose frames reside above the 44bit boundary.
>>> All gfn values should be 64bits wide.
>>>
>>> ~Andrew
>> Internally Xen handles all gfn's as unsigned long's so depending on
>> the compiler it may be only 32-bit wide. If gfn must be larger than
>> 32-bit than we should use unsigned long long's within Xen.
>
> x86_32 Xen support was ripped out a while ago.  For the time being all
> unsigned longs are 64bit.
>
> With the arm32/64 split, there is a slow move in the direction of
> paddr_t rather than unsigned long.
>
> ~Andrew

Ack.

Thanks,
Tamas

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