From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6PZd-0003CD-VA for qemu-devel@nongnu.org; Tue, 28 Aug 2012 13:27:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6PZX-0000US-K0 for qemu-devel@nongnu.org; Tue, 28 Aug 2012 13:27:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6PZX-0000UK-Bj for qemu-devel@nongnu.org; Tue, 28 Aug 2012 13:27:27 -0400 Date: Tue, 28 Aug 2012 20:28:38 +0300 From: "Michael S. Tsirkin" Message-ID: <20120828172838.GD3661@redhat.com> References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503C74DD.3020307@msgid.tls.msk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Blue Swirl Cc: kvm@vger.kernel.org, Marcelo Tosatti , Michael Tokarev , qemu-devel@nongnu.org, Alex Williamson , Jan Kiszka , Avi Kivity 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. 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? 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. > > > > /mjt