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


[Xen-devel] Re: [Patch] by default don't give all memory to dom0

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Patch] by default don't give all memory to dom0
From: "Siddha, Suresh B" <suresh.b.siddha@xxxxxxxxx>
Date: Fri, 19 Aug 2005 18:20:31 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, mark.williamson@xxxxxxxxxxxx, "Siddha, Suresh B" <suresh.b.siddha@xxxxxxxxx>
Delivery-date: Sat, 20 Aug 2005 01:18:48 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <6320da47ae30ead9a43bc18b7e878ae9@xxxxxxxxxxxx>; from Keir.Fraser@xxxxxxxxxxxx on Fri, Aug 19, 2005 at 09:44:03AM +0100
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20050818122413.C17270@xxxxxxxxxxxxxxxxxxxx> <6320da47ae30ead9a43bc18b7e878ae9@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/
On Fri, Aug 19, 2005 at 09:44:03AM +0100, Keir Fraser wrote:
> On 18 Aug 2005, at 20:24, Siddha, Suresh B wrote:
> > By default, xen needs to reserve some portion of memory to satisfy
> > SWIOTLB and other contguous memory region requests. Following
> > the current swiotlb enabling mechanism, Appended patch reserves 128MB
> > of memory on systems with more than 2GB of RAM.
> Hmmm... sounds reasonable. I'd rather have one dom0 memory parameter 
> though --- keeping dom0_mem but have +ve value mean 'allocate this 
> amount' and -ve mean 'allocate full memory - this amount'. Otherwise we 
> have two competing parameters specifying basically the same thing...
> I don't much like hacky 'policies' that hardcode default reservations 
> in the hypervisor, but I think this one is pretty sensible.

I see this incorporated in changeset #6257. Thanks. 

> > Ideally shouldn't we enable SWIOTLB in dom0 and this DMA memory 
> > reservation
> > in hypervisor by default? Otherwise we will have a problem(even on 
> > systems
> > with less than 2GB of RAM) in servicing a driver DMA request to a
> > kmalloc'd buffer which spans more than a page or the various
> > xen_create_contiguous_region() requests.
> You get a pretty clear BUG() message out if this happens. It actually 
> tells you to enable 'swiotlb=force'!  The number of drivers that 
> actually use multi-page buffers is really small -- we only fixed that 

If we decide not to support(/fix) those drivers, then we should enable
swiotlb only if the system has more than 4GB of RAM. Where is the current
2GB magic figure coming from?

> case in 2.0 a few weeks ago.
> I'd rather not waste 64MB of pre-reserved bounce buffers on 
> small-memory systems that almost certainly don't need bounce buffers.

We can have a smaller swiotlb window (couple of MB?) on small-memory systems
if we want to support the drivers doing dma_map_single to multipage buffers.


Xen-devel mailing list