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

Marcelo Tosatti
2013-02-21T00:14:37Z

On Wed, Feb 20, 2013 at 05:53:20PM -0600, Scott Wood wrote:
> >Why exactly you need to set attributes Scott?
>
> That's best answered by looking at patch 6/6 and discussing the
> actual attributes that are defined so far.
>
> The need to set the base address of the registers is
> straightforward. When ARM added their special ioctl for this, we
> discussed it being eventually replaced with a more general API (in
> fact, that was the reason they put "ARM" in the name).
>
> Access to device registers was originally intended for debugging,
> and eventually migration. It turned out to also be very useful for
> injecting MSIs -- nothing special needed to be done. It Just
> Works(tm) the same way it does in hardware, with an MMIO write from
> a PCI device to a specific MPIC register. Again, irqfd may
> complicate this, but there's no need for QEMU-generated MSIs to have
> to take a circuitous path.
>
> Finally, there's the interrupt source attribute. Even if we get rid
> of that, we'll need MPIC-specific documentation on how to flatten
> the IRQ numberspace, and if we ever have a cascaded PIC situation
> things could get ugly since there's no way to identify a specific
> IRQ controller in KVM_IRQ_LINE.
>
> >Also related to this question is the point of avoiding the
> >implementation of devices to be spread across userspace and the kernel
> >(this is one point Avi brought up often). If the device emulation
> >is implemented entirely in the kernel, all is necessary are initial
> >values of device registers (and retrieval of those values later for
> >savevm/migration).
>
> MPIC emulation is entirely in the kernel with this patchset --
> though the register that lets you reset cores will likely need to be
> kicked back to QEMU.
>
> >It is then not necessary to set device attributes on a live guest and
> >deal with the complications associated with that.
>
> Which complications?
>
> -Scott

Semantics of individual attribute writes, for one.

Locking versus currently executing VCPUs, for another (see how
KVM_SET_IRQ's RCU usage, for instance, that is something should be
shared).