Re: Assigning contiguous memory to a driver domain

[Rafal Wojtczuk <rafal@invisiblethingslab.com>]

On Wed, Sep 15, 2010 at 01:58:30PM +0200, Goswin von Brederlow wrote:
> "Jan Beulich" <JBeulich@novell.com> writes:
> 
> >> Well, we do have 2 driver domains in Qubes: one is the netvm (NIC
> >> drivers), and the other one is Dom0 (storage, video, etc). BTW, how is
> >> it that the drivers in Dom0 never has this problem with allocating
> >> continues memory (even if we keep xen free memory = 0)?
> >
> > Merely because post-boot there would not usually be allocations.
> 
> It is also called fragmentation.
> 
> dom0 gets its memory at the start and probably all in one big
> chunk. Other domains have to use the bits and pices that happen to be
> free when the domain is started.

It does not look right. Jan has already written
* 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.

> > Merely because post-boot there would not usually be allocations.
It is not too convincing, either. Firstly, assuming there is no dom0mem
parameter to Xen, dom0 gets all memory initially, so when dom0 boots the
first time, Xen free memory = 0 ? And drivers load fine.
Secondly, by default on Fedora, the pm-utils scripts tell NetworkManager to
turn off networking just before entering S3 sleep, and NetworkManager downs all
interfaces. It brings them up on resume. And apparently there are some
drivers, like tg3, that needs to alloc when bringing up the device. Still,
suspend/resume works when all devices are assigned to dom0.

Is it possible that swiotlb layer works differently in dom0 case ? Swiotlb
is switched on by default in dom0 case, is it correct ?

Regards,
Rafal Wojtczuk