Re: pvops dom0: no sound after boot; possibly causedby swiotlb

[Ronny.Hegewald@online.de]

>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.