VMware handles kernel code. You are right that x86 code can't be 100%
virtualized
(even at the userland level) but VMware uses a lot of nasty disgusting tricks
in order to work around them. (For example, playing with shadow pagetables
so that a page of modified code is run but if the code
I take it self-modifying kernel code would have serious issues.
Seems likely :-) With hardware support, making things like this work should
be *much* easier.
I seem to recall my attempts to run v2OS (which uses a self-modifying
assembly code boot sequence) inside VMWare crashing badly circa
On Tue, Sep 13, 2005 at 09:48:01PM -0500, Anthony Liguori wrote:
Jim C. Brown wrote:
The x86 cannot be virtualized in the Popek/Goldberg sense, so there's
a couple of fast emulation techniques that are possible. Other than a
hand coded dynamic translator, I reckon qemu + kqemu is about as
On Tue, Sep 13, 2005 at 11:27:39PM -0500, Anthony Liguori wrote:
I reckon kqemu has this same problem... Technically, even in ring 3, if
you run natively, you violate the Popek/Goldberg requirements because of
cpuid. It's just not possible to trap it but it shouldn't matter for
most
On Wed, 14 Sep 2005, Jim C. Brown wrote:
Not familar with L4ka. I don't believe that UML does virtualization, it simply
runs linux code 'as is' but intercepts calls to the kernel.
UML does not do hardware virtualization. UML is a special architecture for
the Linux kernel allowing Linux to
Two side footnotes to your comprehensive explanation:
1) with the SKAS host kernel patch you don't have to ptrace the guest
processes and performance (and security) is improved quite a bit, I
understand.
2) UML is currently being ported to run in ring 0. Why? Not for running on
native
There are a couple of interesting paravirtualization techniques too.
There's the Xen approach (really fast, but very invasive), the L4ka
afterburning (theoritically close to as fast, but less invasive), and
then of course the extremes like UML.
Not familar with L4ka. I don't believe that
On Wed, Sep 14, 2005 at 01:46:58PM -0500, Anthony Liguori wrote:
You can't readahead beyond a basic block. Taking a trap for each basic
block and translating the block is what QEMU does.
No, QEMU translates everything from guest machine code into its internal codes.
I'm talking about using
On Wed, Sep 14, 2005 at 10:18:24AM -0700, John R. Hogerhuis wrote:
Why disgusting?
Perhaps you meant disgusting because the Intel architecture forces a
virtualizer to handle a bunch of corner cases like this.
That is exactly what I mean.
-- John.
--
Infinite complexity begets
Alexandre Leclerc wrote:
I'm new to qemu and my question is simple and is probably due to my
ignorance. If I compare qemu and vmware, there is a great deal of
emulation speed differences.
Did you try kqemu or qvm86?
--
Pozdrowienia,
Adrian Smarzewski
On Tue, Sep 13, 2005 at 08:36:29AM -0400, Alexandre Leclerc wrote:
Hi all,
I'm new to qemu and my question is simple and is probably due to my
ignorance. If I compare qemu and vmware, there is a great deal of
emulation speed differences.
- Is it because of what qemu is? (i.e. it is a full
On 9/13/05, Adrian Smarzewski [EMAIL PROTECTED] wrote:
Alexandre Leclerc wrote:
I'm new to qemu and my question is simple and is probably due to my
ignorance. If I compare qemu and vmware, there is a great deal of
emulation speed differences.
Did you try kqemu or qvm86?
Yes, with kqemu.
On Tue, Sep 13, 2005 at 09:58:11AM -0500, Anthony Liguori wrote:
Jim C. Brown wrote:
Fabrice had said that he wants
kqemu to be able to do total virtualization (both kernel and userland
bits);
basically all the translation code of qemu would be left unused but the
hardware emulation
No, I got the impression that Fabrice was taking about virtualization the
way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the works)
do it.
So it'll work w/o needing a 64bit chip.
I hadn't seen vmbear, looks interesting... Full virtualisation on vanilla x86
would be really
Jim C. Brown wrote:
On Tue, Sep 13, 2005 at 09:58:11AM -0500, Anthony Liguori wrote:
Jim C. Brown wrote:
Fabrice had said that he wants
kqemu to be able to do total virtualization (both kernel and userland bits);
basically all the translation code of qemu would be left unused but
No, I got the impression that Fabrice was taking about virtualization the
way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the
works) do it.
The x86 cannot be virtualized in the Popek/Goldberg sense, so there's
a couple of fast emulation techniques that are possible. Other
Well, VMware guests can recognise that they're in a VM because the
software contains a backdoor INT function, mainly used by VMware Tools
for things like Shared Folders and host-controlled mouse cursors
insides guests. I don't quite remember what the function was for
VMware's backdoor, but you can
17 matches
Mail list logo
