From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [kvmarm] [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses Date: Tue, 23 Oct 2012 13:00:14 +0200 Message-ID: <508678BE.4040508@siemens.com> References: <1350173065-35350-1-git-send-email-c.dall@virtualopensystems.com> <507F172D.2030802@suse.de> <20121017221022.GA4333@bloggs.ozlabs.ibm.com> <1350518331.4678.114.camel@pasglop> <508675FC.7090901@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Christoffer Dall , Benjamin Herrenschmidt , Paul Mackerras , Alexander Graf , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , kvm-ppc To: Peter Maydell Return-path: In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 2012-10-23 12:52, Peter Maydell wrote: > On 23 October 2012 11:48, Jan Kiszka wrote: >> The current irqchip API is like this: >> >> KVM_CREATE_IRQCHIP (without any parameters) >> ... >> KVM_CREATE_VCPU >> KVM_SET_IRQCHIP (or the other way around) >> ... >> KVM_RUN >> >> The arguments you cannot pass via KVM_CREATE_IRQCHIP - which is more >> like a "Hey, there will be an IRQ chip!" - could be passed via >> KVM_SET_IRQCHIP (it has 512 bytes space). Provided there are sane >> configuration defaults, at least after KVM_CREATE_VCPU, KVM_SET_IRQCHIP >> becomes optional. Then you don't need the a check on KVM_RUN. > > KVM_SET_IRQCHIP is the state load ioctl, right (companion to > KVM_GET_IRQCHIP)? It seems like a bit of an abuse to use that > for configuration rather than for migration/sync of state > with userspace... Depends on how reconfigurable your chip is. x86 also sends the mapping down this way, which happens to be guest configurable but is practically static. > > (For ARM we will just use the ONE_REG ABI for irqchip state > save/load anyway, so KVM_SET_IRQCHIP isn't relevant.) The less problems you should have using the SET interface to perform one-time configuration. BTW, I guess we will regret that one-reg ABI one day and have to introduce a multi-reg version again for hot-standby, i.e. continuous state migration. I know we also do this for c86 MSRs - that interface has the same limitation. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux