Re: [virtio-dev] Propose to report the offset addr back from vhost to virtio

[Stefan Hajnoczi <stefanha@redhat.com>]

On Thu, Nov 09, 2017 at 01:33:11PM +0800, Tan, Jianfeng wrote:
> This proposal will be from virtio-net perspective, not sure if it helps for
> other device types.
> 
> Current status:
> VIRTIO-net "rx" path will rearm buffers for packets receiving, put the start
> addr and len on the descriptor table (or the single ring for virtio 1.1
> draft spec), vhost backend will put the packet exactly on the start addr,
> and report the real packet len back. This way does not allow the vhost
> backend to put the packet somewhere offset to the start addr.
> 
> Use case:
> When we look at vhost rx zero copy problem, we would like the NIC to put the
> packets directly onto VM memory, but this raw packet (tunnel packet) always
> contains a outer header which should be decap before VM starts receiving the
> packet. And unfortunately, not all NICs support decap. After the whole
> tunnel packet be put on the VM buffer (starting with the start addr), and
> after the vswitch's decap, we can report an "offset" back to VIRTIO
> frontend, and of course, the frontend shall honor this offset and adjust
> accordingly.
> 
> The proposal:
> We can add a new feature like, VIRTIO_NET_F_OFFSET and add a new filed in
> virtio_net_header; if this feature is negotiated, the vhost side can report
> the "offset" in virtio_net_header, and the frontend side will recognize this
> value and adjust the packet buffer accordingly.
> 
> Any comments?

Does exposing the encapsulation header to guest memory pose a security
problem?

In a simple VLAN scenario it tells the guest about the VLAN ID used on
the host.  If fancier encapsulation protocols are used there might be
additional info that the guest shouldn't see?

Besides this concern it seems like a useful virtio-net feature.

Stefan

Attachment: signature.asc
Description: PGP signature