From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmoHJ-0000AK-1S for qemu-devel@nongnu.org; Mon, 16 Jan 2012 10:15:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmoHH-0007WD-UU for qemu-devel@nongnu.org; Mon, 16 Jan 2012 10:15:21 -0500 Message-ID: <4F143F03.5020001@redhat.com> Date: Mon, 16 Jan 2012 17:15:15 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1325894809-17322-1-git-send-email-andreas.faerber@web.de> <1326424168-15705-1-git-send-email-andreas.faerber@web.de> <1326424168-15705-4-git-send-email-andreas.faerber@web.de> <4F129A1A.9070709@redhat.com> <4F143D83.3050502@web.de> In-Reply-To: <4F143D83.3050502@web.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 3/8] prep_pci: Update I/O to MemoryRegion ops List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Alexander Graf , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, "Michael S. Tsirkin" On 01/16/2012 05:08 PM, Andreas F=C3=A4rber wrote: > Am 15.01.2012 10:19, schrieb Avi Kivity: > > On 01/13/2012 05:09 AM, Andreas F=C3=A4rber wrote: > >> Convert to new-style read/write callbacks. > >> > >> =20 > >> -static uint32_t PPC_PCIIO_readl (void *opaque, target_phys_addr_t a= ddr) > >> +static uint64_t ppc_pci_io_read(void *opaque, target_phys_addr_t ad= dr, > >> + unsigned int size) > >> { > >> PREPPCIState *s =3D opaque; > >> - uint32_t val; > >> - val =3D pci_data_read(s->bus, PPC_PCIIO_config(addr), 4); > >> - return val; > >> + switch (size) { > >> + case 1: > >> + case 2: > >> + case 4: > >> + return pci_data_read(s->bus, PPC_PCIIO_config(addr), size); > >> + default: > >> + abort(); > >> + } > >> } > >=20 > > Huh? just call pci_data_read() unconditionally. > > Just so that I understand, is that because PReP is 32-bit ppc? In the > above mechanical conversion, size 8 would abort. The memory core never issues size 8 transactions, since the code is unprepared for it. When we will support it, you'll have to explicitly declare it with .impl.max_access_size =3D 8 or something. > BTW did we agree on an indentation style for switch? What you wrote conforms to the de facto standard. --=20 error compiling committee.c: too many arguments to function