I think it's the only way to solve the problem in a virtio friendly way.
Another option would be extending the config space by a very large
size. We would have to make some changes to virtio-pci to switch to
MMIO but that's easy enough. From a high level perspective, I don't
like the idea of having the config space be extremely large and used as
a communication mechanism between guests. It really should be for
device configuration data that's relatively static. I think we abuse
the config space in the virtio-balloon driver.
Ideally, you'd have an area of guest memory sized by the guest (so there
was no intrinsic limit on table size) that was given to the host to use
as the filter tables. The only way this works with virtio is if you
send this over a virtqueue in the form of messages. You could write a
pfn to the config space but then you lose all the mapping/unmapping
abstraction that virtqueue gives you (even though we don't do anything
useful with that abstraction today :-)).
So yeah, I think a control queue is the way to go.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
