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@...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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main