Re: RFC/patch portability: split kvm_vm_ioctl v3

Avi Kivity
2007-10-30T11:52:08Z

Carsten Otte wrote:
> I think we'll have to come up with a more modular approach later on:
> various aspects are of interest to various architectures and/or
> platforms. The generic kernel has CONFIG_FEATURE toggles for that.
> The portability patches are not intended to split kvm into components
> at this stage, I believe that is something that we will have to come
> up when actual ports are being integrated. In my optinion, a
> reasonable next-step refinement here would be to come up with a
> generic interrupt injection call that can inject an interrupt on any
> architecture and platform. After userspace has adopted to use that
> one, we can keep the old call for backward compatibility reasons in a
> deprecated state for some time before removing it.
> For now, my goal is to seperate what is generic in a way that it is a
> functionality that a portable user space program that uses kvm can
> expect to work the same way on all architectures and platforms.
>

We have to be careful not to force too much portability on the code.
After all, the instruction set is different and some of the hardware
philosophy is different. You will never be able to run the same guest
on different archs, or have exactly the same virtual devices. The
differences are real, and the goal is not portability at any cost; it is
to share as much as possible, but not more.

Architectures which have interrupt request lines that are edge-triggered
or level-triggered and emulate the interrupt controller in the kernel
can share the KVM_IRQ_LINE API in some way; architectures that don't
will need another method.

--
Any sufficiently difficult bug is indistinguishable from a feature.