>> Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
>>
>> ---
>> drivers/kvm/kvm.h | 50
>+++++++++++++++++++++++++++++++++++++++++++++
>> drivers/kvm/kvm_main.c | 53
+++++++++++++++++++++++++++++++++++++++---
>-----
>> 2 files changed, 94 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
>> index fceeb84..3334730 100644
>> --- a/drivers/kvm/kvm.h
>> +++ b/drivers/kvm/kvm.h
>> @@ -236,6 +236,54 @@ struct kvm_pio_request {
>> int rep;
>> };
>>
>> +struct kvm_io_device {
>> + unsigned long (*read)(struct kvm_io_device *this,
>> + gpa_t addr,
>> + unsigned long length);
>> + void (*write)(struct kvm_io_device *this,
>> + gpa_t addr,
>> + unsigned long length,
>> + unsigned long val);
>>
>
>length could be just an int.
>
>> + int (*in_range)(struct kvm_io_device *this, gpa_t addr);
>>
>
>Do you see any reason to have this as a callback and not a pair of
gpas?
This way a device can register for a range that contains holes, this
would allow partial implementation in the kernel and part in user space.
Might be usefull for some VT optimization support (haven't though of a
specific one yet, but there's a good chance to be used.)
>
>> +
>> + void *private;
>> + struct list_head link;
>>
>
>Having these in an array would be much more efficient. A fixed size
>array of moderate size should suffice.
You can take it from my old apic code.
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
