Hollis Blanchard wrote:
> On Sun, 2007-10-28 at 21:11 -0500, Anthony Liguori wrote:
>
>> int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data,
>> int size);
>>
>> Where as is a #define representing the address space (on x86, there is
>> the PIO and MMIO address spaces, on PPC, there is just MMIO).
>>
>
> So the implementation would look something like this:
>
> int io_write(void *opaque, int as, uint64_t addr, uint64_t data, int
> size) {
> io_handler_t cb;
>
> switch (as) {
> case MMIO:
> cb = io_table_lookup(&mmio_table, ...)
> break;
> #ifdef HAS_PIO
> case PIO:
> cb = io_table_lookup(&pio_table, ...)
> break;
> #endif
> #ifdef HAS_DCR
> case DCR:
> cb = io_table_lookup(&dcr_table, ...)
> break;
> #endif
> default:
> cb = NULL;
> }
>
> if (cb)
> return cb(...);
>
> printk("error");
> return -EINVAL;
> }
>
> Sounds fine to me.
>
You could certainly get even more clever and have the arch backend
register the appropriate tables based on the as type but that's merely
an implementation detail. The key observation, that I believe is
correct, is that all architectures have one or more IO "address spaces"
that have at max a 64-bit address space and support at max 64-bit
input/output operations. Once that assumption is made, almost all IO
code becomes common.
Regards,
Anthony Liguori
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
