From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [RFC PATCH 1/6] kvm: add device control API Date: Thu, 21 Feb 2013 08:39:09 +0200 Message-ID: <20130221063909.GW3600@redhat.com> References: <20130221001437.GA29376@amt.cnet> <1361410132.31212.16@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, Christoffer Dall To: Scott Wood Return-path: Content-Disposition: inline In-Reply-To: <1361410132.31212.16@snotra> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Wed, Feb 20, 2013 at 07:28:52PM -0600, Scott Wood wrote: > 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. > If access to an attribute has a guest visible side effect you cannot use this interface for migration. This is exactly the point in favor of distinguish accesses that have side effects (COMMAND or whatever) and accesses that set/get attribute (SET|GET_ATTR). -- Gleb.