On Saturday 12 December 2009 01:58:02 Dave Airlie wrote:
> So I've been musing on the addition of some sort of 3D passthrough for
> qemu (as I'm sure have lots of ppl)
>
> But I think the goals of such an addition need to be discussed prior
> to anyone writing a line of code.
>
> Current existing
> > 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
> > 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
> 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 f
> 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 you
> > 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?
>
> Althoug
> 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
> >> 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 re
> > > 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 image
> 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,
> 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 (
> What about 64-bit systems that use an IOMMU? Don't they already have a
> 64-bit physical -> 32-bit IO address space mapping? I don't know if this
> mapping is per-bus or system global.
If it's an Intel x86_64 machine (no IOMMU yet), IIRC the 32-bit PCI devices
are capable of DMA-ing into the bo
> > Could maybe have the (inevitable) kernel portion of the code grab the
> > interrupt, and not ack it until userspace does an ioctl on a special file
> > (or something like that?). There are patches floating around for
> > userspace IRQ handling, so I guess that could work.
>
> This still requir
> - 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 t
> 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 be
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
> > Are there any plans to add to qemu the capability to simulate the
> > Intel Vanderpool and AMD Pacifica hardware virtualization facilities?
> 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 re
> 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
> h
> 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 load
> 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 cir
> > 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 bel
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 hard
> >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 possibl
> 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 rea
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.
>
>
> > 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 abo
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:
> > >
> 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
> > a
> 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
ould seem to be the best way to
run Windows under Xen right now. Win4Lin also runs under 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/98f3f
> SDL can also run directly inside a linux framebuffer :)
> Qemu does work already with it. I tried a few months back.
> But mouse and keyboard need tuning.
And (Embedded) QT can also render to the framebuffer I believe. Don't know if
that'll work with QtC, tho...
Cheers,
Mark
> Christian
>
>
> 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 b
> The only solution I can imagine being even vaguely worthwhile is a running
> user-mode qemu on top of a native openmozix system.
Probably if you want to run a distributed SMP-style sytem using QEmu, the most
effective approach is going to be running OpenMosix *in* QEmu, on multiple
hosts.
Sad
> if i want to use qemu to run, os2, beos, windows... under linux, i can't
> use i386-user?
No, you need i386-softmmu to run a whole virtual machine. If you use the CVS
version of QEmu, you can also use the KQemu accelerator module to speed this
up.
If you wanted to (for instance) run i386 bin
37 matches
Mail list logo
