netdev - Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <541583E0.7050504@oracle.com>
Date:	Sun, 14 Sep 2014 08:02:40 -0400
From:	David L Stevens <david.stevens@...cle.com>
To:	Raghuram Kothakota <Raghuram.Kothakota@...cle.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version
 1.6

On 09/13/2014 11:30 PM, Raghuram Kothakota wrote:
> I have a question around bumping the sunvnet vio_version to 1.6.
> Each of the versions from 1.0, have a specific feature or behavior defined in the
> protocol, if a given version is negotiated then peers will assume the Guest
> can handle all those feature/enhancement automatically. If a given feature
> is not supported or implemented, it may be best to handle those cases gracefully.

It doesn't (and shouldn't) assume it supports any feature that isn't negotiated, and
the code I submitted does not support or negotiate receive rings, for example. It
therefore does not set the bit. The VIO protocol can negotiate TSO,
which is not supported on Linux, so it doesn't set VNET_LSO_IPV4_CAPAB. And,
as in your example, we don't want physical link state updates, so we use
PHYSLINK_UPDATE_NONE (==0).

I implemented from the VIO protocol spec and verified interoperability by testing
with pre-patched Linux (VIO v1.0) and Solaris 11.1 and 11.2.

> For example, if version 1.3 or higher is negotiated, then Guest is assumed to
> support vlan packet processing.

Nobody should *assume* VLAN support is there based on the VIO protocol version. v1.3
and higher require from the driver that there be space for a vlan header, which I have
added in the patch. I did not do anything else with VLAN processing, because this is
not a patch to add VLAN support, and nothing requires Solaris to enable it. It is no
different with respect to VLAN support than it was before the patch, meaning that if
an admin tries to use a feature that isn't supported on all the machines, it won't
work, just as it wouldn't work pre-patch to enable VLAN on Solaris and try to use it
with Linux over sunvnet. The patch is to update the VIO protocol, which is the layout
and semantics of the fields. It is not to support every feature that can be negotiated
within the protocol.

								+-DLS

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html