[lkml]   [2009]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] kvm: remove in_range from kvm_io_device
Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2009 at 11:49:01AM +0300, Michael S. Tsirkin wrote:
>> On Tue, Jun 23, 2009 at 09:43:31PM -0400, Gregory Haskins wrote:
>>> Michael S. Tsirkin wrote:
>>>> Remove in_range from kvm_io_device and ask read/write callbacks, if
>>>> supplied, to perform range checks internally. This allows aliasing
>>>> (mostly for in-kernel virtio), as well as better error handling by
>>>> making it possible to pass errors up to userspace. And it's enough to
>>>> look at the diffstat to see that it's a better API anyway.
>>>> While we are at it, document locking rules for kvm_io_device.
>>> Hi Michael,
>>> I just tried to apply this to kvm.git/master, and it blew up really
>>> badly. What tree should I be using?
>> Ugh, this is against 2.6.30. I'll post kvm.git version soon.
> I went ahead and tried to rebase it, to find that it conflicts with
> recent patch 35b3038961f94e83557944ae0d30c8fa0b5012cf merged in kvm.git:
> 'KVM: switch irq injection/acking data structures to irq_lock'
> which now does this:
> lock
> find
> unlock
> write
> I thought for a while that it might make sense to start small and just
> add in_range parameter for starters ...
> However, I just realised that this only works because devices are not
> added or removed dynamically.
> The long term fix is to switch to SRCU for bus management. But if we
> need to do this for iosignalfd anyway, in_range removal becomes possible
> again.
> Short term it might be also possible to go back to keeping kvm lock
> across both find and read - since the lock is taken, we don't
> really win anything currently if we drop the lock earlier.
> Comments?

Can we just get iosignalfd merged for now as it is, then? Its not like
we cant patch the group/item code later to clean it up when the time is


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2009-06-25 13:31    [W:0.057 / U:1.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site