[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [virtio-dev] Propose to report the offset addr back from vhost to virtio
> -----Original Message----- > From: Stefan Hajnoczi [mailto:stefanha@redhat.com] > Sent: Friday, November 10, 2017 5:31 PM > To: Tan, Jianfeng > Cc: virtio-dev@lists.oasis-open.org; Michael S. Tsirkin; Liang, Cunming; > Gasparakis, Joseph; 'Jason Wang' > Subject: Re: [virtio-dev] Propose to report the offset addr back from vhost to > virtio > > 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? We could memset it to zero before returning it back to virtio; but that cannot protect from a malicious VM which keep snooping on the memory. What's worse, the malicious can still write that buffer. Hmm, indeed, it's an unsecure solution. > > 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. Thank you for your insight here. Thanks, Jianfeng > > Stefan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]