Hi ----- Original Message ----- > >> Hash ivshmem been used in anger? If yes, how? > > Still the question to answer.
I don't expect users to read this ML everyday (anybody actually). Personally, I have no clue how widespread ivshmem usage is. > Besides the usual PCI properties, we have: > > ivshmem.chardev=str (ID of a chardev to use as a backend) > ivshmem.size=str > ivshmem.vectors=uint32 > ivshmem.ioeventfd=bool (on/off) > ivshmem.msi=bool (on/off) > ivshmem.shm=str > ivshmem.role=str > ivshmem.memdev=link<memory-backend> > ivshmem.use64=uint32 > > Exactly one of chardev, shm, memdev must be given. qemu-doc.info claims > you can omit all three, but that's a bug. interesting, I guess the doc must be updated > vectors, ioeventfd and msi make sense only with chardev. The code > appears to silently ignore them unless chardev is given. Except it > still rejects ioeventfd=on,msi=off. I wouldn't bet on nonsensical > combinations to actually work. I haven't tried all combinations, to me it's not a bug if an argument is silently ignored, but we are missing a warning. > qemu-doc documents role only with chardev. The code doesn't care. yeah, role is only really useful with a server. Another missing warning. > size makes sense only with shm and chardev. If you specify it with > memdev, it's ignored with a warning. Ah! it's probably fine then? > With shm, we first try to create the shared memory object with the > specified size, and if that fails, we try to open it. The specified > size must not be larger than the shared memory object then. > > With chardev, we receive the shared memory object from the server. > Until we get it, BAR isn't mapped. If the specified size is larger, the > BAR remains unmapped. yep > use64 sets PCI_BASE_ADDRESS_SPACE_MEMORY. Not documented in qemu-doc. I don't think all properties are documented, are they? Gerd added this in c08ba66f with pretty good commit message that we could adapt to add in documentation. > This is a byzantine mess even for QEMU standards. > > Questions: > > * Is it okay to have an unmapped BAR? I can't say much, though I remember I did some tests and it was ok. > * We actually have two distinct device kinds: > > - The basic device: shm with parameter size, or memdev > > - The doorbell-capable device: chardev with parameters size, vectors, > ioeventfd=on, msi > > Common parameters: use64, role, although the latter is only documented > for the doorbell-capable device. > > Why is this a single device model? No idea, but I agree it would make sense to have two different devices. > It's not even obvious to me how the guest is supposed to figure out > which kind it has. I don't think it can easily: I can imagine sending a doorbell to yourself, but that wouldn't be really reliable either. > * shm appears to be the same as memdev, just less flexible. Why does it > exist? It was there before. > * Are we *sure* this is ready to become ABI? I doubt it's ABI yet, > because before Marc-André's massive rework, it was even worse (*much* > worse), to a degree that makes me doubt anybody could use it > seriously. It's supposed to be the same ABI as before, with the memdev addition.