From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: Using PCI config space to indicate config location Date: Wed, 17 Oct 2012 00:22:25 +1030 Message-ID: <87d30iplra.fsf@rustcorp.com.au> References: <874nmajcmj.fsf@codemonkey.ws> <87y5jhpuu2.fsf@rustcorp.com.au> <20121010083033.GA4799@redhat.com> <87bog9957l.fsf@rustcorp.com.au> <20121011102333.GA5552@redhat.com> <87391k7icv.fsf@rustcorp.com.au> <20121012093330.GA32014@redhat.com> <871uh4587d.fsf@rustcorp.com.au> <20121012100231.GA32517@redhat.com> <87k3uqpngi.fsf@rustcorp.com.au> <20121016133045.GA12766@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , qemu-devel , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org To: "Michael S. Tsirkin" Return-path: Received: from ozlabs.org ([203.10.76.45]:50613 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753870Ab2JPNx1 (ORCPT ); Tue, 16 Oct 2012 09:53:27 -0400 In-Reply-To: <20121016133045.GA12766@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: "Michael S. Tsirkin" writes: > On Tue, Oct 16, 2012 at 11:45:41PM +1030, Rusty Russell wrote: >> "Michael S. Tsirkin" writes: >> I was assuming the implementation would keep two complete copies of the >> config space: writes go to the scratch version, which gets copied to the >> master version upon latch write. > > Yes but config space has some host modifiable registers too. > So host needs to be careful to avoid overwriting these. > > If accesses have side effects that of course breaks too ... Yes. > >> But I do wonder if we should just skip this for now, since we don't >> have any immediate need. >> >> Cheers, >> Rusty. > > MAC setting from guest needs this right now, no? Ah, I missed that in my table: Driver Config Device changes Driver writes... after init? net Y Y N N block Y Y Y Y console Y Y N N rng N N N N balloon Y Y Y Y scsi Y N Y N 9p Y N N N First line should be: net Y Y Y N So we could add a new cvq command (eg. #define VIRTIO_NET_CTRL_MAC_SET 1) and a VIRTIO_NET_F_CVQ_MAC_SET feature. Or go ahead with the latching scheme (which doesn't really help other busses). Cheers, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO7aO-00036P-9p for qemu-devel@nongnu.org; Tue, 16 Oct 2012 09:53:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TO7aK-0003Jp-7m for qemu-devel@nongnu.org; Tue, 16 Oct 2012 09:53:32 -0400 Received: from ozlabs.org ([203.10.76.45]:51671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO7aJ-0003Ja-Sd for qemu-devel@nongnu.org; Tue, 16 Oct 2012 09:53:28 -0400 From: Rusty Russell In-Reply-To: <20121016133045.GA12766@redhat.com> References: <874nmajcmj.fsf@codemonkey.ws> <87y5jhpuu2.fsf@rustcorp.com.au> <20121010083033.GA4799@redhat.com> <87bog9957l.fsf@rustcorp.com.au> <20121011102333.GA5552@redhat.com> <87391k7icv.fsf@rustcorp.com.au> <20121012093330.GA32014@redhat.com> <871uh4587d.fsf@rustcorp.com.au> <20121012100231.GA32517@redhat.com> <87k3uqpngi.fsf@rustcorp.com.au> <20121016133045.GA12766@redhat.com> Date: Wed, 17 Oct 2012 00:22:25 +1030 Message-ID: <87d30iplra.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Using PCI config space to indicate config location List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , qemu-devel , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org "Michael S. Tsirkin" writes: > On Tue, Oct 16, 2012 at 11:45:41PM +1030, Rusty Russell wrote: >> "Michael S. Tsirkin" writes: >> I was assuming the implementation would keep two complete copies of the >> config space: writes go to the scratch version, which gets copied to the >> master version upon latch write. > > Yes but config space has some host modifiable registers too. > So host needs to be careful to avoid overwriting these. > > If accesses have side effects that of course breaks too ... Yes. > >> But I do wonder if we should just skip this for now, since we don't >> have any immediate need. >> >> Cheers, >> Rusty. > > MAC setting from guest needs this right now, no? Ah, I missed that in my table: Driver Config Device changes Driver writes... after init? net Y Y N N block Y Y Y Y console Y Y N N rng N N N N balloon Y Y Y Y scsi Y N Y N 9p Y N N N First line should be: net Y Y Y N So we could add a new cvq command (eg. #define VIRTIO_NET_CTRL_MAC_SET 1) and a VIRTIO_NET_F_CVQ_MAC_SET feature. Or go ahead with the latching scheme (which doesn't really help other busses). Cheers, Rusty.