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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

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