From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH v2 0/5] Extra capabilities for device assignment Date: Thu, 09 Dec 2010 09:17:02 -0700 Message-ID: <1291911422.2926.0.camel@x201> References: <20101203192343.3579.73722.stgit@s20.home> <20101206161810.4648.45658.stgit@s20.home> <4CFD108C.2060503@redhat.com> <1291653828.3319.26.camel@x201> <4CFD1761.7090405@redhat.com> <4D00F677.3000800@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , kvm@vger.kernel.org, ddutile@redhat.com, mst@redhat.com, chrisw@redhat.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17503 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753365Ab0LIQRE (ORCPT ); Thu, 9 Dec 2010 11:17:04 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9GH4Wn027951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Dec 2010 11:17:04 -0500 In-Reply-To: <4D00F677.3000800@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2010-12-09 at 17:32 +0200, Avi Kivity wrote: > On 12/09/2010 05:13 PM, Markus Armbruster wrote: > > Avi Kivity writes: > > > > > On 12/06/2010 06:43 PM, Alex Williamson wrote: > > >> On Mon, 2010-12-06 at 18:34 +0200, Avi Kivity wrote: > > >> > On 12/06/2010 06:21 PM, Alex Williamson wrote: > > >> > > v2: > > >> > > - Reimplement 2/5 to remove more cruft > > >> > > > > >> > > v1: > > >> > > > > >> > > Now that we've got PCI capabilities cleaned up and device assignment > > >> > > using them, we can add more capabilities to be guest visible. This > > >> > > adds minimal PCI Express, PCI-X, and Power Management, along with > > >> > > direct passthrough Vital Product Data and Vendor Specific capabilities. > > >> > > With this, devices like tg3, bnx2, vxge, and potentially quite a few > > >> > > others that didn't work previously should be happier. Thanks, > > >> > > > > >> > > > >> > Applied, thanks. EFAULT is not the best error return, though. > > >> > > >> Do you prefer EBUSY? Bad address seemed appropriate here, but I'm not > > >> attached to it. Feel free to change it, or I can send a follow-up. > > >> Thanks, > > > > > > EBUSY isn't descriptive either, but EFAULT is wrong, it's the syscall > > > equivalent of a SEGV, which hasn't happened here. How I hate errno.h. > > > > EEXIST? EINVAL? > > I guess EINVAL is best ("go read the source code"). > Patch sent. Thanks, Alex