From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wright Subject: Re: KVM devices assignment; PCIe AER? Date: Tue, 26 Oct 2010 16:05:52 -0700 Message-ID: <20101026230552.GA25455@sequoia.sous-sol.org> References: <20101026183733.GA17477@redhat.com> <20101026204208.GV25455@sequoia.sous-sol.org> <20101026221558.GZ25455@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chris Wright , Alex Williamson , "Michael S. Tsirkin" , kvm@vger.kernel.org To: Etienne Martineau Return-path: Received: from sous-sol.org ([216.99.217.87]:52971 "EHLO sequoia.sous-sol.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756625Ab0JZXGL (ORCPT ); Tue, 26 Oct 2010 19:06:11 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: * Etienne Martineau (etmartin101@gmail.com) wrote: > On Tue, 26 Oct 2010, Chris Wright wrote: > >Right, and adding more to the existing KVM code which we are hoping to > >push to legacy support mode doesn't sound like a great idea. > > I would totally agree with you if the alternative implementation to > this legacy mode would be available in a relatively short time > frame. I'm not sure about that? Depends on how quickly you can help whip it into shape ;) That's why I asked about how you were implementing, for example, the AER extended capability exposure. Capabilities are a problem for the current code (forget about extended capabilities, just regular capabilities). > >>In that context, do you think it's acceptable for KVM to be the > >>driver of the assigned devices? OR should we simply add the AER > >>logic into existing pci-stub and relay the information to user-space > >>through eventfd... > > > >I'm reluctant to add logic to pci-stub, but VFIO should be able to > >handle this directly. > > I agree that VFIO should be able to do the job. It would be great to see some effort on this. thanks, -chris