Re: [RFC v2 00/20] Memory API

Avi Kivity
2011-06-27T15:54:10Z

On 06/27/2011 06:52 PM, Michael S. Tsirkin wrote:
> 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.
>

Okay, looks like generalized clipping is needed. It's nice anyway and
guarantees me a job for life as maintainer of memory.c.

> - bridges might also enable subtractive decoding
> (required for isa behind the bridge)

What does that mean?

--
error compiling committee.c: too many arguments to function