On 07/02/2013 10:21 AM, Alexander Graf wrote: > > On 02.07.2013, at 02:06, David Gibson wrote: > >> On Thu, Jun 27, 2013 at 10:17:19PM +1000, Alexey Kardashevskiy wrote: >>> On 06/27/2013 09:47 PM, David Gibson wrote: >>>> On Thu, Jun 27, 2013 at 04:45:45PM +1000, Alexey Kardashevskiy wrote: >>>>> Currently XICS interrupt controller is not a QEMU device. As we are going >>>>> to support in-kernel emulated XICS which is a part of KVM, it make >>>>> sense not to extend the existing XICS and have multiple KVM stub functions >>>>> but to create yet another device and share pieces between fully emulated >>>>> XICS and in-kernel XICS. >>>> >>>> Hmm. So, I think changing the xics to the qdev/qom framework is a >>>> generally good idea. But I'm not convinced its a good idea to have >>>> different devices for the kernel and non-kernel xics. >>> >>> The idea came from Alex Graf, this is already done for openpic/openpic-kvm. >>> The normal practice is to move ioctls to KVM to KVM code and provide empty >>> stubs for non-KVM case. There were too many so having a separate xics-kvm >>> is kind of help. >>> >>> >>>> Won't that >>>> prevent migrating from a system with a kernel xics to one without, or >>>> vice versa? >>> >>> Mmm. Do we care much about that?... >> >> Enough to avoid making it impossible by design. > > We went that route with x86 too after lots of hassle trying to shoehorn the > in-kernel APIC into the emulation device. It's more hassle than gain.
At the moment it can be supported at no cost so next time I'll post it with matched vmsd. >>> At the moment it is not supported that as VMStateDescription have different >>> .name for xics and xics-kvm but easy to fix. And we do not pass a device to >>> vmstate_register so that must be it. >> >> Ok, if you can make the ids in the vmsd match, then that should be ok. > > I really just wouldn't bother too much about it. Sooner or later QEMU-XICS is > going to be a legacy and debug only option. -- Alexey