[Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Dave Feustel]

Will Qemu be modified to take advantage of the hardware virtualization
facilities incorporated in AMD's Pacifica and/or Intel's Vanderpool technogies?

Thanks,
Dave Feustel
-- 
Tired of having to defend against Malware?
You know: trojans, viruses, SPYWARE, ADWARE, 
KEYLOGGERS, rootkits, worms and popups.
Then Switch to OpenBSD with a KDE desktop!!!

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Hetz Ben Hamo]

It really depends on Fabrice or another contributions from developers..

If Intel or AMD want to donate a machine with VanderPool/Pacificia to
Fabrice, maybe he'll add it :)

Hetz

On 11/6/05, Dave Feustel <dfeustel@verizon.net> wrote:
> Will Qemu be modified to take advantage of the hardware virtualization
> facilities incorporated in AMD's Pacifica and/or Intel's Vanderpool technogies?
>
> Thanks,
> Dave Feustel
> --
> Tired of having to defend against Malware?
> You know: trojans, viruses, SPYWARE, ADWARE,
> KEYLOGGERS, rootkits, worms and popups.
> Then Switch to OpenBSD with a KDE desktop!!!
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Paul Brook]

On Sunday 06 November 2005 15:19, Dave Feustel wrote:
> Will Qemu be modified to take advantage of the hardware virtualization
> facilities incorporated in AMD's Pacifica and/or Intel's Vanderpool
> technogies?

qemu is an emulator, not a virtualizer, so these extensions don't really help.

You may want to look at Xen (www.xensource.com), which already supports these.

Paul

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Mark Williamson]

> On Sunday 06 November 2005 15:19, Dave Feustel wrote:
> > Will Qemu be modified to take advantage of the hardware virtualization
> > facilities incorporated in AMD's Pacifica and/or Intel's Vanderpool
> > technogies?
>
> qemu is an emulator, not a virtualizer, so these extensions don't really
> help.

They could be leveraged by kqemu one day...

/me thinks we'll see a rash of Linux kernel "hypervisor modules" when VTX / 
SVM hardware is available.

Cheers,
Mark

> You may want to look at Xen (www.xensource.com), which already supports
> these.
>
> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Anthony Liguori]

Mark Williamson wrote:

>>qemu is an emulator, not a virtualizer, so these extensions don't really
>>help.
>>    
>>
>
>They could be leveraged by kqemu one day...
>
>/me thinks we'll see a rash of Linux kernel "hypervisor modules" when VTX / 
>SVM hardware is available.
>  
>
Indeed.  I've already started my own ;-)  My initial guess is that the 
kqemu/qvm86 model would work quite well extended for VT/SVM.

That is, a kernel driver that provides a memory area that can be 
read-from/written-to in userspace, and then an ioctl interface that 
blocks while running code and returns when a sensitive instruction is 
hit.  It probably makes sense to handle most of the stuff in kernel 
space (shadow paging and such) and just return to userspace for IO 
operations.

Regards,

Anthony Liguori

>Cheers,
>Mark
>
>  
>
>>You may want to look at Xen (www.xensource.com), which already supports
>>these.
>>
>>Paul
>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>    
>>
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Dave Feustel]

On Sunday 06 November 2005 10:33, Paul Brook wrote:
> On Sunday 06 November 2005 15:19, Dave Feustel wrote:
> > Will Qemu be modified to take advantage of the hardware virtualization
> > facilities incorporated in AMD's Pacifica and/or Intel's Vanderpool
> > technogies?
> 
> qemu is an emulator, not a virtualizer, so these extensions don't really help.
> 
> You may want to look at Xen (www.xensource.com), which already supports these.
> 
> Paul

I've been subscribed to several Xen mailing lists for about a year.
I got further in 1/2 hour with Qemu than with Xen during the past year.
(This is probably due to the fact that Xen is, so far, for all practical purposes, 
a linux-only tool so far, so I can't run it with OpenBSD). Xen will probably 
become more useable with OpenBSD when Xen 3.0 arrives along with 
Pacifica-enabled AMD chips.

But back to Qemu.  I have looked at the faq and the documentation, but
I don't yet see how to load files from my file system to the disk image file
used by qemu.

Also, I am interested in qemu-arm and qemu-ppc, both to run on x86 under
OpenBSD if possible.

The keyboard mapping problem I reported in a previous post goes away when
I invoke startx. The Xwindow programs all seem to get the correct keycodes.



-- 
Tired of having to defend against Malware?
You know: trojans, viruses, SPYWARE, ADWARE, 
KEYLOGGERS, rootkits, worms and popups.
Then Switch to OpenBSD with a KDE desktop!!!

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Anthony Liguori]

Paul Brook wrote:

>On Sunday 06 November 2005 15:19, Dave Feustel wrote:
>  
>
>>Will Qemu be modified to take advantage of the hardware virtualization
>>facilities incorporated in AMD's Pacifica and/or Intel's Vanderpool
>>technogies?
>>    
>>
>
>qemu is an emulator, not a virtualizer, so these extensions don't really help.
>  
>
Not quite.

qemu is technically a JIT.  kqemu/qvm86 are virtualizers.  Bochs is an 
actual emulator.

VT/SVM will definitely improve the performance of kqemu/qvm86.  The only 
bottleneck left in QEMU would be the IO emulation.  Since Xen uses the 
QEmu IO model any performance improvements for Xen IO emulation should 
be sharable with QEmu...

>You may want to look at Xen (www.xensource.com), which already supports these.
>  
>
Xen is a Type I VMM, QEmu is a Type II.  They aren't interchangable.

The main difference between a Type I and a Type II VMM is that a Type I 
runs on bare metal (and has control of the entire platform) whereas a 
Type II VMM runs within an Operating System.

The "Analysis of the Intel Pentium's Abiliity to Support a Secure VMM" 
paper has a good discussion of the differences between the two (the 
original Popek/Goldberg paper is pretty dense).

Regards,

Anthony Liguori

>Paul
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Jim C. Brown]

On Sun, Nov 06, 2005 at 06:57:37PM -0600, Anthony Liguori wrote:
> >qemu is an emulator, not a virtualizer, so these extensions don't really 
> >help.
> > 
> >
> Not quite.
> 
> qemu is technically a JIT.  kqemu/qvm86 are virtualizers.  Bochs is an 
> actual emulator.
> 

VT/SVM won't help the JIT part of qemu. And kqemu/qvm86 are optional.

> VT/SVM will definitely improve the performance of kqemu/qvm86. 

VT/SVM won't actually help them that much in the current case, assuming that my
understanding is correct. They can only make the userland bits a little
faster, and kqemu/qvm86 don't support running kernel code (where the real gains
would be realized). The JIT still handles that, so there is still an emulated
cpu.

They could be extended to take over both userland and kernel code easily though.
(In which case the user space qemu would provide only the system emulation
bits - there'd no longer be any emulation of the guest cpu). I believe that
there are plans to extend kqemu to be able to do this at some point. But at
that point I'd hesitate to call the combination "QEMU", since there would be
nothing of the original qemu left (for the record this considered of the
dynamic translator/JIT and the qemu-user code).

> >You may want to look at Xen (www.xensource.com), which already supports 
> >these.
> > 
> >
> Xen is a Type I VMM, QEmu is a Type II.  They aren't interchangable.
> 

Agreed. Of course, since Xen runs on the bare metal, one would expect that it
would have better performance than qemu anyways (though if qemu's io model is
used, that is not going to be true for the obvious reasons). If ease of
installation is more important than performance, qemu is less invasive. I guess
that can be considered a tradeoff.

I doubt qemu + kqemu/qvm86 is a pure Type II anyways, since it modifies the
host operating system. And from my understanding of qvm86, the userland code
is essentially run directly by qvm86 directly on the bare hardware, since the
only parts of the host kernel that are involved are the parts that tell the
kernel to leave that code alone. Modifying the accelerators so they handle
running of all the guest code moves even farther away from this.

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

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Anthony Liguori]

Jim C. Brown wrote:

>>VT/SVM will definitely improve the performance of kqemu/qvm86. 
>>    
>>
>
>VT/SVM won't actually help them that much in the current case, assuming that my
>understanding is correct. They can only make the userland bits a little
>faster, and kqemu/qvm86 don't support running kernel code (where the real gains
>would be realized).
>
VT/SVM allows you to run kernel code unmodified and without binary 
translation on bare metal.

>They could be extended to take over both userland and kernel code easily though.
>(In which case the user space qemu would provide only the system emulation
>bits - there'd no longer be any emulation of the guest cpu).
>
Yup.

>I believe that
>there are plans to extend kqemu to be able to do this at some point. But at
>that point I'd hesitate to call the combination "QEMU", since there would be
>nothing of the original qemu left (for the record this considered of the
>dynamic translator/JIT and the qemu-user code).
>  
>
kqemu would have to take advantage of VT/SVM to be able to run kernel 
code.  There's an excellent paper (that I referenced in my previous 
note) that explains why this is the case.

>Agreed. Of course, since Xen runs on the bare metal, one would expect that it
>would have better performance than qemu anyways (though if qemu's io model is
>used, that is not going to be true for the obvious reasons). If ease of
>installation is more important than performance, qemu is less invasive. I guess
>that can be considered a tradeoff.
>  
>
Yeah, I think that's the basic trade-off.

>I doubt qemu + kqemu/qvm86 is a pure Type II anyways, since it modifies the
>host operating system. And from my understanding of qvm86, the userland code
>is essentially run directly by qvm86 directly on the bare hardware, since the
>only parts of the host kernel that are involved are the parts that tell the
>kernel to leave that code alone. Modifying the accelerators so they handle
>running of all the guest code moves even farther away from this.
>  
>
The original Popek/Goldberg paper puts a set of requirements on the host 
Operating System such that one can implement a Type II VMM.  You can 
think of kqemu/qvm86 as extending the host operating system to satisfy 
the Type II requirements.

Regards,

Anthony Liguori

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

Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Jim C. Brown]

On Sun, Nov 06, 2005 at 10:19:18AM -0500, Dave Feustel wrote:
> Will Qemu be modified to take advantage of the hardware virtualization
> facilities incorporated in AMD's Pacifica and/or Intel's Vanderpool technogies?
> 
> Thanks,
> Dave Feustel

qemu can't use these, since they dont help running PPC code on x86 or x86 code
on a PPC or ARM code on an x86.

kqemu/qvm86 could. kqemu probably will at some point since it is Fabrice's intention
to turn kqemu into something like VMware.

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