Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int.

[Isaku Yamahata]

On Mon, Jul 13, 2009 at 01:59:31PM -0500, Anthony Liguori wrote:
> Isaku Yamahata wrote:
> >On Fri, Jul 10, 2009 at 07:55:44AM -0500, Anthony Liguori wrote:
> >  
> >>Isaku Yamahata wrote:
> >>    
> >>>Then, the signatures should like the followings?
> >>>
> >>>void cpu_out[bwl](CPUState *env, int64_t addr, int{8, 16, 32}_t val);
> >>>uint{8, 16, 32}_t cpu_inw(CPUState *env, int16_t addr);
> >>>  
> >>>      
> >>If anything, it ought to be:
> >>
> >>void cpu_out[bwl](CPUState *env, uint16_t addr, int{8, 16, 32}_t val);
> >>
> >>But it's int today because the assumption is that most architectures can
> >>more efficiently pass int than other types (because it's the native
> >>type) and that int is adequate to contain all of the necessary types.
> >>
> >>But my original question still remains, what's the motivation for this
> >>change?
> >>    
> >
> >Yes, the patch description too terse.
> >The motivation is to remove inconsistency with the other part of
> >qemu.
> >
> >- Using int for cpu_{in, out}[bwl] is inconsistent with other part.
> >  For address or value, uintN_t is used by other qemu part.
> >  At least I can confirm, softmmu, CPU{Read, Write}MemoryFunc, pci,
> >  target_phys_addr_t and the callers of cpu_{in, out}[bwl]().
> >  
> 
> What does the PCI spec say about the size of PIO IO regions?  Can they 
> be as large as MEM IO regions?
> If so, I would think that we should use ram_addr_t for addr and then we 
> can use the appropriate uintN_t type for value. 

PIO IO regions address is 32 bit width. Unlike MEM IO, 64 bit isn't allowed.
So uint32_t for address?


> Switching value like 
> that though could have some subtle consequences.  For instance, 
> cpu_outb(env, ..., 128) would have worked properly before as would 
> cpu_outb(env, ..., -32).

All the callers except kvm_handle_io() passes uint32_t as value.
So it wouldn't matter.

-- 
yamahata