Messages in this thread | | | Subject | Re: [PATCH 2/2] virtio_net: Improve the recv buffer allocation scheme | From | Mark McLoughlin <> | Date | Fri, 10 Oct 2008 09:30:31 +0100 |
| |
On Thu, 2008-10-09 at 14:26 -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: > > > > Also, including virtio_net_hdr in the data buffer would need another > > feature flag. Rightly or wrongly, KVM's implementation requires > > virtio_net_hdr to be the first buffer: > > > > if (elem.in_num < 1 || elem.in_sg[0].iov_len != sizeof(*hdr)) { > > fprintf(stderr, "virtio-net header not in first element\n"); > > exit(1); > > } > > > > i.e. it's part of the ABI ... at least as KVM sees it :-) > > This is actually something that's broken in a nasty way. Having the > header in the first element is not supposed to be part of the ABI but it > sort of has to be ATM. > > If an older version of QEMU were to use a newer kernel, and the newer > kernel had a larger header size, then if we just made the header be the > first X bytes, QEMU has no way of knowing how many bytes that should be. > Instead, the guest actually has to allocate the virtio-net header in > such a way that it only presents the size depending on the features that > the host supports. We don't use a simple versioning scheme, so you'd > have to check for a combination of features advertised by the host but > that's not good enough because the host may disable certain features. > > Perhaps the header size is whatever the longest element that has been > commonly negotiated? > > So that's why this aggressive check is here. Not to necessarily cement > this into the ABI but as a way to make someone figure out how to > sanitize this all.
Well, features may be orthogonal but they are still added sequentially to the ABI. So, you would have a kind of implicit ABI versioning, while still allowing individual selection of features.
e.g. if NET_F_FOO adds "int foo" to the header and then NET_F_BAR adds "int bar" to the header then if NET_F_FOO is negotiated, the guest should only send a header with "foo" and if NET_F_FOO|NET_F_BAR or NET_F_BAR is negotiated, then the guest sends a header with both "foo" and "bar".
Or put it another way, a host or guest may not implement NET_F_FOO but knowledge of the "foo" header field is part of the ABI of NET_F_BAR. That knowledge would be as simple as knowing that the field exists and that it should be ignored if the feature isn't used.
Cheers, Mark.
| |