[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen kernel 2.6.18 bug with a d-link DFE 580TX - pci hide

On 26/10/08 10:48, "Michael Kapp" <tquarkk@xxxxxxxxxx> wrote:

>>>> Add swiotlb=force to your domain's kernel command line.
>>> I set swiotlb=force in the domU conf, that doesn't fix it - also with
>>> noirqdebug.
>> That should be impossible since the line you are bugging on will not be
>> executed if the swiotlb has been successfully enabled. Do you get a line in
>> dmesg stating "Software IO TLB enabled"? If not then is CONFIG_SWIOTLB
>> enabled in your kernel config (should happen by default). The file
>> lib/swiotlb-xen.c should be getting built and you'll see there is code near
>> the top of that file to parse swiotlb=force which sets swiotlb_force and
>> should cause swiotlb_init() to do the right thing (which should get called
>> via the path mem_init->pci_iommu_alloc->pci_swiotlb_init->swiotlb_init.
> yeah - your right! My domU config was wrong, with swiotlb=force it's
> working, thanks!
> Can you tell me what this parameter is doing in detail, or where i can
> find docs about it?

The network card is only capable of 32-bit DMA. So for addresses above 4GB a
bounce buffer is required (DMA to/from bounce buffer; then copy to/from
proper high-memory buffer using host CPU). The swiotlb is basically a
pre-allocated bounce-buffer area. Because it is pre-allocated it is a waste
of memory if it isn't used and, since domUs do not normally perform real
physical I/O directly, we therefore by default only create a swiotlb for
dom0. You then have to override on the cmdline if this default doesn't
actually work (as in this case).

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.