Can't you just use kboot?
Use a kernel loader to load the kboot module/initrd, include kboot as our
firmware, then let kboot do the magic to launch the real linux kernel
from disk.
Hm, so we'd have to rely on kexec working properly? I've seen how badly
that turned out on the PS3. I
I think it would be great to maintain compatibility with the binary-only
versions of the vm tools though.
But you're changing the semantics of the x86 instruction set. You
potentially break a real operating system. It also eliminates the
possibility of nesting with something like kqemu
I've been giving some thought to Anthony's idea:
http://kvm.qumranet.com/kvmwiki/Specs/StoringCommandLineInImage
However, maybe I'm just too much on vacations, but I don't seem to
come up with a nice way of doing this. Everything keeps coming back to
creating a new 'container' image format
Clemens Kolbitsch wrote :
I'd like to detect if the client OS crashes... right now, only for
linux, but windows systems will become interesting for me as well in the
future...
Real machines usually have hardware watchdogs for that. I do not know
if qemu has one available for your target
Here is a somewhat revised version of a patch I first made nearly
three years ago. The original thread is
The idea here is quite similar to what the VNC server does now.
If this is desirable for SDL too, then perhaps we should find a way to
fold this into common code?
Although, is
I'm also doubtful how much benefit it gave in practice. I'm sure it would
be good for synthetic CPU benchmarks. However using mmap significantly
increases the overhead of context switches/tlb misses.
To get good overall performance I suspect you're going to need closer
cooperation with the
It's mostly intended to be used for accessing the files inside QEMU
disk images locally, without having to launch a virtual machine and
accessing then from there.
mount -o loop does this.
How is everybody missing the point? :-) mount -o loop doesn't mount
qcow images.
Using
And write access works for me. What's this limitation you speak of?
Mounting a partition being served on the same host as read-write can
cause deadlocks. From nbd-2.9.0 README file:
This text is pretty old. Is this still valid? This would imply that
things like loop can result in
Well, have you donated? :)
Is there a way to donate? Couldn't find anything on the main site.
Personally, I'd be willing to pay Fabrice for the Accelerator if it
were open source. But I don't pay for closed source software unless
it's unavoidable. But each is entitled to make their own
Worse, the guest might decide to swap out a page that's already
swapped in by the host, forcing it to be read in again only to be
immediately written out to disk by the guest :-(
...unless the guest's disk I/O is with simulated DMA or recognisable
block-copy instruction sequences, and
It seems the point of the balloon driver is to avoid forcing the host
to swap. For example, suppose I start a new guest OS. I check the
memory usage on the host and everything looks pretty good, maybe 30MB
used. Then suppose I run a recursive grep command in a Linux source
tree on the
On Sat, 8 Apr 2006, Samuel Hunt wrote:
It occurs to me that this program would make an excellent basis for a VNC
terminal server.
Yeah, something like that has been done already:
http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz
There is a notable update since rfb12 (which is
I'm wondering if it would be possible to modify QEMU such that VMs could
access PCI devices on the host system. And, if it would be possible at
all, how much work this would be.
Sounds doable but would require a fair bit of hacking - I think the idea of
doing this under QEmu came up once
- IRQ sharing. Sharing host IRQs between native and virtualized devices is
hard because the host needs to ack the interrupt in the IRQ handler, but
doesn't really know how to do that until after it's run the guest to see
what that does.
Could maybe have the (inevitable) kernel portion of the
Are there any plans to add to qemu the capability to simulate the
Intel Vanderpool and AMD Pacifica hardware virtualization facilities?
snip
You'd think that people would check the mailing list archives before asking
the same questions that others have asked over and over again.
I don't
Have you seen AMD's SimNow? Not quite what you want, I know, but better than
nothing ;-)
Cheers,
Mark
On Tuesday 22 November 2005 11:35, Dave Feustel wrote:
On Monday 21 November 2005 23:43, Jim C. Brown wrote:
On Mon, Nov 21, 2005 at 08:40:37PM -0500, Dave Feustel wrote:
Are there any
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.
I just commited an initial USB support for QEMU. This USB layer will
ultimately enable QEMU to use some host USB devices and to simulate USB
devices.
Coolness!
- Linux host USB redirector to use the USB 1.1 host devices which are
not requested by the host OS (i.e. no host driver is loaded
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
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
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
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
Hi all,
Is it possible to use -user-net but with a statically configured IP address?
Cheers,
Mark
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Actually that'd be a fairly neat trick... As an alternative, IIRC
there's a user space API for writing USB drivers under Linux - using that
you could
get
access to both local and remote (IP encapsulated) USB devices, albeit not
in a cross-platform (host-wise) way.
That would be
Isn't there a USB patch floating around somewhere (emulates OHCI in the
guest)? Or am I remembering something else?
Cheers,
Mark
On Wednesday 10 August 2005 11:57, Ben Taylor wrote:
Jim C. Brown [EMAIL PROTECTED]
On Tue, Aug 09, 2005 at 10:33:31PM +0200, Michael Hoeller wrote:
Hello,
Isn't there a USB patch floating around somewhere (emulates OHCI in the
guest)?
Yes, but noone's written the code to wire it up to host devices. AFAIK it
currently emulates the host controller and not much else.
Oh, OK that makes sense.
Using the usb-over-ip protocol mentioned above
Mark Williamson wrote:
If only one machine (host or guest) has mounted the device then it should
always be safe to do this. You may get away with read only mounting in
one and writing in the other but it's not a reliable solution. Never
allow more than one writer to the filesystem
can I write a file based file system and read it from the host? I can
guarantee I have stopped writing before I read on the host side. I can
even unmount before reading.
If only one machine (host or guest) has mounted the device then it should
always be safe to do this. You may get away
Linux/Xen.
On the other hand, Mark Williamson, one of the Xen dev pointed on Xen
devel ML on a very interesting document from Microsoft
(http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-08878
2200fe7/TWAR05013_WinHEC05.ppt)
It seems that MS will follow an approach similar
But how often will the virtual CPUs need the same page and is there any
other shared resource other than memory? I don't know how independent
each CPU is. Though in side discussions, everyone agrees with you, I
haven't seen numbers to convince my gut. If page only needs to be
faulted back
31 matches
Mail list logo
