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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> But thats not quite all whats dma_alloc_coherent does. As it only returns a 
> 32-bit variable all coherent_dma_mask over 32-bit get casted down. This way 
> bare-metal makes sure that the dma-mask is never over 32-bit.

Ooooh. I completly failed to notice that your dom0 was 32-bit.

But having that there would make the mask always be below
4GB, irregardless if the dom0 is 32 or 64-bit. Which is
exactly what it does on bare-metal. Hmmm, ok: 

http://kerneltrap.org/mailarchive/git-commits-head/2008/10/28/3841954

shows what made that happen.

I am bit worried on the casting - it does not seem to have been the
purpose of that change to utilize that, but that is a upstream problem.

I am curious - if you dom0 is 64-bit, does the sound card work?
> 
> Or are you are saying that when the hardware supports 64 bit and has set the 
> coherent_dma_mask accordingly and dom0 is 32-bit that the allocation of DMA 
> after the 4 GB should work fine? Because thats the assumption i see in the 
> pvops-code.

Yes. It should have worked fine.

> 
> And from what i understood so far the DMA memory should be allocated 
> preferably in the 24-bit address space or max. 32 bit address space, at least 
> in a 32-bit kernel. 
> 
> >The only difference here is that under pvops we behave badly with
> >devices that have GFP_DMA set and don't have the coherent_dma_mask
> >(which it does not seem to be the case?).
> 
> As i understand it the opposite is the case. If coherent_dma_mask is not set 
> xen_swiotlb_alloc_coherent sets it to 32-bit. That should work usually 
> (except the device needs the dma-memory in the 24-bit space). 
> 

You are right.

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