From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvVYe-0000BA-OY for qemu-devel@nongnu.org; Thu, 09 Feb 2012 10:05:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvVYd-0003hk-02 for qemu-devel@nongnu.org; Thu, 09 Feb 2012 10:05:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvVYc-0003hX-Nx for qemu-devel@nongnu.org; Thu, 09 Feb 2012 10:05:10 -0500 Message-ID: <4F33E0A3.5060708@redhat.com> Date: Thu, 09 Feb 2012 17:05:07 +0200 From: Avi Kivity MIME-Version: 1.0 References: <5c058df627b83bf0c35c2e1dcd92b0a3fd301181.1328445531.git.jan.kiszka@web.de> <4F338545.7090205@web.de> <4F3392A7.1020603@redhat.com> <4F33D6C7.4020304@web.de> In-Reply-To: <4F33D6C7.4020304@web.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] subpages with memory region aliases List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On 02/09/2012 04:23 PM, Jan Kiszka wrote: > On 2012-02-09 10:32, Avi Kivity wrote: > > On 02/09/2012 10:35 AM, Jan Kiszka wrote: > >> Avi, > >> > >> Before I forget: > >> > >> On 2012-02-05 13:39, Jan Kiszka wrote: > >>> +static void vapic_map_rom_writable(VAPICROMState *s) > >>> +{ > >>> + target_phys_addr_t rom_paddr = s->rom_state_paddr & ROM_BLOCK_MASK; > >>> + MemoryRegionSection section; > >>> + MemoryRegion *as; > >>> + size_t rom_size; > >>> + uint8_t *ram; > >>> + > >>> + as = sysbus_address_space(&s->busdev); > >>> + > >>> + if (s->rom_mapped_writable) { > >>> + memory_region_del_subregion(as, &s->rom); > >>> + memory_region_destroy(&s->rom); > >>> + } > >>> + > >>> + /* grab RAM memory region (region @rom_paddr may still be pc.rom) */ > >>> + section = memory_region_find(as, 0, 1); > >>> + > >>> + /* read ROM size from RAM region */ > >>> + ram = memory_region_get_ram_ptr(section.mr); > >>> + rom_size = ram[rom_paddr + 2] * ROM_BLOCK_SIZE; > >>> + s->rom_size = rom_size; > >>> + > >>> + /* FIXME: round up as everything underneath would fall apart otherwise > >>> + * (subpages are broken) */ > >>> + rom_size = TARGET_PAGE_ALIGN(rom_size); > >> > >> Removing this alignment triggers an interesting bug in the memory layer. > >> Haven't understood the details yet. Is subpage support supposed to work? > >> > >> > > > > There are plenty of restrictions wrt page size in the memory API. Some > > will be removed, some are enforced by hardware (for example the low bits > > of the guest address and host address must match). > > > > Subpage of course works, but it can't be direct mapped. > > > > Does this mean you can't use them with RAM backing? Should probably be > documented and caught gracefully in that case. Since a few monthss ago, you can (56384e8b). But it will be handled as mmio, of course. -- error compiling committee.c: too many arguments to function