changeset 13403 ...

changeset 13403 ...

[Gerd Hoffmann]

  Hi,

Just noticed that domU kexec doesn't work any more, changeset 13403 is
the culpit.  Hmm.  No, it isn't easy to work-around ...

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: changeset 13403 ...

[Keir Fraser]

On 29/1/07 13:40, "Gerd Hoffmann" <kraxel@suse.de> wrote:

> Just noticed that domU kexec doesn't work any more, changeset 13403 is
> the culpit.  Hmm.  No, it isn't easy to work-around ...
> 
> cheers,

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).

 -- Keir

Re: Re: changeset 13403 ...

[Keir Fraser]

On 29/1/07 13:48, "Keir Fraser" <keir@xensource.com> wrote:

> On 29/1/07 13:40, "Gerd Hoffmann" <kraxel@suse.de> wrote:
> 
>> Just noticed that domU kexec doesn't work any more, changeset 13403 is
>> the culpit.  Hmm.  No, it isn't easy to work-around ...
>> 
>> cheers,
> 
> 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).

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.

 -- Keir

Re: Re: changeset 13403 ...

[Gerd Hoffmann]

Keir Fraser wrote:
> 
> 
> On 29/1/07 13:48, "Keir Fraser" <keir@xensource.com> wrote:
> 
>> On 29/1/07 13:40, "Gerd Hoffmann" <kraxel@suse.de> wrote:
>>
>>> Just noticed that domU kexec doesn't work any more, changeset 13403 is
>>> the culpit.  Hmm.  No, it isn't easy to work-around ...
>>>
>>> cheers,
>> 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.

> 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?

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?  In that case I
could get away with an empty page as page directory?  Or maybe even
baseptr=NULL?

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: Re: changeset 13403 ...

[Keir Fraser]

On 29/1/07 14:47, "Gerd Hoffmann" <kraxel@suse.de> 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

Re: Re: changeset 13403 ...

[Gerd Hoffmann]

  Hi,

> 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.

Good point, that solves at least a part of the problem, as the read-only
mapping is needed one-way only then ...

thanks,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>