[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 00/20] Memory API
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [RFC v2 00/20] Memory API |
Date: |
Mon, 27 Jun 2011 18:59:20 +0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Jun 27, 2011 at 06:54:05PM +0300, Avi Kivity wrote:
> 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?
subtractive decoding is
a method of address decoding in which a device accepts all
accesses not positively decoded by another agent.
> --
> error compiling committee.c: too many arguments to function
[Qemu-devel] [RFC v2 11/20] sysbus: add MemoryRegion based memory management API, Avi Kivity, 2011/06/27
[Qemu-devel] [RFC v2 13/20] pci: add API to get a BAR's mapped address, Avi Kivity, 2011/06/27
[Qemu-devel] [RFC v2 10/20] pci: add MemoryRegion based BAR management API, Avi Kivity, 2011/06/27
Re: [Qemu-devel] [RFC v2 00/20] Memory API, Avi Kivity, 2011/06/27
Re: [Qemu-devel] [RFC v2 00/20] Memory API, Anthony Liguori, 2011/06/27