From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH 2/2] Xen: Add xen-apic support and hook it
	up.
Date: Wed, 11 Apr 2012 17:23:05 +0100
Message-ID: <CAFEAcA9Lpo_ejTuDo+snKGOSzSEAWD6D4b_37ur2RTRSZ_euhQ@mail.gmail.com>
References: <1333618350.2513.5.camel@leeds.uk.xensource.com>
	<1333618505.2513.8.camel@leeds.uk.xensource.com>
	<CAFEAcA9GJKPQBohDg-7NtcLKofH8vWRzO2KUjxNVk90exCknNw@mail.gmail.com>
	<4F85AD8F.7000004@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <4F85AD8F.7000004@siemens.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, Wei Liu <wei.liu2@citrix.com>, "liuw@liuw.name" <liuw@liuw.name>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, QEMU-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
List-Id: xen-devel@lists.xenproject.org

On 11 April 2012 17:13, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2012-04-11 18:07, Peter Maydell wrote:
>>> +#include "hw/apic_internal.h"
>>> +#include "hw/msi.h"
>>> +#include "xen.h"
>>> +
>>> +static uint64_t xen_apic_mem_read(void *opaque, target_phys_addr_t add=
r,
>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned size)
>>> +{
>>> + =C2=A0 =C2=A0return -1U;
>>> +}
>>
>> This seems a rather confusing way to write 'return 0xffffffff;'
>
> You mean 0xffffffffffffffff? :)

No, that's why it's confusing :-)

1U is the integer constant 1 with a type of 'unsigned int'
(cf C99 section 6.4.4.1). It then has the unary negation
operator applied to it, giving (for the usual 32 bit integer
case) 0xffffffff. This is then cast from 'unsigned int'
to 'uint64_t' giving 0xffffffff as a 64 bit unsigned value.

(I had to write a test program to (a) confirm what it was
going to return and (b) that it would be the same thing on
both 32 and 64 bit systems...)

I have no opinion on what the return value actually ought
to be.

-- PMM