> > > @@ -1202,6 +1202,10 @@ int t4vf_eth_xmit(struct sk_buff *skb, struct > > > net_device *dev) > > > BUG_ON(qidx >= pi->nqsets); > > > txq = &adapter->sge.ethtxq[pi->first_qset + qidx]; > > > > > > + if (pi->vlan_id && !skb_vlan_tag_present(skb)) > > > + __vlan_hwaccel_put_tag(skb, cpu_to_be16(ETH_P_8021Q), > > > + pi->vlan_id); > > > + > > > > So it's a purely SW implementation of the feature on the VF side? > > Does the HW enforces the configuration in any way on the VF? > Basically the PF driver passes the VLAN ID it got through ndo_set_vf_vlan to > the > VF driver. And then the VF driver reads it and requests hardware to tag it.
Problem with SW implementations is mainly that they have no effect over Malicious VFs I.e., if the purpose here is to add the VF to some vlan-tagged subnet Whereas the user is oblivious to it, a malicious user can easily modify the driver to ignore this restriction and get access to the entire network. I think one of the problems with this ndo is that it's poorly documented and thus open for various interpretations - so it's debatable what's important and what's not. [If it is properly documented anywhere, please educate me] > > Also, looks like an already tagged packet would be processed with the > > original vlan-id [instead of the one of PF has provided]. > > Is that intentional? > No, this isn't intentional. I thought VST and VGT cannot co-exist. > What should be the behavior? Are you preventing VGT configuration once VST is configured? If not, what to prevent VM user from configuring vlan interfaces on top of the VF, even if VST is configured?
