qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 1/1] linux-user: Probe the guest base for sh


From: Paul Brook
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] linux-user: Probe the guest base for shared objects when needed
Date: Thu, 28 Jun 2012 03:42:44 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.8.3; x86_64; ; )

> 'guest_validate_base' is currently called for three reasons: (1) in main.c
> when using -B, (2) in main.c when using -R after mapping the reserved va
> region, and (3) and when probing for a guest base in probe_guest_base.
> 
> For case (1) I suppose things are pretty much the same -- we just need to
> map the extra region when needed (e.g. for the ARM kernel helpers).

Yes.
 
> For case (2) maybe we can do a probing similar to what I mentioned here
> [1], but taking into account what you stated above and ensuring that the
> probing finds a single region for the request va region size and any
> needed extra stuff.

Something like that, yes. I suspect there are better ways to implement it 
though.  In principle your patch is making (2) a variant of (3). Instead of 
probing for the segments covered by the image we probe for the reserved 
regions (e.g. for ARM [0-reserved_va, 0xffff0000 - 0xffffffff]).  A good 
implementation should automagically DTRT for both 32-bit and 64-bit hosts.

> Case (3) is mostly the same as (2) but we are probing for a guest base with
> a region size deduced from looking at the image we are loading.  I suppose
> it is still OK to map two regions here.  The single region only applies to
> -R?

I'd say (3) is more similar to (1).  There's no fundamental reason why -R has 
to allocate a single block.  In all cases we should be checking the same thing 
- are the addresses we need available on the host?  Having different code 
paths calling guest_validate_base, etc. for different reasons makes me think 
we're doing it wrong :-)

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]