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/
Home Products Support Community News


Re: [Xen-devel] Re: pci passthrough xhci host controller

To: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: pci passthrough xhci host controller
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 27 Sep 2010 11:59:52 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 27 Sep 2010 09:01:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1227438201.20100921220310@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1262837074.20100915230935@xxxxxxxxxxxxxx> <20100920203344.GA26201@xxxxxxxxxxxx> <1227438201.20100921220310@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Sep 21, 2010 at 10:03:10PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> I indeed have the feeling the memleak's aren't huge, and adding the diverse 
> kernel hacking debug options, ended op doing more wrong than right.
> I have turned off the options i added, re-instated the "swiotlb=force" in the 
> domU config to see if it goes from a working to a freezing config, but i have 
> the feeling it will not make a difference.
> Then i have 4 differences left:
> - Other dom0 kernel since the tests resulting in continous freezes of my 
> server
> - Other domU kernel since the tests resulting in continous freezes of my 
> server
> - Other workload (server is running more VM's)
> - Other physical hardware
>         - server is AMD phenom X6, current config Intel quad core
>         - Both have there iommu disabled
>         - Both are 64 capable cpu's with 64 xen, dom0 and domU
>         - But most notably perhaps, the intel has only 2GB RAM, the server 8GB
> Could the available physical RAM be an issue here ?
> I limit the ram for dom0 with dom0_mem=

OK, but that would not limit the memory of where the guest get their memory. I 
you might need this in conjunction with maxmem, say: maxmem=4GB 

This way your 8GB machine has 4GB of memory available for both dom0 and the 

> After this test succeeds on the intel machine, i will retry the samen 
> xen,dom0 kernel and domU kernel on the AMD config.
> Is there anything i can especially log/configure/debug to get more detail to 
> see if the 8GB could be the problem ?

I think we have concluded that the device in question (3.0 PCIe USB host 
controller) can do
64-bit DMA. In which case the SWIOTLB is only used as an address translation 
(pfn -> mfn, and vice-versa). If it was 32-bit it would also be utilized for 
the DMA buffers - there are sometimes cases were the driver does not sync after 
the bounce
(perfect examples are the existing radeon/nouveau drivers) ending up with 
device. But those show up early in development, and this is the new USB 
controller than
can do 64-bit instead of the dreaded 32-bit limit that all other USB 
controllers are stuck
with it.

The memory difference might be a red-herring. It could be the workload - more 
and a latency issue (say we are waiting for an IRQ and it comes just a bit too 
I think the idea of narrowing down on the AMD machine the amount of memory 
could help.

What is the exact model of your USB capture device and the USB PCI device?

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>