Re: [kvm-devel] [Qemu-devel] Re: qemu device emulation libraries (was [PATCH] Patches from the PyQemu project)
On Sep 4, 2007, at 4:38 PM, Paul Brook wrote: On Tuesday 04 September 2007, Hollis Blanchard wrote: On Tue, 2007-09-04 at 21:04 +0100, Paul Brook wrote: This could be very valuable when thinking about running qemu *on* embedded systems with constrained memory and processing power, which is exactly what the KVM for embedded PowerPC project is considering. In that scenario, being able to strip out all unnecessary functionality (especially including devices known to be irrelevant) becomes very important. If you care about memory overhead the last thing you want is to be loading loads of bitty little shared libraries. You want to build a single binary with just the features you need. Hmm, that's a good point. Is that something you think can reasonably be accomplished with qemu today? It should be fairly easy. Why not both? It could be like the linux kernel, =m means build an SO and =y means link it statically. The key is for it to be modular and configurable. -JX
Re: [Qemu-devel] Re: [PATCH] Patches from PyQemu project
Anthony Liguori wrote: On Tue, 2007-09-04 at 23:27 +0100, Thiemo Seufer wrote: Brian Johnson wrote: [snip] 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, Why not? I would like to see better abstracted and more capable device emulations in Qemu. 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. Then, what does a librar-ized Qemu device with its hardcoded PC assumptions help you? Let me give a very pragmatic answer. Right now, KVM has it's own main loop which uses a thread per-vcpu. Device IO is handled in the context of the VCPU that originated the IO. I think there's some desire to move to an N+1 threading model where the extra thread does things like VGA scanning, VNC, etc. Xen, on the other hand, uses a single thread for everything and doesn't attempt to model multiple VCPUs within the QEMU process. All IO is delivered via the same channel. QEMU is strictly used for devices. Merging either of these with QEMU's current model would be challenging, merging both would be extremely challenging b/c the two main loop models are mutually exclusive. However, there's no real trouble merging any of the device emulation back. KVM doesn't maintain any changes to things like device emulation (other than some KVM-specific APIC stuff). Xen, on the other hand, mostly has fixes for some of the devices that haven't been submitted back to QEMU. Other devices are completely unmodified but are severely lagging behind the QEMU versions. VirtualBox is way different than QEMU of course. A bunch of their device emulation is pretty close to QEMU though. I think device emulation is an independent enough problem that there's a good chance everyone can agree on a single implementation. While it's a little more work in QEMU to keep these things as libraries and maintain an interface, I suspect the benefits outweigh the extra cost in that it's much more likely we'll see more patches. There are useful bits of QEMU that could be widely consumed. Their nature is such that their interfaces are unlikely to change dramatically in the future. To me, this just screams "library" :-) I agree with the point that QEMU should be improved so that it is easier to reuse the device model. But I consider that the priority is not to export a library but to improve the existing QEMU C APIs. The goal should be that it is possible to emulate several different CPUs at once with several unrelated buses. Moreover the model should support deterministic simulation. Currently the PCI bus is the closest to what is needed, but even in it there are still some conceptual problems (see the DMA problems which were discussed before). Regarding the other projects, I see no technical reason why the KVM code cannot be merged. QEMU already contains the necessary support code for KQEMU and I see no conceptual difference with KVM. Adding a new main loop for KVM or a new KVM specific CPU is not something I am against. Regards, Fabrice.
[Qemu-devel] When next release of Qemu ?
hi all ! I know that there is a lot of interesting work going around... so I would like to ask: When next release of Qemu ? (0.91?) -- -Alexey Eremenko "Technologov"
[Qemu-devel] expose host CPU features to guests
Hi,
It's a pity not to use a host CPU feature if it is available. This patch
exposes host CPU features to guests. It allows fine-tuning the presented
features from the command-line.
The code could use some serious clean ups, but I think it is interesting
enough right now. I'd be happy to hear your opinion and suggestions.
The diff are done against qemu cvs. I tried it with kvm, but I thinkg it
should be useful also for kqemu.
Regards,
Dan.
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.336
diff -u -p -r1.336 vl.c
--- vl.c28 Aug 2007 22:21:40 - 1.336
+++ vl.c5 Sep 2007 15:48:10 -
@@ -6575,12 +6575,24 @@ int qemu_register_machine(QEMUMachine *m
return 0;
}
+const char *machine_flavor = 0;
+
QEMUMachine *find_machine(const char *name)
{
QEMUMachine *m;
+int n;
+machine_flavor = strchr(name, ',');
+if (machine_flavor) {
+ n = machine_flavor - name;
+ machine_flavor++;
+} else {
+n = strlen(name);
+machine_flavor = "";
+}
+
for(m = first_machine; m != NULL; m = m->next) {
-if (!strcmp(m->name, name))
+if (!strncmp(m->name, name, n))
return m;
}
return NULL;
@@ -7343,6 +7355,7 @@ static void read_passwords(void)
void register_machines(void)
{
#if defined(TARGET_I386)
+qemu_register_machine(&host_pc_machine);
qemu_register_machine(&pc_machine);
qemu_register_machine(&isapc_machine);
#elif defined(TARGET_PPC)
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.264
diff -u -p -r1.264 vl.h
--- vl.h26 Aug 2007 17:46:00 - 1.264
+++ vl.h5 Sep 2007 15:48:10 -
@@ -1156,6 +1156,7 @@ void piix4_smbus_register_device(SMBusDe
void acpi_bios_init(void);
/* pc.c */
+extern QEMUMachine host_pc_machine;
extern QEMUMachine pc_machine;
extern QEMUMachine isapc_machine;
extern int fd_bootchk;
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.83
diff -u -p -r1.83 pc.c
--- hw/pc.c 26 Aug 2007 17:51:39 - 1.83
+++ hw/pc.c 5 Sep 2007 15:48:10 -
@@ -965,6 +965,28 @@ static void pc_init_isa(int ram_size, in
initrd_filename, 0);
}
+int use_hostlike_cpu = 0;
+
+static void pc_init_hostlike(ram_addr_t ram_size, int vga_ram_size, int
boot_device,
+DisplayState *ds, const char **fd_filename,
+int snapshot,
+const char *kernel_filename,
+const char *kernel_cmdline,
+const char *initrd_filename)
+{
+use_hostlike_cpu = 1;
+pc_init1(ram_size, vga_ram_size, boot_device,
+ ds, fd_filename, snapshot,
+ kernel_filename, kernel_cmdline,
+ initrd_filename, 1);
+}
+
+QEMUMachine host_pc_machine = {
+"host",
+"Standard PC with host-like CPU",
+pc_init_hostlike,
+};
+
QEMUMachine pc_machine = {
"pc",
"Standard PC",
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.45
diff -u -p -r1.45 cpu.h
--- target-i386/cpu.h 11 Jul 2007 22:48:58 - 1.45
+++ target-i386/cpu.h 5 Sep 2007 15:48:10 -
@@ -267,21 +267,44 @@
#define CPUID_CMOV (1 << 15)
#define CPUID_PAT (1 << 16)
#define CPUID_PSE36 (1 << 17)
+#define CPUID_PN (1 << 18)
#define CPUID_CLFLUSH (1 << 19)
-/* ... */
+#define CPUID_DTS (1 << 21)
+#define CPUID_ACPI (1 << 22)
#define CPUID_MMX (1 << 23)
#define CPUID_FXSR (1 << 24)
#define CPUID_SSE (1 << 25)
#define CPUID_SSE2 (1 << 26)
+#define CPUID_SS (1 << 27)
+#define CPUID_HT (1 << 28)
+#define CPUID_TM (1 << 29)
+#define CPUID_IA64 (1 << 30)
+#define CPUID_PBE (1 << 31)
#define CPUID_EXT_SSE3 (1 << 0)
#define CPUID_EXT_MONITOR (1 << 3)
+#define CPUID_EXT_DSCPL(1 << 4)
+#define CPUID_EXT_VMX (1 << 5)
+#define CPUID_EXT_SMX (1 << 6)
+#define CPUID_EXT_EST (1 << 7)
+#define CPUID_EXT_TM2 (1 << 8)
+#define CPUID_EXT_SSSE3(1 << 9)
+#define CPUID_EXT_CID (1 << 10)
#define CPUID_EXT_CX16 (1 << 13)
+#define CPUID_EXT_XTPR (1 << 14)
+#define CPUID_EXT_DCA (1 << 17)
+#define CPUID_EXT_POPCNT (1 << 22)
#define CPUID_EXT2_SYSCALL (1 << 11)
+#define CPUID_EXT2_MP (1 << 19)
#define CPUID_EXT2_NX (1 << 20)
+#define CPUID_EXT2_MMXEXT (1 << 22)
#define CPUID_EXT2_FFXSR (1 << 25)
+#define CPUID_EXT2_PDPE1GB (1 << 26)
+#define CPUID_EXT2_RDTSCP (1 << 27)
#define CPUID_EXT2_LM (1 << 29)
+#define CPUID_EXT2_3DNOWEXT (1 << 30)
+#define CPUID_EXT2_3DNOW (1 << 31)
#define EXCP00_DIVZ0
#define EXCP01_SSTP1
Index: target-i386/helper2.c
[Qemu-devel] Re: [kvm-devel] expose host CPU features to guests
On Wed, 2007-09-05 at 20:45 +0300, [EMAIL PROTECTED] wrote:
> Hi,
>
> It's a pity not to use a host CPU feature if it is available. This patch
> exposes host CPU features to guests. It allows fine-tuning the presented
> features from the command-line.
>
> The code could use some serious clean ups, but I think it is interesting
> enough right now. I'd be happy to hear your opinion and suggestions.
> The diff are done against qemu cvs. I tried it with kvm, but I thinkg it
> should be useful also for kqemu.
I like this idea but I have some suggestions about the general approach.
I think instead of defining another machine type, it would be better to
just have a command line option like -cpuid that took a comma separate
string of features with "all" meaning all features that the host has.
I also think it would be nicer to use cpuid() directly instead of
attempting to parse /proc/cpuinfo.
Regards,
Anthony Liguori
> Regards,
>
> Dan.
>
> Index: vl.c
> ===
> RCS file: /sources/qemu/qemu/vl.c,v
> retrieving revision 1.336
> diff -u -p -r1.336 vl.c
> --- vl.c 28 Aug 2007 22:21:40 - 1.336
> +++ vl.c 5 Sep 2007 15:48:10 -
> @@ -6575,12 +6575,24 @@ int qemu_register_machine(QEMUMachine *m
> return 0;
> }
>
> +const char *machine_flavor = 0;
> +
> QEMUMachine *find_machine(const char *name)
> {
> QEMUMachine *m;
>
> +int n;
> +machine_flavor = strchr(name, ',');
> +if (machine_flavor) {
> + n = machine_flavor - name;
> + machine_flavor++;
> +} else {
> +n = strlen(name);
> +machine_flavor = "";
> +}
> +
> for(m = first_machine; m != NULL; m = m->next) {
> -if (!strcmp(m->name, name))
> +if (!strncmp(m->name, name, n))
> return m;
> }
> return NULL;
> @@ -7343,6 +7355,7 @@ static void read_passwords(void)
> void register_machines(void)
> {
> #if defined(TARGET_I386)
> +qemu_register_machine(&host_pc_machine);
> qemu_register_machine(&pc_machine);
> qemu_register_machine(&isapc_machine);
> #elif defined(TARGET_PPC)
> Index: vl.h
> ===
> RCS file: /sources/qemu/qemu/vl.h,v
> retrieving revision 1.264
> diff -u -p -r1.264 vl.h
> --- vl.h 26 Aug 2007 17:46:00 - 1.264
> +++ vl.h 5 Sep 2007 15:48:10 -
> @@ -1156,6 +1156,7 @@ void piix4_smbus_register_device(SMBusDe
> void acpi_bios_init(void);
>
> /* pc.c */
> +extern QEMUMachine host_pc_machine;
> extern QEMUMachine pc_machine;
> extern QEMUMachine isapc_machine;
> extern int fd_bootchk;
> Index: hw/pc.c
> ===
> RCS file: /sources/qemu/qemu/hw/pc.c,v
> retrieving revision 1.83
> diff -u -p -r1.83 pc.c
> --- hw/pc.c 26 Aug 2007 17:51:39 - 1.83
> +++ hw/pc.c 5 Sep 2007 15:48:10 -
> @@ -965,6 +965,28 @@ static void pc_init_isa(int ram_size, in
> initrd_filename, 0);
> }
>
> +int use_hostlike_cpu = 0;
> +
> +static void pc_init_hostlike(ram_addr_t ram_size, int vga_ram_size, int
> boot_device,
> +DisplayState *ds, const char **fd_filename,
> +int snapshot,
> +const char *kernel_filename,
> +const char *kernel_cmdline,
> +const char *initrd_filename)
> +{
> +use_hostlike_cpu = 1;
> +pc_init1(ram_size, vga_ram_size, boot_device,
> + ds, fd_filename, snapshot,
> + kernel_filename, kernel_cmdline,
> + initrd_filename, 1);
> +}
> +
> +QEMUMachine host_pc_machine = {
> +"host",
> +"Standard PC with host-like CPU",
> +pc_init_hostlike,
> +};
> +
> QEMUMachine pc_machine = {
> "pc",
> "Standard PC",
> Index: target-i386/cpu.h
> ===
> RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
> retrieving revision 1.45
> diff -u -p -r1.45 cpu.h
> --- target-i386/cpu.h 11 Jul 2007 22:48:58 - 1.45
> +++ target-i386/cpu.h 5 Sep 2007 15:48:10 -
> @@ -267,21 +267,44 @@
> #define CPUID_CMOV (1 << 15)
> #define CPUID_PAT (1 << 16)
> #define CPUID_PSE36 (1 << 17)
> +#define CPUID_PN (1 << 18)
> #define CPUID_CLFLUSH (1 << 19)
> -/* ... */
> +#define CPUID_DTS (1 << 21)
> +#define CPUID_ACPI (1 << 22)
> #define CPUID_MMX (1 << 23)
> #define CPUID_FXSR (1 << 24)
> #define CPUID_SSE (1 << 25)
> #define CPUID_SSE2 (1 << 26)
> +#define CPUID_SS (1 << 27)
> +#define CPUID_HT (1 << 28)
> +#define CPUID_TM (1 << 29)
> +#define CPUID_IA64 (1 << 30)
> +#define CPUID_PBE (1 << 31)
>
> #define CPUID_EXT_SSE3 (1 << 0)
> #define CPUID_EXT_MONITOR (1 << 3)
> +#define CPUID_EXT_DSCPL(1 << 4)
> +#define CPUID_EXT_VMX (1 << 5)
> +#define CPUID_EXT_SMX (1 << 6)
> +#define CPUID_EXT_EST (1 << 7)
> +#define CPUID_EXT
[Qemu-devel] Re: [kvm-devel] expose host CPU features to guests
Anthony Liguori wrote: On Wed, 2007-09-05 at 20:45 +0300, [EMAIL PROTECTED] wrote: Hi, It's a pity not to use a host CPU feature if it is available. This patch exposes host CPU features to guests. It allows fine-tuning the presented features from the command-line. The code could use some serious clean ups, but I think it is interesting enough right now. I'd be happy to hear your opinion and suggestions. The diff are done against qemu cvs. I tried it with kvm, but I thinkg it should be useful also for kqemu. I like this idea but I have some suggestions about the general approach. I think instead of defining another machine type, it would be better to just have a command line option like -cpuid that took a comma separate string of features with "all" meaning all features that the host has. I think qemu-cvs has a -cpu option for non-x86 which could be used for this. Agree machine types are the wrong approach. I also think it would be nicer to use cpuid() directly instead of attempting to parse /proc/cpuinfo. Yes. -- Any sufficiently difficult bug is indistinguishable from a feature.
[Qemu-devel] Re: [kvm-devel] expose host CPU features to guests
On Wed, Sep 05, 2007 at 10:34:45PM +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > On Wed, 2007-09-05 at 20:45 +0300, [EMAIL PROTECTED] wrote: > > > >> Hi, > >> > >> It's a pity not to use a host CPU feature if it is available. This patch > >> exposes host CPU features to guests. It allows fine-tuning the presented > >> features from the command-line. > >> > >> The code could use some serious clean ups, but I think it is interesting > >> enough right now. I'd be happy to hear your opinion and suggestions. > >> The diff are done against qemu cvs. I tried it with kvm, but I thinkg it > >> should be useful also for kqemu. > >> > > > > I like this idea but I have some suggestions about the general approach. > > I think instead of defining another machine type, it would be better to > > just have a command line option like -cpuid that took a comma separate > > string of features with "all" meaning all features that the host has. > > > > > > I think qemu-cvs has a -cpu option for non-x86 which could be used for > this. Agree machine types are the wrong approach. Yep, machine types are already used to switch between a different concept so using the new -cpu option would make sense. Could perhaps extend the syntax so that instead of '-cpu TYPE' it used '-cpu TYPE,FEATURES' where FEATURES was an optional list of CPU features to allow - though perhaps with some shortcut for specifying 'match the host cpu type & features'. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
[Qemu-devel] qemu cpu-exec.c gdbstub.c monitor.c translate-a...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/09/06 00:18:15 Modified files: . : cpu-exec.c gdbstub.c monitor.c translate-all.c hw : mips_r4k.c mips_timer.c linux-user : main.c signal.c syscall.c target-mips: cpu.h exec.h fop_template.c helper.c op.c op_helper.c op_template.c translate.c translate_init.c Log message: Partial support for 34K multithreading, not functional yet. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.110&r2=1.111 http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemu&r1=1.62&r2=1.63 http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemu&r1=1.77&r2=1.78 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.45&r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_timer.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.118&r2=1.119 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemu&r1=1.39&r2=1.40 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.117&r2=1.118 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.42&r2=1.43 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.30&r2=1.31 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/fop_template.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.45&r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.69&r2=1.70 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.56&r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_template.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.95&r2=1.96 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemu&r1=1.19&r2=1.20
Re: [Qemu-devel] Re: [kvm-devel] expose host CPU features to guests
> > I think qemu-cvs has a -cpu option for non-x86 which could be used for > > this. Agree machine types are the wrong approach. > > Yep, machine types are already used to switch between a different concept > so using the new -cpu option would make sense. Could perhaps extend the > syntax so that instead of '-cpu TYPE' it used '-cpu TYPE,FEATURES' where > FEATURES was an optional list of CPU features to allow I tried this for ARM, and having separate type+features isn't worth the effort. The internal implementation is feature based, but IMHO there's little benefit exposing that to the user. Just define appropriate CPUs for the interesting feature combinations. Of course the x86 emulation doesn't currently support restricting the architecture features available. To make the --cpu option useful you need to implement that first. Paul
[Qemu-devel] qemu api library?
Hi Folks, I originally posted this question to the kvm developer list. I've looked at the code a bit more and it seems like this may be the more appropriate place. I am interested in creating an API library interface to qemu. This interface would allow an application program to access qemu and it's image functions programmatically. Is there any interest in such a thing? Thanks, -G
