<br>Firstly, thank you very much for your details information! Based on
your<br>details information, for me, I guess it is not quite difficult for me
to<br>implement it. :-)<br><br><br>On 2015年08月14日 00:55, Richard Henderson
wrote:<br>><br>> My best guess that this is 3-4 months of
work.<br>><br><br>After communicated with my company related members, they
can accept my<br>3 months time resources on it, but it includes additional
things:<br><br> - At present, except x86_64 host, tci also has issues on
another archs<br> (e.g. under arm host, the linux i386 graphic xcalc can not
work). So<br> under Alpha (or SW64), tic may also have issues (need be
solved).<br><br> - If the performance of "linux-user + softmmu + tci" is not
acceptable<br> (at present, I am not quite sure), we have to implement SW64
tcg host<br> target instead of tci.<br><br> - For the performance reason, I
guess, we have to implment tlb_fill and<br> iovec ( if SW64
support).<br><br>At present, I guess, the time point may be OK within 3
months:<br><br> - We can use 'pipeline' way for it: when "softmmu + linux-user"
are in<br> reviewing, I can try to implement tci (welcome any tci related
ideas,<br> suggestions, and completions).<br><br> - After 1 month later, for
"softmmu + linux-user", we can divide it<br> into 2 branches, one for
upstream version merging, and the other for<br> internal development (which
need be finished within 3 months).<br><br> - If necessary, I have to work
overtime for it. (it is not our hope, it<br> will have negative effect with
tilegx development for upstream :-( ).<br><br>Also I maybe do another things
(e.g. analyze SW64 toolchains issues with<br>provider), but these time
resources are individual. The company accepts:<br>we can delay our "softmmu +
linux-user" time point because of it.<br><br><br>> The current code within
linux-user needs to be abstracted. The new interface<br>> must handle
several things:<br>><br>> (1) Finding unmapped portions of the guest
address space.<br><br>I guess, I need implement it.<br><br>> (2) Mapping
anonymous memory into the guest address space.<br>> (3) Mapping files into
the guest address space.<br><br>I guess, I just re-use them.<br><br>> (4)
Filling in struct iovec for the host pages of a<br>> contiguous guest
memory block.<br><br>I guess, I need implement it, at last.<br><br>> (5)
Copying guest data to/from a contiguous host data block<br>> (like
lock_user/unlock_user).<br>><br><br>I guess, I just re-use it.<br><br>>
The current code has some of the above.<br>><br>> With the current
implementation, (2) and (3) are mostly trivial. There is<br>> extra complex
code to attempt these when host and guest page sizes differ, but<br>> it's
not completely correct. And it definitely fails when 64-bit guests<br>>
running on 32-bit hosts attempt to map data above 4GB.<br>><br><br>OK,
thanks.<br><br>> We don't currently have a need for (4), as contiguous guest
pages currently<br>> always imply contiguous host pages. But with softmmu
that will change, and the<br>> speed of emulation for basic operations like
read and write will be much<br>> improved if we can issue readv and writev
syscalls to the host os.<br>><br>> If (4) fails, or if there's no
equivalent syscall that takes an iovec, then<br>> copy in/out is the only
solution. Obviously we have a solution for the current<br>> linux-user with
lock_user/unlock_user.<br>><br><br>OK, thanks.<br><br>> The sets of
patches that we should see will look something like this:<br>><br>>
(A1) Define the interface, and sets of callbacks. This, IMO, should be
done<br>> at the top level of qemu so that (eventually) both
linux-user<br>> and bsd-user can share the code.<br>><br>>
(A2) Convert the existing two implementations to the set of callbacks.<br>>
Note that I consider RESERVED_VA and !RESERVED_VA
(unreserved_va?)<br>> different. They do share some code, so
callbacks for (4) and (5)<br>> will be the same, but certainly not
the callbacks for (1), (2) or (3).<br>><br>> (A3) Update linux-user to
use the new interface, without (4).<br>><br>> (A4) Update linux-user to
use the new call for (4), for the syscalls<br>> that have iovec
equivalents.<br>><br>> (B) Replace the define CONFIG_SOFTMMU with a
variable use_softmmu.<br>> In system mode (ifndef CONFIG_USER_ONLY),
this should be a define that<br>> is always true, so that the dead
code can be eliminated. In user mode,<br>> this will be set depending
on the guest mapping interface selected.<br>><br>> At this point you've
really not changed anything, algorithmically. Everything<br>> is working
just the same as before you started, but the code is now in a form<br>>
where softmmu can be introduced.<br>><br><br>OK, thanks, hope I can send 1st
related patches to upstream within 2-3<br>weeks.<br><br>> (C) Create the
softmmu_user implementation. You'll need something like the<br>>
kernel's vm_area_struct to record ranges of guest address space<br>>
mappings. It'll need to be fast, as that data structure will provide<br>>
the implementation for tlb_fill.<br>><br><br>OK, thanks. I guess it will
implement (1) and (4), which is my main work.<br><br>Welcome any additional
ideas, suggestions and completions for it.<br><br>> (D) In the absence of
command-line options, auto-select the most appropriate<br>>
implementation:<br>><br>> (1) If the host and guest page sizes
don't match, select softmmu_user.<br>> (2) Otherwise, if 32-bit guest
and 64-bit host, select reserved_va.<br>> (3) Otherwise, if a
guest_base can be found to safely map the guest<br>> binary into
the host address space (e.g. a 64-bit binary isn't<br>> linked
above 4GB on a 32-bit host), select unreserved_va.<br>> (4) Otherwise,
select softmmu.<br>><br><br>OK, thanks. I guess we needn't implement it
within 3 months (although it<br>is easy to be
implemented).<br><br><br>Thanks.<br>--<br>Chen Gang<br><br>Open, share, and
attitude like air, water, and life which God blessed<br>
