From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35071)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ghammer@redhat.com>) id 1Z1xIf-0005Jj-4u
	for qemu-devel@nongnu.org; Mon, 08 Jun 2015 09:41:18 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ghammer@redhat.com>) id 1Z1xIb-00067N-RK
	for qemu-devel@nongnu.org; Mon, 08 Jun 2015 09:41:13 -0400
Received: from mx1.redhat.com ([209.132.183.28]:32864)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ghammer@redhat.com>) id 1Z1xIb-000637-L0
	for qemu-devel@nongnu.org; Mon, 08 Jun 2015 09:41:09 -0400
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (Postfix) with ESMTPS id 3F1F5BBF60
	for <qemu-devel@nongnu.org>; Mon,  8 Jun 2015 13:41:08 +0000 (UTC)
Message-ID: <55759BB8.3010604@redhat.com>
Date: Mon, 08 Jun 2015 16:42:16 +0300
From: Gal Hammer <ghammer@redhat.com>
MIME-Version: 1.0
References: <1430133591-6197-1-git-send-email-ghammer@redhat.com>
	<1430133591-6197-5-git-send-email-ghammer@redhat.com>
	<556F2D51.2000203@redhat.com>
In-Reply-To: <556F2D51.2000203@redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine
	Generation ID device
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: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: imammedo@redhat.com, mst@redhat.com

On 03/06/2015 19:37, Paolo Bonzini wrote:
>
> Since Michael said he'd merge this version, there's just one thing I
> would change.  You can access the region only one byte at a time, and
> let the memory core fix endianness here:

I've applied the change offered below. Thanks.

There are two unanswered questions:

1. You wrote that I should not use the memory_region_init_io() function. 
Should I use memory_region_init_ram() instead?

2. Is it possible to create a sysbus device using the "-device" command 
line argument? I vaguely recall that it is not possible to do it and 
that's the reason that I specifically add the device in the pc init.

Thanks,

     Gal.

> On 27/04/2015 13:19, Gal Hammer wrote:
>> +static uint64_t vmgenid_ram_read(void *opaque, hwaddr addr,
>> +                                 unsigned size)
>> +{
>> +    VmGenIdState *s = VMGENID(opaque);
>> +    uint64_t value;
>> +
>> +    memcpy(&value, s->guid + addr, size);
>
> value = s->guid[addr];
>
>> +    return value;
>> +}
>> +
>> +static const MemoryRegionOps vmgenid_ram_ops = {
>> +    .read = vmgenid_ram_read,
>> +    .valid = {
>> +        .min_access_size = 4,
>> +        .max_access_size = 4,
>> +    },
>
> And instead of this .valid declaration, use this:
>
>      .valid.min_access_size = 1,
>      .valid.max_access_size = 4,
>      .impl.min_access_size = 1,
>      .impl.max_access_size = 1,
>
>
>> +    .endianness = DEVICE_NATIVE_ENDIAN,
>
>      .endianness = DEVICE_LITTLE_ENDIAN
>
>
>> +};
>
> Thanks,
>
> Paolo
>