Xen devel - Apr 2006 - 3.0.2-testing: pci_set_dma_mask, pci_set_consistent_dma_mask(pci, 0x0fffffff) returns < 0 (ICE1712)

Hi all,

I''m currently running on Ubuntu Dapper and xen 3.0 testing. I noticed
my
sound card didnt work.

I looked in dmesg and found this:

Apr  9 17:49:29 phoenix kernel: [   27.490852] architecture does not
support 28bit PCI busmaster DMA

Grepping the kernel I came up with this, from sound/pci/ice1712/ice1712.c:

        /* check, if we can restrict PCI DMA transfers to 28 bits */
        if (pci_set_dma_mask(pci, 0x0fffffff) < 0 ||
            pci_set_consistent_dma_mask(pci, 0x0fffffff) < 0) {
                snd_printk(KERN_ERR "architecture does not support 28bit
PCI busmaster DMA\n");
                pci_disable_device(pci);
                return -ENXIO;
        }

I commented it out, and the module loaded but I got a burst of static
from the speakers. I suspect that this code is incompatible with Xen.

Why does Xen not allow the dom0 to set these parameters? My development
workstation is my main home box, and I like to have sound on it.

Thanks

Tom





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

>         /* check, if we can restrict PCI DMA transfers to 28 bits */
>         if (pci_set_dma_mask(pci, 0x0fffffff) < 0 ||
>             pci_set_consistent_dma_mask(pci, 0x0fffffff) < 0) {
>                 snd_printk(KERN_ERR "architecture does not 
> support 28bit PCI busmaster DMA\n");
>                 pci_disable_device(pci);
>                 return -ENXIO;
>         }
> 
> I commented it out, and the module loaded but I got a burst 
> of static from the speakers. I suspect that this code is 
> incompatible with Xen.
> 
> Why does Xen not allow the dom0 to set these parameters? My 
> development workstation is my main home box, and I like to 
> have sound on it.
Xen''s allocator currently only supports a 31 bit DMA zone, which is
sufficient for the vast majority of hardware devices. I guess you could
try hacking the constants, but you might exhaust a 28b pool.

Ian 

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

On 12 Apr 2006, at 13:14, Ian Pratt wrote:
>> I commented it out, and the module loaded but I got a burst
>> of static from the speakers. I suspect that this code is
>> incompatible with Xen.
>>
>> Why does Xen not allow the dom0 to set these parameters? My
>> development workstation is my main home box, and I like to
>> have sound on it.
>
> Xen''s allocator currently only supports a 31 bit DMA zone, which
is
> sufficient for the vast majority of hardware devices. I guess you could
> try hacking the constants, but you might exhaust a 28b pool.
I think we will support it out of the box when I get some more time to 
hack on the Xen memory allocator.

  -- Keir


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

Hi,

On Wed, 2006-04-12 at 17:55 +0100, Keir Fraser wrote:
> I think we will support it out of the box when I get some more time to 
> hack on the Xen memory allocator.
Are there plans to extend it to allow targeted freeing of memory in
specific physical regions?  That would improve the ability to support
odd dma masks, but would also directly improve other things like the pgd
starvation issue that we''re currently working around with the
lowmem_emergency_pool.  It would be good to have a generic approach to
that which did not require custom boot parameters.

--Stephen



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

On 12 Apr 2006, at 18:15, Stephen C. Tweedie wrote:
>> I think we will support it out of the box when I get some more time to
>> hack on the Xen memory allocator.
>
> Are there plans to extend it to allow targeted freeing of memory in
> specific physical regions?  That would improve the ability to support
> odd dma masks, but would also directly improve other things like the 
> pgd
> starvation issue that we''re currently working around with the
> lowmem_emergency_pool.  It would be good to have a generic approach to
> that which did not require custom boot parameters.
I''m not sure what you mean. Can you give a simple example?

  -- Keir


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

Hi,

On Wed, 2006-04-12 at 18:19 +0100, Keir Fraser wrote:
> > Are there plans to extend it to allow targeted freeing of memory in
> > specific physical regions?  That would improve the ability to support
> > odd dma masks, but would also directly improve other things like the 
> > pgd
> > starvation issue that we''re currently working around with the
> > lowmem_emergency_pool.  It would be good to have a generic approach to
> > that which did not require custom boot parameters.
> 
> I''m not sure what you mean. Can you give a simple example?
On raw metal, when we start to get low on a specific memory zone, either
for DMA24/DMA32 or on a specific NUMA node, we can start to specifically
reclaim pages from that memory zone, swapping them out or simply
evicting cache.

If the Xen HV runs out of MEMZONE_DMADOM pages, aren''t we basically out
of luck right now?  Xen guests can''t see that shortage, nor does the
vmscan.c code have any code to target pages for stealing based on MFN
rather than PFN.

--Stephen



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

On 12 Apr 2006, at 19:53, Stephen C. Tweedie wrote:
> On raw metal, when we start to get low on a specific memory zone, 
> either
> for DMA24/DMA32 or on a specific NUMA node, we can start to 
> specifically
> reclaim pages from that memory zone, swapping them out or simply
> evicting cache.
>
> If the Xen HV runs out of MEMZONE_DMADOM pages, aren''t we
basically out
> of luck right now?  Xen guests can''t see that shortage, nor does
the
> vmscan.c code have any code to target pages for stealing based on MFN
> rather than PFN.
Yes, if that happens then we could be in trouble. Although mostly low 
memory is allocated for devices only at start of day. The main fly in 
the ointment is PAE pgds. We get around that right now by reserving a 
lowmem pool in Xen that normal allocations cannot fall back to. That 
sorts out most kinds of bad behaviour. We would need the guest kernels 
to help out with reclamation (at least for guests not on shadow page 
tables). If Linux had support for hotplug memory (add and remove) I 
suspect we could make use of that to help out, if we were careful.

  -- Keir


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

Hi,

On Thu, 2006-04-13 at 08:46 +0100, Keir Fraser wrote:
> > If the Xen HV runs out of MEMZONE_DMADOM pages, aren''t we
basically out
> > of luck right now?  Xen guests can''t see that shortage, nor
does the
> > vmscan.c code have any code to target pages for stealing based on MFN
> > rather than PFN.
> Yes, if that happens then we could be in trouble. Although mostly low 
> memory is allocated for devices only at start of day. 
DomU creation too, if we''re using driver domains, I guess.  But
that''s a
minority case right now.
> The main fly in 
> the ointment is PAE pgds. We get around that right now by reserving a 
> lowmem pool in Xen that normal allocations cannot fall back to.
Right, although that pool defaults to empty unless you manually
configure it.  It would be good if we could avoid the fragility of
requiring custom intervention to set this up.
>  That 
> sorts out most kinds of bad behaviour. We would need the guest kernels 
> to help out with reclamation (at least for guests not on shadow page 
> tables). If Linux had support for hotplug memory (add and remove) I 
> suspect we could make use of that to help out, if we were careful.
Or simply get the balloon driver to target the appropriate pages.  The
problem with using hotplug memory is that that generally works on the
basis of ranges of physical addresses, not machine addresses.  

--Stephen



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

On 13 Apr 2006, at 20:05, Stephen C. Tweedie wrote:
>>  That
>> sorts out most kinds of bad behaviour. We would need the guest kernels
>> to help out with reclamation (at least for guests not on shadow page
>> tables). If Linux had support for hotplug memory (add and remove) I
>> suspect we could make use of that to help out, if we were careful.
>
> Or simply get the balloon driver to target the appropriate pages.  The
> problem with using hotplug memory is that that generally works on the
> basis of ranges of physical addresses, not machine addresses.
Is there a VM interface to allow you to say ''please terminate usage of 
*that* page''? That could be extremely useful!

  -- Keir


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

Keir Fraser wrote:
> Is there a VM interface to allow you to say ''please terminate
usage of
> *that* page''? That could be extremely useful!
Could it?
Such an interface sounds extremely prone to race conditions to my ear.

(I know you''re a much smart man than I, so I''m almost certain
that my
perception of a race problem is wrong.  I''m just asking because
I''m
curious - sorry :-).)

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

On 14 Apr 2006, at 08:53, Molle Bestefich wrote:
>> Is there a VM interface to allow you to say ''please terminate
usage of
>> *that* page''? That could be extremely useful!
>
> Could it?
> Such an interface sounds extremely prone to race conditions to my ear.
Well, it does depend on how the interface is defined. What you want is 
to be able to tell the VM system to stop using a page, not to reuse it, 
and not to put it on the usual free-page lists. Quite how the transfer 
of ''ownership'' of that page to e.g., the balloon driver is
enacted
would perhaps be a subtle issue. I was mainly wondering whether 
anything like this already exists in the Linux kernel -- because adding 
it from scratch could be a huge pain. Unfortunately I think that huge 
pain is why patches to do hotplug memory removal have not been added to 
the mainline Linux tree.

  -- Keir


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