Re: [Qemu-devel] [RFC v2 00/20] Memory API

[Michael S. Tsirkin]

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