Re: [Qemu-devel] Plex86 and Qemu

["Jim C. Brown" <jma5@umd.edu>]

On Sun, Feb 13, 2005 at 05:20:04PM -0600, jeebs@yango.us wrote:
> From: "Jim C. Brown" <jma5@umd.edu>
> 
> > a) is taken care of by letting user space qemu use dynamic translation on
> > ring 0 instructions (same as qemu + kqemu works now), and b) is taken care of
> 
> If I remember right (and I may not), one of the problems with Plex86 v1 was the difficulty of catching all possible transistions, from areas where it was safe to let the code run, to areas that had to be carefully monitored.
> 
> It sounds like your idea of letting qemu handle the ring 0 stuff is going to have the same kind of problems.
> 
> But, I could be wrong.  I'm not that good of a programmer, and I certainly am not familiar with emulator programming.
> 

This has already been solved for kqemu. I don't actually have to code anything
for this, it has already been taken care of. (That's also probably why no one
aside from Fabrice himself has tried before now - getting a non CVS version of
qemu to work with plex86 would be consiberably more work.)

> >> I wouldn't call that "majority of potential users"...  Maybe "many in this mailing list", but that's not quite the same thing.
> >> 
> >> [grimace]
> >> 
> >> Oh well.
> > 
> > Feel free to port it to a Windows host then. I noticed that you didn't complain
> 
> I'm not that good of a programmer.  I have never made any comments to suggest that I was.
> 

Fair enough. This is the qemu-devel list (the developers list), so generally
it is a good idea to ask.

> 
> >> Then that's still going to be extremely limited.  Effecting probably 95%+ of the potential users.
> > 
> > It will support the same series of users that kqemu does.
> 
> Right.  And that's still very limited.
> 
> There has been a lot of excitement in the mailing list, but few have bothered to mention that for most users, the kqemu stuff doesn't matter.  I suspect most of those people either got distracted by the license, or just kept their mouth shut.
> 
> 

In my experience, most users of qemu tend to be using linux as the host OS,
and some version of Windows as a guest OS.

(Of course, I only read this list. It would make sense if users of Windows Qemu
were mainly on the user forum or such. Still, I honestly find that "95% of qemu
users use Windows as the host OS" a bit hard to swallow, but I digress.)

> 
> > when kqemu was announced, despite the fact that it only supports linux hosts.
> > Care to explain why?
> 
> Fabrice mentioned long ago that his module would only work with Linux hosts.  I don't know why.  Whether its his familiarity with Linux, or if it's something that can only be done under Linux and not Windows.  (I have no idea how vmware & virtualPC do their stuff, or what method kqemu uses.)
> So when he did finally release it, it was no surprise.  I was already resigned to the fact that it wasn't going to help me in the slightest.  And therefor I don't care what license it is released under.  If it ever works under Windows, then I'll care.
> When you announced your plans, I was hoping that it might be something that I and 95% of the rest of the world could actually use.  You weren't clear in your original message, so I asked.
> Turns out I was wrong though.
> Since it's not going to help us, I have no further interest in your project.
> Your project sounds like it falls into the exact same category as qemu-fast and now kqemu... Mildly worth knowing they exist, but of no practical value for me.  No reason to get excited or upset.
> 

Fair enough. I apologize for the unintended insult.

I'm not against the idea of getting qemu virtalization to work on a Windows
host, but I don't know enough to do it myself. That is the only reason
I'm not supporting it. If someone who knew enough wanted to work with me on it,
I'd be more than happy to do so.

I don't even know enough to get this to work for Linux, which is why I'm
modifying qemu to use the plex86 kernel module unmodified. It would actually
be easier and cleaner to rewrite the 4 functions in kqemu-mod-i386.o from
scratch (not to mention, far easier to maintain). The other person who is
working on replacing kqemu is doing this, more or less (that person is studying
plex86 as a reference in order to figure out what needs to be done).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.