Re: [Qemu-devel] [RFC] 64 bit device I/O

[Blue Swirl <blauwirbel@gmail.com>]

On 2/25/09, Robert Reif <reif@earthlink.net> wrote:
> Avi Kivity wrote:
>
> > Robert Reif wrote:
> >
> > > Blue Swirl wrote:
> > >
> > > > Would it be better to use a structure with four elements with correct
> > > > types (including uint8/16_t)  instead of the cast? This could also be
> > > > limited to only cpu_register_io_memory64.
> > > >
> > > >
> > > >
> > > >
> > > This is what I would prefer and is what the first version of this patch
> > > that I submitted a year ago did:
> http://landley.net/qemu/2008-01-01.html
> > >
> > > The problem is that every hardware driver would need to be changed and
> > > some of them would need to be changed drastically because they use the
> > > same functions for all three data sizes.  No one seemed interested in
> this
> > > approach so I abandoned it.
> > >
> > > This approach while uglier requires no changes to the hardware drivers
> > > unless they need 64 bit support so I hoped it would be better received.
> > >
> >
> > You might try adding a struct-based 4-function interface, and implementing
> the array-based 3-function interface on top of that.  This way, no immediate
> changes would be needed for devices, but we could change them incrementally
> from the old interface to the new interface.
> >
> >
> >
>  I just tried this by changing exec.c to use a structure internally but
> still provide an array interface through the old interface and it's a real
> nice cleanup until you have to deal with subpages.  Changing the subpage
> code over to a structure doesn't really improve it any.
>
>  Why is the subpage code now saving so much redundant stuff compared to what
> it initially started out as.  Is it because that one VGA driver is messing
> with the internals of QEMU?

Also CPURead/WriteMemoryFunc structure could be read only, except for
these VGA hacks.