Re: [qvm86-devel] qvm86 under amd64 is now working.

[Paul Brook]

On Wednesday 27 July 2005 19:53, address@hidden wrote:
> On Wed, 27 Jul 2005, Paul Brook wrote:
> > On Wednesday 27 July 2005 09:56, address@hidden wrote:
> > > I have upated switch.S and qvm86 now compiles and boots under amd64.
> >
> > Really? How did you cope with PAE (ie. 64-bit physical memory addresses)?
> > The shadow pagetable code definitely doesn't handle that, I'm currently
> > part way through implementing it.
>
> Truth be told, it doesn't.  All of my memory is below 32bits (1gb) which
> is probably why we've not seen a problem.  Systems with more memory would
> need to be mapped down somehow.  If you have been working on an
> implementation which supports PAE then you are far ahead of me!  The diff
> and switch.S are available here:
>
> http://www.nsci.us/~ewheeler/qvm86/
>
> The changes I have made allow it to compile without error and use the REX
> registers.  The AMD x86-64 Architecture Programmer's Manual was an
> excellent help (below).  It only took an hour or two to make the updates
> to switch.S and most of the changes were simple replacements such as
>
> :%s/e\([abcd]x\)/r\1/g .  See the block comments around pushq and popq.
>
> Since %ds,es,fs,gs don't appear to exist on x86_64, I wasn't sure what to
> do with them.  To my surprise, it still worked even after blindly
> commenting out the blocks.  Perhaps you can offer better insight as to
> what this actually affects.

I've really no idea how this manages to work. It certainly doesn't deserve 
to :-)

I guess what's happening is that when we load the guest CR0/4 values it 
switches the CPU back into legacy 32-bit mode, and the instruction encoding 
for the 64-bit long mode encoding happens to be the same as the 32-bit 
encoding.

There's a short period where the new CR values are loaded where you have CR3 
pointing at 32-bit legacy pagetables, but CR0/4 setup for long mode PAE. I 
can only guess that the CPU happens to have the next 3 instructions in cache 
as a TLB lookup at this point would be fatal.

The proper solution is to handle PAE, leave the CPU in long mode when 
switching to the monitor, then run the guest code in compatibility mode.

> The qvm86.ko module inserts fine and qemu reports that qvm86 is active.
> In addition, w2k appears to boot faster but has the same problem that
> kqemu does, thus prompting my interest in qvm86
> (http://m2.dad-answers.com/qemu-forum/viewtopic.php?t=123).  Initially I
> thought this was a gcc4 issue, but someone else is experiencing the same
> issue.  Since both kqemu and qvm86 BSOD at the same place, it may be a
> qemu issue more than an accelerator issue.

I've no idea what's happening on here. I'm extremely surprised qvm86 even gets 
this far.

Paul