> -----Original Message----- > From: Anthony Wright [mailto:anth...@overnetdata.com] > Sent: 06 September 2016 13:23 > To: Xen-devel <xen-devel@lists.xen.org> > Cc: Paul Durrant <paul.durr...@citrix.com> > Subject: Bug in hash changes to netback in 4.7.2 kernel > > When I run Xen (4.7.0) nested in VirtualBox (5.0.24_Ubuntu r108355) with a > linux-4.7.2 Dom0 kernel, none of my DomU's (linux-3.17.3) have network > connectivity because they reject all packets with the error 'Invalid extra > type: > 4'. When I run exactly the same setup on bare metal, I don't get the error > messages. > > From poking around in the code this seems to be because the 4.7.2 kernel > wrongly decides that the DomU's will understand EXTRA_TYPE_HASH, and so > attach it to the network packet. Since the DomU's don't understand the extra > info their netfront driver rejects the whole packet. >
The code in xenvif_select_queue() deliberately clears the skb->sw_hash field (which gates adding the new extra type) if the hash algorithm selected by the frontend is 'none', which should be the default. So, unless you have a frontend that is implementing the control ring protocol, but failing to recognize the new extra type I'm not how you're seeing the problem... unless somehow a packet which hash is getting into netback's start_xmit without first having gone through select_queue? > I'm guessing that the nesting is confusing the new hash code. > > I also wonder if the DomU's should simply ignore extra info that they don't > understand rather than rejecting the packet. > Yes, that would certainly be sensible. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
