Haven't had the time to look at this in detail, but
here are some brief comments.
Ulrich Weigand wrote:
> this patch activates PDBR switching to a real monitor/guest page directory.
> (The patch applies against fwm-19990822b.)
Cool :). Looks good.
> - Remove the dynamic allocation of interrupt reflection stubs (sorry Ramon :-/).
> These stubs are called in the guest VM, so using kmalloc() -- which
> returns some arbitrary address inside host physical memory -- to
> allocate them is not a real good idea ;-) I've moved them to memory
> inside the module's data pages.
I don't like your array (you knew it ;)). The structure,
according to my calculations, takes up more than half a
page of memory ((4+4+1+1)*256 = 2560 bytes.) We want to
minimise the amount of memory that needs to be shared between
the monitor and the host, because the more pages need to be
shared the more of a nuisance the monitor is going to be.
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.
> Before I'm implementing this, I'd like you all to test this patch;
> I've tested it only on Linux 2.0.36 ...
I'll test it on my 2.2 box tonight.
> Also, testing with various
> versions of gcc and/or ld to find out whether the linker script works
> would be great (note that GNU ld is now required ...).
The linker script looks sane to me... I think that in
order for that not to work you need a REALLY old version
of ld :)
> (Please do sync your disks before testing; I've managed to trigger
> triple faults more than once while implementing this :-/)
Heh, I'm kinda used to crashes by now ;)
How nice it would be if linux has a journalling filesystem...
Crashing is okay, but those fsck's every time are driving
me crazy :)
> + /*
> + * 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 ?
I can't imagine you can't do this, as many hardware drivers need
to know the physical address of a buffer in memory.
Ramon
