linux-kernel - Re: [PATCH] kvm: remove in_range from kvm_io

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jun 2009 18:31:44 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Gregory Haskins <ghaskins@...ell.com>
Cc:	avi@...hat.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	mtosatti@...hat.com, paulmck@...ux.vnet.ibm.com, markmc@...hat.com
Subject: Re: [PATCH] kvm: remove in_range from kvm_io_device

On Tue, Jun 23, 2009 at 11:21:53AM -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.
> >   
> 
> Sorry, not trying to be a PITA, but I liked your last suggestion better.  :(
> 
> I am thinking forward to when we want to use something smarter than a
> linear search (like rbtree/radix) for scaling the number of "devices"
> (really, virtio-rings) that we support.

in_range is broken for this anyway: you need more than a boolean
predicate to implement rbtree/radix

> The current device-count
> target is 512, which we will begin to rapidly consume as the in-kernel
> virtio work progresses.

That's a large number. I had in mind more like 4 virtio devices, for
starters: 1 for each virtqueue in net and block.

>  This proposed approach forces us into a
> potential O(256) algorithm in the hotpath (all MMIO/PIO exits will hit
> this, not just in-kernel users).  How would you address this?

Two ideas that come to mind:
- add addr/len fields to devices, use these to speed up lookup
- add a small cache that can be scanned first

In both cases, you first do a fast lookup, ask the device whether
it wants the transaction, then resort to linear scan if not

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/