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

["Siddha, Suresh B" <suresh.b.siddha@xxxxxxxxx>]

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.

thanks,
suresh

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