[Qemu-devel] OT: Running qemu without host os?

[Qemu-devel] OT: Running qemu without host os?

[Peter Karlsson]

Hi!

I'm toying with the idea of running qemu as a vm from linuxbios and then
boot another os inside the vm (qemu). Qemu would have to virtualise the
hardware but still let the virtual os access hardware via normal hardware
registers, i.e. the os would not know a real computer from a virtualised
one. Is this theoretically possible, or maybe even practically?

One of the reasons for doing something like this would be to snoop windows
driver registers for example reverse engineering of graphics hardware and
maybe wireless network cards. But I can think of several other useful
areas like high-availability, remote management of cluster nodes etc...

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Qemu-devel] OT: Running qemu without host os?

[Jim C. Brown]

On Fri, Jan 21, 2005 at 05:10:33PM +0100, Peter Karlsson wrote:
> Hi!
> 
> I'm toying with the idea of running qemu as a vm from linuxbios and then
> boot another os inside the vm (qemu). Qemu would have to virtualise the
> hardware but still let the virtual os access hardware via normal hardware
> registers, i.e. the os would not know a real computer from a virtualised
> one. Is this theoretically possible, or maybe even practically?

>From instead a host OS the virtual (or guest) OS would not know that it is
not a real computer. Emulating from the hardware would make this even harder
to figure out. The part about giving access to the native hardware directly
(instead of access to emulated hardware) is interesting.

> 
> One of the reasons for doing something like this would be to snoop windows
> driver registers for example reverse engineering of graphics hardware and
> maybe wireless network cards. But I can think of several other useful
> areas like high-availability, remote management of cluster nodes etc...

This can still be done in a host OS. The only benefit of using qemu directly is
the factor of speed and RAM usage (you can go faster when you access the bare
metal and you don't have to load up an OS).

> 
> Best regards
> 
> Peter K
> 
> -- 
> We Can Put an End to Word Attachments:
> http://www.fsf.org/philosophy/no-word-attachments.html
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] OT: Running qemu without host os?

[Peter Karlsson]

On Fri, 21 Jan 2005, Jim C. Brown wrote:

> >From instead a host OS the virtual (or guest) OS would not know that it is
> not a real computer. Emulating from the hardware would make this even harder
> to figure out. The part about giving access to the native hardware directly
> (instead of access to emulated hardware) is interesting.

Well, the vm would still have virtualise the hardware wouldn't it? I'm
thinking of it as like a filter which can let everything, nothing and all
in between pass through depending on settings. Think of linux virtual
memory where a process does not know whether it's in real memory or not.

> This can still be done in a host OS. The only benefit of using qemu directly is
> the factor of speed and RAM usage (you can go faster when you access the bare
> metal and you don't have to load up an OS).

So if I use linux as a host os and run windows 2000 as a vm would qemu let
windows access for example a radeon 9800xt graphics card via ati's
official windows drivers? I haven't played with qemu yet and don't know
it's capabilities but I doubt that the host os would be happy with a
virtual os taking over the graphics hardware (for instance)...

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Qemu-devel] OT: Running qemu without host os?

[Jim C. Brown]

On Fri, Jan 21, 2005 at 07:03:18PM +0100, Peter Karlsson wrote:
> On Fri, 21 Jan 2005, Jim C. Brown wrote:
> 
> > >From instead a host OS the virtual (or guest) OS would not know that it is
> > not a real computer. Emulating from the hardware would make this even harder
> > to figure out. The part about giving access to the native hardware directly
> > (instead of access to emulated hardware) is interesting.
> 
> Well, the vm would still have virtualise the hardware wouldn't it? I'm
> thinking of it as like a filter which can let everything, nothing and all
> in between pass through depending on settings. Think of linux virtual
> memory where a process does not know whether it's in real memory or not.

What exactly do you mean by "virtualise the hardware" ?

Qemu already acts as such a filter (except that it has to go thru the host OS
to access the bare metal and that the emulated hardware usually isn't the same
as the hardware the host OS has.)

> 
> > This can still be done in a host OS. The only benefit of using qemu directly is
> > the factor of speed and RAM usage (you can go faster when you access the bare
> > metal and you don't have to load up an OS).
> 
> So if I use linux as a host os and run windows 2000 as a vm would qemu let
> windows access for example a radeon 9800xt graphics card via ati's
> official windows drivers?

No, that would be the intriquing part. (Actually, a linux host CAN give that
access, as long as it is a PCI card you are giving the guest access to - but
then only the guest can use it exclusively. Of course Qemu needs to run in X so
this isn't yet possible .. unless you have 2 graphics cards, one of them is
PCI, and the linux host is using the other graphic card.)

> I haven't played with qemu yet and don't know
> it's capabilities but I doubt that the host os would be happy with a
> virtual os taking over the graphics hardware (for instance)...

As long as it is exclusive, it isn't a problem.

> 
> Best regards
> 
> Peter K
> 
> -- 
> We Can Put an End to Word Attachments:
> http://www.fsf.org/philosophy/no-word-attachments.html
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

[Qemu-devel] Re: OT: Running qemu without host os?

[Ben Pfaff]

"Jim C. Brown" <jbrown106@phreaker.net> writes:

> (Actually, a linux host CAN give that access, as long as it is
> a PCI card you are giving the guest access to - but then only
> the guest can use it exclusively. Of course Qemu needs to run
> in X so this isn't yet possible .. unless you have 2 graphics
> cards, one of them is PCI, and the linux host is using the
> other graphic card.)

qemu does not need to run in X.  Use the -nographic option.
-- 
"The only problem with Linux for Dummies is that the advice it
 contains will result only in embarrassment and inconvenience if
 followed, not actual death."
--henke at insync dot net

Re: [Qemu-devel] Re: OT: Running qemu without host os?

[Karl Magdsick]

> 
> qemu does not need to run in X.  Use the -nographic option.
>

Additionally, I believe QEMU only uses X11 through SDL.  I also
believe that SDL is primarily used in conjunction with device
emulation... so if you're getting rid of all emulated devices, it
would seem that the use or disuse of the -nographic option would be
irrelivant unless you went through a LOT of trouble to snoop and
interpret what the guest was writing to the graphics card.  By giving
the guest access to real graphics, sound, mouse, and keyboard
hardware, you are pretty much cutting SDL out of QEMU.

Presumably, you would have the host hide a NIC from the guest and
provide an emulated NIC or else a second physical NIC for the guest to
use.  You would then use the hidden NIC to remotely log all of the
data you were collecting while spying on the drivers.  The hidden NIC
would also presumably be the only way to interact with the minimalist
host.  You could also do something similar with HD controllers rather
than NICs and log everything to a hidden HD.  However, a flaw in your
virtualization/emulation would put local logs at risk for corruption.

A hidden NIC or an emulated keyboard chipset would almost be mandatory
in order to communicate with the minimalist host.


-Karl

Re: [Qemu-devel] Re: OT: Running qemu without host os?

[Peter Karlsson]

On Fri, 21 Jan 2005, Karl Magdsick wrote:

> Additionally, I believe QEMU only uses X11 through SDL.  I also
> believe that SDL is primarily used in conjunction with device
> emulation... so if you're getting rid of all emulated devices, it
> would seem that the use or disuse of the -nographic option would be
> irrelivant unless you went through a LOT of trouble to snoop and
> interpret what the guest was writing to the graphics card.  By giving
> the guest access to real graphics, sound, mouse, and keyboard
> hardware, you are pretty much cutting SDL out of QEMU.
>
> Presumably, you would have the host hide a NIC from the guest and
> provide an emulated NIC or else a second physical NIC for the guest to
> use.  You would then use the hidden NIC to remotely log all of the
> data you were collecting while spying on the drivers.  The hidden NIC
> would also presumably be the only way to interact with the minimalist
> host.  You could also do something similar with HD controllers rather
> than NICs and log everything to a hidden HD.  However, a flaw in your
> virtualization/emulation would put local logs at risk for corruption.
>
> A hidden NIC or an emulated keyboard chipset would almost be mandatory
> in order to communicate with the minimalist host.

Possible scenario?:

*Linux host, one hidden nic, running sshd.
*windows 2000 guest os with ati windows drivers.
*host releases relevant hardware (radeon 9800xt, keyboard,
mouse) to guest os.

Would that work?

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Qemu-devel] Re: OT: Running qemu without host os?

[Jim C. Brown]

On Fri, Jan 21, 2005 at 01:30:44PM -0800, Ben Pfaff wrote:
> "Jim C. Brown" <jbrown106@phreaker.net> writes:
> 
> > (Actually, a linux host CAN give that access, as long as it is
> > a PCI card you are giving the guest access to - but then only
> > the guest can use it exclusively. Of course Qemu needs to run
> > in X so this isn't yet possible .. unless you have 2 graphics
> > cards, one of them is PCI, and the linux host is using the
> > other graphic card.)
> 
> qemu does not need to run in X.  Use the -nographic option.

This only works if the guest OS is a linux kernel, and it requires the
-kernel option, if iirc.

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

Re: [Qemu-devel] Re: OT: Running qemu without host os?

[Ben Pfaff]

"Jim C. Brown" <jbrown106@phreaker.net> writes:

> On Fri, Jan 21, 2005 at 01:30:44PM -0800, Ben Pfaff wrote:
>> qemu does not need to run in X.  Use the -nographic option.
>
> This only works if the guest OS is a linux kernel, and it requires the
> -kernel option, if iirc.

It works with any kernel that supports a serial (or network)
console.  It does not require -kernel.  I have used it with Linux
and with my own instructional OS, Pintos, to useful effect.
-- 
"Premature optimization is the root of all evil."
--D. E. Knuth, "Structured Programming with go to Statements"

Re: [Qemu-devel] OT: Running qemu without host os?

[Peter Karlsson]

On Fri, 21 Jan 2005, Jim C. Brown wrote:

> What exactly do you mean by "virtualise the hardware" ?

virtual_os(hardware access) -> vm -> hardware

> Qemu already acts as such a filter (except that it has to go thru the host OS
> to access the bare metal and that the emulated hardware usually isn't the same
> as the hardware the host OS has.)

Ok.

> No, that would be the intriquing part. (Actually, a linux host CAN give that
> access, as long as it is a PCI card you are giving the guest access to - but
> then only the guest can use it exclusively. Of course Qemu needs to run in X so
> this isn't yet possible .. unless you have 2 graphics cards, one of them is
> PCI, and the linux host is using the other graphic card.)

Would the other way around work (i.e. linux using pci gfx card and the
guest os using agp)? Anyway that's good to know. Thanks!

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Qemu-devel] OT: Running qemu without host os?

[Jim C. Brown]

On Fri, Jan 21, 2005 at 11:45:11PM +0100, Peter Karlsson wrote:
> On Fri, 21 Jan 2005, Jim C. Brown wrote:
> 
> > What exactly do you mean by "virtualise the hardware" ?
> 
> virtual_os(hardware access) -> vm -> hardware

That would be interesting. Qemu can't do that yet (it shares hardware via
the help of the host OS, of course, but not direct access).

If you had qemu running multiple OSes, and all of them could access the same
hardware "virtually directly", that would be simply amazing. Not quite sure
how one could go about doing this though..

> 
> > No, that would be the intriquing part. (Actually, a linux host CAN give that
> > access, as long as it is a PCI card you are giving the guest access to - but
> > then only the guest can use it exclusively. Of course Qemu needs to run in X so
> > this isn't yet possible .. unless you have 2 graphics cards, one of them is
> > PCI, and the linux host is using the other graphic card.)
> 
> Would the other way around work (i.e. linux using pci gfx card and the
> guest os using agp)? Anyway that's good to know. Thanks!

No, it currently only works with PCI. ISA, AGP, USB, and traditional hardware
can't be accessed directly yet (tho it is theoreticly possible).

> 
> Best regards
> 
> Peter K
> 
> -- 
> We Can Put an End to Word Attachments:
> http://www.fsf.org/philosophy/no-word-attachments.html
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] OT: Running qemu without host os?

[Karl Magdsick]

> 
> If you had qemu running multiple OSes, and all of them could access the same
> hardware "virtually directly", that would be simply amazing. Not quite sure
> how one could go about doing this though..
> 

Unless all of the guest OSes were modified to be aware that they were
sharing hardware (or else some really intelligent dynamic patching was
going on), the OSes would step all over eachother.  For instance, one
guest OS might put the NIC in promiscuous mode right before another
guest OS boots and re-initializes the NIC to non-promiscuous mode.  A
third guest OS might then change the MAC address on the NIC and screw
up ARP.

However, your idea isn't that much different from the (fairly new)
exokernel concept, where each process has its own copy of virtualized
hardware, with simulated direct access from userspace, and each
process has its own drivers.  My understanding is that the drivers
would usually be implemented as dynamic libraries, so most of the
applications would actually be sharing driver implementations.


-Karl

Re: [Qemu-devel] OT: Running qemu without host os?

[Paul Brook]

> However, your idea isn't that much different from the (fairly new)
> exokernel concept, where each process has its own copy of virtualized
> hardware, with simulated direct access from userspace, and each
> process has its own drivers.  My understanding is that the drivers
> would usually be implemented as dynamic libraries, so most of the
> applications would actually be sharing driver implementations.

Which is pretty much the same as the Hypervisor which has been in use on IBM 
mainframes for ages :-)

Paul

Re: [Qemu-devel] OT: Running qemu without host os?

[Peter Karlsson]

On Sat, 22 Jan 2005, Karl Magdsick wrote:

> Unless all of the guest OSes were modified to be aware that they were
> sharing hardware (or else some really intelligent dynamic patching was
> going on), the OSes would step all over eachother.  For instance, one
> guest OS might put the NIC in promiscuous mode right before another
> guest OS boots and re-initializes the NIC to non-promiscuous mode.  A
> third guest OS might then change the MAC address on the NIC and screw
> up ARP.

Isn't that what xen does? All guest OSes has to be modified to run.

See:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Qemu-devel] OT: Running qemu without host os?

[Jim C. Brown]

On Sat, Jan 22, 2005 at 10:09:04PM +0100, Peter Karlsson wrote:
> Isn't that what xen does? All guest OSes has to be modified to run.
> 

Yes but i thought the idea of qemu is that the guest OS wouldn't need modification
in order to run.

> 
> Best regards
> 
> Peter K
> 
> -- 
> We Can Put an End to Word Attachments:
> http://www.fsf.org/philosophy/no-word-attachments.html
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] OT: Running qemu without host os?

[Peter Karlsson]

On Sat, 22 Jan 2005, Jim C. Brown wrote:

> Yes but i thought the idea of qemu is that the guest OS wouldn't need modification
> in order to run.

Yes, that is the idea, and qemu seems a lot more flexible. But for other
projects it may be a reasonable/desirable goal, linux-clusters for
instance, but it only works on x86 (for now at least).

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Qemu-devel] OT: Running qemu without host os?

[Mark Williamson]

> > Unless all of the guest OSes were modified to be aware that they were
> > sharing hardware (or else some really intelligent dynamic patching was
> > going on), the OSes would step all over eachother.  For instance, one
> > guest OS might put the NIC in promiscuous mode right before another
> > guest OS boots and re-initializes the NIC to non-promiscuous mode.  A
> > third guest OS might then change the MAC address on the NIC and screw
> > up ARP.
>
> Isn't that what xen does? All guest OSes has to be modified to run.

In a situation where you want multiple guests to directly control different 
bits of the hardware, Xen can hide all the "irrelevant" hardware from a guest 
so that it won't tread on other guests' devices.  This technique would be 
applicable to a hypothetical "qemu on bare metal" as well.

Cheers,
Mark

Re: [Qemu-devel] OT: Running qemu without host os?

[Peter Karlsson]

On Fri, 21 Jan 2005, Jim C. Brown wrote:

> That would be interesting. Qemu can't do that yet (it shares hardware via
> the help of the host OS, of course, but not direct access).
>
> If you had qemu running multiple OSes, and all of them could access the same
> hardware "virtually directly", that would be simply amazing. Not quite sure
> how one could go about doing this though..

It would be like "streaming" or "multitasking" the guest OSes, at least
that's what I'm thinking. How one would go about to actually do it without
hardware support is another matter. But would it really be that different
from what qemu are doing now? However, having qemu start first (with the
help from linuxbios) and then launch guest OSes would be a lot easier I
suspect (from a theoretical standpoint), unless the host os is aware of
sharing the resources. And what I originally thought of was having qemu as
a part of the bios, in control of the hardware.

>From what I've been told, qemu is a target in linuxbios V2.

See:
http://www.clustermatic.org/pipermail/linuxbios/2005-January/010680.html
http://www.clustermatic.org/pipermail/linuxbios/2004-June/008423.html

> No, it currently only works with PCI. ISA, AGP, USB, and traditional hardware
> can't be accessed directly yet (tho it is theoreticly possible).

I thought AGP was a PCI bus.

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Qemu-devel] OT: Running qemu without host os?

[venkateshp]

-----------------------------------------------------------------------
International Institute of Information Technology, PUNE, INDIA -411 057


---------- Original Message -----------
From: Peter Karlsson <petekarl@student.chalmers.se>
To: qemu-devel@nongnu.org
Sent: Fri, 21 Jan 2005 17:10:33 +0100 (MET)
Subject: [Qemu-devel] OT: Running qemu without host os?

> Hi!
> 
> I'm toying with the idea of running qemu as a vm from linuxbios and then
> boot another os inside the vm (qemu). Qemu would have to virtualise the
> hardware but still let the virtual os access hardware via normal hardware
> registers, i.e. the os would not know a real computer from a virtualised
> one. Is this theoretically possible, or maybe even practically?
i and my friend are trying to make a tiny (live)distro running only qemu. then
make qemu boot the os on the computer. does that come anywhere near?
> 
> One of the reasons for doing something like this would be to snoop windows
> driver registers for example reverse engineering of graphics 
> hardware and maybe wireless network cards. But I can think of 
> several other useful areas like high-availability, remote management 
> of cluster nodes etc...
we are working towards the cluster part..
> 
> Best regards
> 
> Peter K
> 
> -- 
> We Can Put an End to Word Attachments:
> http://www.fsf.org/philosophy/no-word-attachments.html
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
------- End of Original Message -------

DISCLAIMER: This Mail is from the International Institute of Information Technology ( ISquareIT, PUNE, INDIA-411 057 ) student mail system, The Institute is not responsible for the contents. In case you detect misuse or offensive content report to mailadmin@isquareit.ac.in.

Re: [Qemu-devel] OT: Running qemu without host os?

[Peter Karlsson]

On Sat, 22 Jan 2005, venkateshp wrote:

> i and my friend are trying to make a tiny (live)distro running only qemu. then
> make qemu boot the os on the computer. does that come anywhere near?

Yes, I would think so. I was thinking of replacing the bios with linuxbios
and qemu. It sounds like a common goal. But you should check out
linuxbios, if you haven't already:
http://www.clustermatic.org/
http://www.linuxbios.org/

> we are working towards the cluster part..

Oh, I'm interested in that too. I only wish I could afford a cluster, let
alone one more computer... :-)

But an active bios/vm would be very interesting indeed for a cluster, be
it a load-balancing, HA-cluster or any other kind of cluster.

Best regards

Peter K

-- 
We Can Put an End to Word Attachments:
http://www.fsf.org/philosophy/no-word-attachments.html

[Qemu-devel] anybody working on smp..?

[venkateshp]

hi,
i edited the configure script to print a few lines of #defines for smp.. into
smp.h(or should it be printed into somewhere else?) now when i go to bios..
which would be easier (or better?) to do? take the bochs bios from earliest
version which came with smp, or edit the present bios?
if anybody working on smp, please share your experiences.. i'm seeing smp
support in the todo file under short term: for quite sometime..
thanks
DISCLAIMER: This Mail is from the International Institute of Information Technology ( ISquareIT, PUNE, INDIA-411 057 ) student mail system, The Institute is not responsible for the contents. In case you detect misuse or offensive content report to mailadmin@isquareit.ac.in.

Re: [Qemu-devel] anybody working on smp..?

[Damien "tuX" Thebault]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

venkateshp wrote :
 > hi,
 > i edited the configure script to print a few lines of #defines for
smp.. into
 > smp.h(or should it be printed into somewhere else?) now when i go to
bios..
 > which would be easier (or better?) to do? take the bochs bios from
earliest
 > version which came with smp, or edit the present bios?
 > if anybody working on smp, please share your experiences.. i'm seeing smp
 > support in the todo file under short term: for quite sometime..
 > thanks
 >

I have a dual-cpu computer so I'm interested in smp support too.
But how would it work?

I mean, emulate a smp system on a up one, a un system on a smp one, or
just a smp system on a system with the same number of cpus?
The last should be enough for me but the others are cool too.

On the bochs CVS (I didn't try the archives), ther are some smp bioses :
2,4 and 8 processors support...

I tried this bios with qemu... the bios shows "2 cpus" and the Linux
kernel see that from the bios. But there is a problem juste after the
first cpu detection ("BIOS bug, local APIC #0 not detected!...")

I know that BIOS support is far than enough to enable smp support in
qemu, but it is a good start, isn't it?
(there is also some details here on what need to be done to enable smp :
http://bochs.sourceforge.net/doc/docbook/user/smp.html, maybe it could
help someone...)

I don't know if smp support is important, but it may be nice :)

Damien.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]