From kvm-owner@vger.kernel.org Mon Sep 26 01:21:36 2011 Return-path: Envelope-to: rlpowell@digitalkingdom.org Delivery-date: Mon, 26 Sep 2011 01:21:36 -0700 Received: from vger.kernel.org ([209.132.180.67]:44535) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1R86RO-0000k0-2a for rlpowell@digitalkingdom.org; Mon, 26 Sep 2011 01:21:36 -0700 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751375Ab1IZIV0 (ORCPT ); Mon, 26 Sep 2011 04:21:26 -0400 Received: from ozlabs.org ([203.10.76.45]:40960 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750975Ab1IZIV0 (ORCPT ); Mon, 26 Sep 2011 04:21:26 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id C8A7AB6F80; Mon, 26 Sep 2011 18:21:24 +1000 (EST) Date: Mon, 26 Sep 2011 17:51:44 +1000 From: David Gibson To: Stuart Yoder Cc: alex.williamson@redhat.com, Scott Wood , qemu-devel@nongnu.org, agraf@suse.de, kvm@vger.kernel.org, avi@redhat.com, anthony@codemonkey.ws, Benjamin Herrenschmidt Message-ID: <20110926075144.GT12286@yookeroo.fritz.box> Mail-Followup-To: Stuart Yoder , alex.williamson@redhat.com, Scott Wood , qemu-devel@nongnu.org, agraf@suse.de, kvm@vger.kernel.org, avi@redhat.com, anthony@codemonkey.ws, Benjamin Herrenschmidt References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Flag: YES X-Spam-Score: 5.8 (+++++) X-Spam_score: 5.8 X-Spam_score_int: 58 X-Spam_bar: +++++ X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote: > Based on the discussions over the last couple of weeks > I have updated the device fd file layout proposal and > tried to specify it a bit more formally. > > =============================================================== > > 1. Overview > > This specification describes the layout of device files > used in the context of vfio, which gives user space > direct access to I/O devices that have been bound to > vfio. > > When a device fd is opened and read, offset 0x0 contains > a fixed sized header followed by a number of variable length > records that describe different characteristics > of the device-- addressable regions, interrupts, etc. > > 0x0 +++ > | magic | u32 // identifies this as a vfio > device file > ++ and identifies the type of bus > | version | u32 // specifies the version of this > ++ > | flags | u32 // encodes any flags > ++ > | dev info record 0 | > | type | u32 // type of record > | rec_len | u32 // length in bytes of record > | | (including record header) > | flags | u32 // type specific flags > | ...content... | // record content, which could > ++ // include sub-records > | dev info record 1 | > ++ > | dev info record N | > ++ [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB 2.5 TAB_IN_FROM From starts with a tab -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Subject: [kvm] Re: [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files Content-Length: 3394 On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote: > Based on the discussions over the last couple of weeks > I have updated the device fd file layout proposal and > tried to specify it a bit more formally. > > =============================================================== > > 1. Overview > > This specification describes the layout of device files > used in the context of vfio, which gives user space > direct access to I/O devices that have been bound to > vfio. > > When a device fd is opened and read, offset 0x0 contains > a fixed sized header followed by a number of variable length > records that describe different characteristics > of the device-- addressable regions, interrupts, etc. > > 0x0 +-------------+-------------+ > | magic | u32 // identifies this as a vfio > device file > +---------------------------+ and identifies the type of bus > | version | u32 // specifies the version of this > +---------------------------+ > | flags | u32 // encodes any flags > +---------------------------+ > | dev info record 0 | > | type | u32 // type of record > | rec_len | u32 // length in bytes of record > | | (including record header) > | flags | u32 // type specific flags > | ...content... | // record content, which could > +---------------------------+ // include sub-records > | dev info record 1 | > +---------------------------+ > | dev info record N | > +---------------------------+ I really should have chimed in on this earlier, but I've been very busy. Um, not to put too fine a point on it, this is madness. Yes, it's very flexible and can thereby cover a very wide range of cases. But it's much, much too complex. Userspace has to parse a complex, multilayered data structure, with variable length elements just to get an address at which to do IO. I can pretty much guarantee that if we went with this, most userspace programs using this interface would just ignore this metadata and directly map the offsets at which they happen to know the kernel will put things for the type of device they care about. _At least_ for PCI, I think the original VFIO layout of each BAR at a fixed, well known offset is much better. Despite its limitations, just advertising a "device type" ID which describes one of a few fixed layouts would be preferable to this. I'm still hoping, that we can do a bit better than that. But we should try really hard to at the very least force the metadata into a simple array of resources each with a fixed size record describing it, even if it means some space wastage with occasionally-used fields. Anything more complex than that and userspace is just never going to use it properly. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From kvm-owner@vger.kernel.org Mon Sep 26 05:27:46 2011 Return-path: Envelope-to: rlpowell@digitalkingdom.org Delivery-date: Mon, 26 Sep 2011 05:27:46 -0700 Received: from vger.kernel.org ([209.132.180.67]:59433) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1R8AHa-0002b4-Kl for rlpowell@digitalkingdom.org; Mon, 26 Sep 2011 05:27:46 -0700 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753477Ab1IZM1g convert rfc822-to-quoted-printable (ORCPT ); Mon, 26 Sep 2011 08:27:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23480 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753205Ab1IZM1g (ORCPT ); Mon, 26 Sep 2011 08:27:36 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8QCRZB5022043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Sep 2011 08:27:36 -0400 Received: from dhcp-27-148.brq.redhat.com (dhcp-27-148.brq.redhat.com [10.34.27.148]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8QCRYSs023017; Mon, 26 Sep 2011 08:27:35 -0400 Message-ID: <4E806FB6.1050301@redhat.com> Date: Mon, 26 Sep 2011 14:27:34 +0200 From: =?ISO-8859-2?Q?Luk=E1=B9_Doktor?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Lucas Meneghel Rodrigues CC: kvm@vger.kernel.org, mjenner@redhat.com References: <1316820461-14259-1-git-send-email-lmr@redhat.com> In-Reply-To: <1316820461-14259-1-git-send-email-lmr@redhat.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Flag: YES X-Spam-Score: 5.8 (+++++) X-Spam_score: 5.8 X-Spam_score_int: 58 X-Spam_bar: +++++ X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, vm.screendump() doesn't have parameter 'debug'. So you should either add debug parameter to kvm_vm.py or remove this parameter (and perhaps add debug=False into kvm_vm.py). [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB 2.5 TAB_IN_FROM From starts with a tab -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Subject: [kvm] Re: [PATCH] virt.virt_env_process: Abstract screenshot production Content-Length: 2292 Hi, vm.screendump() doesn't have parameter 'debug'. So you should either add debug parameter to kvm_vm.py or remove this=20 parameter (and perhaps add debug=3DFalse into kvm_vm.py). Regards, Luk=E1=B9 Dne 24.9.2011 01:27, Lucas Meneghel Rodrigues napsal(a): > In order to ease work with other virtualization types, > make virt_env_process to call vm.screendump() instead > of vm.monitor.screendump(). > > Signed-off-by: Lucas Meneghel Rodrigues > --- > client/virt/virt_env_process.py | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/client/virt/virt_env_process.py b/client/virt/virt_env_p= rocess.py > index 789fa01..9999a2e 100644 > --- a/client/virt/virt_env_process.py > +++ b/client/virt/virt_env_process.py > @@ -110,7 +110,7 @@ def preprocess_vm(test, params, env, name): > scrdump_filename =3D os.path.join(test.debugdir, "pre_%s.ppm" %= name) > try: > if vm.monitor and params.get("take_regular_screendumps") =3D= =3D "yes": > - vm.monitor.screendump(scrdump_filename, debug=3DFalse) > + vm.screendump(scrdump_filename, debug=3DFalse) > except kvm_monitor.MonitorError, e: > logging.warn(e) > > @@ -151,7 +151,7 @@ def postprocess_vm(test, params, env, name): > scrdump_filename =3D os.path.join(test.debugdir, "post_%s.ppm" = % name) > try: > if vm.monitor and params.get("take_regular_screenshots") =3D= =3D "yes": > - vm.monitor.screendump(scrdump_filename, debug=3DFalse) > + vm.screendump(scrdump_filename, debug=3DFalse) > except kvm_monitor.MonitorError, e: > logging.warn(e) > > @@ -460,7 +460,7 @@ def _take_screendumps(test, params, env): > if not vm.is_alive(): > continue > try: > - vm.monitor.screendump(filename=3Dtemp_filename, debu= g=3DFalse) > + vm.screendump(filename=3Dtemp_filename, debug=3DFals= e) > except kvm_monitor.MonitorError, e: > logging.warn(e) > continue -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From kvm-owner@vger.kernel.org Mon Sep 26 06:10:53 2011 Return-path: Envelope-to: rlpowell@digitalkingdom.org Delivery-date: Mon, 26 Sep 2011 06:10:53 -0700 Received: from vger.kernel.org ([209.132.180.67]:54264) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1R8AxI-0003L9-5F for rlpowell@digitalkingdom.org; Mon, 26 Sep 2011 06:10:53 -0700 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751166Ab1IZNKm convert rfc822-to-quoted-printable (ORCPT ); Mon, 26 Sep 2011 09:10:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63969 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750Ab1IZNKl (ORCPT ); Mon, 26 Sep 2011 09:10:41 -0400 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.14.4/8.14.4) with ESMTP id p8QDAfxT007808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Sep 2011 09:10:41 -0400 Received: from freedom.local (vpn-11-88.rdu.redhat.com [10.11.11.88]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8QDAdJC000970; Mon, 26 Sep 2011 09:10:40 -0400 Message-ID: <4E8079CF.6000508@redhat.com> Date: Mon, 26 Sep 2011 10:10:39 -0300 From: Lucas Meneghel Rodrigues User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?ISO-8859-2?Q?Luk=E1=B9_Doktor?= CC: kvm@vger.kernel.org, mjenner@redhat.com References: <1316820461-14259-1-git-send-email-lmr@redhat.com> <4E806FB6.1050301@redhat.com> In-Reply-To: <4E806FB6.1050301@redhat.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Flag: YES X-Spam-Score: 5.8 (+++++) X-Spam_score: 5.8 X-Spam_score_int: 58 X-Spam_bar: +++++ X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 09/26/2011 09:27 AM, Lukáš Doktor wrote: > Hi, > > vm.screendump() doesn't have parameter 'debug'. My fault, the screendump method on both qmp and human monitors does take this parameter, and since the implementation on virt_env_process was using the monitor method directly, I forgot to add the param to screendump. [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB 2.5 TAB_IN_FROM From starts with a tab -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Subject: [kvm] Re: [PATCH] virt.virt_env_process: Abstract screenshot production Content-Length: 2597 On 09/26/2011 09:27 AM, Luk=E1=B9 Doktor wrote: > Hi, > > vm.screendump() doesn't have parameter 'debug'. My fault, the screendump method on both qmp and human monitors does tak= e=20 this parameter, and since the implementation on virt_env_process was=20 using the monitor method directly, I forgot to add the param to screend= ump. It's fixed now. debug=3DTrue by default, the only place where it is Fal= se=20 is during screendump thread (to avoid polluting the logs). https://github.com/autotest/autotest/commit/49b1d9b65ab0061aaf631c19620= 987bc59592af6 > So you should either add debug parameter to kvm_vm.py or remove this > parameter (and perhaps add debug=3DFalse into kvm_vm.py). > > Regards, > Luk=E1=B9 > > > Dne 24.9.2011 01:27, Lucas Meneghel Rodrigues napsal(a): >> In order to ease work with other virtualization types, >> make virt_env_process to call vm.screendump() instead >> of vm.monitor.screendump(). >> >> Signed-off-by: Lucas Meneghel Rodrigues >> --- >> client/virt/virt_env_process.py | 6 +++--- >> 1 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/client/virt/virt_env_process.py >> b/client/virt/virt_env_process.py >> index 789fa01..9999a2e 100644 >> --- a/client/virt/virt_env_process.py >> +++ b/client/virt/virt_env_process.py >> @@ -110,7 +110,7 @@ def preprocess_vm(test, params, env, name): >> scrdump_filename =3D os.path.join(test.debugdir, "pre_%s.ppm" % name= ) >> try: >> if vm.monitor and params.get("take_regular_screendumps") =3D=3D "yes= ": >> - vm.monitor.screendump(scrdump_filename, debug=3DFalse) >> + vm.screendump(scrdump_filename, debug=3DFalse) >> except kvm_monitor.MonitorError, e: >> logging.warn(e) >> >> @@ -151,7 +151,7 @@ def postprocess_vm(test, params, env, name): >> scrdump_filename =3D os.path.join(test.debugdir, "post_%s.ppm" % nam= e) >> try: >> if vm.monitor and params.get("take_regular_screenshots") =3D=3D "yes= ": >> - vm.monitor.screendump(scrdump_filename, debug=3DFalse) >> + vm.screendump(scrdump_filename, debug=3DFalse) >> except kvm_monitor.MonitorError, e: >> logging.warn(e) >> >> @@ -460,7 +460,7 @@ def _take_screendumps(test, params, env): >> if not vm.is_alive(): >> continue >> try: >> - vm.monitor.screendump(filename=3Dtemp_filename, debug=3DFalse) >> + vm.screendump(filename=3Dtemp_filename, debug=3DFalse) >> except kvm_monitor.MonitorError, e: >> logging.warn(e) >> continue > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From kvm-owner@vger.kernel.org Mon Sep 26 06:20:54 2011 Return-path: Envelope-to: rlpowell@digitalkingdom.org Delivery-date: Mon, 26 Sep 2011 06:20:54 -0700 Received: from vger.kernel.org ([209.132.180.67]:33207) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1R8B6x-0003Qk-QX for rlpowell@digitalkingdom.org; Mon, 26 Sep 2011 06:20:54 -0700 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751609Ab1IZNUl convert rfc822-to-quoted-printable (ORCPT ); Mon, 26 Sep 2011 09:20:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7700 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751257Ab1IZNUl (ORCPT ); Mon, 26 Sep 2011 09:20:41 -0400 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.14.4/8.14.4) with ESMTP id p8QDKeDR025039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Sep 2011 09:20:41 -0400 Received: from dhcp-27-148.brq.redhat.com (dhcp-27-148.brq.redhat.com [10.34.27.148]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8QDKd8L004779; Mon, 26 Sep 2011 09:20:39 -0400 Message-ID: <4E807C26.7060101@redhat.com> Date: Mon, 26 Sep 2011 15:20:38 +0200 From: =?ISO-8859-2?Q?Luk=E1=B9_Doktor?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Lucas Meneghel Rodrigues CC: kvm@vger.kernel.org, mjenner@redhat.com References: <1316820461-14259-1-git-send-email-lmr@redhat.com> <4E806FB6.1050301@redhat.com> <4E8079CF.6000508@redhat.com> In-Reply-To: <4E8079CF.6000508@redhat.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Flag: YES X-Spam-Score: 5.8 (+++++) X-Spam_score: 5.8 X-Spam_score_int: 58 X-Spam_bar: +++++ X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dne 26.9.2011 15:10, Lucas Meneghel Rodrigues napsal(a): > On 09/26/2011 09:27 AM, Lukáš Doktor wrote: >> Hi, >> >> vm.screendump() doesn't have parameter 'debug'. > > My fault, the screendump method on both qmp and human monitors does > take this parameter, and since the implementation on virt_env_process > was using the monitor method directly, I forgot to add the param to > screendump. > > It's fixed now. debug=True by default, the only place where it is > False is during screendump thread (to avoid polluting the logs). > > https://github.com/autotest/autotest/commit/49b1d9b65ab0061aaf631c19620987bc59592af6 > We used the same fix ;-) [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB 2.5 TAB_IN_FROM From starts with a tab -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Subject: [kvm] Re: [PATCH] virt.virt_env_process: Abstract screenshot production Content-Length: 2808 Dne 26.9.2011 15:10, Lucas Meneghel Rodrigues napsal(a): > On 09/26/2011 09:27 AM, Luk=E1=B9 Doktor wrote: >> Hi, >> >> vm.screendump() doesn't have parameter 'debug'. > > My fault, the screendump method on both qmp and human monitors does=20 > take this parameter, and since the implementation on virt_env_process= =20 > was using the monitor method directly, I forgot to add the param to=20 > screendump. > > It's fixed now. debug=3DTrue by default, the only place where it is=20 > False is during screendump thread (to avoid polluting the logs). > > https://github.com/autotest/autotest/commit/49b1d9b65ab0061aaf631c196= 20987bc59592af6=20 > We used the same fix ;-) Acked-by: Luk=E1=B9 Doktor > >> So you should either add debug parameter to kvm_vm.py or remove this >> parameter (and perhaps add debug=3DFalse into kvm_vm.py). >> >> Regards, >> Luk=E1=B9 >> >> >> Dne 24.9.2011 01:27, Lucas Meneghel Rodrigues napsal(a): >>> In order to ease work with other virtualization types, >>> make virt_env_process to call vm.screendump() instead >>> of vm.monitor.screendump(). >>> >>> Signed-off-by: Lucas Meneghel Rodrigues >>> --- >>> client/virt/virt_env_process.py | 6 +++--- >>> 1 files changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/client/virt/virt_env_process.py >>> b/client/virt/virt_env_process.py >>> index 789fa01..9999a2e 100644 >>> --- a/client/virt/virt_env_process.py >>> +++ b/client/virt/virt_env_process.py >>> @@ -110,7 +110,7 @@ def preprocess_vm(test, params, env, name): >>> scrdump_filename =3D os.path.join(test.debugdir, "pre_%s.ppm" % nam= e) >>> try: >>> if vm.monitor and params.get("take_regular_screendumps") =3D=3D "ye= s": >>> - vm.monitor.screendump(scrdump_filename, debug=3DFalse) >>> + vm.screendump(scrdump_filename, debug=3DFalse) >>> except kvm_monitor.MonitorError, e: >>> logging.warn(e) >>> >>> @@ -151,7 +151,7 @@ def postprocess_vm(test, params, env, name): >>> scrdump_filename =3D os.path.join(test.debugdir, "post_%s.ppm" % na= me) >>> try: >>> if vm.monitor and params.get("take_regular_screenshots") =3D=3D "ye= s": >>> - vm.monitor.screendump(scrdump_filename, debug=3DFalse) >>> + vm.screendump(scrdump_filename, debug=3DFalse) >>> except kvm_monitor.MonitorError, e: >>> logging.warn(e) >>> >>> @@ -460,7 +460,7 @@ def _take_screendumps(test, params, env): >>> if not vm.is_alive(): >>> continue >>> try: >>> - vm.monitor.screendump(filename=3Dtemp_filename, debug=3DFalse) >>> + vm.screendump(filename=3Dtemp_filename, debug=3DFalse) >>> except kvm_monitor.MonitorError, e: >>> logging.warn(e) >>> continue >> > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From kvm-owner@vger.kernel.org Mon Sep 26 10:43:06 2011 Return-path: Envelope-to: rlpowell@digitalkingdom.org Delivery-date: Mon, 26 Sep 2011 10:43:06 -0700 Received: from vger.kernel.org ([209.132.180.67]:48729) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1R8FCi-0006LV-4A for rlpowell@digitalkingdom.org; Mon, 26 Sep 2011 10:43:06 -0700 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752207Ab1IZRmh (ORCPT ); Mon, 26 Sep 2011 13:42:37 -0400 Received: from mail-ey0-f174.google.com ([209.85.215.174]:35093 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751990Ab1IZRme (ORCPT ); Mon, 26 Sep 2011 13:42:34 -0400 Received: by mail-ey0-f174.google.com with SMTP id 28so3816098eya.19 for ; Mon, 26 Sep 2011 10:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=r2zac7mXGvV5fLf5CGNXrIYXewr5BsjWKL0qBt/1FXA=; b=YOnzpfBxKNjdc9+6ceg2mQr6yjerrr91HhR+2wSUcdbk7sKdy74S4hqtimq1J5e49h 0sRR+MXyFosGACqwViCk+quPMAn2kxEIRQSX5XB3q8BVi22dmriLmyw5evfY6Jn5rhL+ hJnHqnwjpniRU/rvQjZhH6QcdHAjFZBXzcasU= Received: by 10.14.17.97 with SMTP id i73mr1918409eei.50.1317058953410; Mon, 26 Sep 2011 10:42:33 -0700 (PDT) Received: from localhost.localdomain (bzq-79-180-204-136.red.bezeqint.net. [79.180.204.136]) by mx.google.com with ESMTPS id u14sm62382858eeh.1.2011.09.26.10.42.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 10:42:32 -0700 (PDT) From: Sasha Levin To: linux-kernel@vger.kernel.org Cc: Sasha Levin , Rusty Russell , "Michael S. Tsirkin" , virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, kvm@vger.kernel.org Date: Mon, 26 Sep 2011 20:41:09 +0300 Message-Id: <1317058869-19276-2-git-send-email-levinsasha928@gmail.com> X-Mailer: git-send-email 1.7.6.1 In-Reply-To: <1317058869-19276-1-git-send-email-levinsasha928@gmail.com> References: <1317058869-19276-1-git-send-email-levinsasha928@gmail.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Flag: YES X-Spam-Score: 5.9 (+++++) X-Spam_score: 5.9 X-Spam_score_int: 59 X-Spam_bar: +++++ X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: This patch prevents a NULL dereference when the user has passed a length longer than an actual buffer to virtio-net. Cc: Rusty Russell Cc: "Michael S. Tsirkin" Cc: virtualization@lists.linux-foundation.org Cc: netdev@vger.kernel.org Cc: kvm@vger.kernel.org Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) [...] Content analysis details: (5.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB 2.5 TAB_IN_FROM From starts with a tab 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (levinsasha928[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service Subject: [kvm] [PATCH 2/2] virtio-net: Prevent NULL dereference Content-Length: 1053 This patch prevents a NULL dereference when the user has passed a length longer than an actual buffer to virtio-net. Cc: Rusty Russell Cc: "Michael S. Tsirkin" Cc: virtualization@lists.linux-foundation.org Cc: netdev@vger.kernel.org Cc: kvm@vger.kernel.org Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 64e0717..8d32c1e 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -198,7 +198,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi, len -= copy; offset += copy; - while (len) { + while (len && page) { set_skb_frag(skb, page, offset, &len); page = (struct page *)page->private; offset = 0; -- 1.7.6.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From kvm-owner@vger.kernel.org Mon Sep 26 11:44:37 2011 Return-path: Envelope-to: rlpowell@digitalkingdom.org Delivery-date: Mon, 26 Sep 2011 11:44:37 -0700 Received: from vger.kernel.org ([209.132.180.67]:34307) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1R8GAH-0006x6-NN for rlpowell@digitalkingdom.org; Mon, 26 Sep 2011 11:44:37 -0700 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752685Ab1IZSoF (ORCPT ); Mon, 26 Sep 2011 14:44:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42333 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752375Ab1IZSoC (ORCPT ); Mon, 26 Sep 2011 14:44:02 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8QIhbrd001011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 14:43:37 -0400 Received: from redhat.com (vpn-200-93.tlv.redhat.com [10.35.200.93]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id p8QIhXd5025868; Mon, 26 Sep 2011 14:43:34 -0400 Date: Mon, 26 Sep 2011 21:44:45 +0300 From: "Michael S. Tsirkin" To: Sasha Levin Cc: linux-kernel@vger.kernel.org, Rusty Russell , virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, kvm@vger.kernel.org Message-ID: <20110926184445.GA22278@redhat.com> References: <1317058869-19276-1-git-send-email-levinsasha928@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1317058869-19276-1-git-send-email-levinsasha928@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Flag: YES X-Spam-Score: 5.8 (+++++) X-Spam_score: 5.8 X-Spam_score_int: 58 X-Spam_bar: +++++ X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Mon, Sep 26, 2011 at 08:41:08PM +0300, Sasha Levin wrote: > This patch verifies that the length of a buffer stored in a linked list > of pages is small enough to fit into a skb. > > If the size is larger than a max size of a skb, it means that we shouldn't > go ahead building skbs anyway since we won't be able to send the buffer as > the user requested. > > Cc: Rusty Russell > Cc: "Michael S. Tsirkin" > Cc: virtualization@lists.linux-foundation.org > Cc: netdev@vger.kernel.org > Cc: kvm@vger.kernel.org > Signed-off-by: Sasha Levin [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB 2.5 TAB_IN_FROM From starts with a tab -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Subject: [kvm] Re: [PATCH 1/2] virtio-net: Verify page list size before fitting into skb Content-Length: 2095 On Mon, Sep 26, 2011 at 08:41:08PM +0300, Sasha Levin wrote: > This patch verifies that the length of a buffer stored in a linked list > of pages is small enough to fit into a skb. > > If the size is larger than a max size of a skb, it means that we shouldn't > go ahead building skbs anyway since we won't be able to send the buffer as > the user requested. > > Cc: Rusty Russell > Cc: "Michael S. Tsirkin" > Cc: virtualization@lists.linux-foundation.org > Cc: netdev@vger.kernel.org > Cc: kvm@vger.kernel.org > Signed-off-by: Sasha Levin Interesting. This is a theoretical issue, correct? Not a crash you actually see. This crash would mean device is giving us packets that are way too large. Avoiding crashes even in the face of a misbehaved device is a good idea, but should we print a diagnostic to a system log? Maybe rate-limited or print once to avoid filling up the disk. Other places in driver print with pr_debug I'm not sure that's right but better than nothing. > --- > drivers/net/virtio_net.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 0c7321c..64e0717 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -165,6 +165,9 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi, > unsigned int copy, hdr_len, offset; > char *p; > > + if (len > MAX_SKB_FRAGS * PAGE_SIZE) unlikely()? Also, this seems too aggressive: at this point len includes the header and the linear part. The right place for this test is probably where we fill in the frags, just before while (len) The whole can only happen when mergeable buffers are disabled, right? > + return NULL; > + > p = page_address(page); > > /* copy small packet so we can reuse these pages for small data */ > -- > 1.7.6.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From kvm-owner@vger.kernel.org Mon Sep 26 11:10:13 2011 Return-path: Envelope-to: rlpowell@digitalkingdom.org Delivery-date: Mon, 26 Sep 2011 11:10:14 -0700 Received: from vger.kernel.org ([209.132.180.67]:33116) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1R8Fcz-0006hb-5w for rlpowell@digitalkingdom.org; Mon, 26 Sep 2011 11:10:13 -0700 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751837Ab1IZSKA (ORCPT ); Mon, 26 Sep 2011 14:10:00 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:46759 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788Ab1IZSKA (ORCPT ); Mon, 26 Sep 2011 14:10:00 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p8QHjmki022568 for ; Mon, 26 Sep 2011 13:45:48 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8QI9wPs241230 for ; Mon, 26 Sep 2011 14:09:58 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8QI9vC3004808 for ; Mon, 26 Sep 2011 12:09:58 -0600 Received: from [9.65.169.63] (sig-9-65-169-63.mts.ibm.com [9.65.169.63]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p8QI9tfv004706; Mon, 26 Sep 2011 12:09:56 -0600 Message-ID: <4E80BFF3.8000907@us.ibm.com> Date: Mon, 26 Sep 2011 13:09:55 -0500 From: Anthony Liguori User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Avi Kivity CC: Jan Kiszka , Stefan Hajnoczi , Marcelo Tosatti , kvm , Kevin Wolf References: <4E78C42D.5030207@siemens.com> <20110921080600.GA9847@stefanha-thinkpad.localdomain> <4E80B50B.9000301@siemens.com> <4E80B55F.5020203@redhat.com> In-Reply-To: <4E80B55F.5020203@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Flag: YES X-Spam-Score: 5.8 (+++++) X-Spam_score: 5.8 X-Spam_score_int: 58 X-Spam_bar: +++++ X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 09/26/2011 12:24 PM, Avi Kivity wrote: > On 09/26/2011 08:23 PM, Jan Kiszka wrote: >> > >> > Perhaps qemu_eventfd() can be used in the future instead of an explicit >> > pipe. Then Linux will do eventfd while other OSes will fall back to >> > pipes. >> >> Basically simpler code, or does this also have runtime benefits? >> > > In corner cases, the completion can block on the write() with pipes, but not > eventfd. [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB 2.5 TAB_IN_FROM From starts with a tab -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Subject: [kvm] Re: [PATCH] qemu-kvm: Switch POSIX compat AIO implementation to upstream Content-Length: 970 On 09/26/2011 12:24 PM, Avi Kivity wrote: > On 09/26/2011 08:23 PM, Jan Kiszka wrote: >> > >> > Perhaps qemu_eventfd() can be used in the future instead of an explicit >> > pipe. Then Linux will do eventfd while other OSes will fall back to >> > pipes. >> >> Basically simpler code, or does this also have runtime benefits? >> > > In corner cases, the completion can block on the write() with pipes, but not > eventfd. The pipe is O_NONBLOCK and the only thing the caller cares about is whether there is *some* data in the PIPE so it can happily ignore EAGAIN. So the pipe implementation never blocks on write() either. It may require multiple reads to drain the queue though whereas eventfd would only require a single read to drain the queue. Regards, Anthony Liguori > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html