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

Benjamin Herrenschmidt
2013-03-06T02:48:33Z

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 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.