On Mon, Jun 27, 2011 at 06:13:03PM +0300, Avi Kivity wrote: > On 06/27/2011 04:21 PM, Avi Kivity wrote: > >As expected, this is taking longer than expected, so I'm releasing something > >less complete than I'd have liked. Not even all of the PC machine is > >converted, but the difficult parts are (cirrus). It appears to work well. > > > >The major change compared to v1 is the introduction of > >memory_region_init_alias(), which defines a memory region in terms of another. > >With the current API, the ability to alias is provided by address arithmetic > >on ram_addr_t: > > > > ram_addr = qemu_ram_alloc(...); > > cpu_register_physical_memory(..., ram_addr, size, ...); > > /* alias: */ > > cpu_register_physical_memory(..., ram_addr + offset, another_size, ...); > > > >With the new API, you have to create an alias: > > > > memory_region_init_ram(&mem, ...); > > memory_region_register_subregion(...,&mem); > > /* alias: */ > > memory_region_init_alias(&alias, ...,&mem, offset, another_size); > > memory_region_register_subregion(...,&alias); > > > >The patchset is somewhat churny. One of the reasons is that we move from a > >handle/pointer scheme in ram_addr_t to an object constructor/destructor scheme. > >Another is that region size becomes a property of a region instead of being > >maintained externally. Also, container memory regions must be passed around, > >though we don't do that as well as we should. > > > >Todo: > > - eliminate calls to get_system_memory() (where we ignore the bus hierarchy) > > - add PCI APIs for the VGA window > > - support the PIO address space using the memory API (allowing simplified > > PCI BAR registration) > > - convert 440FX > > - convert everything else > > Michael, I'm looking at the pci bridge code, and it basically does > the same thing - clip each BAR to the intersection of the decode > window of all bridges it hides behind. > > How does a PCI bridge behave wrt VGA? is it a separate control? If > so I probably need to implement generalized clipping (i.e. decode > between 0xa0000-0xc0000 or between 0xc0000000-0xf0000000). Per spec, VGA is special: - bridges have VGA enable bit The VGA Enable bit in the Bridge Control register (see Section 3.2.5.18) is used to control response by the bridge to both the VGA frame buffer addresses and to the VGA register addresses. When a VGA compatible device is located downstream of a PCI-to-PCI bridge, the VGA Enable bit must be set. When set, the bridge will positively decode and forward memory accesses to VGA frame buffer addresses and I/O accesses to VGA registers from the primary to secondary interface and block forwarding of these same accesses from the secondary to primary interface (see Section 4.5.1). VGA memory addresses: 0A 0000h through 0B FFFFh VGA I/O addresses (including ISA aliases address - AD[15::10] are not decoded): AD[9::0] = 3B0h through 3BBh and 3C0h through 3DFh The bridge does not decode or forward VGA BIOS memory addresses when the VGA Enable bit is set. ROM code provided by PCI compatible devices may be mapped to any address in PCI memory address space via the Expansion ROM Base Address register in the device's configuration header and must be copied to system memory before execution. - bridges might also enable subtractive decoding (required for isa behind the bridge) Both are currently unimplemented. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
