From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH RFC] virtio-pci: flexible configuration layout Date: Thu, 3 Nov 2011 15:30:16 +0200 Message-ID: <20111103133015.GL18296@redhat.com> References: <87wrbkvh3v.fsf@rustcorp.com.au> <20111101114542.GA13434@redhat.com> <1320150813.3847.24.camel@lappy> <20111101124223.GA14060@redhat.com> <8739e7uy87.fsf@rustcorp.com.au> <20111102233110.GA20289@redhat.com> <1320279543.31237.14.camel@lappy> <20111103103314.GA18296@redhat.com> <1320318591.29407.17.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Krishna Kumar , kvm@vger.kernel.org, Pawel Moll , Wang Sheng-Hui , Alexey Kardashevskiy , lkml - Kernel Mailing List , Jesse Barnes , virtualization@lists.linux-foundation.org, Christian Borntraeger , Amit Shah , Linus Torvalds To: Sasha Levin Return-path: Content-Disposition: inline In-Reply-To: <1320318591.29407.17.camel@lappy> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: kvm.vger.kernel.org > 2. Move device specific features into the device specific region. > Currently the features field is a mix between virtio-pci and device > specific features. A single feature field with bits partitioned to transport specific and device specific fields is a generic virtio thing. So there's relatively little to be gained from moving the device bits out. > I did more similar things in the spec suggestion I've sent, What lacked there is the motivation. I am aware of several issues that need to be addressed, as they block extending virtio going forward: - There's no place to put more transport registers. For MSIX I hacked around that with moving device config when a feature bit is set, but in hindsight this setup is fragile and is panful to extend any further. Splitting out device and transport helps. - PIO space is limited. We are wasting it on non data path configuration. There might also be a wish to have largish data in configuration space, like a 1024 byte ID field. - PIO is faster than MMIO on x86 KVM so we need to keep using it for data path on that architecture - Support architectures which have host/guest at different endian-ness. I addressed the first 3 and added capability infrastructure which we can use in the future to support the last one (by nature of using little endian format for capabilities). > could you > look at the second part for more ideas please? I saw the per-queue features - but I don't see how it will work really or what is the issue they solve. Any more ideas I missed? > -- > > Sasha.