qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS
Date: Tue, 2 Jul 2013 10:06:35 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

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.

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

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: pgppjzuerfceY.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]