[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value inst
From: |
Isaku Yamahata |
Subject: |
Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int. |
Date: |
Tue, 14 Jul 2009 10:58:21 +0900 |
User-agent: |
Mutt/1.5.6i |
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
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., (continued)
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Tristan Gingold, 2009/07/10
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Anthony Liguori, 2009/07/10
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Tristan Gingold, 2009/07/10
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Anthony Liguori, 2009/07/10
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Tristan Gingold, 2009/07/10
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Anthony Liguori, 2009/07/10
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Isaku Yamahata, 2009/07/12
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Anthony Liguori, 2009/07/13
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Stuart Brady, 2009/07/13
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Anthony Liguori, 2009/07/13
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int.,
Isaku Yamahata <=
- Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int., Anthony Liguori, 2009/07/10
[Qemu-devel] [PATCH 0/6] ioport related clean ups, Isaku Yamahata, 2009/07/03
[Qemu-devel] [PATCH 3/6] ioport: consolidate duplicated logic in register_ioport_{read, write}()., Isaku Yamahata, 2009/07/03
[Qemu-devel] [PATCH 6/6] use uint{32, 16, 8}_t for ioport port and value instead of int., Isaku Yamahata, 2009/07/03
[Qemu-devel] [PATCH 2/6] use constant IOPORTS_MASK instead of 0xffff., Isaku Yamahata, 2009/07/03