Re: [PATCH] Support for in-kernel mmio handlers

Gregory Haskins
2007-04-10T11:49:25Z

>>> On Tue, Apr 10, 2007 at 3:56 AM, in message <461B4319.80608-atKUWr5tajBWk0Htik3J/w@public.gmane.org>, Avi
Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> Gregory Haskins wrote:
>>
>> Note that I finally understand what you were getting at with the array of
> objects thing. I didn't change it yet for the same reason that you
> mentioned: reduction of churn. However, now that I understand it, I see why
> you wanted it. Perhaps I will send a follow- on to this patch that uses your
> idea. But for now...
>>
>
> I will try to be more explicit in the future.
>

Nah, I think you explained it fine, I was just being too obtuse ;) When you first brought it up, I figured there was some secret deficiency in the linked-list implementation compared to arrays that I wasn't aware of and didn't question it. I see now that what you were getting at is that an array of objects with the range criteria in-line can be made to fit in a handful of cache-lines. Having an indirection to find the kvm_io_device* and another to find the in_range() function do not have this benefit (which both the list and the pointer-array as I have implemented suffer from this).

>> ---
>>
>> KVM: Add support for in- kernel mmio handlers
>>
>> There is a near- term need for moving some of the emulation from userspace to
>> the kernel (e.g. interrupt handling). This patch adds a construct for
>> registering in- kernel MMIO handlers. The consumers of this interface will
>> appear in a follow- on patch.
>>
>
>
> Given that the first consumer is the local apic, it makes sense to add
> the vcpu- local bus first, no?

I'm confused. I thought you didn't like the vpcu-local bus? I pulled it based on your feedback :) Please advise.

Regards,
-Greg