> > I guess I'm not clear what memory model you need for Minix, can you
> > clarify? What version of Minix is this? Does it really not do any
> > virtual memory of its own? Does it do any tricks at all (demand paging?
> > page sharing?), or does it run unpaged or something else?
>
> well, minix uses segmentation but doesn't use paging at all, because it's
> build to be portable and not all processers have a mmu unit(i think the arm
> doesn't and such). Im using minix 3.
OK, I thought it might be something like that; it does, after all, date back
to the days of the XT, etc.
> > Domains get a hard allocation of real memory, so when the pages get
> > populated is entirely up to the guest; Xen won't interfere.
>
> What about page faults? Will I have to have to write code to handle these,
> or can I assume that since im only ever using memory thats alreayd mapped,
> page faults wont occur?
If your builder correctly sets up the page table to map all your memory and
you never access memory that's not mapped, you'll never get a page fault.
"Correctly" here assmes "writable where appropriate" and "NX not set, where
appropriate", otherwise you'll get protection violations.
> Thats exactly what I want. Does the 64M address space need to have entries
> in my page table or can i just make my guest's pagetable from 64M-xxM.
> Also, is there are any pages allocated in this 64M address space, will they
> my allocated from the domains pool of page frames, or from dom0's?
Xen wants to be in the top of your address space... For Linux, BSD, etc. this
is above where the kernel is mapped (for this reason, the upper limit of the
kernel VA space is reduced for the native ports of these OSes). I've no idea
what Minix does here. Any pages allocated in that space belong to Xen, not
to dom0 or your domain - you never get access to them anyhow. You don't need
to care about them...
IIRC, Xen will stick its own entries into the top part of your page table:
just don't use the top part of the VA space and Xen should take care of
itself.
Cheers,
Mark
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|