Re: [Xen-devel] pvops dom0: no sound after boot; possibly causedby swiotlb

[Ronny.Hegewald@xxxxxxxxx]

>Well, since you are volunteering. The problem sounds like the sound card
>allocates a buffer from the region above 4GB and tries to DMA to it.
>Keep in mind that on most machines, when you have 4GB, 768 MB of it are 
>offset
>past the 4GB mark. You have these two mega regions: 0-3.3GB, 4GB-4.7GB,
>the 3.3GB to 4GB is called the PCI hole.

I added some log-messages in the sound-driver and indeed, it allocates memory 
from above 4GB.

On bare metal and with dom0 based on the forward-ported xen-patches from gentoo 
the dma-memory is allocated in the 4GB range.

When i checked the dma-memory allocation in the driver i noticed that depending 
if the sound-card reports that it is 64bit-compatible the driver sets the 
dma_mask to 64, else to 32 (by calling pci_set_consistent_dma_mask).

So i changed the driver that it always sets the dma-mask to 32 - and the sound 
worked without the need to start a domU. 

Which left the question why it didnt worked out of the box on pvops-dom0.

So i followed the code for the dma-allocation from the sound-driver and found 
the problem in the xen-swiotlb code in arch/x86/xen/pci-swiotlb.

Bare metal and the forward-ported dom0 both call dma_alloc_coherent_mask if 
they try to allocate coherent dma-memory - pvops dom0 doesnt. This call sets 
the DMA-mask to 24 bit when __GFP_DMA is set, else to 32-bit. 

I guess this is the right fix for pvops-dom0 too? I will sent a proper patch 
for that soon.

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