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

[qemu]

On Wed, 27 Jul 2005, Paul Brook wrote:
> 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.
> >
> > [...]
> >
> > 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 :-)

Yes!  Ugly half-baked hack works again! ... wait - we try not to promote 
that, right?

> 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.

Does this have to do with the long rxx regs not overlapping legacy exx?  
I figured this should be relatively simple because of the way AMD designed
it.  Though, they do state that you can not rely on register values
between mode switches and I think this is an assumption that I made.

> 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.

You're probably right -- Your code is tight enough that the whole thing
might be in cache.  All of switch.S represents maybe 1k of byte code, 
right?

> 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.

How well is your implementation of this going?

> > 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.

To be honest, I am surprised too.  I thought - what the heck - sit down, 
replace the regs, get it to compile and see what happens.  We used to 
write ATMO on our proofs when we knew the answer but couldn't prove it: 
  "and then a miracle occurred."  I always ended up with ATMO far before 
QED ;)

I look forward to your PAE implementation and a stable qemu/qvm86. Since 
your code is GPL (and kqemu is not) this could end up being a very well 
built vmware replacement!

-Eric


-- 
Eric Wheeler
Vice President
National Security Concepts, Inc.
PO Box 3567
Tualatin, OR 97062

http://www.nsci.us/
Voice: (503) 293-7656
Fax:   (503) 885-0770