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

[gchen gchen]

<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>&gt;<br>&gt; My best guess that this is 3-4 months of 
work.<br>&gt;<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>&gt; The current code within 
linux-user needs to be abstracted.  The new interface<br>&gt; must handle 
several things:<br>&gt;<br>&gt;  (1) Finding unmapped portions of the guest 
address space.<br><br>I guess, I need implement it.<br><br>&gt;  (2) Mapping 
anonymous memory into the guest address space.<br>&gt;  (3) Mapping files into 
the guest address space.<br><br>I guess, I just re-use them.<br><br>&gt;  (4) 
Filling in struct iovec for the host pages of a<br>&gt;      contiguous guest 
memory block.<br><br>I guess, I need implement it, at last.<br><br>&gt;  (5) 
Copying guest data to/from a contiguous host data block<br>&gt;      (like 
lock_user/unlock_user).<br>&gt;<br><br>I guess, I just re-use it.<br><br>&gt; 
The current code has some of the above.<br>&gt;<br>&gt; With the current 
implementation, (2) and (3) are mostly trivial.  There is<br>&gt; extra complex 
code to attempt these when host and guest page sizes differ, but<br>&gt; it's 
not completely correct.  And it definitely fails when 64-bit guests<br>&gt; 
running on 32-bit hosts attempt to map data above 4GB.<br>&gt;<br><br>OK, 
thanks.<br><br>&gt; We don't currently have a need for (4), as contiguous guest 
pages currently<br>&gt; always imply contiguous host pages.  But with softmmu 
that will change, and the<br>&gt; speed of emulation for basic operations like 
read and write will be much<br>&gt; improved if we can issue readv and writev 
syscalls to the host os.<br>&gt;<br>&gt; If (4) fails, or if there's no 
equivalent syscall that takes an iovec, then<br>&gt; copy in/out is the only 
solution.  Obviously we have a solution for the current<br>&gt; linux-user with 
lock_user/unlock_user.<br>&gt;<br><br>OK, thanks.<br><br>&gt; The sets of 
patches that we should see will look something like this:<br>&gt;<br>&gt;   
(A1) Define the interface, and sets of callbacks.  This, IMO, should be 
done<br>&gt;        at the top level of qemu so that (eventually) both 
linux-user<br>&gt;        and bsd-user can share the code.<br>&gt;<br>&gt;   
(A2) Convert the existing two implementations to the set of callbacks.<br>&gt;  
      Note that I consider RESERVED_VA and !RESERVED_VA 
(unreserved_va?)<br>&gt;        different.  They do share some code, so 
callbacks for (4) and (5)<br>&gt;        will be the same, but certainly not 
the callbacks for (1), (2) or (3).<br>&gt;<br>&gt;   (A3) Update linux-user to 
use the new interface, without (4).<br>&gt;<br>&gt;   (A4) Update linux-user to 
use the new call for (4), for the syscalls<br>&gt;        that have iovec 
equivalents.<br>&gt;<br>&gt;   (B) Replace the define CONFIG_SOFTMMU with a 
variable use_softmmu.<br>&gt;       In system mode (ifndef CONFIG_USER_ONLY), 
this should be a define that<br>&gt;       is always true, so that the dead 
code can be eliminated.  In user mode,<br>&gt;       this will be set depending 
on the guest mapping interface selected.<br>&gt;<br>&gt; At this point you've 
really not changed anything, algorithmically. Everything<br>&gt; is working 
just the same as before you started, but the code is now in a form<br>&gt; 
where softmmu can be introduced.<br>&gt;<br><br>OK, thanks, hope I can send 1st 
related patches to upstream within 2-3<br>weeks.<br><br>&gt;   (C) Create the 
softmmu_user implementation.  You'll need something like the<br>&gt;       
kernel's vm_area_struct to record ranges of guest address space<br>&gt;       
mappings.  It'll need to be fast, as that data structure will provide<br>&gt;   
    the implementation for tlb_fill.<br>&gt;<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>&gt;   (D) In the absence of 
command-line options, auto-select the most appropriate<br>&gt;       
implementation:<br>&gt;<br>&gt;       (1) If the host and guest page sizes 
don't match, select softmmu_user.<br>&gt;       (2) Otherwise, if 32-bit guest 
and 64-bit host, select reserved_va.<br>&gt;       (3) Otherwise, if a 
guest_base can be found to safely map the guest<br>&gt;           binary into 
the host address space (e.g. a 64-bit binary isn't<br>&gt;           linked 
above 4GB on a 32-bit host), select unreserved_va.<br>&gt;       (4) Otherwise, 
select softmmu.<br>&gt;<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>