Wine on RiscV

[André Hentschel]

Hi,

I once ported Wine to ARM and ARM64, now I tried an initial port to Risc-V.
Sadly I fail to get a stable, non-crashing emulation running with the provided scripts.
So my question is, can someone please try running my binaries on riscv64?
http://dawncrow.de/wineriscv.tar.gz
Code can be found at: https://github.com/AndreRH/wine/commits/riscv64 (it was compiled from https://github.com/AndreRH/wine/commit/896fbaf9396559a04e3fd01271bfac7e1130097e)
Thanks in advance!

[Michael Clark]

Does Wine have a built-in instruction set simulator when running on non-x86 platforms or does it rely on an external translator such as QEMU? I don't know much about Wine on non-x86 systems.

Can you for example run Wine for Linux x86_64 using qemu-x86_64 linux-user emulation?

[André Hentschel]

Well, Wine has no integrated emulator (Wine is not an emulator), but there are other use cases for such a port.
One can run winelib applications, that means you can recompile existing windows application source code for a architecture windows does not support.
That already includes the the builtin applications of wine, such as cmd or regedit
So a good first test with my binaries would be "./wine cmd" and see if that works
Another use case I'm interested in is Hangover https://github.com/AndreRH/hangover
This is a great way to combine qemu with wine, but it also needs to be ported to riscv first...
A future use-case might be native Windows Risc-V applications, in case MS will port Windows to that platform in the future...

With regards to Linux user space emulation, I'm not sure about x86_64 which might be tricky, but 32-bit applications can run with qemu-i386 e.g. on ARM, but performance is worse compared to the Hangover approach.

[Richard W.M. Jones]

On Sat, Mar 31, 2018 at 12:21:31PM -0700, 'André Hentschel' via RISC-V SW Dev wrote:
> Hi,
>
> I once ported Wine to ARM and ARM64, now I tried an initial port to Risc-V.
> Sadly I fail to get a stable, non-crashing emulation running with the
> provided scripts.
> So my question is, can someone please try running my binaries on riscv64?
> http://dawncrow.de/wineriscv.tar.gz

I ran this under Fedora/RISC-V
(see https://fedorapeople.org/groups/risc-v/disk-images/).

Unfortunately I failed at the first hurdle because these are
compiled with the old glibc ABI:

$ ./wine --help
./wine: /lib64/lp64d/libc.so.6: version `GLIBC_2.26' not found (required by ./wine)
./wine: /lib64/lp64d/libdl.so.2: version `GLIBC_2.26' not found (required by /home/rjones/installed/bin/../lib/libwine.so.1)
./wine: /lib64/lp64d/libc.so.6: version `GLIBC_2.26' not found (required by /home/rjones/installed/bin/../lib/libwine.so.1)

Can you try compiling them from within the Fedora environment?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Richard W.M. Jones]

FYI (as almost certainly you would expect) the Fedora wine package
couldn't be compiled. The logs are here:

https://fedorapeople.org/groups/risc-v/logs/wine-2.20-1.fc27.src.rpm/

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com

virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Michael Clark]

On 31/03/2018, at 1:53 PM, 'André Hentschel' via RISC-V SW Dev <sw-...@groups.riscv.org> wrote:

Well, Wine has no integrated emulator (Wine is not an emulator), but there are other use cases for such a port.
One can run winelib applications, that means you can recompile existing windows application source code for a architecture windows does not support.
That already includes the the builtin applications of wine, such as cmd or regedit
So a good first test with my binaries would be "./wine cmd" and see if that works
Another use case I'm interested in is Hangover https://github.com/AndreRH/hangover
This is a great way to combine qemu with wine, but it also needs to be ported to riscv first...

Okay. I see it uses QEMU. This should be a bit easier to port now we have an experimental RISC-V backend for QEMU. I have the x86_64 front-end working against a new RISC-V TCG back-end. I’ve tested linux-user emulation but softmmu still requires some work. I posted about it in another thread. Here is the tree:

- https://github.com/riscv/riscv-qemu/tree/wip-riscv-tcg-backend

A future use-case might be native Windows Risc-V applications, in case MS will port Windows to that platform in the future...

With regards to Linux user space emulation, I'm not sure about x86_64 which might be tricky, but 32-bit applications can run with qemu-i386 e.g. on ARM, but performance is worse compared to the Hangover approach.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/48e8147f-919c-4ca0-a251-f3258c0e5894%40groups.riscv.org.

[André Hentschel]

Well, as I said, I had trouble running a stable environment in the emulator. and even in the wine log you provided there is a kernel oops...

[André Hentschel]

Well, for porting Hangover real HW is needed, it simply makes no sense to run an emulator in an emulator to see every frame without a feeling for speed bottlenecks...
Sadly the HW is not really affortable right now, so I started with Wine

[Luke Kenneth Casson Leighton]

On Sat, Mar 31, 2018 at 10:57 PM, 'André Hentschel' via RISC-V SW Dev
<sw-...@groups.riscv.org> wrote:

> Well, for porting Hangover real HW is needed, it simply makes no sense to
> run an emulator in an emulator to see every frame without a feeling for
> speed bottlenecks...

ahh come ooon, it's fuuun! try this: install linux. then wine.
then MSYS and MingW32... both under wine. then get the python 2.7
source code, and track down and apply the mingw32 patches. then
compile python-win32.... using a native win32 port of gcc... emulated
under wine... mwahahaha. it's really quite educational to see what
keels over and what doesn't, and you will be very surprised to learn
how far it gets: the unit tests actually score *higher* than the
python software foundation's own python-win32 build!

but seriously, the reason i recommend running emulators under
emulators is because if anything is truly, truly dreadfully slow, then
congratulations you've just found a bug [which otherwise you would not
notice].

with systems being so utterly insanely fast now, severe performance
bugs are often completely overlooked. in the case of the above
insanity there was a bug... *in bash* that was (eventually) tracked
down after 6-8 months... thanks to running autoconf scripts where
everything was compiled for win32's posix emulation *and then itself
emulated*. the bug resulted *literally* in each line of an autoconf
script taking between 1-4 seconds, where normally it takes
milliseconds natively.

plus it's just hilarious to run emulators inside emulators.

l.

[Richard W.M. Jones]

On Sat, Mar 31, 2018 at 02:55:46PM -0700, 'André Hentschel' via RISC-V SW Dev wrote:
> Well, as I said, I had trouble running a stable environment in the
> emulator.

Can you describe what exact "trouble" you had? If you follow
the readme file exactly it should work.

> and even in the wine log you provided there is a kernel oops...

I didn't see any kernel oops.

[André Hentschel]

From your scripts I noticed:

------------[ cut here ]------------
WARNING: CPU: 3 PID: 0 at drivers/irqchip/irq-riscv-intc.c:158 riscv_irq_enable+0x92/0x94
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.16.0-rc5-01493-g7f82cffaad50 #6
Call Trace:
[<ffffffe0000331ee>] walk_stackframe+0x0/0xa2
[<ffffffe0000332ec>] show_stack+0x26/0x34
[<ffffffe0005de660>] dump_stack+0x62/0x80
[<ffffffe00003655a>] __warn+0xc6/0xdc
[<ffffffe000036606>] warn_slowpath_null+0x2c/0x3e
[<ffffffe0002a1b5e>] riscv_irq_enable+0x8e/0x94
[<ffffffe00006ee4e>] irq_enable+0x3a/0x6a
[<ffffffe00006eefe>] __irq_startup+0x80/0x88
[<ffffffe00006ef54>] irq_startup+0x4e/0xe2
[<ffffffe00006f004>] irq_activate_and_startup+0x1c/0x28
[<ffffffe00006f07e>] __irq_do_set_handler+0x6e/0x134
[<ffffffe00006fad0>] irq_set_chained_handler_and_data+0x2c/0x4a
[<ffffffe0002a218a>] plic_init+0x216/0x34a
[<ffffffe000015408>] of_irq_init+0x132/0x232
[<ffffffe00000e9a4>] irqchip_init+0x10/0x1c
[<ffffffe000002126>] init_IRQ+0x8/0x14
[<ffffffe0000008ac>] start_kernel+0x1f6/0x32c
[<ffffffe00000004e>] _sinittext+0x4e/0x56
random: get_random_bytes called from print_oops_end_marker+0x3a/0x52 with crng_init=0
---[ end trace a21f64d6a74625f3 ]---

which might be harmless.

But on my qemu build (from the freedom-u-sdk) I had filesystem related oops so that even "ls" segfaulted, so I gave up.

Regarding the GLIBC problem: I crosscompiled Wine, building it in qemu would take horribly long. Is there a fedora risc-v crosscompilation toolchain available?

[Richard W.M. Jones]

On Tue, Apr 03, 2018 at 09:37:09AM -0700, 'André Hentschel' via RISC-V SW Dev wrote:
> >From your scripts I noticed:
>
> ------------[ cut here ]------------
> WARNING: CPU: 3 PID: 0 at drivers/irqchip/irq-riscv-intc.c:158 riscv_irq_enable+0x92/0x94
> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.16.0-rc5-01493-g7f82cffaad50 #6
> Call Trace:
> [<ffffffe0000331ee>] walk_stackframe+0x0/0xa2
> [<ffffffe0000332ec>] show_stack+0x26/0x34
> [<ffffffe0005de660>] dump_stack+0x62/0x80
> [<ffffffe00003655a>] __warn+0xc6/0xdc
> [<ffffffe000036606>] warn_slowpath_null+0x2c/0x3e
> [<ffffffe0002a1b5e>] riscv_irq_enable+0x8e/0x94

[...]

As far as I know this can be ignored, but ...

> But on my qemu build (from the freedom-u-sdk) I had filesystem
> related oops so that even "ls" segfaulted, so I gave up.

Use upstream qemu + these 2 patches which should go upstream soon:

http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07034.html

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com

Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Michael Clark]

> On 4/04/2018, at 7:26 AM, Richard W.M. Jones <rjo...@redhat.com> wrote:
>
> On Tue, Apr 03, 2018 at 09:37:09AM -0700, 'André Hentschel' via RISC-V SW Dev wrote:
>>> From your scripts I noticed:
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 3 PID: 0 at drivers/irqchip/irq-riscv-intc.c:158 riscv_irq_enable+0x92/0x94
>> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.16.0-rc5-01493-g7f82cffaad50 #6
>> Call Trace:
>> [<ffffffe0000331ee>] walk_stackframe+0x0/0xa2
>> [<ffffffe0000332ec>] show_stack+0x26/0x34
>> [<ffffffe0005de660>] dump_stack+0x62/0x80
>> [<ffffffe00003655a>] __warn+0xc6/0xdc
>> [<ffffffe000036606>] warn_slowpath_null+0x2c/0x3e
>> [<ffffffe0002a1b5e>] riscv_irq_enable+0x8e/0x94
> [...]
>
> As far as I know this can be ignored, but ...
>
>> But on my qemu build (from the freedom-u-sdk) I had filesystem
>> related oops so that even "ls" segfaulted, so I gave up.
>
> Use upstream qemu + these 2 patches which should go upstream soon:
>
> http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07034.html

The mstatus.FS workaround has landed in upstream so we need to get Richard Henderson to update his patch set to reverse out the workaround.

https://github.com/riscv/riscv-qemu riscv-all branch should be fine as the workaround is included. I’ll do some testing with freedom-u-sdk to see what’s going on with make qemu and bump the qemu dependency if necessary. It’s hard to know what’s going on without replicating your environment. It’s also recommended to make sure the RISCV environment variable is unset when running make qemu as some of the components (buildroot in particular) have dependencies on specific toolchain versions.

A segfault in ls might indicate either a QEMU, glibc, buildroot or linux-kernel issue. QEMU full system mode emulation is unlikely to cause programs like ls to segfault although we can’t really eliminate it as a root cause without some more testing.

I’ll look into this...

[Andreas Schwab]

On Mär 31 2018, 'André Hentschel' via RISC-V SW Dev <sw-...@groups.riscv.org> wrote:

> Code can be found at: https://github.com/AndreRH/wine/commits/riscv64 (it
> was compiled from
> https://github.com/AndreRH/wine/commit/896fbaf9396559a04e3fd01271bfac7e1130097e)

This builds fine for openSUSE
(https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/wine),
how can it be tested?

Andreas.

--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[André Hentschel]

I really appreciate that!
You can test it by running something like "wine cmd" and see if it comes up. Beside some debug output, you should end up with a prompt like:
Z:\home\user>
You can then try things like "set" to print the environment and "echo hello world"

[Andreas Schwab]

On Apr 05 2018, André Hentschel <dawnc...@googlemail.com> wrote:

> Is there some script to get opensuse running in qemu or can you tar me a working setup?

There are some tarballs available from
<https://download.opensuse.org/repositories/openSUSE:/Factory:/RISCV/images/>.
I'm currently working on getting the full repository online, so that you
can easily install more packages inside them.