| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: changeset 13403 ...
On 29/1/07 14:47, "Gerd Hoffmann" <kraxel@xxxxxxx> wrote:
>>> Two pagetable switches in a single multicall? First switch is to a pagetable
>>> which maps only the multicall structure. This small intermediate table has
>>> to be mapped read-only in the original pagetables and in the final
>>> pagetables, but it will only be a few pages of memory (4 in the worst case).
>
> Helps a bit, but doesn't solve the fundamental problem that I can't use
> the page tables created by the domain-builder as-is.
That's not fundamental. You know where those pagetables are. You can walk
them and you can modify them. You may even know that they only map part of
the guest physical memory and so choose to locate the intermediate
pagetables outside that mapped area. Then perhaps you can get away with
needing to modify the builder pagetables at all?
>> Oh, it'll need a hypercall transfer page too. And it's a mmuext_op list that
>> you need, not a multicall. The transfer page and mmuext_op list can be
>> placed in adjacent pages so that you don't need any more intermediate
>> pagetable pages.
>
> Hmm. hypercall transfer page? The one with the int 82h instructions?
Yes. But actually I meant an mmuext_op array.
> Is the mmuext_op list copyed over before running it? If so, the it
> should not be required to be mapped all the time, right?
It gets written back to with hypercall result. Mmuext_op arrays also get
read from for each individual sub-operation.
> In that case I
> could get away with an empty page as page directory? Or maybe even
> baseptr=NULL?
No and no, I'm afraid. It's not quite that easy.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home