From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic. Date: Fri, 07 Sep 2012 08:30:55 +0930 Message-ID: <874nnaiwns.fsf@rustcorp.com.au> References: <877gsia8rm.fsf@rustcorp.com.au> <87627y3p1r.fsf@rustcorp.com.au> <87ipbtj77o.fsf@rustcorp.com.au> <5048B7A3.9040507@redhat.com> <5048BE36.40105@redhat.com> <5048C2DA.4050104@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Graf , Rusty Russell , Christoffer Dall , "kvmarm\@lists.cs.columbia.edu" , kvm-devel To: Avi Kivity , Peter Maydell Return-path: Received: from ozlabs.org ([203.10.76.45]:49704 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755430Ab2IGAC0 (ORCPT ); Thu, 6 Sep 2012 20:02:26 -0400 In-Reply-To: <5048C2DA.4050104@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity writes: > On 09/06/2012 06:23 PM, Peter Maydell wrote: >> On 6 September 2012 16:16, Avi Kivity wrote: >>> (and the APIC, if treated as one-large-register) is 4k) >> >> ...so don't do that then. Trying to treat the whole APIC >> as a single "register" means you don't get any of the >> advantages of "does this kernel support this register?" >> etc. Is there some reason I'm not seeing why it would >> make sense to do it that way? > > It's just the easiest path forward. > > "one large register" is mainly useful if registers have > interdependencies. That doesn't exist in the APIC AFAIR, but it does > exist elsewhere. Another way to handle interdependencies is to defer > applying the changes until a KVM_RUN, and then evaluate them as a group. The other option is to implement KVM_SET_MULTI_REG. I have enough of an implmentation to show it's trivial, but it's needless complexity until/if we need it. Cheers, Rusty.