From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRjv7-0007Qm-MV for qemu-devel@nongnu.org; Fri, 17 Jul 2009 05:40:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRjv5-0007QP-W7 for qemu-devel@nongnu.org; Fri, 17 Jul 2009 05:40:01 -0400 Received: from [199.232.76.173] (port=49306 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRjv5-0007QM-PK for qemu-devel@nongnu.org; Fri, 17 Jul 2009 05:39:59 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:29935) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MRjv5-0006uq-BO for qemu-devel@nongnu.org; Fri, 17 Jul 2009 05:39:59 -0400 Received: by fg-out-1718.google.com with SMTP id d23so263475fga.8 for ; Fri, 17 Jul 2009 02:39:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <200907162312.n6GNCidA022228@d01av03.pok.ibm.com> References: <200907162312.n6GNCidA022228@d01av03.pok.ibm.com> From: Blue Swirl Date: Fri, 17 Jul 2009 12:39:38 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [Qemu-commits] [COMMIT ee6847d] qdev: rework device properties. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , Gerd Hoffmann Cc: qemu-devel On Fri, Jul 17, 2009 at 2:12 AM, Anthony Liguori wrote= : > From: Gerd Hoffmann > > This patch is a major overhaul of the device properties. =C2=A0The proper= ties > are saved directly in the device state struct now, the linked list of > property values is gone. > =C2=A0 =C2=A0 .qdev.name =C2=A0=3D "fdc", > =C2=A0 =C2=A0 .qdev.size =C2=A0=3D sizeof(fdctrl_t), > - =C2=A0 =C2=A0.qdev.props =3D (DevicePropList[]) { > - =C2=A0 =C2=A0 =C2=A0 =C2=A0{.name =3D "io_base", .type =3D PROP_TYPE_IN= T}, > - =C2=A0 =C2=A0 =C2=A0 =C2=A0{.name =3D "strict_io", .type =3D PROP_TYPE_= INT}, > - =C2=A0 =C2=A0 =C2=A0 =C2=A0{.name =3D "mem_mapped", .type =3D PROP_TYPE= _INT}, > - =C2=A0 =C2=A0 =C2=A0 =C2=A0{.name =3D "sun4m", .type =3D PROP_TYPE_INT}= , > - =C2=A0 =C2=A0 =C2=A0 =C2=A0{.name =3D NULL} > + =C2=A0 =C2=A0.qdev.props =3D (Property[]) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0{ > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.name =3D "io_base", > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.info =3D &qdev_prop_uint32, > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.offset =3D offsetof(fdctrl_t,= io_base), > + =C2=A0 =C2=A0 =C2=A0 =C2=A0}, This is broken, on SS-600MP, SS-10 and SS-20 fdc is located above 4G. The correct type is target_phys_addr_t. I'll fix this. > +typedef struct RamDevice > +{ > + =C2=A0 =C2=A0SysBusDevice busdev; > + =C2=A0 =C2=A0uint32_t size; > +} RamDevice; > + > =C2=A0/* System RAM */ > =C2=A0static void ram_init1(SysBusDevice *dev) > =C2=A0{ > =C2=A0 =C2=A0 ram_addr_t RAM_size, ram_offset; > + =C2=A0 =C2=A0RamDevice *d =3D FROM_SYSBUS(RamDevice, dev); > > - =C2=A0 =C2=A0RAM_size =3D qdev_get_prop_int(&dev->qdev, "size", 0); > + =C2=A0 =C2=A0RAM_size =3D d->size; > > =C2=A0 =C2=A0 ram_offset =3D qemu_ram_alloc(RAM_size); > =C2=A0 =C2=A0 sysbus_init_mmio(dev, RAM_size, ram_offset); > @@ -496,6 +499,7 @@ static void ram_init(target_phys_addr_t addr, ram_add= r_t RAM_size, > =C2=A0{ > =C2=A0 =C2=A0 DeviceState *dev; > =C2=A0 =C2=A0 SysBusDevice *s; > + =C2=A0 =C2=A0RamDevice *d; > > =C2=A0 =C2=A0 /* allocate RAM */ > =C2=A0 =C2=A0 if ((uint64_t)RAM_size > max_mem) { > @@ -506,20 +510,26 @@ static void ram_init(target_phys_addr_t addr, ram_a= ddr_t RAM_size, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 exit(1); > =C2=A0 =C2=A0 } > =C2=A0 =C2=A0 dev =3D qdev_create(NULL, "memory"); > - =C2=A0 =C2=A0qdev_set_prop_int(dev, "size", RAM_size); > =C2=A0 =C2=A0 qdev_init(dev); > =C2=A0 =C2=A0 s =3D sysbus_from_qdev(dev); > > + =C2=A0 =C2=A0d =3D FROM_SYSBUS(RamDevice, s); > + =C2=A0 =C2=A0d->size =3D RAM_size; > + > =C2=A0 =C2=A0 sysbus_mmio_map(s, 0, addr); > =C2=A0} This is completely hosed because of the wrong order of setting d->size. Now qemu_ram_alloc gets passed a zero. Moreover, this limits the maximum memory to 4G. We would need a 64 bit or ram_addr_t type, the memory could be specified in units of mebibytes, or target_phys_addr_t could be misused. I'm not sure how to fix this, but now sparc-softmmu just aborts at ram_init= 1.