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] USB virt status --- Help please!!!

On Mon, 2005-11-14 at 13:50 -0500, Stephen C. Tweedie wrote:
> Hi,
> 
> On Mon, 2005-11-14 at 18:42 +0000, Keir Fraser wrote:
> 
> > > That got fixed that by adding an arch-specific __alloc_skb which 
> > > avoided
> > > crossing page boundaries by disabling CONFIG_DEBUG_SLAB for the skb
> > > caches.  But that fix is also something that I doubt maintainers will
> > > allow to go upstream.  I wonder if we'll find enough such special cases
> > > that we really want to have a swiotlb available, just in case, at all
> > > times?
> > 
> > swiotlb performance is pretty poor since it involves memcpy. The 
> > alloc_skb fix was pretty clean, if we're allowed an arch hook for 
> > alloc_skb. We didn;t need to hack the slab allocator itself.
> 
> There are two different questions --- whether we should rely on swiotlb
> in the general case, and whether we should have it available
> just-in-case for edge cases.
> 
> I'm not suggesting that we fix the networking problem via swiotlb.  But
> that problem does make me wonder what other edge-cases remain lurking
> that may bite users later; and if they exist, panicing the kernel when
> we get an IO we can't translate directly is a lot worse than falling
> back to a slow swiotlb path.
> 
> The fact is, on 2.6 the slab allocator can hand out objects (even
> sub-pagesized ones) that cross page boundaries.  If some driver happens
> to allocate its own objects from a slab cache and run pci_map_single()
> on them, it works fine on 2.6 mainline but breaks on Xen w/o swiotlb.
> 
> The alloc_skb is just avoiding one special case of this.  It's an
> important special case, sure, but to be robust, might we not want to
> have a minimal swiotlb cache available at all times as fallback?
> 
> --Stephen

I agree:  there has to be code in the BE somewhere to check that the
pages used by the FE are good otherwise there is a big security hole:
any FE can toast dom0 by invoking the BUG in pci_map_single.

Having swiotlb on by default would be convenient because it would
implement the checking once for all the drivers that need it.

If it's off, I'm going to at least have to implement extra checking in
the BE to avoid the security hole and my own staging if I want to
guarantee that the USB driver will work reliably.

So, I'd like it to be on as a fallback.

-- 
Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>


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