RE: [Xen-users] Pacifica/VT

["Petersson, Mats" <mats.petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Matthijs ter Woord
> Sent: 25 October 2005 16:29
> To: Mark Williamson; xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] Pacifica/VT
> 
> 
> > In theory, other Windows versions (and other random OSes) 
> ought to work.
> > Certainly, I think the Linuxes and BSDs are known to work happily.  
> > Some people will probably want to run ancient Windows 
> versions on Xen 
> > in order
> to
> > migrate really old servers to a new machine.
> 
> Ancient? is Windows 2000 also ancient already?

There isn't any particular reason why Win2K or WinNT wouldn't work. The
only quirk with this is that each OS-version has it's own special things
that someone has cleverly thought out how to do special things. With
these things, when emulating for instance memory mapped IO, the
hypervisor needs to understand every instruction. So, for instance, if
Windows XP always uses MOV-instructions to access MMIO-space, but some
base-driver in Win2K uses an OR-instruction for one special operation,
then Win2K would require that this OR-instruction is included in the set
of instructions to be emulated. It's no rocket science, but it's a
complex subject, and there's many more ways that can break than the
number of ways that works. 

In essense, there's really no reason to think that any particular OS
isn't supposed to work, but it all depends on what particulars of
hardware access and weirdness occurs in that particular OS. If all OS's
were written cleanly and never using any special functionality in the
OS, then it's fine. 

I think someone found out (the hard way) that some OS's don't follow the
published standard for how to transfer from Real-mode to protected mode
(which is the instruction immediately following move to CR0 should be a
far-jump), which meant that the emulation code would think and behave
like if the processor was in protected mode, but the CS register wasn't
updated to it's proper protected mode values, which of course causes
weird behaviour in the emulation software. Lots of these special cases
can exist in software, and the emulation code that interprets this code
MUST be able to handle it just like the real hardware (whether the
hardware does what is really expected or something else). 

> 
> > Intel are certainly planning to support 32-bit VTX on a 
> 64-bit host -
> somebody
> > from AMD would have to comment on their plans for this (if 
> they can at
> this
> > stage).
> 
> This would be great, although i'd personally hope that AMD 
> will support that too, as AMD's are more powerfull (imo)

It's certainly our plan to support 64-bit Xen running 32-bit OS's. As
with Intel's solution, it's not ENTIRELY trivial to support 3-level
page-tables on a system which natively needs 4-level page-tables, and
the related interesting problems that this leads to. But by all
accounts, it should "just work". This may or may not be in the first
release of code to the public, that I can't really say, as I'm not sure
what will be released and when...

--
Mats
> 
> 
> Thanks for the information thusfar.
> 
> Regards,
> 
> Matthijs ter Woord
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users