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.
--
error compiling committee.c: too many arguments to function
