On Tue, Sep 14, 2010 at 10:36:56AM +0100, Jan Beulich wrote:
> >>> On 14.09.10 at 11:24, Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > Hello,
> > Could someone guide me in the right direction with the topic of assigning
> > contiguous memory to a domain.
> > I have an issue with a PV domain that is assigned a PCI device. Sometimes,
> > the
> > driver fails to load
> > Sep 13 10:36:43 localhost kernel: [ 103.651858] iwlagn 0000:00:01.0:
> > firmware: requesting iwlwifi-4965-2.ucode
> > Sep 13 10:36:43 localhost kernel: [ 103.669105] iwlagn 0000:00:01.0: loaded
> > firmware version 18.104.22.168
> > Sep 13 10:36:43 localhost kernel: [ 103.669263] iwlagn 0000:00:01.0: failed
> > to allocate pci memory
> > The reason seems to be that the domain does not have enough contiguous
> > memory, in mfn terms.
> No, how (dis)contiguous the memory of a domain is doesn't matter
> here. What matters is whether the domain can *make* the requested
> memory contiguous, and that depends on how much contiguous
> memory Xen has at the point of the allocation.
Ah, so you are saying that regardless of whether a domain has some
contiguous memory, the driver will call xen_create_contiguous_region when
memory (via dma_alloc_coherent ?).
Slightly out-of-the-list-scope: is there a convention when a driver should
allocate DMA-able memory ? Is it safe to assume that as soon as the driver
has loaded, it will no longer need to call xen_create_contiguous_region
anymore and we can use up all free Xen memory ? Particularly, would a
network card driver need to "*make* the requested memory contiguous"
whenever creating a skbuff [*] (and creating skbuffs is a frequent thing during
network card life)?
Thank you for your answer,
[*] Admittedly, for a device with a sane MTU, skbuff should fit in a single
frame, so no issue with contiguousness here, but thinking generic.
Xen-devel mailing list