Re: [Qemu-devel] Plan for using softmmu with linux-user

[gchen gchen]

Firstly, thank you very much for your details information! Based on your
details information, for me, I guess it is not quite difficult for me to
implement it. :-)


On 2015年08月14日 00:55, Richard Henderson wrote:
>
> My best guess that this is 3-4 months of work.
>

After communicated with my company related members, they can accept my
3 months time resources on it, but it includes additional things:

 - At present, except x86_64 host, tci also has issues on another archs
   (e.g. under arm host, the linux i386 graphic xcalc can not work). So
   under Alpha (or SW64), tic may also have issues (need be solved).

 - If the performance of "linux-user + softmmu + tci" is not acceptable
   (at present, I am not quite sure), we have to implement SW64 tcg host
   target instead of tci.

 - For the performance reason, I guess, we have to implment tlb_fill and
   iovec ( if SW64 support).

At present, I guess, the time point may be OK within 3 months:

 - We can use 'pipeline' way for it: when "softmmu + linux-user" are in
   reviewing, I can try to implement tci (welcome any tci related ideas,
   suggestions, and completions).

 - After 1 month later, for "softmmu + linux-user", we can divide it
   into 2 branches, one for upstream version merging, and the other for
   internal development (which need be finished within 3 months).

 - If necessary, I have to work overtime for it. (it is not our hope, it
   will have negative effect with tilegx development for upstream :-( ).

Also I maybe do another things (e.g. analyze SW64 toolchains issues with
provider), but these time resources are individual. The company accepts:
we can delay our "softmmu + linux-user" time point because of it.


> The current code within linux-user needs to be abstracted.  The new interface
> must handle several things:
>
>  (1) Finding unmapped portions of the guest address space.

I guess, I need implement it.

>  (2) Mapping anonymous memory into the guest address space.
>  (3) Mapping files into the guest address space.

I guess, I just re-use them.

>  (4) Filling in struct iovec for the host pages of a
>      contiguous guest memory block.

I guess, I need implement it, at last.

>  (5) Copying guest data to/from a contiguous host data block
>      (like lock_user/unlock_user).
>

I guess, I just re-use it.

> The current code has some of the above.
>
> With the current implementation, (2) and (3) are mostly trivial.  There is
> extra complex code to attempt these when host and guest page sizes differ, but
> it's not completely correct.  And it definitely fails when 64-bit guests
> running on 32-bit hosts attempt to map data above 4GB.
>

OK, thanks.

> We don't currently have a need for (4), as contiguous guest pages currently
> always imply contiguous host pages.  But with softmmu that will change, and 
> the
> speed of emulation for basic operations like read and write will be much
> improved if we can issue readv and writev syscalls to the host os.
>
> If (4) fails, or if there's no equivalent syscall that takes an iovec, then
> copy in/out is the only solution.  Obviously we have a solution for the 
> current
> linux-user with lock_user/unlock_user.
>

OK, thanks.

> The sets of patches that we should see will look something like this:
>
>   (A1) Define the interface, and sets of callbacks.  This, IMO, should be done
>        at the top level of qemu so that (eventually) both linux-user
>        and bsd-user can share the code.
>
>   (A2) Convert the existing two implementations to the set of callbacks.
>        Note that I consider RESERVED_VA and !RESERVED_VA (unreserved_va?)
>        different.  They do share some code, so callbacks for (4) and (5)
>        will be the same, but certainly not the callbacks for (1), (2) or (3).
>
>   (A3) Update linux-user to use the new interface, without (4).
>
>   (A4) Update linux-user to use the new call for (4), for the syscalls
>        that have iovec equivalents.
>
>   (B) Replace the define CONFIG_SOFTMMU with a variable use_softmmu.
>       In system mode (ifndef CONFIG_USER_ONLY), this should be a define that
>       is always true, so that the dead code can be eliminated.  In user mode,
>       this will be set depending on the guest mapping interface selected.
>
> At this point you've really not changed anything, algorithmically. Everything
> is working just the same as before you started, but the code is now in a form
> where softmmu can be introduced.
>

OK, thanks, hope I can send 1st related patches to upstream within 2-3
weeks.

>   (C) Create the softmmu_user implementation.  You'll need something like the
>       kernel's vm_area_struct to record ranges of guest address space
>       mappings.  It'll need to be fast, as that data structure will provide
>       the implementation for tlb_fill.
>

OK, thanks. I guess it will implement (1) and (4), which is my main work.

Welcome any additional ideas, suggestions and completions for it.

>   (D) In the absence of command-line options, auto-select the most appropriate
>       implementation:
>
>       (1) If the host and guest page sizes don't match, select softmmu_user.
>       (2) Otherwise, if 32-bit guest and 64-bit host, select reserved_va.
>       (3) Otherwise, if a guest_base can be found to safely map the guest
>           binary into the host address space (e.g. a 64-bit binary isn't
>           linked above 4GB on a 32-bit host), select unreserved_va.
>       (4) Otherwise, select softmmu.
>

OK, thanks. I guess we needn't implement it within 3 months (although it
is easy to be implemented).


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed