On 07/09/2009 12:33 AM, Stephen Donnelly wrote:
Shared memory is fully coherent. You can use the ordinary x86 bus lock
operations for concurrent read-modify-write access, and the memory barrier
instructions to prevent reordering. Just like ordinary shared memory.
Okay, I think I was confused by the 'dirty' code. Is that just to do
with migration?
Migration and reducing vga updates.
static void cirrus_pci_lfb_map(PCIDevice *d, int region_num,
uint32_t addr, uint32_t size, int type)
{
...
/* XXX: add byte swapping apertures */
cpu_register_physical_memory(addr, s->vga.vram_size,
s->cirrus_linear_io_addr);
This function is called whenever the guest updates the BAR.
So guest accesses to the LFB PCI_BAR trigger the cirrus_linear
functions, which set dirty on writes and allow 'side effect' handling
for reads if required? In my case there should be no side effects, so
it could be quite simple. I wonder about the cost of the callbacks on
each access though, am I still missing something?
Sorry, I quoted the wrong part. vga is complicated because some modes
do need callbacks on reads and writes, and others can use normal RAM
(with dirty tracking).
The real direct mapping code is:
static void map_linear_vram(CirrusVGAState *s)
{
vga_dirty_log_stop(&s->vga);
if (!s->vga.map_addr && s->vga.lfb_addr && s->vga.lfb_end) {
s->vga.map_addr = s->vga.lfb_addr;
s->vga.map_end = s->vga.lfb_end;
cpu_register_physical_memory(s->vga.map_addr,
s->vga.map_end - s->vga.map_addr, s->vga.vram_offset);
}
s->vga.vram_offset is a ram_addr_t describing the the vga framebuffer.
You're much better off reading Cam's code as it's much simpler and
closer to what you want to do (possibly you can use it as is).
--
error compiling committee.c: too many arguments to function
--
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
