[Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Andreas Färber]

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 HACKING | 1 +
 1 file changed, 1 insertion(+)

diff --git a/HACKING b/HACKING
index e73ac79..d9dbb46 100644
--- a/HACKING
+++ b/HACKING
@@ -42,6 +42,7 @@ ram_addr_t.
 
 Use target_ulong (or abi_ulong) for CPU virtual addresses, however
 devices should not need to use target_ulong.
+Use vaddr for CPU virtual addresses in target-independent code.
 
 Of course, take all of the above with a grain of salt.  If you're about
 to use some system interface that requires a type like size_t, pid_t or
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Peter Maydell]

On 22 July 2013 17:36, Andreas Färber <afaerber@suse.de> wrote:
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  HACKING | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/HACKING b/HACKING
> index e73ac79..d9dbb46 100644
> --- a/HACKING
> +++ b/HACKING
> @@ -42,6 +42,7 @@ ram_addr_t.
>
>  Use target_ulong (or abi_ulong) for CPU virtual addresses, however
>  devices should not need to use target_ulong.
> +Use vaddr for CPU virtual addresses in target-independent code.

Here's my suggestion for this paragraph (ie to replace
both the "Use target_ulong..." and "Use vaddr" sentences
above):

===begin===
For CPU virtual addresses there are several possible types.
vaddr is the best type to use to hold a CPU virtual address
in target-independent code, including most devices. It is
guaranteed to be large enough to hold a virtual address for
any target, and it does not change size from target to target.
It is always unsigned.
target_ulong is a type the size of a virtual address on the CPU;
this means it may be 32 or 64 bits depending on which target
is being built. It should therefore be used only in target
specific code, and in some performance-critical built-per-target
core code such as the TLB code. There is also a signed version,
target_long.
abi_ulong is for the *-user targets, and represents a type the
size of 'void *' in that target's ABI. (This may not be the same
as the size of a full CPU virtual address in the case of target
ABIs which use 32 bit pointers on 64 bit CPUs, like sparc32plus.)
Definitions of structures that must match the target's ABI
must use this type for anything that on the target is defined
to be an 'unsigned long' or a pointer type. There is also a
signed version, abi_long.
===endit===

(cc'ing Paolo to check I didn't mangle the abi_ulong/target_ulong
distinction.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Andreas Färber]

Am 22.07.2013 19:27, schrieb Peter Maydell:
> On 22 July 2013 17:36, Andreas Färber <afaerber@suse.de> wrote:
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  HACKING | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/HACKING b/HACKING
>> index e73ac79..d9dbb46 100644
>> --- a/HACKING
>> +++ b/HACKING
>> @@ -42,6 +42,7 @@ ram_addr_t.
>>
>>  Use target_ulong (or abi_ulong) for CPU virtual addresses, however
>>  devices should not need to use target_ulong.
>> +Use vaddr for CPU virtual addresses in target-independent code.
> 
> Here's my suggestion for this paragraph (ie to replace
> both the "Use target_ulong..." and "Use vaddr" sentences
> above):
> 
> ===begin===
> For CPU virtual addresses there are several possible types.
> vaddr is the best type to use to hold a CPU virtual address
> in target-independent code, including most devices. It is

Thanks. What reason can you think of for using vaddr in a device?

Andreas

> guaranteed to be large enough to hold a virtual address for
> any target, and it does not change size from target to target.
> It is always unsigned.
> target_ulong is a type the size of a virtual address on the CPU;
> this means it may be 32 or 64 bits depending on which target
> is being built. It should therefore be used only in target
> specific code, and in some performance-critical built-per-target
> core code such as the TLB code. There is also a signed version,
> target_long.
> abi_ulong is for the *-user targets, and represents a type the
> size of 'void *' in that target's ABI. (This may not be the same
> as the size of a full CPU virtual address in the case of target
> ABIs which use 32 bit pointers on 64 bit CPUs, like sparc32plus.)
> Definitions of structures that must match the target's ABI
> must use this type for anything that on the target is defined
> to be an 'unsigned long' or a pointer type. There is also a
> signed version, abi_long.
> ===endit===
> 
> (cc'ing Paolo to check I didn't mangle the abi_ulong/target_ulong
> distinction.)
> 
> thanks
> -- PMM
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Peter Maydell]

On 22 July 2013 18:32, Andreas Färber <afaerber@suse.de> wrote:
> Am 22.07.2013 19:27, schrieb Peter Maydell:
>> On 22 July 2013 17:36, Andreas Färber <afaerber@suse.de> wrote:
>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>> ---
>>>  HACKING | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/HACKING b/HACKING
>>> index e73ac79..d9dbb46 100644
>>> --- a/HACKING
>>> +++ b/HACKING
>>> @@ -42,6 +42,7 @@ ram_addr_t.
>>>
>>>  Use target_ulong (or abi_ulong) for CPU virtual addresses, however
>>>  devices should not need to use target_ulong.
>>> +Use vaddr for CPU virtual addresses in target-independent code.
>>
>> Here's my suggestion for this paragraph (ie to replace
>> both the "Use target_ulong..." and "Use vaddr" sentences
>> above):
>>
>> ===begin===
>> For CPU virtual addresses there are several possible types.
>> vaddr is the best type to use to hold a CPU virtual address
>> in target-independent code, including most devices. It is
>
> Thanks. What reason can you think of for using vaddr in a device?

I put that in because the existing text says "devices should
not need to use target_ulong" and they obviously shouldn't
use abi_ulong, leaving only vaddr if they want to play with
target virtual addresses. I agree that most devices shouldn't
care about virtual addresses at all, though, so it's probably
less confusing to just drop the ", including most devices" bit.

PS, I dunno if this amount of text needs a signoff, but you have my
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
in case it matters.

-- PMM

Re: [Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Andreas Färber]

Am 22.07.2013 19:36, schrieb Peter Maydell:
> On 22 July 2013 18:32, Andreas Färber <afaerber@suse.de> wrote:
>> Am 22.07.2013 19:27, schrieb Peter Maydell:
>>> Here's my suggestion for this paragraph (ie to replace
>>> both the "Use target_ulong..." and "Use vaddr" sentences
>>> above):
>>>
>>> ===begin===
>>> For CPU virtual addresses there are several possible types.
>>> vaddr is the best type to use to hold a CPU virtual address
>>> in target-independent code, including most devices. It is
>>
>> Thanks. What reason can you think of for using vaddr in a device?
> 
> I put that in because the existing text says "devices should
> not need to use target_ulong" and they obviously shouldn't
> use abi_ulong, leaving only vaddr if they want to play with
> target virtual addresses. I agree that most devices shouldn't
> care about virtual addresses at all, though, so it's probably
> less confusing to just drop the ", including most devices" bit.
> 
> PS, I dunno if this amount of text needs a signoff, but you have my
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> in case it matters.

Thanks, I've attributed it to you and applied without the devices bit:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Paolo Bonzini]

Il 22/07/2013 19:27, Peter Maydell ha scritto:
> On 22 July 2013 17:36, Andreas Färber <afaerber@suse.de> wrote:
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  HACKING | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/HACKING b/HACKING
>> index e73ac79..d9dbb46 100644
>> --- a/HACKING
>> +++ b/HACKING
>> @@ -42,6 +42,7 @@ ram_addr_t.
>>
>>  Use target_ulong (or abi_ulong) for CPU virtual addresses, however
>>  devices should not need to use target_ulong.
>> +Use vaddr for CPU virtual addresses in target-independent code.
> 
> Here's my suggestion for this paragraph (ie to replace
> both the "Use target_ulong..." and "Use vaddr" sentences
> above):
> 
> ===begin===
> For CPU virtual addresses there are several possible types.
> vaddr is the best type to use to hold a CPU virtual address
> in target-independent code, including most devices. It is
> guaranteed to be large enough to hold a virtual address for
> any target, and it does not change size from target to target.
> It is always unsigned.
> target_ulong is a type the size of a virtual address on the CPU;
> this means it may be 32 or 64 bits depending on which target
> is being built. It should therefore be used only in target
> specific code, and in some performance-critical built-per-target
> core code such as the TLB code. There is also a signed version,
> target_long.
> abi_ulong is for the *-user targets, and represents a type the
> size of 'void *' in that target's ABI. (This may not be the same
> as the size of a full CPU virtual address in the case of target
> ABIs which use 32 bit pointers on 64 bit CPUs, like sparc32plus.)
> Definitions of structures that must match the target's ABI
> must use this type for anything that on the target is defined
> to be an 'unsigned long' or a pointer type. There is also a
> signed version, abi_long.
> ===endit===
> 
> (cc'ing Paolo to check I didn't mangle the abi_ulong/target_ulong
> distinction.)

Yes, it's fine.  You might add that abi_short, abi_int, etc. also exist,
and that they have the same alignment as short/int/etc in the target ABI.

There is one nit: tn fact abi_ulong has the size of 'long'---which is
the same as 'void *', but only because our *-user targets are all ILP32
or LP64.  A hypotectical windows-user target would make abi_ullong the
size of 'void *'.

Paolo

Re: [Qemu-devel] [PATCH qom-cpu] HACKING: Document vaddr type usage

[Andreas Färber]

Am 23.07.2013 08:33, schrieb Paolo Bonzini:
> Il 22/07/2013 19:27, Peter Maydell ha scritto:
>> On 22 July 2013 17:36, Andreas Färber <afaerber@suse.de> wrote:
>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>> ---
>>>  HACKING | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/HACKING b/HACKING
>>> index e73ac79..d9dbb46 100644
>>> --- a/HACKING
>>> +++ b/HACKING
>>> @@ -42,6 +42,7 @@ ram_addr_t.
>>>
>>>  Use target_ulong (or abi_ulong) for CPU virtual addresses, however
>>>  devices should not need to use target_ulong.
>>> +Use vaddr for CPU virtual addresses in target-independent code.
>>
>> Here's my suggestion for this paragraph (ie to replace
>> both the "Use target_ulong..." and "Use vaddr" sentences
>> above):
>>
>> ===begin===
>> For CPU virtual addresses there are several possible types.
>> vaddr is the best type to use to hold a CPU virtual address
>> in target-independent code, including most devices. It is
>> guaranteed to be large enough to hold a virtual address for
>> any target, and it does not change size from target to target.
>> It is always unsigned.
>> target_ulong is a type the size of a virtual address on the CPU;
>> this means it may be 32 or 64 bits depending on which target
>> is being built. It should therefore be used only in target
>> specific code, and in some performance-critical built-per-target
>> core code such as the TLB code. There is also a signed version,
>> target_long.
>> abi_ulong is for the *-user targets, and represents a type the
>> size of 'void *' in that target's ABI. (This may not be the same
>> as the size of a full CPU virtual address in the case of target
>> ABIs which use 32 bit pointers on 64 bit CPUs, like sparc32plus.)
>> Definitions of structures that must match the target's ABI
>> must use this type for anything that on the target is defined
>> to be an 'unsigned long' or a pointer type. There is also a
>> signed version, abi_long.
>> ===endit===
>>
>> (cc'ing Paolo to check I didn't mangle the abi_ulong/target_ulong
>> distinction.)
> 
> Yes, it's fine.  You might add that abi_short, abi_int, etc. also exist,
> and that they have the same alignment as short/int/etc in the target ABI.
> 
> There is one nit: tn fact abi_ulong has the size of 'long'---which is
> the same as 'void *', but only because our *-user targets are all ILP32
> or LP64.  A hypotectical windows-user target would make abi_ullong the
> size of 'void *'.

Given the number of people that will read HACKING to that detail level,
I hope you can send a follow-up patch to clarify that once merged. :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg