| Message ID | 1374510975-9896-1-git-send-email-afaerber@suse.de |
|---|---|
| State | New |
| Headers | show |
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
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 >
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
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
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
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
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
Signed-off-by: Andreas Färber <afaerber@suse.de> --- HACKING | 1 + 1 file changed, 1 insertion(+)