From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROzp8-0005Ey-Uj for qemu-devel@nongnu.org; Fri, 11 Nov 2011 17:43:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROzp7-0004j9-TA for qemu-devel@nongnu.org; Fri, 11 Nov 2011 17:43:50 -0500 Received: from cantor2.suse.de ([195.135.220.15]:33886 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROzp7-0004if-Ks for qemu-devel@nongnu.org; Fri, 11 Nov 2011 17:43:49 -0500 Message-ID: <4EBDA51D.1090803@suse.de> Date: Fri, 11 Nov 2011 23:43:41 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1320887981-2099-1-git-send-email-agraf@suse.de> <4A2D3614-438C-40F4-B3D1-A8ABF30FB82F@suse.de> <4EBD467F.7040107@suse.de> <4EBD4C57.1080709@suse.de> <4EBD5E13.8000604@suse.de> In-Reply-To: <4EBD5E13.8000604@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] s390x: initialize virtio dev region List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , qemu-devel@nongnu.org Am 11.11.2011 18:40, schrieb Alexander Graf: > On 11/11/2011 05:44 PM, Peter Maydell wrote: >> On 11 November 2011 16:24, Alexander Graf wrote: >>> On 11/11/2011 05:11 PM, Peter Maydell wrote: >>>> Yes, so that's option (2) and you need to be using a >>>> target_phys_addr_t. >>> But ram_size is ram_addr_t and is the ram size that I have available >>> to use, >>> so it's exactly the address that I want. I don't see your point. >>> Should go >>> jump through random useless hoops of doing >>> >>> target_phys_addr_t ram_end =3D ram_size; >>> >>> just because there are some subtile semantic differences between the = two >>> variables? They're integers at the end of the day. Both of them. >> Because handing a ram_addr_t to something that wants a target_phys_add= r_t >> is a red flag that something might be wrong. (As is handing a variable >> called _size to something that wants an address.) >> >> Force in Newtons and Force in pound-feet are also both just integers >> at the end of the day, but that doesn't make them interchangeable: >> http://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Communications_loss >=20 > Or actually rather this one: >=20 >=20 > Alex >=20 > diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c > index d936809..61b67e8 100644 > --- a/hw/s390-virtio.c > +++ b/hw/s390-virtio.c > @@ -167,6 +167,7 @@ static void s390_init(ram_addr_t my_ram_size, > uint8_t *storage_keys; > void *virtio_region; > target_phys_addr_t virtio_region_len; > + target_phys_addr_t virtio_region_start; > int i; >=20 > /* s390x ram size detection needs a 16bit multiplier + an > increment. So > @@ -188,7 +189,9 @@ static void s390_init(ram_addr_t my_ram_size, >=20 > /* clear virtio region */ > virtio_region_len =3D my_ram_size - ram_size; > - virtio_region =3D cpu_physical_memory_map(ram_size, > &virtio_region_len, true); > + virtio_region_start =3D ram_size; > + virtio_region =3D cpu_physical_memory_map(virtio_region_start, > + &virtio_region_len, true); Yes, ..._start reads better than ..._size there. Thanks. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg