Ramon van Handel <[EMAIL PROTECTED]> wrote:

> Can't we do something like this:  allocate a shared page
> for the monitor heap, and define our own mon_alloc() and
> mon_free() functions to allocate memory within the heap.
> When the heap overflows we allocate another page, etc.
> That way we minimise the amount of monitor memory that
> needs to be mapped into the guest address space.

Well, we might need an allocator some time, but I'd prefer to
get by with just a page-level allocator;  everything else is
non-trivial to get right (fragmentation issues and all that stuff).
You need to that care that the code needed to implement this doesn't
take more space than what you save :-/

(In the specific case of the interrupts, you know that I'd prefer
to redirect all interrupts anyway, in which case we don't need 
dynamic allocation either ;-)

> > +    /*
> > +     * Grrr.  There doesn't seem to be an exported mechanism to retrieve
> > +     * the physical pages underlying a vmalloc()'ed area.
> 
> Isn't that what virt_to_phys() is for ?  Or am I confused ?

virt_to_phys() can only be applied to addresses retrieve by get_free_page()
(or one of the services that uses get_free_page() as underlying mechanism,
like kmalloc()).  Those are the addresses that point inside the 
identity mapping of all physical memory inside kernel space, so the
implementation of virt_to_phys is trivial: just subtract the base 
address of that identity mapping range from the given address, and
you have a physical address.  (In fact, on Linux 2.0 this base address
happens to be zero, so virt_to_phys is completely trivial.)

Something completely different is vmalloc(), which returns addresses
in the kernel virtual address space, but *after* the identity mapped
region.  The point of this is to be able to fulfil *large* allocation
requests, without having to use large *physically contiguous* regions
of memory: every call to kmalloc() or so returns a physically contiguous
region of memory, while the physical memory underlying a vmalloc()'ed
area consists of arbitrary physical pages, which are sorted into the
virtual memory range in question by populating the page tables.

Thus, to find out those physical addresses, you need to walk
page tables, which virt_to_phys() definitely doesn't ;-)


> I can't imagine you can't do this, as many hardware drivers need
> to know the physical address of a buffer in memory.

Yes; they have to allocate that buffer using get_free_pages(), then.
(They probably need physically contiguous memory anyway ...)

Bye,
Ulrich

Reply via email to