Re: R/W HG memory mappings with kvm?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/08/2009 01:23 AM, Stephen Donnelly wrote:

Also it appears that PCI IO memory (cpu_register_io_memory) is
provided via access functions, like the pci config space?
It can also use ordinary RAM (for example, vga maps its framebuffer as a PCI
BAR).

So host memory is exported as a PCI_BAR to the guest via
cpu_register_physical_memory(). It looks like the code has to
explicitly manage marking pages dirty and synchronising at appropriate
times. Is the coherency problem bidirectional, e.g. writes from either
host or guest to the shared memory need to mark pages dirty, and
ensure sync is called before the other side reads those areas?

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.

Does this
cause a page fault/vm_exit on each read or write, or is it more
efficient than that?
It depends on how you configure it.  Look at the vga code (hw/vga.c,
hw/cirrus_vga.c).  Also Cam (copied) wrote a PCI card that provides shared
memory across guests, you may want to look at that.

I will look into the vga code and see if I get inspired. The 'copied'
driver sounds interesting, the code is not in kvm git?

(copied) means Cam was copied (cc'ed) on the email, not the name of the driver. It hasn't been merged but copies (of the driver, not Cam) are floating around on the Internet.

The relevant parts of cirrus_vga.c are:

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.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux