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
