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

xen-devel

[Top] [All Lists]

Re: [Xen-devel] USB virt status --- Help please!!!

To: Muli Ben-Yehuda <mulix@xxxxxxxxx>
Subject: Re: [Xen-devel] USB virt status --- Help please!!!
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: 2005年11月15日 10:23:40 +0000
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, sanjay.kushwaha@xxxxxxxxx, mark.williamson@xxxxxxxxxxxx
Delivery-date: 2005年11月15日 10:18:20 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20051114214609.GC24964@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D32E930@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1131906498.7898.20.camel@localhost > <aa8e1dea0e3038d0d50d615fe9049458@xxxxxxxxxxxx> <1131963126.28635.3.camel@xxxxxxxxxxxxxxxxxxxxx> <4b44eaf35c9bb921b7940c157936c38a@xxxxxxxxxxxx> <1131989401.3989.19.camel@xxxxxxxxxxxxxxxxxxxxx> <681ca7ec21d7aac712bae9e9cde2c493@xxxxxxxxxxxx> <1131994239.3989.41.camel@xxxxxxxxxxxxxxxxxxxxx> <20051114214609.GC24964@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 14 Nov 2005, at 21:46, Muli Ben-Yehuda wrote:
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?
I think we certainly do. swiotlb will already avoid bouncing where
possible via the checks for address_needs_mapping(). Is swiotlb
prohibitively expensive even when no bouncing is necessary? if yes, we
could either trim it down or just use it selectively as I outlined
earlier on a per bus / device / subsystem basis.
Not expensive in time, but it does waste memory if it's unused. Currently we allocate a 64MB aperture if the machine has memory mapped above 2GB (this catches devices like aacraid that can only address 31 bits). I could also allocate an aperture of, say, 2MB for smaller systems. There is of course a tension between not wasting memory yet having a big enough aperture that the system will not run out of iommu space and crash even when stressed.
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: [Xen-devel] [PATCH] fix kbd issue on 2.6 kernel in vmx guest. , Ling, Xiaofeng
Next by Date: Re: [Xen-devel] FW: [Xen-ia64-devel] [Patch] gcc3.4 build patch , Keir Fraser
Previous by Thread: Re: [Xen-devel] USB virt status --- Help please!!! , Muli Ben-Yehuda
Next by Thread: Re: [Xen-devel] USB virt status --- Help please!!! , Muli Ben-Yehuda
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /