On 05/12/2010 07:14 PM, Cam Macdonell wrote:
Why can't we complete initialization before exposing the card and BAR?
Seems to be the simplest solution.
Looking at it more closely, you're right, the fds for shared
memory/eventfds are received in a fraction of a second, so that's why
I haven't seen any problems since the memory is mapped before the BIOS
detects and configures the device.
We can't block on a qemu char device (in anyway I can see) so we have
to handle mapping the memory BAR in the callback function. But, we
can make the semantics that the VM ID is not set until the memory is
mapped. So if the VM ID is -1, then the memory has not been mapped
yet, reads/writes work but don't do anything useful. So the user can
detect the mapping of the memory
and it does not invalidate PCI since the BAR is always present, but
just not mapped to the shared memory.
I don't like this very much. We expose an internal qemu implementation
detail, the lack of ability to complete negotiation during init, and
make the device more error prone to use.
However, it does make some sense if we regard the device as an HBA
accessing an external memory, so it's not unreasonable. But please be
sure to document this.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
