Increasing guest memory in Vancouver
Markus Partheymueller
mail at ...119...
Tue Jul 31 09:44:04 CEST 2012
Hi Norman,
thanks for your explanations. Now I know that I should not use
0x47000000 as link address ;)
My experiments are not yet made publicly available. Right now I am
trying to setup an environment to run Fiasco/Fiasco.OC in a VM,
investigating the problems to be solved. But mainly I am working on
understanding the architecture of Vancouver/Genode/NOVA, running into
several issues, which are in the process of being explained/resolved.
My question is of this broad nature because if my not yet very
targeted work ;)
But for now, thanks for the insights again and be aware, I'm afraid I
will come back to you with more (specific) questions ;)
Regards
Markus
On 30 July 2012 19:56, Norman Feske <norman.feske at ...1...> wrote:
> 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
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
More information about the users
mailing list