From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4X3J-0006r6-9t for qemu-devel@nongnu.org; Mon, 15 Jun 2015 12:16:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4X3G-0000IN-GI for qemu-devel@nongnu.org; Mon, 15 Jun 2015 12:16:01 -0400 Received: from omzsmtpe04.verizonbusiness.com ([199.249.25.207]:18718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4X3G-0000IF-9I for qemu-devel@nongnu.org; Mon, 15 Jun 2015 12:15:58 -0400 From: Don Slutz Message-ID: <557EFA38.1030108@one.verizon.com> Date: Mon, 15 Jun 2015 12:15:52 -0400 MIME-Version: 1.0 References: <1434117956-4929-1-git-send-email-dslutz@verizon.com> <1434117956-4929-2-git-send-email-dslutz@verizon.com> <557B5F49.5050109@redhat.com> <557ED8D3.8010900@one.verizon.com> <557EEA9C.3040303@redhat.com> In-Reply-To: <557EEA9C.3040303@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [BUGFIX][PATCH v7 1/9] vmport: The io memory region needs to be at least a size of 4 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , "qemu-devel@nongnu.org" Cc: "Michael S. Tsirkin" , Markus Armbruster , Luiz Capitulino , Don Slutz , Anthony Liguori , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Richard Henderson On 06/15/15 11:09, Eric Blake wrote: > On 06/15/2015 07:53 AM, Don Slutz wrote: >> On 06/12/15 18:38, Eric Blake wrote: > >>>> >>>> + /* Only support 1 address */ >>>> + if (addr) { >>>> + return ~0U; >>>> + } >>> >>> Different answer on 32-bit platforms (there, ~0U is 0xffffffff, which >>> then 0-extends to uint64_t rather than your desired result of >>> 0xffffffffffffffffULL). >>> >> >> This is not true: > > Oh, I was confusing ~0UL (where sign extension on 32- vs 64-bit matters) > and ~0U (which you used). > >> >>> Why can't you just 'return -1;'? >>> >> >> I/O instructions on x86 are limited to 32bits max. Also when EAX is >> changed via inl, the high 32bits are 0. So the correct result is ~0U >> not -1. > > Still, it might be better to write an explicit 0xffffffff or even have a > named constant, rather than making people reason about whether ~0U > promotes into a 64-bit value with only 32 bits set. > Ok, Will switch to 0xffffffff. -Don Slutz