Re: [RFC PATCH 1/6] kvm: add device control API

[Gleb Natapov <gleb@redhat.com>]

On Wed, Mar 06, 2013 at 01:48:33PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2013-02-13 at 23:49 -0600, Scott Wood wrote:
> > Currently, devices that are emulated inside KVM are configured in a
> > hardcoded manner based on an assumption that any given architecture
> > only has one way to do it.  If there's any need to access device state,
> > it is done through inflexible one-purpose-only IOCTLs (e.g.
> > KVM_GET/SET_LAPIC).  Defining new IOCTLs for every little thing is
> > cumbersome and depletes a limited numberspace.
> > 
> > This API provides a mechanism to instantiate a device of a certain
> > type, returning an ID that can be used to set/get attributes of the
> > device.  Attributes may include configuration parameters (e.g.
> > register base address), device state, operational commands, etc.  It
> > is similar to the ONE_REG API, except that it acts on devices rather
> > than vcpus.
> 
> Allright guys, let's take a break for a minute :-)
> 
> What you seem to be proposing is a whole new construct / API to create
> "device" objects with "attributes" as a way to avoid adding tons of
> ioctls to the VM.
> 
> Then you somewhat "coerce" behaviours (ie. methods) as side effects of
> setting some of those attributes, and create some kind of rigid API
> through which any kind of potential device "attribute" needs to be
> coerced through.
> 
> Essentially you are trying to re-invent encapsulation of kernel objects
> manipulated by userspace, we already have several mechanisms for doing
> just that and you are trying to add yet a new one :-)
> 
> What about instead using existing mechanisms for doing just that:
> 
> Make your "create device" return an anonymous file descriptor !
> 
That was faster that I predicted! :)

http://www.spinics.net/lists/kvm/msg86687.html last paragraph.

> That gives you everything ... private ioctl's which can do whatever the
> heck you want (attributes, methods, etc...), mmap, etc...
> 
> Guess what ? That's already what we do for various things like our
> in-kernel emulated iommu tables as far as I can remember.
> 
> If your problem is to avoid the bottleneck of having to deal with
> upstream maintainers for generic VM ioctls every time you add some new
> platform specific kernel "object" then this is probably a much better
> approach.
> 
> Cheers,
> Ben.
> 

--
			Gleb.