On Wed, Dec 21, 2022 at 10:26:51AM -0300, Daniel Henrique Barboza wrote: > > > On 12/21/22 06:46, Cédric Le Goater wrote: > > On 12/16/22 17:47, Daniel Henrique Barboza wrote: > > > > > > > > > On 12/13/22 09:35, Philippe Mathieu-Daudé wrote: > > > > spapr_ovec.c is a device, but it uses target_ulong which is > > > > target specific. The hwaddr type (declared in "exec/hwaddr.h") > > > > better fits hardware addresses. > > > > > > As said by Harsh, spapr_ovec is in fact a data structure that stores platform > > > options that are supported by the guest. > > > > > > That doesn't mean that I oppose the change made here. Aside from semantics - which > > > I also don't have a strong opinion about it - I don't believe it matters that > > > much - spapr is 64 bit only, so hwaddr will always be == target_ulong. > > > > > > Cedric/David/Greg, let me know if you have any restriction/thoughts about this. > > > I'm inclined to accept it as is. > > > > Well, I am not sure. > > > > The vector table variable is the result of a ppc64_phys_to_real() conversion > > of the CAS hcall parameter, which is a target_ulong, but ppc64_phys_to_real() > > returns a uint64_t. > > > > The code is not consistent in another places : > > > > hw/ppc/spapr_tpm_proxy.c uses a uint64_t > > hw/ppc/spapr_hcall.c, a target_ulong > > hw/ppc/spapr_rtas.c, a hwaddr > > hw/ppc/spapr_drc.c, a hwaddr indirectly > > > > Should we change ppc64_phys_to_real() to return an hwaddr (also) ? > > It makes sense to me a function called ppc64_phys_to_real() returning > a hwaddr type. Yes, I also think that makes sense. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
