qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] [RFC] 64 bit device I/O
Date: Tue, 24 Feb 2009 22:16:47 +0200

On 2/24/09, Robert Reif <address@hidden> wrote:
> Robert Reif wrote:
>
> > Here is my second proof of concept attempt at supporting
> > 64 bit device I/O.
> >
> > This attempt doesn't require changing all devices to add a forth
> > function for 64 bit I/O unless actually needed.  Unfortunately it
> > does require an ugly cast when 64 bit is required.
> >
> > This has been tested only on sparc32 and only the slavio_timer
> > hw device has been converted to support 64 bit I/O.
> >
> > All other architectures should work as before except when
> > 64 bit I/O is performed.  They will now get an unassigned
> > access error because there is no 64 bit callback defined by
> > default.  Adding a 64 bit callback and using
> > cpu_register_io_memory64 to register the new callback
> > will fix it.  See slavio_timer.c to to see how the new callback
> > is registered.
> >
> > Comments welcome.
> >
>  This is a bug fix version of the previous patch.
>   exec.c  subpage_readlen64 had a truncation bug
>   slavio_timer.c had a timer limit bug
>
>  With this patch, a sparc32 SS5-170 openboot image
>  passes the 64bit user timer self test.  I have also tested it on
>  sparc32 with an unreleased hw device that does extensive
>  64 bit i/o.
>
>  Please let me know what other ports and hardware configurations
>  perform 64 bit i/o so I can make the necessary changes for
>  inclusion into QEMU.

Sparc64 would use 64 bit IO extensively for most native device
registers, but so far there is only the PCI host bridge and even that
is not fully implemented. Accessing the registers with 8/16/32 bit
operations should trigger a fault.

>  +static CPUReadMemoryFunc *unassigned_mem_read[4] = {
>      unassigned_mem_readb,
>      unassigned_mem_readw,
>      unassigned_mem_readl,
>  +    (CPUReadMemoryFunc*)unassigned_mem_readq,
>   };

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]