From: Brian Johnson <bjj4@charter.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] Patches from PyQemu project
Date: Tue, 04 Sep 2007 14:57:07 -0500 [thread overview]
Message-ID: <46DDB893.2060403@charter.net> (raw)
In-Reply-To: <1188852253.10151.3.camel@squirrel>
Anthony Liguori wrote:
> On Mon, 2007-09-03 at 18:41 +0300, Blue Swirl wrote:
>> Sorry to ruin your GSoC project, but the plugin system was discussed
>> last year, please see this thread:
>> http://thread.gmane.org/gmane.comp.emulators.qemu/14341/focus=14473
>
> I've always agreed that allowing plugins was not a good idea. However,
> I had a different thought recently.
>
> While I don't think there's much of a reason to allow plugins for QEMU,
> it would be interesting to make some of QEMU's device emulation into
> more a of a library that could be used by other programs.
>
> With things like KVM making it relatively simple to do CPU emulation, if
> QEMU's device emulation was available as a library (even a GPL library),
> it would be pretty easy to do interesting things without forking QEMU
> which is what everyone seems to be doing these days.
Yes -- it would be valuable to have QEMU's devices available as a
separate library(ies), with a simple, well-defined API. Some of us use
other CPU emulators (yes, yes, I know we should emulate all
architectures under qemu, but that's not always easy :) and would love
to use qemu's device emulations.
> My initial thought is to make the libraries at the individual device
> level.
It would be good to have a general mechanism for bus providers,
interrupts, APICs, chipsets, etc. as well, so we could emulate fancier
architectures than a simple PC (or simple Sparc/MIPS/ARM/etc. box.) For
instance, I'd like to emulate multiple PCIe host bridges, each with an
APIC and multiple cards, which might contain PCI-to-PCI bridges. And
I'd like to emulate NUMA systems with many memory controllers and a
complex memory map, with multiple sets of chipset registers. I don't
expect qemu to do this off the shelf, but I'd like to avoid hardcoding
PC assumptions into the device libraries, so I can code the fancy
machines myself and use the I/O as-is.
Any more thoughts on how to structure the libraries?
Brian J. Johnson
next prev parent reply other threads:[~2007-09-04 19:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-02 13:50 [Qemu-devel] [PATCH] Patches from PyQemu project Maria Zabolotnaya
2007-09-03 15:41 ` Blue Swirl
2007-09-03 20:44 ` Anthony Liguori
2007-09-04 19:40 ` [Qemu-devel] Re: qemu device emulation libraries (was [PATCH] Patches from the PyQemu project) Hollis Blanchard
2007-09-04 20:04 ` Paul Brook
[not found] ` <200709042104.59276.paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org>
2007-09-04 20:21 ` Hollis Blanchard
2007-09-04 20:21 ` Hollis Blanchard
2007-09-04 20:38 ` Paul Brook
2007-09-04 20:38 ` Paul Brook
[not found] ` <200709042138.03999.paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org>
2007-09-04 23:38 ` Jimi Xenidis
2007-09-04 23:38 ` [kvm-devel] " Jimi Xenidis
2007-09-04 20:52 ` Anthony Liguori
2007-09-04 19:57 ` Brian Johnson [this message]
2007-09-04 20:56 ` [Qemu-devel] Re: [PATCH] Patches from PyQemu project Anthony Liguori
2007-09-04 22:27 ` Thiemo Seufer
2007-09-04 23:34 ` Anthony Liguori
2007-09-04 23:45 ` Anthony Liguori
2007-09-05 10:08 ` Fabrice Bellard
2007-09-04 22:13 ` [Qemu-devel] " Paul Sokolovsky
2007-09-04 19:40 ` qemu device emulation libraries (was [PATCH] Patches from the Hollis Blanchard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46DDB893.2060403@charter.net \
--to=bjj4@charter.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.