From mboxrd@z Thu Jan 1 00:00:00 1970 From: Blue Swirl Subject: Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment Date: Tue, 28 Aug 2012 20:06:21 +0000 Message-ID: References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503C74DD.3020307@msgid.tls.msk.ru> <20120828172838.GD3661@redhat.com> <87fw76ak5l.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: "Michael S. Tsirkin" , Michael Tokarev , Jan Kiszka , Avi Kivity , Marcelo Tosatti , Alex Williamson , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mail-ob0-f174.google.com ([209.85.214.174]:63525 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752716Ab2H1UGm (ORCPT ); Tue, 28 Aug 2012 16:06:42 -0400 Received: by obbuo13 with SMTP id uo13so11336383obb.19 for ; Tue, 28 Aug 2012 13:06:41 -0700 (PDT) In-Reply-To: <87fw76ak5l.fsf@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori wrote: > Blue Swirl writes: > >> On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin wrote: >>> On Tue, Aug 28, 2012 at 05:01:55PM +0000, Blue Swirl wrote: >>>> On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev wrote: >>>> > On 27.08.2012 22:56, Blue Swirl wrote: >>>> > [] >>>> >>> +static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr) >>>> >>> +{ >>>> >>> + AssignedDevRegion *d = opaque; >>>> >>> + uint8_t *in = d->u.r_virtbase + addr; >>>> >> >>>> >> Don't perform arithmetic with void pointers. >>>> > >>>> > There are a few places in common qemu code which does this for a very >>>> > long time. So I guess it is safe now. >>>> >>>> It's a non-standard GCC extension. >>> >>> So? We use many other GCC extensions. grep for typeof. >> >> Dependencies should not be introduced trivially. In this case, it's >> pretty easy to avoid void pointer arithmetic as Jan's next version >> shows. > > The standard is vague with respect void arithmetic. Most compilers > allow it. A very good analysis of the standard can be found below. > > http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c The analysis would seem to show that arithmetic may be acceptable, but it doesn't say that void pointers must be treated like char pointers. In my view, this would make sense: char *cptr; void *vptr; Since cptr++; is equivalent to cptr = (char *)((uintptr_t)cptr + sizeof(*cptr)); therefore vptr++; should be equivalent to vptr = (void *)((uintptr_t)vptr + sizeof(*vptr)); That is, vptr++ should be equivalent to vptr += 0 because sizeof(void) should be 0 if allowed. > > BTW: can we please stop arguing about C standards. If we currently are > using something in QEMU that's supported by clang and GCC, it's fine and > we ought to continue using it. > > The reserved names actually did bite us when porting to a new platform. > But the only requirement for C extensions ought to be reasonable support > in GCC and clang. > > I don't care at all about supporting proprietary compilers. We also don't have crowds banging doors with their money bags with a need for such support. > > Regards, > > Anthony Liguori > >> >>> >>> Is there a work in progress to build GCC with visual studio? >>> If yes what are the chances KVM device assignment >>> will work on windows? >> >> IIRC there was really a project to use KVM on Windows and another >> project to build QEMU with MSVC. >> >>> >>> Look QEMU codebase is what it is. Unless you rework all existing >>> code to confirm to your taste, I do not see why you NACK valid new code >>> unless it confirms to same. >> >> Yes, I'd be happy to fix the style with huge patches at once. But our >> fearless leader does not agree, so we are stuck with the codebase >> being what it is until it is fixed one step at a time. >> >>> >>>> > >>>> > /mjt >> -- >> 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6S3l-0000Oc-0Z for qemu-devel@nongnu.org; Tue, 28 Aug 2012 16:06:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6S3e-0003cD-U8 for qemu-devel@nongnu.org; Tue, 28 Aug 2012 16:06:48 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:50465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6S3e-0003c6-PQ for qemu-devel@nongnu.org; Tue, 28 Aug 2012 16:06:42 -0400 Received: by obbta14 with SMTP id ta14so10600051obb.4 for ; Tue, 28 Aug 2012 13:06:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87fw76ak5l.fsf@codemonkey.ws> References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503C74DD.3020307@msgid.tls.msk.ru> <20120828172838.GD3661@redhat.com> <87fw76ak5l.fsf@codemonkey.ws> From: Blue Swirl Date: Tue, 28 Aug 2012 20:06:21 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , Michael Tokarev , qemu-devel@nongnu.org, Alex Williamson , Jan Kiszka , Avi Kivity On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori wrote: > Blue Swirl writes: > >> On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin wrote: >>> On Tue, Aug 28, 2012 at 05:01:55PM +0000, Blue Swirl wrote: >>>> On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev wrote: >>>> > On 27.08.2012 22:56, Blue Swirl wrote: >>>> > [] >>>> >>> +static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr) >>>> >>> +{ >>>> >>> + AssignedDevRegion *d = opaque; >>>> >>> + uint8_t *in = d->u.r_virtbase + addr; >>>> >> >>>> >> Don't perform arithmetic with void pointers. >>>> > >>>> > There are a few places in common qemu code which does this for a very >>>> > long time. So I guess it is safe now. >>>> >>>> It's a non-standard GCC extension. >>> >>> So? We use many other GCC extensions. grep for typeof. >> >> Dependencies should not be introduced trivially. In this case, it's >> pretty easy to avoid void pointer arithmetic as Jan's next version >> shows. > > The standard is vague with respect void arithmetic. Most compilers > allow it. A very good analysis of the standard can be found below. > > http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c The analysis would seem to show that arithmetic may be acceptable, but it doesn't say that void pointers must be treated like char pointers. In my view, this would make sense: char *cptr; void *vptr; Since cptr++; is equivalent to cptr = (char *)((uintptr_t)cptr + sizeof(*cptr)); therefore vptr++; should be equivalent to vptr = (void *)((uintptr_t)vptr + sizeof(*vptr)); That is, vptr++ should be equivalent to vptr += 0 because sizeof(void) should be 0 if allowed. > > BTW: can we please stop arguing about C standards. If we currently are > using something in QEMU that's supported by clang and GCC, it's fine and > we ought to continue using it. > > The reserved names actually did bite us when porting to a new platform. > But the only requirement for C extensions ought to be reasonable support > in GCC and clang. > > I don't care at all about supporting proprietary compilers. We also don't have crowds banging doors with their money bags with a need for such support. > > Regards, > > Anthony Liguori > >> >>> >>> Is there a work in progress to build GCC with visual studio? >>> If yes what are the chances KVM device assignment >>> will work on windows? >> >> IIRC there was really a project to use KVM on Windows and another >> project to build QEMU with MSVC. >> >>> >>> Look QEMU codebase is what it is. Unless you rework all existing >>> code to confirm to your taste, I do not see why you NACK valid new code >>> unless it confirms to same. >> >> Yes, I'd be happy to fix the style with huge patches at once. But our >> fearless leader does not agree, so we are stuck with the codebase >> being what it is until it is fixed one step at a time. >> >>> >>>> > >>>> > /mjt >> -- >> 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