From: Anthony Liguori <anthony@codemonkey.ws>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API
Date: Tue, 19 Jul 2011 21:53:56 -0500 [thread overview]
Message-ID: <4E264344.1080505@codemonkey.ws> (raw)
In-Reply-To: <CA+1xoqe0tr3Y7zJpk248pMi3S3VBznvDFLCbsy=iOQk_m-xncw@mail.gmail.com>
On 07/19/2011 04:03 PM, Sasha Levin wrote:
> On Tue, Jul 19, 2011 at 11:51 PM, Anthony Liguori<anthony@codemonkey.ws> wrote:
>> The e1000 is not performance competitive with virtio-net though so it
>> certainly is reasonable to assume that noone would notice if we removed
>> coalesced I/O from the e1000.
>>
>> The point is, it's so incredibly special cased that having it as part of
>> such a general purpose API seems wrong. Of the hundreds of devices, we only
>> have one device that we know for sure really needs it and it could easily be
>> done independent of the memory API for that device.
>
> Sorry for sidetracking it a bit, but if coalesced mmio doesn't fit
> nicely in a good memory model, maybe the problem is with coalesced
> mmio and not the memory model itself.
Well, I'd say it's the exception that proves the rule :-) I'm really
just advocating that we should treat it as an exception and not try to
change our rules to take it into account.
> It's something that's not really being used at the moment - neither in
> qemu nor in kvm tools (we just use dirty log in a guest memory block
> after finding out coalesced mmio is still slow).
QEMU does use it and it's quite important. Coalesced MMIO is really
about write caching MMIO exits. It only works with devices that have
registers where writing has no side effects. Moreover, it only really
works well when there are lots and lots of writes to these registers
simultaneously.
Couple that with the fact that the buffer is a fixed size and it's
really not flexible enough to be useful for a wide variety of devices.
But for VGA planar mode writes, it works wonders. It would be terrible
to totally lose it. That said, I'm not at all convinced it's useful for
much other than VGA planar mode.
Regards,
Anthony Liguori
> What about just deprecating it and doing either the sockets approach
> (whenever it's ready), or doing a brand new virtio-memory device to
> avoid the possibility of sockets turning into something like coalesced
> mmio.
>
next prev parent reply other threads:[~2011-07-20 2:53 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-17 11:13 [RFC v4 00/58] Memory API Avi Kivity
2011-07-17 11:13 ` [RFC v4 01/58] Hierarchical memory region API Avi Kivity
2011-07-17 11:13 ` [RFC v4 02/58] memory: implement dirty tracking Avi Kivity
2011-07-17 11:13 ` [RFC v4 03/58] memory: merge adjacent segments of a single memory region Avi Kivity
2011-07-17 11:13 ` [RFC v4 04/58] Internal interfaces for memory API Avi Kivity
2011-07-17 11:13 ` [RFC v4 05/58] memory: abstract address space operations Avi Kivity
2011-07-17 11:13 ` [RFC v4 06/58] memory: rename MemoryRegion::has_ram_addr to ::terminates Avi Kivity
2011-07-17 11:13 ` [RFC v4 07/58] memory: late initialization of ram_addr Avi Kivity
2011-07-17 11:13 ` [RFC v4 08/58] memory: I/O address space support Avi Kivity
2011-07-17 11:13 ` [RFC v4 09/58] memory: add backward compatibility for old portio registration Avi Kivity
2011-07-17 11:13 ` [RFC v4 10/58] memory: add backward compatibility for old mmio registration Avi Kivity
2011-07-17 11:13 ` [RFC v4 11/58] memory: add ioeventfd support Avi Kivity
2011-07-20 17:29 ` [Qemu-devel] " Blue Swirl
2011-07-20 17:31 ` Avi Kivity
2011-07-17 11:13 ` [RFC v4 12/58] exec.c: initialize memory map Avi Kivity
2011-07-17 11:13 ` [RFC v4 13/58] ioport: register ranges by byte aligned addresses always Avi Kivity
2011-07-17 11:13 ` [RFC v4 14/58] pc: grab system_memory Avi Kivity
2011-07-17 11:13 ` [RFC v4 15/58] pc: convert pc_memory_init() to memory API Avi Kivity
2011-07-17 11:13 ` [RFC v4 16/58] pc: move global memory map out of pc_init1() and into its callers Avi Kivity
2011-07-17 11:13 ` [RFC v4 17/58] pci: pass address space to pci bus when created Avi Kivity
2011-07-17 11:13 ` [RFC v4 18/58] pci: add MemoryRegion based BAR management API Avi Kivity
2011-07-17 11:13 ` [RFC v4 19/58] sysbus: add MemoryRegion based memory " Avi Kivity
2011-07-17 11:13 ` [RFC v4 20/58] usb-ohci: convert to MemoryRegion Avi Kivity
2011-07-17 11:13 ` [RFC v4 21/58] pci: add API to get a BAR's mapped address Avi Kivity
2011-07-17 11:13 ` [RFC v4 22/58] vmsvga: don't remember pci BAR address in callback any more Avi Kivity
2011-07-17 11:13 ` [RFC v4 23/58] vga: convert vga and its derivatives to the memory API Avi Kivity
2011-07-20 14:05 ` Jan Kiszka
2011-07-20 14:40 ` Avi Kivity
2011-07-20 14:45 ` Jan Kiszka
2011-07-20 14:48 ` Avi Kivity
2011-07-20 14:52 ` Jan Kiszka
2011-07-20 14:55 ` Avi Kivity
2011-07-17 11:13 ` [RFC v4 24/58] cirrus: simplify mmio BAR access functions Avi Kivity
2011-07-17 11:13 ` [RFC v4 25/58] cirrus: simplify bitblt " Avi Kivity
2011-07-17 11:13 ` [RFC v4 26/58] cirrus: simplify vga window mmio " Avi Kivity
2011-07-17 11:13 ` [RFC v4 27/58] vga: " Avi Kivity
2011-07-17 11:13 ` [RFC v4 28/58] cirrus: simplify linear framebuffer " Avi Kivity
2011-07-17 11:13 ` [RFC v4 29/58] Integrate I/O memory regions into qemu Avi Kivity
2011-07-17 11:13 ` [RFC v4 30/58] exec.c: fix initialization of system I/O memory region Avi Kivity
2011-07-17 11:13 ` [RFC v4 31/58] pci: pass I/O address space to new PCI bus Avi Kivity
2011-07-17 11:13 ` [RFC v4 32/58] pci: allow I/O BARs to be registered with pci_register_bar_region() Avi Kivity
2011-07-17 11:14 ` [RFC v4 33/58] rtl8139: convert to memory API Avi Kivity
2011-07-17 11:14 ` [RFC v4 34/58] ac97: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 35/58] e1000: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 36/58] eepro100: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 37/58] es1370: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 38/58] ide: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 39/58] ivshmem: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 40/58] virtio-pci: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 41/58] ahci: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 42/58] intel-hda: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 43/58] lsi53c895a: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 44/58] ppc: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 45/58] ne2000: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 46/58] pcnet: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 47/58] i6300esb: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 48/58] isa-mmio: concert " Avi Kivity
2011-07-17 11:14 ` [RFC v4 49/58] sun4u: convert " Avi Kivity
2011-07-17 11:14 ` [RFC v4 50/58] ehci: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 51/58] uhci: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 52/58] xen-platform: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 53/58] msix: " Avi Kivity
2011-07-17 11:14 ` [RFC v4 54/58] pci: remove pci_register_bar_simple() Avi Kivity
2011-07-17 11:14 ` [RFC v4 55/58] pci: convert pci rom to memory API Avi Kivity
2011-07-17 11:14 ` [RFC v4 56/58] pci: remove pci_register_bar() Avi Kivity
2011-07-17 11:14 ` [RFC v4 57/58] pci: fold BAR mapping function into its caller Avi Kivity
2011-07-17 11:14 ` [RFC v4 58/58] pci: rename pci_register_bar_region() to pci_register_bar() Avi Kivity
2011-07-19 13:09 ` [Qemu-devel] [RFC v4 00/58] Memory API Anthony Liguori
2011-07-19 13:27 ` Avi Kivity
2011-07-19 14:50 ` Anthony Liguori
2011-07-19 16:05 ` Avi Kivity
2011-07-19 16:10 ` Avi Kivity
2011-07-19 20:51 ` Anthony Liguori
2011-07-19 21:03 ` Sasha Levin
2011-07-20 2:53 ` Anthony Liguori [this message]
2011-07-20 6:10 ` Sasha Levin
2011-07-20 8:12 ` Avi Kivity
2011-07-20 12:12 ` Anthony Liguori
2011-07-20 8:10 ` Avi Kivity
2011-07-20 14:31 ` Anthony Liguori
2011-07-20 14:45 ` Avi Kivity
2011-07-19 13:56 ` Michael S. Tsirkin
2011-07-19 13:57 ` Avi Kivity
2011-07-19 17:01 ` Jan Kiszka
2011-07-19 17:14 ` Avi Kivity
2011-07-19 17:30 ` Jan Kiszka
2011-07-20 8:13 ` Avi Kivity
2011-07-20 11:20 ` Jan Kiszka
2011-07-20 11:59 ` Avi Kivity
2011-07-20 11:43 ` Jan Kiszka
2011-07-20 11:57 ` Avi Kivity
2011-07-20 13:57 ` Jan Kiszka
2011-07-20 14:32 ` Avi Kivity
2011-07-20 14:37 ` Michael S. Tsirkin
2011-07-20 14:42 ` Jan Kiszka
2011-07-20 14:54 ` Avi Kivity
2011-07-20 15:58 ` Jan Kiszka
2011-07-20 16:02 ` Avi Kivity
2011-07-20 16:13 ` Jan Kiszka
2011-07-20 16:19 ` Avi Kivity
2011-07-20 16:10 ` Michael S. Tsirkin
2011-07-20 16:52 ` Avi Kivity
2011-07-20 17:06 ` Michael S. Tsirkin
2011-07-20 16:53 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E264344.1080505@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox