Increasing guest memory in Vancouver

[Norman Feske]

Hi Markus,

> experimenting with the link address of Vancouver, I encountered very
> mixed results.
> Using 0x6000000 works fine, whereas addresses like 0x47000000, 0x80000000,
> 0xa0000000 or 0xb0000000 cause pagefaults very early in the startup of Genode.
> Init complains about addresses having changed after attach.

does changing the link address of vancouver influence the behavior of
init? This is unexpected and should not happen. No matter what strange
things vancouver is doing, it should not be able to have an effect on
init. If Vancouver is able to mess up init, you have likely hit a bug. I
would appreciate a way to reproduce it.

Of the addresses you mentioned above, only 0x47000000 looks suspicious.
The virtual address range from 0x40000000 to 0x4fffffff is used to keep
thread context information (such as stacks and the UTCB). I you picked
this link address, the text segment would conflict with the context area.

>From the top of my head, I do not know why you run into problems with
the other addresses. I will need to investigate.

> This leads me to my real question: How is the link address restricted, or how
> does it affect the memory situation? Maybe you could just elaborate a
> bit more on
> how the entire memory handling works when using vancouver on Genode.

The important invariant Vancouver needs to uphold is that the lower part
if address space corresponds one-to-one to the guest-physical memory.
Let's call this low virtual area within Vancouver "guest-physical
shadow". If your virtual machine is supposed to have 256 MB of physical
memory, you will have to keep the lowest 256 MB from being used by any
ordinary memory object. That includes the link address of the Vancouver
binary.

Unfortunately, reality is just a bit more twisted than that. By taking
the paragraph above verbatim, you might expect that a Genode dataspace
attached within the guest-physical shadow area will automatically appear
in the guest-physical memory. However, this is not true. It's important
that the guest-physical shadow area is populated by using a mapping with
the 'update_guest_pt' bit set. Otherwise, NOVA won't update the guest's
physical memory. For ordinary page-fault resolutions performed by core's
pager, the 'update_guest_pt' bit is not set. For this reason, the
guest-physical shadow area is paged locally within Vancouver. The
physical backing store is acquired using core's RAM service (at
construction time of the 'Guest_memory' object) and mapped within
Vancouver at a free virtual address range. Each time, a NPT fault occurs
(when the guest OS access guest-physical memory that is not mapped), the
'_handle_map_memory' function is called. It remaps a flexpage from the
backing store to the guest-physical shadow area using the
'update_guest_pt' bit.

> Maybe that could help me find out what is causing my current problems,
> because I think it could me memory-related.

That is quite possible. When I ported the code, getting the NPT mappings
right was the most difficult part. The code may still behave wrong in
some corner cases that I just haven't hit so far. Have you tried to
cross-check my version of 'vancouver.cc' with Bernhard's original
implementation? Bernhard's code is known to work for running Linux as
Guest OS. I would recommend you to somehow cross-correlate both versions
so you may spot semantic gaps in my version.

Please excuse this overly general answer. The broad nature of your
question makes it hard to give more specific advice. ;-) Maybe you could
share more details about what you are specifically trying to do, or even
post a link to the git branch you are working on?

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth