Re: Assigning contiguous memory to a driver domain

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2291 bytes --]

On 09/20/10 21:48, Konrad Rzeszutek Wilk wrote:

>>> If so, it requires nonzero Xen free memory ? And that is why when I do
>>> "ifconfig eth0 down; ifconfig eth0 up" in the driver domain the second one
>>> fails ?
> 
> There are couple of things happening when you do ifconfig eth0 up. The 
> PTE used for virtual address for the BARs are updated with the _PAGE_IOMAP
> which means that the GMFN->PFN->MFN is shortcircuited to be GMFN->MFN.
> Obviously that doesn' use any Xen heap memory. The next thing is
> that the the driver might allocate coherent DMA mappings. Those are the
> ones I think Jan is referring to. For coherent DMA mappings we just
> do page_alloc and then we swap the memory behind those pages with Xen
> to be under the 32-bit limit (xen_create_contiguous_region).
> Naturally when the driver is unloaded the de-allocation will call
> xen_destroy_contiguous_region. Loking at the code I think it swaps with
> the highest bit order (so with memory close to the end of physical space).
> 
> 

A coherent DMA mapping == continues mfns, right?

So, is there a way to assure that this page_alloc for coherent DMA
mapping *always* succeeds for a given domain, assuming it succeeded at
least once (at its startup)?

>>
>> Generally the second "up" shouldn't fail as long as the prior "down"
>> properly returned all resources. See the restrictions above.
> 
> Yeah, it might be worth looking at what it is doing to cause this. The e1000/igb
> are pretty good at cleaning everying so you can do ifup;ifdown indefinitly.
> 

But if they are so good at cleaning everything as you say, then wouldn't
that mean they are giving back the continues mfns back to Xen, which
makes it possible that they will no longer be available when we do ifup
next time (because e.g. some other drv domain will use them this time)?

> In reference to the Xen-SWIOTLB for other versions that upstream, there are a couple
> of implementations at:
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6.git
> 
> for different Linux versions. Which version of kernel do you guys use?

We use 2.6.34.1 with OpenSuse xenlinux pacthes (sorry guys, we decided
to switch to xenlinux some time ago for better suspend and DRM).

Thanks,
joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 518 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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