| Message ID | COL130-W58B75ECEB01203B3158016B97E0@phx.gbl |
|---|---|
| State | New |
| Headers | show |
On 08/11/2015 11:03 PM, gchen gchen wrote: > Under Alpha host, for ubuntu12.04.5 i386 guest, it will cause failure: > "Invalid ELF image for this architecture". > > The related issue commit is "a70daba linux-user: Tell guest about big > host page sizes". > > Signed-off-by: Chen Gang<gang.chen.5i5j@gmail.com> > --- > linux-user/elfload.c | 4 ++++ > 1 file changed, 4 insertions(+) Nack. There's 99 problems with host page size > guest page size. This solves none of them, and in the hackiest way possible. r~
On 2015年08月12日 14:45, Richard Henderson wrote: > On 08/11/2015 11:03 PM, gchen gchen wrote: >> Under Alpha host, for ubuntu12.04.5 i386 guest, it will cause failure: >> "Invalid ELF image for this architecture". >> >> The related issue commit is "a70daba linux-user: Tell guest about big >> host page sizes". >> >> Signed-off-by: Chen Gang<gang.chen.5i5j@gmail.com> >> --- >> linux-user/elfload.c | 4 ++++ >> 1 file changed, 4 insertions(+) > > Nack. There's 99 problems with host page size> guest page size. This > solves none of them, and in the hackiest way possible. > Under alpha virtual machine, if set i386 guest page size 8KB, it will cause failure directly (any dynamically linked binaries can not work). This fix can let i386 bash/cp/vi/ls run under alpha virtual machine, although there maybe be many other issues (which I did not meet, now). Do you have any other ideas for solving this issue? e.g. can we rebuild all i386 programs with segment alignment to 8KB? I am not quite sure, but some i386 programs (which are interested in) have no source code! :-(. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
On 2015年08月12日 15:59, gchen gchen wrote: > On 2015年08月12日 14:45, Richard Henderson wrote: >> On 08/11/2015 11:03 PM, gchen gchen wrote: >>> Under Alpha host, for ubuntu12.04.5 i386 guest, it will cause failure: >>> "Invalid ELF image for this architecture". >>> >>> The related issue commit is "a70daba linux-user: Tell guest about big >>> host page sizes". >>> >>> Signed-off-by: Chen Gang<gang.chen.5i5j@gmail.com> >>> --- >>> linux-user/elfload.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >> >> Nack. There's 99 problems with host page size> guest page size. This >> solves none of them, and in the hackiest way possible. >> > > Under alpha virtual machine, if set i386 guest page size 8KB, it will > cause failure directly (any dynamically linked binaries can not work). > > This fix can let i386 bash/cp/vi/ls run under alpha virtual machine, > although there maybe be many other issues (which I did not meet, now). > > Do you have any other ideas for solving this issue? e.g. can we rebuild > all i386 programs with segment alignment to 8KB? I am not quite sure, > but some i386 programs (which are interested in) have no source code! > :-(. > By the way, the patches about the alpha are my current work, I can do it during my work time, it will have no any negative effect with my tilegx linux-user development in my free time. :-) One of my current work contents are: "run ubuntu12.04.5 (no graphic) under alpha virtual machine, and run wine under ubuntu12.04.5 i386 guest under ubuntu alpha vm, and wine will run Win32 graphic programs". - I want to x86_64 laptop run Alpha linux-user run i386 linux-user run wine run Win32 graphic programs. I guess, I need build X libs under ubuntu Alpha vm (which nographic) -- use them for alpha linux-user. - At present, x86_64 laptop run arm linux-user run i386 linux-user run wine run Windows i386 graphic programs are OK, the performance is acceptable! the qemu code keeps no touch -- our qemu is very good!!!. Welcome any ideas, suggestions and completions. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
On 08/12/2015 12:59 AM, gchen gchen wrote: >> Nack. There's 99 problems with host page size> guest page size. This >> solves none of them, and in the hackiest way possible. >> > > Under alpha virtual machine, if set i386 guest page size 8KB, it will > cause failure directly (any dynamically linked binaries can not work). Yes, I know. The same thing happens when running i386 guests on other (non-virtual) hosts. E.g. Sparc64's 8kB page, PowerPC64's 64kB page. > Do you have any other ideas for solving this issue? The only complete solution that I see is to use softmmu with linux-user, so that we properly emulate the guest pages. Yes, it will cause quite some slow-down in emulation, but I believe it's the only reliable way. r~
On 2015年08月12日 23:06, Richard Henderson wrote:<br>> On 08/12/2015 12:59 AM, gchen gchen wrote:<br>>>> Nack. There's 99 problems with host page size> guest page size. This<br>>>> solves none of them, and in the hackiest way possible.<br>>>><br>>><br>>> Under alpha virtual machine, if set i386 guest page size 8KB, it will<br>>> cause failure directly (any dynamically linked binaries can not work).<br>><br>> Yes, I know. The same thing happens when running i386 guests on other<br>> (non-virtual) hosts. E.g. Sparc64's 8kB page, PowerPC64's 64kB page.<br>><br><br>Yes. The reason why I am only focus on Alpha is "the machine which I am<br>working for is almost the same as Alpha. But this machine is very slow,<br>its performance maybe like 10 years ago's x86_64 laptop".<br><br>>> Do you have any other ideas for solving this issue?<br>><br>> The only complete solution that I see is to use softmmu with linux-user, so<br>> that we properly emulate the guest pages. Yes, it will cause quite some<br>> slow-down in emulation, but I believe it's the only reliable way.<br>><br><br>I have tried softmmu, for me, the performance is not acceptable, we can<br>not use this way.<br><br>Our main goal is "let most of Windows XP graphic free programs (but not<br>open source), can be used by user under Alpha like machine, also its<br>performance and stability are acceptable".<br><br><br>Thanks.<br>--<br>Chen Gang<br><br>Open, share, and attitude like air, water, and life which God blessed<br>
On 2015年08月12日 23:06, Richard Henderson wrote: > On 08/12/2015 12:59 AM, gchen gchen wrote: >>> Nack. There's 99 problems with host page size> guest page size. This >>> solves none of them, and in the hackiest way possible. >>> >> >> Under alpha virtual machine, if set i386 guest page size 8KB, it will >> cause failure directly (any dynamically linked binaries can not work). > > Yes, I know. The same thing happens when running i386 guests on other > (non-virtual) hosts. E.g. Sparc64's 8kB page, PowerPC64's 64kB page. > Yes. The reason why I am only focus on Alpha is "the machine which I am working for is almost the same as Alpha. But this machine is very slow, its performance maybe like 10 years ago's x86_64 laptop". >> Do you have any other ideas for solving this issue? > > The only complete solution that I see is to use softmmu with linux-user, so > that we properly emulate the guest pages. Yes, it will cause quite some > slow-down in emulation, but I believe it's the only reliable way. > I have tried softmmu, for me, the performance is not acceptable, we can not use this way. Our main goal is "let most of Windows XP graphic free programs (but not open source), can be used by user under Alpha like machine, also its performance and stability are acceptable". Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
> Am 13.08.2015 um 04:45 schrieb gchen gchen <xili_gchen_5257@hotmail.com>: > >> On 2015年08月12日 23:06, Richard Henderson wrote: >> On 08/12/2015 12:59 AM, gchen gchen wrote: >>>> Nack. There's 99 problems with host page size> guest page size. This >>>> solves none of them, and in the hackiest way possible. >>> >>> Under alpha virtual machine, if set i386 guest page size 8KB, it will >>> cause failure directly (any dynamically linked binaries can not work). >> >> Yes, I know. The same thing happens when running i386 guests on other >> (non-virtual) hosts. E.g. Sparc64's 8kB page, PowerPC64's 64kB page. > > Yes. The reason why I am only focus on Alpha is "the machine which I am > working for is almost the same as Alpha. But this machine is very slow, > its performance maybe like 10 years ago's x86_64 laptop". What does "Almost the same as Alpha" mean? Does it use 8k or 4k page size? > >>> Do you have any other ideas for solving this issue? >> >> The only complete solution that I see is to use softmmu with linux-user, so >> that we properly emulate the guest pages. Yes, it will cause quite some >> slow-down in emulation, but I believe it's the only reliable way. > > I have tried softmmu, for me, the performance is not acceptable, we can > not use this way. Softmmu but without system emulation. Performance should be about half of today's linux-user. Alex
[ Re-adding qemu-devel so that the plan can be critiqued. ] On 08/13/2015 07:32 AM, Chen Gang wrote: > On 8/13/15 22:05, Richard Henderson wrote: >> On 08/13/2015 12:20 AM, gchen gchen wrote: >>> Excuse me, I am not quite familiar with it, could any members provide >>> more details about "use softmmu with linux-user" or "softmmu but without >>> system emulation"? >> >> It doesn't exist yet. It must be written. >> > > OK, thanks, and I shall try to implement it ... My best guess that this is 3-4 months of work. 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. (2) Mapping anonymous memory into the guest address space. (3) Mapping files into the guest address space. (4) Filling in struct iovec for the host pages of a contiguous guest memory block. (5) Copying guest data to/from a contiguous host data block (like lock_user/unlock_user). 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. 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. 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. (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. (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. r~
<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>
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
On 14 August 2015 at 04:25, gchen gchen <xili_gchen_5257@hotmail.com> wrote: > - 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. If you care even slightly about performance, then do not use TCI. A tcg backend is only about 2000 lines of code, they're not terribly difficult to implement. -- PMM
On 2015年08月14日 16:44, Peter Maydell wrote: > On 14 August 2015 at 04:25, gchen gchen <xili_gchen_5257@hotmail.com> wrote: >> - 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. > > If you care even slightly about performance, then do not use TCI. > A tcg backend is only about 2000 lines of code, they're not terribly > difficult to implement. > OK, thank you for your suggestion, but for me, I guess, I still need let tci work correctly: - If I implement SW64 tcg backend, I guess, I cann't get help from qemu upstream: I don't think SW64 is valuable enough for upstream (either I am not sure that I can implment Alpha tcg backend in working time). - tci is one tcg backend, at present, it can let i386 console programs work under Alpha. So I can learn tcg backend by fixing its X issues with the help from upstream (then implement SW64 tcg backend, next). - Also tci is only slightly lower than tcg native backend, so if we are lucky, its performance may be enough too! (I hope so). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
On 08/14/2015 02:37 AM, gchen gchen wrote: > - If I implement SW64 tcg backend, I guess, I cann't get help from qemu > upstream: I don't think SW64 is valuable enough for upstream (either > I am not sure that I can implment Alpha tcg backend in working time). It'll need some updating to apply to master, but I started an alpha backend a couple of years ago. It looks like it was last rebased in May 2014. git://github.com/rth7680/qemu.git tcg-alpha-2 r~
On 8/14/15 22:44, Richard Henderson wrote: > On 08/14/2015 02:37 AM, gchen gchen wrote: >> - If I implement SW64 tcg backend, I guess, I cann't get help from qemu >> upstream: I don't think SW64 is valuable enough for upstream (either >> I am not sure that I can implment Alpha tcg backend in working time). > > It'll need some updating to apply to master, but I started an alpha backend a > couple of years ago. It looks like it was last rebased in May 2014. > > git://github.com/rth7680/qemu.git tcg-alpha-2 > Thank you very much, I shall clone it. I guess, it will save my much time resources. If possible, it will be better to merge the alpha tcg backend to qemu master main branch (at least for me, it is useful). :-) Thanks.
On 2015年08月15日 04:45, Chen Gang wrote: > On 8/14/15 22:44, Richard Henderson wrote: >> On 08/14/2015 02:37 AM, gchen gchen wrote: >>> - If I implement SW64 tcg backend, I guess, I cann't get help from qemu >>> upstream: I don't think SW64 is valuable enough for upstream (either >>> I am not sure that I can implment Alpha tcg backend in working time). >> >> It'll need some updating to apply to master, but I started an alpha backend a >> couple of years ago. It looks like it was last rebased in May 2014. >> >> git://github.com/rth7680/qemu.git tcg-alpha-2 >> > After get sw_64 pc, it is much slower than I guess (it is much slower than my intel x86_64 laptop which was made in 2007-2008). So I have to use tcg backend instead of tci. Will qemu upstream accept alpha tcg backend to master tree? If possible I can do it in my working time (after simply trying, I am sure, alpha tcg backend can not work if only simply merge and let it pass building). By the way, for me, I have to process alpha/sw_64 tcg backend firstly, then process softmmu + linux-user. Welcome any ideas, suggestions, and completions. Thanks. > Thank you very much, I shall clone it. I guess, it will save my much > time resources. > > If possible, it will be better to merge the alpha tcg backend to qemu > master main branch (at least for me, it is useful). > :-) > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
On 2015年08月19日 16:01, gchen gchen wrote: > On 2015年08月15日 04:45, Chen Gang wrote: >> On 8/14/15 22:44, Richard Henderson wrote: >>> On 08/14/2015 02:37 AM, gchen gchen wrote: >>>> - If I implement SW64 tcg backend, I guess, I cann't get help from qemu >>>> upstream: I don't think SW64 is valuable enough for upstream (either >>>> I am not sure that I can implment Alpha tcg backend in working time). >>> >>> It'll need some updating to apply to master, but I started an alpha backend a >>> couple of years ago. It looks like it was last rebased in May 2014. >>> >>> git://github.com/rth7680/qemu.git tcg-alpha-2 >>> Really thank you very much again!! I have implemented sw_64 tcg back end, its performance is much better than tci (10 times faster for testing i386 bash). I guess at present, our qemu performance should be enough for my current using. :-) And next, I shall try to merge alpha related code to the latest qemu, and send patches for it. Hope it is useful for our qemu (since no any additional reply for it, I guess I should try to send patches for it). Thanks. >> > > After get sw_64 pc, it is much slower than I guess (it is much slower > than my intel x86_64 laptop which was made in 2007-2008). So I have to > use tcg backend instead of tci. > > Will qemu upstream accept alpha tcg backend to master tree? If possible > I can do it in my working time (after simply trying, I am sure, alpha > tcg backend can not work if only simply merge and let it pass building). > > By the way, for me, I have to process alpha/sw_64 tcg backend firstly, > then process softmmu + linux-user. > > > Welcome any ideas, suggestions, and completions. > > Thanks. > >> Thank you very much, I shall clone it. I guess, it will save my much >> time resources. >> >> If possible, it will be better to merge the alpha tcg backend to qemu >> master main branch (at least for me, it is useful). >> :-) >> > > -- > Chen Gang > > Open, share, and attitude like air, water, and life which God blessed > > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
On 2015年08月12日 17:00, gchen gchen wrote: > > - At present, x86_64 laptop run arm linux-user run i386 linux-user run > wine run Windows i386 graphic programs are OK, the performance is > acceptable! the qemu code keeps no touch -- our qemu is very good!!!. > Oh, sorry, wine will use execve(), then qemu will use host execve(), under x86_64, the i386 wine will be executed directly. But I guess, at present, the performance is still OK, I have let i386 xcalc run successfully under sw_64. It looks very good. :-) Next, I shall have to analyze wine, too, so can let wine and qemu work together correctly. Welcome any ideas, suggestions, and completions. Thanks.
diff --git a/linux-user/elfload.c b/linux-user/elfload.c index 1788368..f4cf9b6 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -1614,7 +1614,11 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc, NEW_AUX_ENT(AT_PHDR, (abi_ulong)(info->load_addr + exec->e_phoff)); NEW_AUX_ENT(AT_PHENT, (abi_ulong)(sizeof (struct elf_phdr))); NEW_AUX_ENT(AT_PHNUM, (abi_ulong)(exec->e_phnum)); +#ifdef TARGET_I386 + NEW_AUX_ENT(AT_PAGESZ, (abi_ulong)TARGET_PAGE_SIZE); +#else NEW_AUX_ENT(AT_PAGESZ, (abi_ulong)(MAX(TARGET_PAGE_SIZE, getpagesize()))); +#endif NEW_AUX_ENT(AT_BASE, (abi_ulong)(interp_info ? interp_info->load_addr : 0)); NEW_AUX_ENT(AT_FLAGS, (abi_ulong)0); NEW_AUX_ENT(AT_ENTRY, info->entry);
Under Alpha host, for ubuntu12.04.5 i386 guest, it will cause failure: "Invalid ELF image for this architecture". The related issue commit is "a70daba linux-user: Tell guest about big host page sizes". Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> --- linux-user/elfload.c | 4 ++++ 1 file changed, 4 insertions(+) -- 1.9.1