|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH 11/23] memory: add ioeventfd support |
Date: | Tue, 26 Jul 2011 13:08:48 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11 |
On 07/25/2011 10:08 PM, Anthony Liguori wrote:
+static void as_memory_ioeventfd_add(AddressSpace *as, MemoryRegionIoeventfd *fd)+{ + int r; + + if (!fd->match_data || fd->addr.size != 4) { + abort(); + } ++ r = kvm_set_ioeventfd_mmio_long(fd->fd, fd->addr.start, fd->data, true);+ if (r< 0) { + abort(); + }asserts would be friendlier.
I thought asserts were disabled by default. But I see it isn't so; will update.
I really dislike baking ioeventfd into this API. There is only one user of ioeventfd in the tree.
Two: virtio-pci and ivshmem.
I worry that by having things like ioeventfd the API, we're making it too difficult to side-step the API which prevents future optimizations.I'd prefer virtio-pci to have ugliness in it where it circumvented the layering vs. having such a device specific thing in generic code.
It's impossible (or at least, impossible without further information from the API) to do this and retain correctness. Currently virtio-pci is broken wrt bridges and overlapping BARs; it's probably also broken on targets that bridge the I/O address space to MMIO.
With the memory API, this is fixed in a natural way by making the I/O address space a subregion of the bridge which does the conversion; the code will automatically add the needed offset and use MMIO ioeventfd instead of portio.
On a more general note, I don't want this to be a lean and mean API that throws any complexity to the users; instead I want to make writing devices as simple as possible and own all the smarts.
(an example - undecoded address bits can be specified to the API which then takes care of replication or shifting).
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |