From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [RFC PATCH 1/6] kvm: add device control API Date: Wed, 20 Feb 2013 19:28:52 -0600 Message-ID: <1361410132.31212.16@snotra> References: <20130221001437.GA29376@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Gleb Natapov , Alexander Graf , , , Christoffer Dall To: Marcelo Tosatti Return-path: In-Reply-To: <20130221001437.GA29376@amt.cnet> (from mtosatti@redhat.com on Wed Feb 20 18:14:37 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 02/20/2013 06:14:37 PM, Marcelo Tosatti wrote: > On Wed, Feb 20, 2013 at 05:53:20PM -0600, Scott Wood wrote: > > >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. When the attribute is a device register, the hardware documentation takes care of that. Otherwise, the semantics are documented in the device-specific documentation -- which can include restricting when the access is allowed. Same as with any other interface documentation. I suppose mpic.txt could use an additional statement that KVM_DEV_MPIC_GRP_REGISTER performs an access as if it were performed by the guest. > Locking versus currently executing VCPUs, for another (see how > KVM_SET_IRQ's RCU usage, for instance, that is something should be > shared). If you mean kvm_set_irq() in irq_comm.c, that's only relevant when you have a GSI routing table, which this patchset doesn't. Assuming we end up having a routing table to support irqfd, we still can't share the code as is, since it's APIC-specific. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Thu, 21 Feb 2013 01:28:52 +0000 Subject: Re: [RFC PATCH 1/6] kvm: add device control API Message-Id: <1361410132.31212.16@snotra> List-Id: References: <20130221001437.GA29376@amt.cnet> In-Reply-To: <20130221001437.GA29376@amt.cnet> (from mtosatti@redhat.com on Wed Feb 20 18:14:37 2013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Marcelo Tosatti Cc: Gleb Natapov , Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, Christoffer Dall On 02/20/2013 06:14:37 PM, Marcelo Tosatti wrote: > On Wed, Feb 20, 2013 at 05:53:20PM -0600, Scott Wood wrote: > > >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. When the attribute is a device register, the hardware documentation takes care of that. Otherwise, the semantics are documented in the device-specific documentation -- which can include restricting when the access is allowed. Same as with any other interface documentation. I suppose mpic.txt could use an additional statement that KVM_DEV_MPIC_GRP_REGISTER performs an access as if it were performed by the guest. > Locking versus currently executing VCPUs, for another (see how > KVM_SET_IRQ's RCU usage, for instance, that is something should be > shared). If you mean kvm_set_irq() in irq_comm.c, that's only relevant when you have a GSI routing table, which this patchset doesn't. Assuming we end up having a routing table to support irqfd, we still can't share the code as is, since it's APIC-specific. -Scott