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). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
