Re: [Qemu-devel] [RFC PATCH v1 2/4] bitops: Add UInt32StateInfo and helper functions

[Michael S. Tsirkin]

On Tue, Mar 05, 2013 at 03:17:13PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >>>> We also need uint8_t, uint16_t and uint64_t versions for some devices.
> >>>> Perhaps it would be better to implement a uint64_t device which can be
> >>>> used with shorter widths or even stronger connection with memory API.
> >>>
> >>> Why not uint8_t for everyone?
> >>
> >> That would be simple, but then modeling for example 32 bit registers
> >> gets clumsy.
> > 
> > The way we do this in pci is support wrappers for word/long accesses.
> > This is a nice way to do endian-ness conversion anyway, I guess.
> > If people are interested, it shouldn't be hard to generalize the pci code...
> 
> > At least with PCI, guest can perform a long access and host word access
> > to the same register, so width is not a register property.
> 
> Thanks, but I'm not interested.
> 
> Memory API handles this just fine for me, and there is zero reason to
> care about how the guests accesses the registers (unless the hardware
> you are emulating behaves strange enough that you have to care to get it
> right).
> 
> cheers,
>   Gerd

If the intended audience uses the memory API, then it's not needed.
pci config is not going through a memory API ATM though
I think it might be possible to make it do this by creating a separate
config address space per device.

-- 
MST