From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:56389)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UgtIs-00077q-Na
	for qemu-devel@nongnu.org; Mon, 27 May 2013 05:01:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UgtIn-0006FS-Mz
	for qemu-devel@nongnu.org; Mon, 27 May 2013 05:01:18 -0400
Received: from mx1.redhat.com ([209.132.183.28]:60081)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UgtIn-0006FG-ED
	for qemu-devel@nongnu.org; Mon, 27 May 2013 05:01:13 -0400
Message-ID: <51A320C9.9050705@redhat.com>
Date: Mon, 27 May 2013 11:00:57 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1369194397-608-1-git-send-email-lig.fnst@cn.fujitsu.com>
	<1369194397-608-3-git-send-email-lig.fnst@cn.fujitsu.com>
	<20130522052854.GB12536@valinux.co.jp>
	<1369201061.5142.154.camel@liguang.fnst.cn.fujitsu.com>
	<20130524012442.GH22054@valinux.co.jp>
	<1369360963.5142.207.camel@liguang.fnst.cn.fujitsu.com>
In-Reply-To: <1369360963.5142.207.camel@liguang.fnst.cn.fujitsu.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 2/4] acpi/gpe: expand bits of gpe register
List-Id: <qemu-devel.nongnu.org>
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>
To: li guang <lig.fnst@cn.fujitsu.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Stefan Berger <stefanb@linux.vnet.ibm.com>, Joel Schopp <jschopp@linux.vnet.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, Bruce Rogers <brogers@suse.com>, Isaku Yamahata <yamahata@valinux.co.jp>, Paolo Bonzini <pbonzini@redhat.com>, =?UTF-8?B?QW5kcmVhcyBGw6RyYmU=?= =?UTF-8?B?cg==?= <afaerber@suse.de>

On 05/24/13 04:02, li guang wrote:
> =E5=9C=A8 2013-05-24=E4=BA=94=E7=9A=84 10:24 +0900=EF=BC=8CIsaku Yamaha=
ta=E5=86=99=E9=81=93=EF=BC=9A
>> On Wed, May 22, 2013 at 01:37:41PM +0800, li guang wrote:
>>> =E5=9C=A8 2013-05-22=E4=B8=89=E7=9A=84 14:28 +0900=EF=BC=8CIsaku Yama=
hata=E5=86=99=E9=81=93=EF=BC=9A
>>>> Why?
>>>> And it breaks pointer operation like
>>>
>>> the fact is I can't guess why gpe->sts is defined uint8_t=20
>>> but the real hardware is 32-bit width.
>>
>> Which section of ACPI spec?
>=20
> seems ACPI SPEC does not define the length,
> but, real hardware does, e.g. ICH9.

Still fail to see what exactly you are trying to fix.

qemu can continue work with uint8_t internally just fine.  memory api
will split dword access by guests into 4 byte accesses.  ich9_gpe_ops
looks correct.

>>> I expand it to 32 because the future usage for me will=20
>>> access bit beyond 8.

gpe->sts is an array, so you already have more than 8 bits.

>> I don't have strong opinion wheter uint8_t or uint32_t.
>> But the current patch is broken as the pointer offset=20
>> operation needs to be fixed.

Oh, and it breaks live migration too.

cheers,
  Gerd