This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Assigning contiguous memory to a driver domain

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Assigning contiguous memory to a driver domain
From: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 21 Sep 2010 13:28:30 +0200
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 21 Sep 2010 04:29:29 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=dAqRKsEB3YaZzV/6lfF1Df6kXNc=; b=pEwHDnnl9GZwU0hPvZbZU5TC13u0+YR8a9zfismyRo2IsmO1CJwOyJaNR5mtfzRSkO5GSVmGxC10p9vwpzHYQoQuR/LEpG9X14sFvkj7UiS61jF1sUkkEXOLf7TbLljrwwQSz6PI+AOYQoLDwZ29W8dEukzc3m9trA8kX/0WmSI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100920194836.GA25803@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C90B31902000078000163E8@xxxxxxxxxxxxxxxxxx> <4C90A32A.7010803@xxxxxxxxxxxxxxxxxxxxxx> <4C90C3200200007800016442@xxxxxxxxxxxxxxxxxx> <4C90A8E4.9090004@xxxxxxxxxxxxxxxxxxxxxx> <4C90CF39020000780001647E@xxxxxxxxxxxxxxxxxx> <87pqwfgqvt.fsf@xxxxxxxxxxxxxxxxxxxx> <20100915120626.GA2024@email> <4C90EB1102000078000164C6@xxxxxxxxxxxxxxxxxx> <20100915144413.GB2098@email> <4C91027802000078000165E8@xxxxxxxxxxxxxxxxxx> <20100920194836.GA25803@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4
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 with OpenSuse xenlinux pacthes (sorry guys, we decided
to switch to xenlinux some time ago for better suspend and DRM).


Attachment: signature.asc
Description: OpenPGP digital signature

Xen-devel mailing list