Jens Nerche wrote:
> >All of the monitor structures are mapped into an address
> >space spanned by one page table (a 4MByte span).
> >This is done for convenience so we can migrate the such structures
> >within the address space efficiently and easily, if the guest ever
> >requires the use of a linear address within that range.
> >Likely we have placed the monitor in a portion of the address space
> >in which the guest doesn't use.
> Plus the code to switch between host and guest, you called it 'nexus'.
Sure, I was considering the nexus as part of the monitor.
> >We have also allocated memory for the guest's physical memory,
> >though for now let's say we have not yet mapped any of it into
> >the monitor's address space.
> And stored pointers to allocated page frames in a table. This table
> we can use for a third level, software implemented address translation,
> useful for virtualizing page tables.
OK, I'll add something like this to the text. It may help to mention
we are storing the physical addresses in an array.
> >The guest is to begin execution at a given address in
> >it's linear address space. As the guest begins executing at this
> >address which is not yet mapped into the monitor, the monitor will
> >receive a page fault. This is given that we mark all unused address
> >space with an entry in the page tables such that a page fault occurs.
> Hm, some month ago a asked a question in the same direction: do we need
> a own pager in monitor or not? The reaction was that all paging stuff
> should do the guest and after a while of thinking I also agreed that this
> is a good point. Why do you suggest a pager? For now, we give the
> guest all the memory we allocated for it just at start point and spare
> performance decreasing page faults. One argument could be: save memory.
> But if we give the guest "8 megs of RAM" the guest will try to use this
> 8 megs. I prefer the method discussed some weeks ago: withdraw pages
> dynamically.
> And for virtualizing page tables I prefer the method I mailed to you,
> Kevin.
The way I explained this was intended so people could understand
the way virtualizing the linear address space works. It wasn't
a vote for a particular implementation. It is a lot easier to
understand something when you can start with a clean slate, and
build on it.
I usually like to present something in the simplest most clean
approach, and then offer a more efficient variant of it. This
is why I noted later that we can do the mapping ahead of time,
in chunks or in whole.
Whichever way we do this, we can still use the 'withdraw' method
we talked about some time ago to allow the host to swap pages.
Reasons not to do this dynamically:
- performance.
Reasons to do this dynamically:
- Can add a put-in-service timestamp for instrumentation and stats
- Depends on how populated the guest addr space is. To populate
the full 4GByte space, it would take 1024 page tables = 4MBytes
of page table space that we'd have to allocated for the monitor.
Keep in mind, many linear pages can be mapped to the same
phy addr, so a guest could do all kinds of funky stuff.
You sure wouldn't want to race through rebuilding 1 million
page table entries every time slice. Not that this will
be our normal case, but it keeps you honest. :^)
I'll read your ideas so I can comment on those.
> >For situations where the guest OS gropes physical memory
> >to determine the amount of memory installed, we must handle
> >this in such a way that the guest determines that memory
> >beyond the amount which we have allocated, does not exist.
> There are two situations: guest activated paging unit or not.
> Without paging, the guests linear address is its physical address.
> An access to an address higher than the range we allocated for
> guest should result in a page fault delivered to the guest.
> We simply have to compare faulting address with number of bytes
> we allocated as guest's physical memory.
> With activated paging, the monitor has to parse guest's page
> table - just as above with the "real page fault in the guest".
> I don't see a real difference.
We're talking in terms of physical memory here. The paging
unit deals in protections at the linear address level. If
you access bogus physical memory, the paging unit does not deliver a
page fault.
> >The problem with this approach is that it involves heavy
> >overhead to handle the execution of such guest code.
> Oh, we can hope that a well programmed guest tryes not often
> to access non-existent physical memory. ;) And even when
> guest applications do so, in most cases they were closed
> down and this take a lot longer than our emulation code.
> Hm, does anybody know what happens in a real computer while
> accessing non-existent memory? Page fault or vanishing access?
What I'm concerned with is not application access to bogus memory.
It's OS access to phy memory to check the size of memory. I'm not sure
how problematic it is, but I pretty much just want to speed up
boot times. I hate waiting for something to boot. If it's as
simple as mapping to truly non-existent mem, then we should do
that.
-Kevin
