WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH 4/6] xen/netback: Always pull throughPKT_PROT_LEN

On Wed, 2010-02-24 at 09:23 +0000, James Harper wrote:
> > 
> > On Wed, 2010-02-24 at 08:28 +0000, Jan Beulich wrote:
> > > Could you point out what problem this addresses?
> > 
> > It ensures that at least the TCP/IP headers will be pulled into the
> > linear part of the SKB. At least skb_checksum_setup relies on this and
> I
> > think it is a more generic assumption in at least some parts of the
> > network stack as well. The next patch increases PKT_PROT_LEN to
> include
> > the TCP options as well since we have observed cases where Windows
> > guests with PV drivers can generate a frame with a split at the point.
> > 
> 
> My PV drivers couldn't always be relied on to do this, because Windows
> couldn't be relied on to do it either. I just coalesced the first buffer
> to some minimum value depending on the header type. If you are doing TCP
> checksum offload then you have to tell Windows that you support IP
> checksum offload too - Linux doesn't support that so you have to lie to
> Windows about it and calculate the IP checksum in the PV drivers, and if
> you are doing that you have to have your own copy of the header anyway
> so it turns out not to be a big deal.

Yes, it's best if the guest takes care of this in the common case but
domain 0 can't trust the guest so we need a backstop in netback too. If
the guest is doing the sane thing the backstop shouldn't trigger.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel