0.3.16 in qemu

Ask your support questions in here

Moderator: Moderator Team

ssam
Posts: 3
Joined: Tue Apr 08, 2014 3:56 pm

0.3.16 in qemu

Post by ssam » Tue Apr 08, 2014 4:04 pm

Hi,

I am having some trouble running reactos 0.3.16 in qemu 1.6.2 (I know its not the latest, but its the one in Fedora 20). I had a look at http://www.reactos.org/wiki/QEMU but did not find anything useful.

I solved one issue. In order to get network (which is needed for gecko during installation), I need to add the qemu arguments

Code: Select all

-net nic,model=rtl8139 -net user
My next issue is mouse. Mouse movements and clicks are not be detected by reactos. The reactos pointer stays still in the center of the qemu window. Leopard seems to work fine. Any ideas?

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: 0.3.16 in qemu

Post by vicmarcal » Tue Apr 08, 2014 11:04 pm

You may try http://iso.reactos.org/bootcd/bootcd-62690-dbg.7z
It's latest. If yo find the same issues,please tell us so we can report the bug/regression.
:)
Image

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

Mouse Integration in ReactOS under QEMU (for Windows)

Post by justincase » Tue Apr 08, 2014 11:37 pm

Hello,
I have been using ReactOS under QEMU for Windows v1.6.0 (latest version available from omledom.com [IDK why they removed the link]) for quite some time, and have not experienced the issue you've described.
However you may want to try using the

Code: Select all

-usbdevice tablet
option.
I use it because it works similar to Host/Guest mouse integration in other VMs (i.e. when I move the mouse over ReactOS's display QEMU automatically grabs mouse control, & when moving back to the edge QEMU releases it back to Windows).

NOTE: There are some QEMU bugs (i.e. it'll occasionally prevent the cursor from moving outside the space that the QEMU window occupies when QEMU is not on top, but you can just use alt+tab to bring QEMU forward, move the cursor outside of QEMU's space, then switch back to something else) but testing ReactOS this way has worked quite well for me.

Also NOTE: I'm speaking from "QEMU for Windows" experience. YMMV.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.

ssam
Posts: 3
Joined: Tue Apr 08, 2014 3:56 pm

Re: 0.3.16 in qemu

Post by ssam » Wed Apr 09, 2014 12:56 pm

with

Code: Select all

-usbdevice tablet
it i get working mouse on 0.3.16 and bootcd-62690

My full qemu commands for install and running are:

Code: Select all

qemu-system-x86_64 -cdrom bootcd-62690-dbg.iso -m 1024 -hda reactos.img -net nic,model=rtl8139 -net user  -boot d -usbdevice tablet
qemu-system-x86_64 -m 1024 -hda reactos.img -net nic,model=rtl8139 -net user  -boot c -usbdevice tablet
Thanks

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

I'm glad / Latest Trunk Builds / Why use QEMU-x86_64 ?

Post by justincase » Wed Apr 09, 2014 6:21 pm

Good, I'm glad that's working out for you. :)
Perhaps someone who has access to edit the Wiki could make a note that "-usbdevice tablet" now works on both 64-bit Windows 7 Professional with QEMU v1.6.0, and Fedora 20 with QEMU v1.6.2 (my account seems to be only on the forums, not anywhere else :cry:)

NOTE: At the time of writing, ReactOS "Releases" are not necessarily more stable than the latest trunk builds which are available at ReactOS.org/GetBuilds, and are usually out-of-date enough (in comparison to "trunk") that there's little-to-no point in testing with them if you have any plans to post bug reports or really want to see how close ReactOS is to it's goal. [See Z98's posts on THIS thread]

And I have to ask: Why "qemu-system-x86_64"? unless you're running an x86_64 guest OS (which ReactOS currently isn't) there's no point, it's just that much more emulation to get the same result.
[Also IDK about Fedora, but on Windows qemu-system-x86_64.exe is a 32-bit (x86) QEMU build which has to do a lot of extra work to do the things x86_64 CPUs do, so even if you're running 64-bit Windows there's no point in using qemu-system-x86_64.exe unless you've found (or compiled) QEMU as a 64-bit (x86_64) build. (Again, I'm speaking from QEMU for Windows experience, so YMMV.)]
:arrow:P.S.: If someone who can see/edit user accounts could possibly fix mine so I can write on the Wiki and report on JIRA (and whatever else is normal), I'd really like that :D.
(Also I can't set my password, but I think that's pretty directly related to my user account apparently being forum-only)
[EDIT: Proper capitalisation of Z98]
Last edited by justincase on Wed Apr 09, 2014 11:42 pm, edited 1 time in total.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

P.P.S: [FIXED]: No Edit Function?

Post by justincase » Wed Apr 09, 2014 6:28 pm

[FIXED]
P.P.S.:Why can't I edit my posts?
I just noticed that I wrote z98 and wanted to fix it (should be Z98) ... but I can't, 'cause I don't have an edit button.
EDIT
1: @Webunny: yes I'm certain I'm logged in.
2: The icon was not defined in the stylesheet.
3: If I switched to another language it would work.
4: I found the appropriate image for it to point to: http://www.reactos.org/forum/styles/pro ... t_edit.gif
5: I don't know who, but someone fixed it, 'cause it seems to be working perfectly now.
6: Merged posts, and changed references to things that are no longer the case into past tense.
... to whoever fixed this issue: Thank you.
Last edited by justincase on Thu Apr 10, 2014 5:03 pm, edited 5 times in total.

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: P.P.S:

Post by Webunny » Wed Apr 09, 2014 11:14 pm

justincase wrote:
P.P.S.:Why can't I edit my posts?
I just noticed that I wrote z98 and wanted to fix it (should be Z98) ... but I can't, 'cause I don't have an edit button.
You sure you are logged in on the forum? (see above right corner).

I remember when I first logged on, I had some trouble with edit-buttons not being there (even when logged in), but that was on the old system. I thought those problems would not be possible anymore with the new system (?).

ssam
Posts: 3
Joined: Tue Apr 08, 2014 3:56 pm

Re: I'm glad / Latest Trunk Builds / Why use QEMU-x86_64 ?

Post by ssam » Thu Apr 10, 2014 4:05 pm

justincase wrote: And I have to ask: Why "qemu-system-x86_64"? unless you're running an x86_64 guest OS (which ReactOS currently isn't) there's no point, it's just that much more emulation to get the same result.
[Also IDK about Fedora, but on Windows qemu-system-x86_64.exe is a 32-bit (x86) QEMU build which has to do a lot of extra work to do the things x86_64 CPUs do, so even if you're running 64-bit Windows there's no point in using qemu-system-x86_64.exe unless you've found (or compiled) QEMU as a 64-bit (x86_64) build. (Again, I'm speaking from QEMU for Windows experience, so YMMV.)]
Fedora does not seem to ship with a plain 'qemu' binary, only qemu-ARCH and qemu-system-ARCH (with a large selection of ARCHs). I am on fedora x86-64 so all the binaries are compiled as 64bit. I assumed that the native one would be fastest.

With a bit of experimenting it looks like I should have been using qemu-kvm, which is noticeably faster than qemu-system-x86_64.

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

Sorry, i forgot about qemu-kvm

Post by justincase » Thu Apr 10, 2014 5:15 pm

Ah yes, I'd forgotten about qemu-kvm (not available on Windows, and currently no [working] "equivalent")
If it's available to you, that's probably your best bet performance-wise as it makes use of your hardware directly, eliminating a lot of overhead necessary to emulate such hardware in a software environment.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.

oldman
Posts: 1072
Joined: Sun Dec 20, 2009 1:23 pm

Re: 0.3.16 in qemu

Post by oldman » Thu Apr 10, 2014 5:40 pm

justincase
P.S.: If someone who can see/edit user accounts could possibly fix mine so I can write on the Wiki and report on JIRA (and whatever else is normal), I'd really like that
I have to go to the front page, log out, then log in, then go back to the wiki page, refresh the page in the browser, before I am logged in.

Hope that helps.
Please keep the Windows classic (9x/2000) look and feel.
The layman's guides to - debugging - bug reporting - compiling - with some complementary scripts.
They may help you with a problem, so do have a look at them.

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

Someone fixed my account‼ =) / KVM support in ReactOS?

Post by justincase » Thu Apr 10, 2014 7:56 pm

oldman wrote:I have to go to the front page, log out, then log in, then go back to the wiki page, refresh the page in the browser, before I am logged in.
I was going to say that "Unfortunately it doesn't as I can't use the login on the front page, it tells me my username or password is wrong, won't send me a password-reset email, and won't let me try to create an account because PHPbb tells it it can't." however it appears that someone has silently fixed that for me, so now it does work.
Once again, to whoever fixed this issue for me: Thank you.

Now to get (sortof) back on topic:
Windows doesn't support "KVM" virtual machines because KVM support has to be built into the Kernel right? Do you think we could (eventually) 1up Microsoft by adding KVM support into ReactOS?
Does anyone know how difficult would it be?

Obviously implementing KVM support in ReactOS isn't a priority at the moment, but it's an interesting thought, isn't it.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.

Forever Winter
Posts: 131
Joined: Sun Oct 20, 2013 6:50 am

Re: 0.3.16 in qemu

Post by Forever Winter » Thu Apr 10, 2014 9:43 pm

@ justincase

If you really need KVM on Windows, you can try WinKVM, but as far as I know, it's development has been abandoned years ago.
But if there are any Windows-based applications, that can use it is another question...

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

Not TRUE KVM / Re: WinKVM

Post by justincase » Fri Apr 11, 2014 8:26 am

To my knowledge a true KVM on Microsoft Windows is (currently) impossible, because support has to be built into the kernel.

As far as I can tell what WinKVM does is use Cygwin to compile Linux's KVM into a standalone 'hardware' driver which gives a sort of bypass to go around Windows itself for Cygwin based Windows ports of Linux apps that were designed to use Linux's KVM. It's an interesting ... workaround, which gives some degree of performance enhancement, but is very buggy, which I think is because it has to use the hardware directly without the OS's guidance, and can easily be interfered with by the OS itself trying to use the same hardware. So basically it boils down to needing to be compiled into the kernel itself, thus my suggestion for ReactOS to support it, because I highly doubt Microsoft Windows ever will, even though they could.

Note: This is my understanding of the WinKVM project after just a short look. If anyone here knows better than what I've posted, please feel free to post the correct information for I and others to learn from.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.

Forever Winter
Posts: 131
Joined: Sun Oct 20, 2013 6:50 am

Re: 0.3.16 in qemu

Post by Forever Winter » Fri Apr 11, 2014 4:04 pm

Basicaly, the WinKVM driver provides (more or less) a basic linux environment, wich is able to run KVM (with minor modifications) and to wich KVM is linked to. The usage of the functions provided by WinKVM is not restricted to cygwin based applications. As far as I can see, cygwin is required to compile the KVM source into a object file, wich is then linked into the driver, cause it contains code that VS can't compile.

WinKVM shouldn't bypass the OS, cause (I assume) KVM uses Linux kernel APIs to do it's job, wich are emulated by WinKVM. Of course I could be wrong, so also for me corrections are welcome.

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

Does anyone here KNOW how it works, or are we ALL just guess

Post by justincase » Fri Apr 11, 2014 11:10 pm

Maybe I was wrong about it bypassing windows, IDK but it's certainly not all on-top of Windows.

To my knowledge:
  • Cygwin is a "translation layer" between Win32 and POSIX user-mode APIs created as a c library and distributed in a Windows style DLL file (for Cygwin compiled windows binaries of for-Linux user-mode software) see http://cygwin.com/faq.html#faq.api.everything & http://superuser.com/a/729393.
  • KVM is a Linux device-driver which has to directly communicate with the OS's kernel (last time I used KVM I had to rebuild my Linux kernel from [patched] sources to add KVM support), thus I wouldn't think that Cygwin would support compiling KVM at all.
So what it looks to me like they've done is to develop a driver with similar purpose to Cygwin but for translating Linux kernel functions to Windows kernel APIs, then to put a piece of Cygwin-based user-mode software running under Windows to interface with it. However since Windows' kernel doesn't have equivalents to all the functions Linux's kernel needs to have for KVM to function they apparently had to directly use portions of Linux's kernel in their driver, this runs on the hardware itself without (much) communication with Windows' own kernel, and since you now basically have (portions of) two kernels running on the same hardware at the same time without really knowing that the other ones there (AFAIK there are no predefined rules for how such interaction would take place) they can (and do) step on each-others toes. Thus all kinds of weird bugs, and since it's not being developed any more none of the bugs are getting fixed.

Note my interpretation could be totally off base, but that's how I (currently) understand it, if someone who really knows what's going on can explain it, please do.

P.S.: Darn it looks like we got off topic again. :?

Now to go WAY back on-topic:
I was going to edit the wiki to show that qemu's USB tablet option works in current builds, but I'm not sure about the ReactOS wiki's hardware support status updating etiquette.
Should I replace the already existing note stating that it "Failed" with r59118, or am I supposed to add another "Works" entry for 0.13.16 & r62690+ with ssam & I in the tester cell and a comment stating that ssam tested under Fedora 20 w/ qemu & qemu-kvm & I tested under Windows 7 Pro x64? (or is there another way that it should be done which I've not thought of?)
Last edited by justincase on Sat Apr 12, 2014 9:13 am, edited 1 time in total.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 1 guest