[Qemu-devel] (resend) Allow setting the vendor and model_id strings with x86's -cpu option
Would you consider the following patch, that allows users to set two
important x86 cpu options from the command line? (the vendor and
model_id strings)
Every once in a while I am resending this little patch. It had generated
a lot of interest when it included silly bugs, but now it seems to be
largely ignored. However, it is important if one would like qemu to
impersonate a cpu closely as possible.
Regards,
Dan.
commit 04433bad959a7a4c1b8a0c22bd50eab9bf181b32
Author: Dan Kenigsberg <[EMAIL PROTECTED]>
Date: Thu Dec 20 15:43:15 2007 +0200
Change vendor string and model id from the -cpu command line option
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 551a0d8..b59bf92 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -121,6 +121,7 @@ typedef struct x86_def_t {
const char *name;
uint32_t level;
uint32_t vendor1, vendor2, vendor3;
+char model_id[48];
int family;
int model;
int stepping;
@@ -262,7 +263,21 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
-} else {
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = x86_cpu_def->vendor2 =
x86_cpu_def->vendor3 = 0;
+for(i = 0; i < 4; i++) {
+x86_cpu_def->vendor1 |= ((unsigned char)val[i]) << (8
* i);
+x86_cpu_def->vendor2 |= ((unsigned char)val[i + 4]) << (8
* i);
+x86_cpu_def->vendor3 |= ((unsigned char)val[i + 8]) << (8
* i);
+}
+} else if (!strcmp(featurestr, "model_id"))
+strncpy(x86_cpu_def->model_id, val, 48);
+else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
goto error;
@@ -323,13 +338,14 @@ static int cpu_x86_register (CPUX86State *env, const char
*cpu_model)
env->cpuid_ext3_features = def->ext3_features;
{
const char *model_id = "QEMU Virtual CPU version " QEMU_VERSION;
-int c, len, i;
-len = strlen(model_id);
+int c = -1, i;
+
+if (def->model_id[0] != '\0')
+model_id = def->model_id;
+
for(i = 0; i < 48; i++) {
-if (i >= len)
-c = '\0';
-else
-c = model_id[i];
+if (c != '\0')
+c = (unsigned char)model_id[i];
env->cpuid_model[i >> 2] |= c << (8 * (i & 3));
}
}
Re: [Qemu-devel] [PATCH 5/9] CoreDUO CPU
On Tue, Jan 08, 2008 at 04:22:52PM +0100, Alexander Graf wrote:
> Mac OS X as is has a condition to only run on family 13 Intel CPUs, so
> this adds a definition for a CoreDuo CPU.
> Furthermore it adds the MSR Mac OS X uses to read the CPU multiplier and
> the CPUID used to read the cache information.
> Index: qemu-snapshot-2008-01-08_05/target-i386/cpu.h
> ===
> --- qemu-snapshot-2008-01-08_05.orig/target-i386/cpu.h
> +++ qemu-snapshot-2008-01-08_05/target-i386/cpu.h
> @@ -232,6 +232,8 @@
> #define MSR_MCG_STATUS 0x17a
> #define MSR_MCG_CTL 0x17b
>
> +#define MSR_IA32_PERF_STS 0x198
> +
> #define MSR_PAT 0x277
>
> #define MSR_EFER0xc080
> Index: qemu-snapshot-2008-01-08_05/target-i386/helper.c
> ===
> --- qemu-snapshot-2008-01-08_05.orig/target-i386/helper.c
> +++ qemu-snapshot-2008-01-08_05/target-i386/helper.c
> @@ -1710,6 +1710,79 @@ void helper_cpuid(void)
> ECX = 0;
> EDX = 0x2c307d;
> break;
> +case 4:
> +/* cache info: needed for Core Duo compatibility */
> +/* From the Intel documentation:
> +EAX:
> + Bits 4-0: Cache Type**
> + Bits 7-5: Cache Level (starts at 1)
> + Bits 8: Self Initializing cache level (does not need SW initialization)
> + Bits 9: Fully Associative cache Bits
> + 13-10: Reserved Bits
> + 25-14: Number of threads sharing this cache* Bits
> + 31-26: Number of processor cores on this die (Multicore)*
> +EBX:
> + Bits 11-0: L = System Coherency Line Size*
> + Bits 21-12: P = Physical Line partitions*
> + Bits 31-22: W = Ways of associativity*
> +ECX:
> + Bits 31-0: S = Number of Sets*
> +EDX: Reserved
> + * Add one to the value in the register file to get the number. For example,
> the number
> + of processor cores is EAX[31:26]+1.
> +** Cache Types fields
> + 0 = Null - No more caches
> + 1 = Data Cache
> + 2 = Instruction Cache
> + 3 = Unified Cache
> + 31-4 = Reserved
> +*/
> +
> +switch (ECX) {
> +case 0: // L1 cache info
> +/*EAX = 3// Unified Cache
> +| (1 << 5) // L1 Cache
> +| (1 << 8);// Self Initializing
> +EBX = 63 // Line size = 64 bytes
> +| (1022 << 12) // Partitions = 1024 bytes
> +| (0 << 22); // Ways = 2
> +ECX = 0x3f; // One L1 Cache
> +EDX = 0;*/
> +EAX = 0x123;
> +EBX = 0x1c0003f;
> +ECX = 0x03f;
> +EDX = 0x001;
> +break;
> +case 1: // L2 cache info
> +/*EAX = 3// Unified Cache
> +| (2 << 5) // L2 Cache
> +| (1 << 8);// Self Initializing
> +EBX = 63 // Line size = 64 bytes
> +| (1023 << 12) // Partitions = 1024 bytes
> +| (0 << 22); // Ways = 512
> +ECX = 0; // One L2 Cache
> +EDX = 0;
> +*/
> +EAX = 0x122;
> +EBX = 0x1c0003f;
> +ECX = 0x03f;
> +EDX = 0x001;
> +break;
Why do you explain one set of values, and actually use something
different? It confuses the untrained reader (me).
Dan.
[Qemu-devel] [PATCH] (resend) Allow setting the vendor and model_id strings with x86's -cpu option
Would you consider the following patch, that allows users to set two
important x86 cpu options from the command line? (the vendor and
model_id strings)
Regards,
Dan.
commit 04433bad959a7a4c1b8a0c22bd50eab9bf181b32
Author: Dan Kenigsberg <[EMAIL PROTECTED]>
Date: Thu Dec 20 15:43:15 2007 +0200
Change vendor string and model id from the -cpu command line option
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 551a0d8..b59bf92 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -121,6 +121,7 @@ typedef struct x86_def_t {
const char *name;
uint32_t level;
uint32_t vendor1, vendor2, vendor3;
+char model_id[48];
int family;
int model;
int stepping;
@@ -262,7 +263,21 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
-} else {
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = x86_cpu_def->vendor2 =
x86_cpu_def->vendor3 = 0;
+for(i = 0; i < 4; i++) {
+x86_cpu_def->vendor1 |= ((unsigned char)val[i]) << (8
* i);
+x86_cpu_def->vendor2 |= ((unsigned char)val[i + 4]) << (8
* i);
+x86_cpu_def->vendor3 |= ((unsigned char)val[i + 8]) << (8
* i);
+}
+} else if (!strcmp(featurestr, "model_id"))
+strncpy(x86_cpu_def->model_id, val, 48);
+else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
goto error;
@@ -323,13 +338,14 @@ static int cpu_x86_register (CPUX86State *env, const char
*cpu_model)
env->cpuid_ext3_features = def->ext3_features;
{
const char *model_id = "QEMU Virtual CPU version " QEMU_VERSION;
-int c, len, i;
-len = strlen(model_id);
+int c = -1, i;
+
+if (def->model_id[0] != '\0')
+model_id = def->model_id;
+
for(i = 0; i < 48; i++) {
-if (i >= len)
-c = '\0';
-else
-c = model_id[i];
+if (c != '\0')
+c = (unsigned char)model_id[i];
env->cpuid_model[i >> 2] |= c << (8 * (i & 3));
}
}
[Qemu-devel] [PATCH] Correct the max cpuid level for each x86 cpu model
Hi,
This little patch corrects the max cpuid level that is exposed to the
guest for each of the x86 cpu models. It allows cpuid levels other than 2.
Dan.
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index b9b3093..dee53d6 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -119,6 +119,7 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
typedef struct x86_def_t {
const char *name;
+uint32_t level;
uint32_t vendor1, vendor2, vendor3;
char model_id[48];
int family;
@@ -136,6 +137,7 @@ static x86_def_t x86_defs[] = {
#ifdef TARGET_X86_64
{
.name = "qemu64",
+.level = 2,
.vendor1 = 0x68747541, /* "Auth" */
.vendor2 = 0x69746e65, /* "enti" */
.vendor3 = 0x444d4163, /* "cAMD" */
@@ -156,6 +158,7 @@ static x86_def_t x86_defs[] = {
#endif
{
.name = "qemu32",
+.level = 2,
.family = 6,
.model = 3,
.stepping = 3,
@@ -165,6 +168,7 @@ static x86_def_t x86_defs[] = {
},
{
.name = "486",
+.level = 0,
.family = 4,
.model = 0,
.stepping = 0,
@@ -173,6 +177,7 @@ static x86_def_t x86_defs[] = {
},
{
.name = "pentium",
+.level = 1,
.family = 5,
.model = 4,
.stepping = 3,
@@ -181,6 +186,7 @@ static x86_def_t x86_defs[] = {
},
{
.name = "pentium2",
+.level = 2,
.family = 6,
.model = 5,
.stepping = 2,
@@ -189,6 +195,7 @@ static x86_def_t x86_defs[] = {
},
{
.name = "pentium3",
+.level = 2,
.family = 6,
.model = 7,
.stepping = 3,
@@ -321,7 +328,7 @@ static int cpu_x86_register (CPUX86State *env, const char
*cpu_model)
env->cpuid_vendor2 = 0x49656e69; /* "ineI" */
env->cpuid_vendor3 = 0x6c65746e; /* "ntel" */
}
-env->cpuid_level = 2;
+env->cpuid_level = def->level;
env->cpuid_version = (def->family << 8) | (def->model << 4) |
def->stepping;
env->cpuid_features = def->features;
env->pat = 0x0007040600070406ULL;
[Qemu-devel] [PATCH] Allow setting the vendor and model_id strings with x86's -cpu option
Having AuthenticAMD hard-coded is nice, but allowing the user to impersonate
whatever CPU she wants is even nicer.
Hopefully it would now work on big endian host and with non-ASCII
characters.
Dan.
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 6d40c64..b9b3093 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -120,6 +120,7 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
typedef struct x86_def_t {
const char *name;
uint32_t vendor1, vendor2, vendor3;
+char model_id[48];
int family;
int model;
int stepping;
@@ -255,7 +256,21 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
-} else {
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = x86_cpu_def->vendor2 =
x86_cpu_def->vendor3 = 0;
+for(i = 0; i < 4; i++) {
+x86_cpu_def->vendor1 |= ((unsigned char)val[i]) << (8
* i);
+x86_cpu_def->vendor2 |= ((unsigned char)val[i + 4]) << (8
* i);
+x86_cpu_def->vendor3 |= ((unsigned char)val[i + 8]) << (8
* i);
+}
+} else if (!strcmp(featurestr, "model_id"))
+strncpy(x86_cpu_def->model_id, val, 48);
+else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
goto error;
@@ -316,13 +331,14 @@ static int cpu_x86_register (CPUX86State *env, const char
*cpu_model)
env->cpuid_ext3_features = def->ext3_features;
{
const char *model_id = "QEMU Virtual CPU version " QEMU_VERSION;
-int c, len, i;
-len = strlen(model_id);
+int c = -1, i;
+
+if (def->model_id[0] != '\0')
+model_id = def->model_id;
+
for(i = 0; i < 48; i++) {
-if (i >= len)
-c = '\0';
-else
-c = model_id[i];
+if (c != '\0')
+c = (unsigned char)model_id[i];
env->cpuid_model[i >> 2] |= c << (8 * (i & 3));
}
}
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 08:58:34PM +0200, Dan Kenigsberg wrote: > On Sun, Dec 09, 2007 at 07:29:49PM +0100, Andreas Schwab wrote: > > Dan Kenigsberg <[EMAIL PROTECTED]> writes: > > > > > +x86_cpu_def->vendor1 = val[0] + (val[1] << 8) > > > + + (val[2] << 16) + (val[3] << 24); > > > +x86_cpu_def->vendor2 = val[4] + (val[5] << 8) > > > + + (val[6] << 16) + (val[7] << 24); > > > +x86_cpu_def->vendor3 = val[8] + (val[9] << 8) > > > + + (val[10] << 16) + (val[11] << 24); > > > > That will do the wrong thing with the sign bit. > > > > Please tell me when I'm done making a fool of myself. > Apparently, I was not done. So I'll just shut up now. Sorry for the noise. Dan.
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 07:29:49PM +0100, Andreas Schwab wrote:
> Dan Kenigsberg <[EMAIL PROTECTED]> writes:
>
> > +x86_cpu_def->vendor1 = val[0] + (val[1] << 8)
> > + + (val[2] << 16) + (val[3] << 24);
> > +x86_cpu_def->vendor2 = val[4] + (val[5] << 8)
> > + + (val[6] << 16) + (val[7] << 24);
> > +x86_cpu_def->vendor3 = val[8] + (val[9] << 8)
> > + + (val[10] << 16) + (val[11] << 24);
>
> That will do the wrong thing with the sign bit.
>
Please tell me when I'm done making a fool of myself.
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 67658e2..98c03cc 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,6 +254,18 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = val[0] ^ (val[1] << 8)
+ ^ (val[2] << 16) ^ (val[3] << 24);
+x86_cpu_def->vendor2 = val[4] ^ (val[5] << 8)
+ ^ (val[6] << 16) ^ (val[7] << 24);
+x86_cpu_def->vendor3 = val[8] ^ (val[9] << 8)
+ ^ (val[10] << 16) ^ (val[11] << 24);
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 11:36:34AM +, Paul Brook wrote:
> > +x86_cpu_def->vendor1 = cpu_to_le32(*(uint32_t *)val);
> > +x86_cpu_def->vendor2 = cpu_to_le32(*(uint32_t *)(val +
> > 4)); +x86_cpu_def->vendor3 = cpu_to_le32(*(uint32_t *)(val
>
> Still not good enough. val might not be aligned.
>
So, is it that my only hope is going back to basics?
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 67658e2..2ef4be3 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,6 +254,18 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = val[0] + (val[1] << 8)
+ + (val[2] << 16) + (val[3] << 24);
+x86_cpu_def->vendor2 = val[4] + (val[5] << 8)
+ + (val[6] << 16) + (val[7] << 24);
+x86_cpu_def->vendor3 = val[8] + (val[9] << 8)
+ + (val[10] << 16) + (val[11] << 24);
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 03:02:44AM +, Thiemo Seufer wrote:
> Dan Kenigsberg wrote:
> > Having AuthenticAMD hard-coded is nice, but allowing the user to impersonate
> > whatever CPU she wants is even nicer.
> >
> > Also, an English typo (due to me) is corrected.
> >
> > Dan.
> >
> > --- a/target-i386/helper2.c
> > +++ b/target-i386/helper2.c
> > @@ -254,8 +254,17 @@ static int cpu_x86_find_by_name(x86_def_t
> > *x86_cpu_def, const char *cpu_model)
> > goto error;
> > }
> > x86_cpu_def->stepping = stepping;
> > +} else if (!strcmp(featurestr, "vendor")) {
> > +if (strlen(val) != 12) {
> > +fprintf(stderr, "vendor string must be 12 chars
> > long\n");
> > +x86_cpu_def = 0;
> > +goto error;
> > +}
> > +x86_cpu_def->vendor1 = *(uint32_t *)val;
> > +x86_cpu_def->vendor2 = *(uint32_t *)(val + 4);
> > +x86_cpu_def->vendor3 = *(uint32_t *)(val + 8);
>
> Endianness bug.
>
Indeed. Please consider the following:
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 67658e2..6109283 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,6 +254,15 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = cpu_to_le32(*(uint32_t *)val);
+x86_cpu_def->vendor2 = cpu_to_le32(*(uint32_t *)(val + 4));
+x86_cpu_def->vendor3 = cpu_to_le32(*(uint32_t *)(val + 8));
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
Re: [Qemu-devel] feature request: changing boot device in the monitor
On Mon, Dec 03, 2007 at 01:34:16PM +, Gildas wrote: > Hi, > > I don't know whether this is an easy one or not and if it will apply > to all archs, but I'd like to see an option in the monitor to > change/override the value given for -boot. > > This way, for instance if you install a VM from a CDROM using "-boot > d", you would be able to restart it on the hard-drive from the monitor > with something like "boot c" followed by "system_reset". > > I know there is still the workaround of stopping the emulation and > restarting it with a different set of commands, but when remotely > accessing a VM with a lots of redirection/connection, it's not very > handy. And there's another workaround: you can now start qemu with -boot dc , do your thing with the cd image, go to monitor, eject the cd, and system_reset. This time, since there's no cd, the bios will boot from the hard drive. Just as it happens in OS installation on real hardware. Dan.
[Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
Having AuthenticAMD hard-coded is nice, but allowing the user to impersonate
whatever CPU she wants is even nicer.
Also, an English typo (due to me) is corrected.
Dan.
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,8 +254,17 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = *(uint32_t *)val;
+x86_cpu_def->vendor2 = *(uint32_t *)(val + 4);
+x86_cpu_def->vendor3 = *(uint32_t *)(val + 8);
} else {
-fprintf(stderr, "unregnized feature %s\n", featurestr);
+fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
goto error;
}
Re: [Qemu-devel] [PATCH] Handle cpu_model in copy_cpu()
On Sat, Nov 24, 2007 at 11:30:28PM +0200, Kirill A. Shutemov wrote: > copy_cpu() has been broken since cpu_model added to parameters list of > cpu_init(). This patch fix copy_cpu() by storing cpu_model string in > CPUState structure on cpu_init and use this string in copy_cpu(). Please excuse my layman's question: why does each cpu need its own copy of the string, and not just point to the same const char *cpu_model? The reason I'm asking is that > +char cpu_model_str[32]; might be too short for the feature-reach i386 cpu model string, and that > +strcpy(env->cpu_model_str, cpu_model); is not safe when this is mind. Regards, Dan.
[Qemu-devel] [RFC] persistent real-time-clock
Real PC lets its user set the real-time-clock and store it on CMOS,
which advances the clock even when the PC is offline.
This patch will allow doing the same with VM:
- Before shutting a VM down, use the monitor's info timeoffset to see
how much (in seconds) does the rtc differ from the host clock.
- Store this offset somewhere.
- Use it next time with -startdate now+offset.
Dan.
diff --git a/console.h b/console.h
index 1ac74fa..3e1ac56 100644
--- a/console.h
+++ b/console.h
@@ -124,6 +124,8 @@ int vnc_display_open(DisplayState *ds, const char *display);
int vnc_display_password(DisplayState *ds, const char *password);
void do_info_vnc(void);
+void do_info_timeoffset(void);
+
/* x_keymap.c */
extern uint8_t _translate_keycode(const int key);
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index c1d5956..246535a 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -397,16 +397,12 @@ static void rtc_set_date_from_host(RTCState *s)
int val;
/* set the CMOS date */
-if (rtc_start_date == -1) {
-time(&ti);
-if (rtc_utc)
-tm = gmtime(&ti);
-else
-tm = localtime(&ti);
-} else {
-ti = rtc_start_date;
+ti = rtc_start_date;
+if (rtc_utc)
tm = gmtime(&ti);
-}
+else
+tm = localtime(&ti);
+
rtc_set_date(s, tm);
val = to_bcd(s, (tm->tm_year / 100) + 19);
@@ -603,3 +599,19 @@ RTCState *rtc_mm_init(target_phys_addr_t base, int
it_shift, qemu_irq irq)
register_savevm("mc146818rtc", base, 1, rtc_save, rtc_load, s);
return s;
}
+
+int rtc_get_timeoffset(RTCState *s)
+{
+time_t ti, rtc_ti;
+
+rtc_set_time(s);
+
+if (rtc_utc)
+rtc_ti = timegm(&s->current_tm);
+else
+rtc_ti = mktime(&s->current_tm);
+
+time(&ti);
+
+return rtc_ti - ti;
+}
diff --git a/hw/pc.c b/hw/pc.c
index 7049c44..bf60ca6 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -48,6 +48,12 @@ static PITState *pit;
static IOAPICState *ioapic;
static PCIDevice *i440fx_state;
+void do_info_timeoffset(void)
+{
+int rtc_get_timeoffset(RTCState *s);
+term_printf("now%+d\n", rtc_get_timeoffset(rtc_state));
+}
+
static void ioport80_write(void *opaque, uint32_t addr, uint32_t data)
{
}
diff --git a/monitor.c b/monitor.c
index 4a9e8bb..bc2870e 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1370,6 +1370,8 @@ static term_cmd_t info_cmds[] = {
"", "show which guest mouse is receiving events" },
{ "vnc", "", do_info_vnc,
"", "show the vnc server status"},
+{ "timeoffset", "", do_info_timeoffset,
+ "", "show how much the VM real time clock differ from host time" },
{ "name", "", do_info_name,
"", "show the current VM name" },
#if defined(TARGET_PPC)
diff --git a/sysemu.h b/sysemu.h
index d54f115..5a10518 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -72,7 +72,7 @@ void do_info_slirp(void);
extern int ram_size;
extern int bios_size;
extern int rtc_utc;
-extern int rtc_start_date;
+extern time_t rtc_start_date;
extern int cirrus_vga_enabled;
extern int vmsvga_enabled;
extern int graphic_width;
diff --git a/vl.c b/vl.c
index 6f83740..bed1402 100644
--- a/vl.c
+++ b/vl.c
@@ -183,7 +183,7 @@ int nb_nics;
NICInfo nd_table[MAX_NICS];
int vm_running;
int rtc_utc = 1;
-int rtc_start_date = -1; /* -1 means now */
+time_t rtc_start_date;
int cirrus_vga_enabled = 1;
int vmsvga_enabled = 0;
#ifdef TARGET_SPARC
@@ -7709,6 +7709,8 @@ int main(int argc, char **argv)
nb_nics = 0;
/* default mac address of the first network interface */
+time(&rtc_start_date); /* now is the default */
+
optind = 1;
for(;;) {
if (optind >= argc)
@@ -8168,8 +8170,21 @@ int main(int argc, char **argv)
case QEMU_OPTION_startdate:
{
struct tm tm;
-if (!strcmp(optarg, "now")) {
-rtc_start_date = -1;
+char sign;
+long timeoffset;
+if (sscanf(optarg, "now%c%lu", &sign, &timeoffset) == 2) {
+switch (sign) {
+case '+':
+rtc_start_date += timeoffset;
+break;
+case '-':
+rtc_start_date -= timeoffset;
+break;
+default:
+goto date_fail;
+}
+} else if (!strcmp(optarg, "now")) {
+/* keep the default */
} else {
if (sscanf(optarg, "%d-%d-%dT%d:%d:%d",
&tm.tm_year,
Re: [Qemu-devel] qemu hw/pc.c target-i386/cpu.h target-i386/help...
On Thu, Nov 08, 2007 at 01:28:47PM +, Fabrice Bellard wrote:
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Fabrice Bellard07/11/08 13:28:47
>
> Modified files:
> hw : pc.c
> target-i386: cpu.h helper2.c
>
> Log message:
> added -cpu option for x86 (initial patch by Dan Kenigsberg)
>
> CVSWeb URLs:
> http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.89&r2=1.90
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemu&r1=1.51&r2=1.52
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemu&r1=1.54&r2=1.55
>
Only now did I notice this. Thanks for applying, but as Thiemo Seufer
mentioned on this list, one must correct a segfault-inducing typo:
Regards,
Dan.
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index b46475e..67658e2 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -83,7 +83,7 @@ static void add_flagname_to_bitmaps(char *flagname, uint32_t
*features,
return;
}
for ( i = 0 ; i < 32 ; i++ )
-if (ext3_features[i] && !strcmp (flagname, ext3_feature_name[i])) {
+if (ext3_feature_name[i] && !strcmp (flagname, ext3_feature_name[i])) {
*ext3_features |= 1 << i;
return;
}
Re: [Qemu-devel] [PATCH 0/3] Add SCSI support for PC target
On Wed, Oct 31, 2007 at 11:17:23AM +0100, Laurent Vivier wrote: > Dan Kenigsberg a écrit : > >Hi, > > > >I have some newby's questions: is a speedup expected, comparing to ide > > We should have a speedup. Would you suggest where it could show? I was trying simple dd and bonnie++, and saw big variace between consequtive runs, but little change between mounting an image with if=ide and if=scsi. Was I doing something wrong? > But an improvement can also be to interface a _real_ SCSI disk and send > directly to it the SCSI commands generated by the _virtual_ SCSI interface > (as it is done in BasiliskII emulator) And regardless of any improvement it's important enough to have this feature avaiable. Regards, Dan.
Re: [Qemu-devel] [PATCH 0/3] Add SCSI support for PC target
Hi, I have some newby's questions: is a speedup expected, comparing to ide (I didn't notice any)? Can the PC boot from a SCSI-mounted device (I did not succeede)?
[Qemu-devel] [Patch] handle VNC v3.7 clients correctly
According to http://www.realvnc.com/docs/rfbproto.pdf section 6.2.1,
when handling older clients, SecurityResult should not be sent.
diff --git a/vnc.c b/vnc.c
index 72c8d1c..8ae671a 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1775,7 +1775,10 @@ static int protocol_client_auth(VncState *vs, char
*data, size_t len)
switch (vs->auth) {
case VNC_AUTH_NONE:
VNC_DEBUG("Accept auth none\n");
- vnc_write_u32(vs, 0); /* Accept auth completion */
+ if (vs->minor >= 8) {
+ vnc_write_u32(vs, 0); /* Accept auth completion */
+ vnc_flush(vs);
+ }
vnc_read_when(vs, protocol_client_init, 1);
break;
Re: [Qemu-devel] [Patch] set boot sequence from command line - Take 2
On Thu, Oct 25, 2007 at 10:49:25AM +0200, Bernhard Kauer wrote:
> It is perhaps not the best idea to read behind the
> end of the boot_device string. It would be safer to
> declare boot_device as 'static char boot_device[4]'
> and use a strncpy.
>
>
> Bernhard
>
Thanks for the good catch! (and to others who commented)
In this "take" has the following changes:
1. QEMUMachineInitFunc uses const char *boot_device
2. correct spelling of `nibble'
3. avoid touching PPC_NVRAM_set_params() API needlessly
4. allocate boot_device statically
5. define MAX_BOOT_DEVICES clearly according to the TARGET. Only three
devices are supoorted by the i386 bios
6. reject the boot string if it includes a single unrecognized letter
Dan.
diff --git a/hw/an5206.c b/hw/an5206.c
index 94ecccb..d9931df 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -27,7 +27,7 @@ void DMA_run (void)
/* Board init. */
-static void an5206_init(int ram_size, int vga_ram_size, int boot_device,
+static void an5206_init(int ram_size, int vga_ram_size, const char
*boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index 993a686..8c4181b 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -197,7 +197,7 @@ static void mcf5208_sys_init(qemu_irq *pic)
}
}
-static void mcf5208evb_init(int ram_size, int vga_ram_size, int boot_device,
+static void mcf5208evb_init(int ram_size, int vga_ram_size, const char
*boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/palm.c b/hw/palm.c
index 623fcd6..3101e9e 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -61,7 +61,7 @@ static void palmte_microwire_setup(struct omap_mpu_state_s
*cpu)
{
}
-static void palmte_init(int ram_size, int vga_ram_size, int boot_device,
+static void palmte_init(int ram_size, int vga_ram_size, const char
*boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/pc.c b/hw/pc.c
index a0c824f..3e4e06a 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -152,8 +152,25 @@ static void cmos_init_hd(int type_ofs, int info_ofs,
BlockDriverState *hd)
rtc_set_memory(s, info_ofs + 8, sectors);
}
+/* convert boot_device letter to something recognizable by the bios */
+static int boot_device2nibble(char boot_device)
+{
+switch(boot_device) {
+case 'a':
+case 'b':
+return 0x01; /* floppy boot */
+case 'c':
+return 0x02; /* hard drive boot */
+case 'd':
+return 0x03; /* CD-ROM boot */
+case 'n':
+return 0x04; /* Network boot */
+}
+return 0;
+}
+
/* hd_table must contain 4 block drivers */
-static void cmos_init(int ram_size, int boot_device, BlockDriverState
**hd_table)
+static void cmos_init(int ram_size, const char *boot_device, BlockDriverState
**hd_table)
{
RTCState *s = rtc_state;
int val;
@@ -184,24 +201,12 @@ static void cmos_init(int ram_size, int boot_device,
BlockDriverState **hd_table
rtc_set_memory(s, 0x34, val);
rtc_set_memory(s, 0x35, val >> 8);
-switch(boot_device) {
-case 'a':
-case 'b':
-rtc_set_memory(s, 0x3d, 0x01); /* floppy boot */
-if (!fd_bootchk)
-rtc_set_memory(s, 0x38, 0x01); /* disable signature check */
-break;
-default:
-case 'c':
-rtc_set_memory(s, 0x3d, 0x02); /* hard drive boot */
-break;
-case 'd':
-rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */
-break;
-case 'n':
-rtc_set_memory(s, 0x3d, 0x04); /* Network boot */
-break;
-}
+/* set boot devices, and disable floppy signature check if requested */
+rtc_set_memory(s, 0x3d,
+boot_device2nibble(boot_device[1]) << 4 |
+boot_device2nibble(boot_device[0]) );
+rtc_set_memory(s, 0x38,
+boot_device2nibble(boot_device[2]) << 4 | (fd_bootchk ? 0x0 :
0x1));
/* floppy type */
@@ -663,7 +668,7 @@ static void pc_init_ne2k_isa(NICInfo *nd, qemu_irq *pic)
}
/* PC hardware initialisation */
-static void pc_init1(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init1(int ram_size, int vga_ram_size, const char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
@@ -947,7 +952,7 @@ static void pc_init1(int ram_size, int vga_ram_size, int
boot_device,
#endif
[Qemu-devel] [Patch] set boot sequence from command line
Real PCs try to boot from a CD, then try the hard drive, and finally go
to the network. And they let their owner change that order.
This patch lets Qemu do the same with "-boot dcn".
I'll be happy to hear comments about it,
Dan.
diff --git a/hw/an5206.c b/hw/an5206.c
index 94ecccb..2134184 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -27,7 +27,7 @@ void DMA_run (void)
/* Board init. */
-static void an5206_init(int ram_size, int vga_ram_size, int boot_device,
+static void an5206_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index 993a686..19689ba 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -197,7 +197,7 @@ static void mcf5208_sys_init(qemu_irq *pic)
}
}
-static void mcf5208evb_init(int ram_size, int vga_ram_size, int boot_device,
+static void mcf5208evb_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/palm.c b/hw/palm.c
index 623fcd6..971ff37 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -61,7 +61,7 @@ static void palmte_microwire_setup(struct omap_mpu_state_s
*cpu)
{
}
-static void palmte_init(int ram_size, int vga_ram_size, int boot_device,
+static void palmte_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/pc.c b/hw/pc.c
index a0c824f..3c552ff 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -152,8 +152,25 @@ static void cmos_init_hd(int type_ofs, int info_ofs,
BlockDriverState *hd)
rtc_set_memory(s, info_ofs + 8, sectors);
}
+/* convert boot_device letter to something recognizable by the bios */
+static int boot_device2nible(char boot_device)
+{
+switch(boot_device) {
+case 'a':
+case 'b':
+return 0x01; /* floppy boot */
+case 'c':
+return 0x02; /* hard drive boot */
+case 'd':
+return 0x03; /* CD-ROM boot */
+case 'n':
+return 0x04; /* Network boot */
+}
+return 0;
+}
+
/* hd_table must contain 4 block drivers */
-static void cmos_init(int ram_size, int boot_device, BlockDriverState
**hd_table)
+static void cmos_init(int ram_size, char *boot_device, BlockDriverState
**hd_table)
{
RTCState *s = rtc_state;
int val;
@@ -184,24 +201,12 @@ static void cmos_init(int ram_size, int boot_device,
BlockDriverState **hd_table
rtc_set_memory(s, 0x34, val);
rtc_set_memory(s, 0x35, val >> 8);
-switch(boot_device) {
-case 'a':
-case 'b':
-rtc_set_memory(s, 0x3d, 0x01); /* floppy boot */
-if (!fd_bootchk)
-rtc_set_memory(s, 0x38, 0x01); /* disable signature check */
-break;
-default:
-case 'c':
-rtc_set_memory(s, 0x3d, 0x02); /* hard drive boot */
-break;
-case 'd':
-rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */
-break;
-case 'n':
-rtc_set_memory(s, 0x3d, 0x04); /* Network boot */
-break;
-}
+/* set boot devices, and disable floppy signature check if requested */
+rtc_set_memory(s, 0x3d,
+boot_device2nible(boot_device[1]) << 4 |
+boot_device2nible(boot_device[0]) );
+rtc_set_memory(s, 0x38,
+boot_device2nible(boot_device[2]) << 4 | (fd_bootchk ? 0x0 : 0x1));
/* floppy type */
@@ -663,7 +668,7 @@ static void pc_init_ne2k_isa(NICInfo *nd, qemu_irq *pic)
}
/* PC hardware initialisation */
-static void pc_init1(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init1(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
@@ -947,7 +952,7 @@ static void pc_init1(int ram_size, int vga_ram_size, int
boot_device,
#endif
}
-static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init_pci(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename,
int snapshot,
const char *kernel_filename,
@@ -961,7 +966,7 @@ static void pc_init_pci(int ram_size, int vga_ram_size, int
boot_device,
initrd_filename, 1, cpu_model);
}
-static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
+static vo
Re: [Qemu-devel] RFC: avoid #ifdef for target cpu list - for x86, too.
On Mon, Oct 22, 2007 at 01:47:42AM +0100, Thiemo Seufer wrote:
> Dan Kenigsberg wrote:
> > This seems like a good excuse to send my suggested -cpu option for the
> > x86 target. It is just like my previous "take 4", but fits to the newly
> > unified cpu_list.
>
> Leads to an instant segfault for the i386 usermode emulation.
>
Ouch. You are NOT my alpha tester, but I suspect that
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -97,7 +97,7 @@ static void add_flagname_to_bitmaps(char *flagname, uint32_t
*features, uint32_t
return;
}
for ( i = 0 ; i < 32 ; i++ )
-if (ext3_feature[i] && !strcmp (flagname, ext3_feature_name[i])) {
+if (ext3_feature_name[i] && !strcmp (flagname, ext3_feature_name[i])) {
*ext3_features |= 1 << i;
return;
}
is my embarrassing typo. I resubmit the whole thing below:
diff --git a/hw/pc.c b/hw/pc.c
index c561cbf..a0c824f 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -667,7 +667,7 @@ static void pc_init1(int 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,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -683,6 +683,13 @@ static void pc_init1(int ram_size, int vga_ram_size, int
boot_device,
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
for(i = 0; i < smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -951,7 +958,7 @@ static void pc_init_pci(int ram_size, int vga_ram_size, int
boot_device,
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -965,7 +972,7 @@ static void pc_init_isa(int ram_size, int vga_ram_size, int
boot_device,
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 2341990..e92fc31 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -274,23 +274,56 @@
#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 CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
#define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)
+#define CPUID_EXT3_CR8LEG (1 << 4)
+#define CPUID_EXT3_ABM (1 << 5)
+#define CPUID_EXT3_SSE4A (1 << 6)
+#define CPUID_EXT3_MISALIGNSSE (1 << 7)
+#define CPUID_EXT3_3DNOWPREFETCH (1 << 8)
+#define CPUID_EXT3_OSVW(1 << 9)
+#define CPUID_EXT3_IBS (1 << 10)
#define EXCP00_DIVZ0
#define EXCP01_SSTP
[Qemu-devel] RFC: avoid #ifdef for target cpu list - for x86, too.
This seems like a good excuse to send my suggested -cpu option for the
x86 target. It is just like my previous "take 4", but fits to the newly
unified cpu_list.
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.87
diff -u -p -r1.87 pc.c
--- hw/pc.c 9 Oct 2007 03:08:56 - 1.87
+++ hw/pc.c 12 Oct 2007 08:50:22 -
@@ -667,7 +667,7 @@ static void pc_init1(int ram_size, int v
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -683,6 +683,13 @@ static void pc_init1(int ram_size, int v
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
for(i = 0; i < smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -951,7 +958,7 @@ static void pc_init_pci(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -965,7 +972,7 @@ static void pc_init_isa(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.50
diff -u -p -r1.50 cpu.h
--- target-i386/cpu.h 27 Sep 2007 16:44:31 - 1.50
+++ target-i386/cpu.h 12 Oct 2007 08:50:22 -
@@ -274,23 +274,56 @@
#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 CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
#define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)
+#define CPUID_EXT3_CR8LEG (1 << 4)
+#define CPUID_EXT3_ABM (1 << 5)
+#define CPUID_EXT3_SSE4A (1 << 6)
+#define CPUID_EXT3_MISALIGNSSE (1 << 7)
+#define CPUID_EXT3_3DNOWPREFETCH (1 << 8)
+#define CPUID_EXT3_OSVW(1 << 9)
+#define CPUID_EXT3_IBS (1 << 10)
#define EXCP00_DIVZ0
#define EXCP01_SSTP1
@@ -564,6 +597,9 @@ typedef struct CPUX86State {
CPUX86State *cpu_x86_init(void);
int cpu_x86_exec(CPUX86State *s);
void cpu_x86_close(CPUX86State *s);
+int x86_find_cpu_by_name (const unsigned char *name);
+void x86_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
+ ...));
int cpu_get_pic_interrupt(CPUX86State *s);
/* MSDOS compatibility mode FPU exception support */
void cpu_set_ferr(CPUX86State *s);
@@ -687,6 +723,7 @@ static inline int cpu_get_time_fast(void
#define cpu_exec cpu_x86_exec
#define cpu_gen_code cpu_x86_gen_code
#define cpu_signal_handler cpu_x86_signal_handler
+#define cpu_list x86_cpu_list
#include "cpu-all.h"
Index: target-i386/helper2.c
===
RCS file: /sources/qemu/qemu/target-i386/helper2.c,v
retrieving revision 1.52
diff -u -
Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest
On Mon, Oct 08, 2007 at 09:55:37AM -0500, Anthony Liguori wrote:
> Dan Kenigsberg wrote:
> >In X's vmmouse_drv, the magic number is defined as uint32_t. Therefore
> >the top half of the 64 bit ax register is garbage that should be
> >ignored. This makes fc6 guest's vmmouse work.
> >
> >
>
> I think a better fix would be to change eax from target_ulong to uint32_t.
>
I don't really mind that.
Index: hw/vmport.c
===
RCS file: /sources/qemu/qemu/hw/vmport.c,v
retrieving revision 1.1
diff -u -p -r1.1 vmport.c
--- hw/vmport.c 26 Aug 2007 17:48:12 - 1.1
+++ hw/vmport.c 8 Oct 2007 15:24:50 -
@@ -52,7 +52,7 @@ static uint32_t vmport_ioport_read(void
{
VMPortState *s = opaque;
unsigned char command;
-target_ulong eax;
+uint32_t eax;
eax = s->env->regs[R_EAX];
if (eax != VMPORT_MAGIC)
Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest
In X's vmmouse_drv, the magic number is defined as uint32_t. Therefore the top half of the 64 bit ax register is garbage that should be ignored. This makes fc6 guest's vmmouse work. Index: hw/vmport.c === RCS file: /sources/qemu/qemu/hw/vmport.c,v retrieving revision 1.1 diff -u -p -r1.1 vmport.c --- hw/vmport.c 26 Aug 2007 17:48:12 - 1.1 +++ hw/vmport.c 8 Oct 2007 13:11:45 - @@ -55,7 +55,7 @@ static uint32_t vmport_ioport_read(void target_ulong eax; eax = s->env->regs[R_EAX]; -if (eax != VMPORT_MAGIC) +if ((uint32_t)eax != VMPORT_MAGIC) return eax; command = s->env->regs[R_ECX];
[Qemu-devel] x86 -cpu option: Take 4
Hi,
Due to comments on "Take 3", I rewrote the feature name list according
to Intel's and AMD's specs in order not to contaminate target-i386 with
GPL code. More importantly - the "host" cpu type is dropped. It will be
added, as a kvm-specific code, in a future patch.
I'd be happy to hear if patch is applicable in its current minimalistic
form this, or that more changes should be made.
Thanks,
Dan.
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.346
diff -u -p -r1.346 vl.c
--- vl.c5 Oct 2007 13:08:34 - 1.346
+++ vl.c7 Oct 2007 12:34:45 -
@@ -7696,6 +7696,8 @@ int main(int argc, char **argv)
mips_cpu_list(stdout, &fprintf);
#elif defined(TARGET_SPARC)
sparc_cpu_list(stdout, &fprintf);
+#elif defined(TARGET_I386)
+x86_cpu_list(stdout, &fprintf);
#endif
exit(0);
} else {
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.86
diff -u -p -r1.86 pc.c
--- hw/pc.c 5 Oct 2007 13:08:35 - 1.86
+++ hw/pc.c 7 Oct 2007 12:34:46 -
@@ -666,7 +666,7 @@ static void pc_init1(int ram_size, int v
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -682,6 +682,13 @@ static void pc_init1(int ram_size, int v
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
for(i = 0; i < smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -950,7 +957,7 @@ static void pc_init_pci(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -964,7 +971,7 @@ static void pc_init_isa(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.50
diff -u -p -r1.50 cpu.h
--- target-i386/cpu.h 27 Sep 2007 16:44:31 - 1.50
+++ target-i386/cpu.h 7 Oct 2007 12:34:46 -
@@ -274,23 +274,56 @@
#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 CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
#define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)
+#define CPUID_EXT3_CR8LEG (1 << 4)
+#define CPUID_EXT3_ABM (1 << 5)
+#define CPUID_EXT3_SSE4A (1 << 6)
+#define CPUID_EXT3_MISALIGNSSE (1 << 7)
+#define CPUID_EXT3_3DNOWPREFETCH (1 << 8)
+#define CPUID_EXT3_OSVW(1 << 9)
+#define CPUID_EXT3_IBS (1 << 10)
#define EXCP00_DIVZ0
#define EXCP01_SSTP1
@@ -564,6 +597,9 @@ typedef struct CPUX86State {
CPUX86St
[Qemu-devel] typo in qemu_next_deadline()
(int64_t)UINT64_MAX is -1 and should not be assigned to nearest_delta_us
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.343
diff -u -p -r1.343 vl.c
--- vl.c29 Sep 2007 19:24:40 - 1.343
+++ vl.c1 Oct 2007 14:55:05 -
@@ -1181,7 +1179,7 @@ static void host_alarm_handler(int host_
static uint64_t qemu_next_deadline(void)
{
-int64_t nearest_delta_us = UINT64_MAX;
+int64_t nearest_delta_us = INT64_MAX;
int64_t vmdelta_us;
if (active_timers[QEMU_TIMER_REALTIME])
[Qemu-devel] redundant qemu_rearm_alarm_timer() in qemu_del_timer()
There is no need to rearm the alarm timer when a qemu timer is deleted. The current code contains a redundant rearm whenever qemu_del_timer() is used, which is very often - in every qemu_mod_timer(). The rearm in qemu_mod_timer() is redundant because a currently-set timer could not be brought forward due to delete - only postponed. And postponing the timer is better done once in the end of qemu_run_timers(). Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.343 diff -u -p -r1.343 vl.c --- vl.c29 Sep 2007 19:24:40 - 1.343 +++ vl.c1 Oct 2007 14:13:01 - @@ -988,8 +988,6 @@ void qemu_del_timer(QEMUTimer *ts) } pt = &t->next; } - -qemu_rearm_alarm_timer(alarm_timer); } /* modify the current timer so that it will be fired when current_time
Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest
On Tue, Sep 25, 2007 at 11:06:58PM +0100, Daniel P. Berrange wrote: > > By an unfortunate co-incidence I've just hit a similar problem myself. It > turns out QEMU mouse handling is more complex than I realized. QEMU can > export several different input devices to a guest OS, PS/2 mouse, VMWare > mouse, USB mouse, USB EvTouch tablet, USB Wacom tablet. Only one of these > devices will be fed mouse events from the host OS though at any time. The > default is that the most recently 'activated' mouse will get the events. > This starts off being the PS/2 mouse. Certain actions in the guest OS may > cause one or more of the other input devices to activate itself, and thus > claiming control of all input events from the host. > > You can see what mice are configured at any time from the QEMU monitor by > typing 'info mice'. The active one has an * next to it. What I suspect > is happening in your case is that you've configured the USB tablet, but > during initial boot only the PS/2 mouse is activated & GPM is actually > responding to events from the PS/2 mouse no the tablet. Then during boot > something in HAL (or perhaps X itself) causes the USB tablet to become > active & thus the PS/2 mouse stops getting events. But then it sounds > like neither GPM or X are configured to use the USB tablet either, so > you end up with no movement at all. > > So I guess it is probably a matter of suitably configuring Xorg to use > the USB tablet, though I can't remember exact syntax for Fedora Core 6, > in Fedora 7 I have successfully used: > > Section "InputDevice" > Name "Mouse0" > Driver "evdev" > Option "Name" "QEMU 0.8.2 QEMU USB Tablet" > Option "Mode" "Absolute" > EndSection > > NB, make sure 'Mouse0' is referenced as the CorePointer in the ServerLayout > section of the config. Also the 'Name' value varies acording to what QEMU > version you have[1] - check /proc/bus/input/devices for exact name seen > by the guest OS > Thanks for your eye-opening response! As you suspected, my guest's haldaemon activated the USB Tablet mouse and robbed GPM of its mouse source. And evdev's (?) by-name device selection is so nice comparing to guessing which /dev/input/event? is used. However, I still have a usability problem. Do you experience smooth mouse movement with evdev? I have untolerable cursor movement, unless I move the mouse very very very slowly. Otherwise, the cursor tends to keep its horizontal position. Thanks, Dan.
Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest
On Tue, Sep 25, 2007 at 08:47:47AM -0500, Anthony Liguori wrote: > Dor Laor wrote: > >Dan Kenigsberg wrote: > >>Frustrated with evtouch, I wanted to try vmmouse's absolute mode, > >>supported by > >>Liguori's patch > >>http://thread.gmane.org/gmane.comp.emulators.qemu/16083 . > > Did you try it in KVM or in QEMU? > In QEMU (cvs). > In KVM, you need an additional patch to ensure that the register state > is synchronized. Thanks, I'll make a note of that, and return to you for details before I try to port vmmouse to KVM.
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
On Tue, Sep 25, 2007 at 03:07:44PM +0200, Jocelyn Mayer wrote: > > So, running qemu without any parameters would use host capabilities if > > kvm is available and the default qemu cpu if not. The -cpu option can > > be used to override this if necessary. > > Well, it may be needed to integrate the "-cpu host" option. > But I think it's a really bad idea that running qemu without the -cpu > option would not act the same on different host. When I want to test > qemu with the same command line, I want it to behave exactly the same, > whatever the host I'm running on, like any other tool. Think about gcc, > for example, if you launch it without option, it compiles for a generic > CPU. If you want to tune the generated code, even for the host you're > running on, you have to use -mcpu/-march/-mtune. Using one command line > always have gives the same result. > Then, my opinion is that running qemu without any -cpu option should > always use a default target. Note that in "take 3" the default is indeed to expose the "basic" default cpu features if no -cpu is specified. One must add -cpu host in order to read and expose the host cpuid.
[Qemu-devel] vmmouse with Fedora-6 64bit guest
Frustrated with evtouch, I wanted to try vmmouse's absolute mode, supported by Liguori's patch http://thread.gmane.org/gmane.comp.emulators.qemu/16083 . My guest has vmmouse_drv.so, and I configured its xorg.conf to load it. However, for some reason I get (EE) VMWARE(0): vmmouse enabled failed On the host side, after define DEBUG_VMMOUSE, I see vmmouse_init and nothing else. Any idea what I am doing wrong? Regards, Dan.
Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest
On Thu, Sep 20, 2007 at 02:41:32PM +0100, Daniel P. Berrange wrote: > On Thu, Sep 20, 2007 at 03:36:26PM +0200, Dan Kenigsberg wrote: > > Hi, > > > > I saw that using the tablet with Linux guest is possible > > http://thread.gmane.org/gmane.comp.emulators.qemu/11516 > > yet I fail to do that. > > > > I managed to compile, configure and load the evtouch X module, but still > > there is no movement of the mouse (after I disabled the default X > > pointer). I attach my Xorg.0.log for the joy of the readership. > > Don't use the evtouch X module. Use the regular 'evdev' module. > > Dan. Dan, thanks for this info. However, my problem begins earlier than in X and using evdev instead of evtouch does not solve it. It seems that some Linux guests have problems communicating with the tablet device. The most reproducible behavior that I noticed is when FC-6 starts: gpm senses the tablet, but only until haldaemon starts. After that, I cannot obtain any mouse event (even after stopping haldaemon). Could you tell if this can be avoided? Thanks, Dan.
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
> Hi,
>
> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> > As with previous "Takes" of this patch, its purpose is to expose host
> > +{
> > +asm("cpuid"
> > +: "=a" (*ax),
> > + "=b" (*bx),
> > + "=c" (*cx),
> > + "=d" (*dx)
> > +: "a" (function));
> > +}
>
> I haven't really read through the rest of your code but this piece
> appears to be outside any #ifdef/#endif so it will only build on x86.
I might be missing something here, but isn't not being on the
TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
elsewhere under target-i386. I don't mind adding extra protection, I
just be happy to better understand the whats and whys.
Dan.
[Qemu-devel] expose host CPU features to guests: Take 3
As with previous "Takes" of this patch, its purpose is to expose host
CPU features to guests. It proved rather helpful to KVM in various
benchmarks, and it should similarly speed kqemu up. Note that it does
not extend the set of emulated opcodes, only exposes what's supported by
the host CPU.
Another purpose for "Take 2" is to add the -cpu option to the x86
architecture, similarly to that of other architectures.
-cpu 486, pentium, pentium2 and pentium3 are supported in addition to
finer-grained features such as -cpu pentium,-mmx . As in Take 1,
-cpu host exposes host features to guest.
This patch exposes the requested CPU also right after RESET command, and
not only in CPUID.
Please let me know if you have more suggestions,
Dan.
===
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.342
diff -u -p -r1.342 vl.c
--- vl.c17 Sep 2007 21:25:20 - 1.342
+++ vl.c24 Sep 2007 16:53:29 -
@@ -7694,6 +7694,8 @@ int main(int argc, char **argv)
mips_cpu_list(stdout, &fprintf);
#elif defined(TARGET_SPARC)
sparc_cpu_list(stdout, &fprintf);
+#elif defined(TARGET_I386)
+x86_cpu_list(stdout, &fprintf);
#endif
exit(0);
} else {
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.85
diff -u -p -r1.85 pc.c
--- hw/pc.c 17 Sep 2007 08:09:47 - 1.85
+++ hw/pc.c 24 Sep 2007 16:53:29 -
@@ -666,7 +666,7 @@ static void pc_init1(int ram_size, int v
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -682,6 +682,13 @@ static void pc_init1(int ram_size, int v
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
for(i = 0; i < smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -948,7 +955,7 @@ static void pc_init_pci(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -962,7 +969,7 @@ static void pc_init_isa(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.48
diff -u -p -r1.48 cpu.h
--- target-i386/cpu.h 23 Sep 2007 15:28:04 - 1.48
+++ target-i386/cpu.h 24 Sep 2007 16:53:30 -
@@ -274,23 +274,56 @@
#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 CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
#define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)
[Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest
Hi, I saw that using the tablet with Linux guest is possible http://thread.gmane.org/gmane.comp.emulators.qemu/11516 yet I fail to do that. I managed to compile, configure and load the evtouch X module, but still there is no movement of the mouse (after I disabled the default X pointer). I attach my Xorg.0.log for the joy of the readership. Where could my problem lie? How can I tell whether Linux gets ANYTHING from the tablet device? lsusb gives a bizarre ID that does not seem too relevant: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd BTW, did anyone manage to use the tablet device in Linux's console (with gpm)? Regads, Dan. Xorg.0.log.gz Description: GNU Zip compressed data
Re: [Qemu-devel] expose host CPU features to guests: Take 2
On Mon, Sep 10, 2007 at 12:47:51PM +0100, Natalia Portillo wrote: > I don't see in what is it useful without KVM/KQEMU. It is not. I tried to be clear about it in my post. Sorry for not being clearer. > And even with them there are some instructions that can't be accesible > without KQEMU/KVM prepared for them. I suspect this is true. For example, in my patch I blocked ACPI and VMX. Still, those features that ARE exposed to the guest, speed it up. Isn't it the Right Thing? > And, the -cpu option, should be enabled in x86 and x86_64 to > enable/disable emulation of instructions (and them cpuid adjusted to > indicate them). I'm not sure I understand this comment. If you mean that -cpu should not expose a feature that is not emulated by qemu, I agree. Regards, Dan.
Re: [Qemu-devel] question regarding odd CPU feature assignement
Thanks! On Mon, Sep 10, 2007 at 10:55:55AM +0200, Filip Navara wrote: > It's not a typo. The short story is that there are two CPUID feature > registers - 1/EDX and 0x8001/EDX - that differ slightly. The later one > was first used by AMD CPUs and mostly enhanced by adding new features to > processors from the said company (3DNow and such). The first one was > introduced by Intel and on AMD processor it's only used for compatibility, > but not for AMD-specific extensions. You can learn more by looking at the > tables on http://www.sandpile.org/ia32/cpuid.htm. > > Best regards, > Filip Navara > > On 9/10/07, Dan Kenigsberg <[EMAIL PROTECTED]> wrote: > > > > Line 132 of qemu/target-i386/helper2.c has > > > > /* currently not enabled for std i386 because not fully tested */ > > env->cpuid_ext2_features = (env->cpuid_features & 0x0183F3FF); > > > > Which smells like a typo: I see no reason to make cpuid_ext2_features a > > masked version of cpuid_features. > > > > Would someone care to elaborate? > > > > Thanks, > > > > Dan. > > > > > >
[Qemu-devel] expose host CPU features to guests: Take 2
As with Take 1 of this patch, its purpose is to expose host CPU features to
guests. It proved rather helpful to KVM in various benchmarks, and it should
similarly speed kqemu up. Note that it does not extend the set of emulated
opcodes, only exposes what's supported by the host CPU.
I changed the patch according to the comments on these mailing lists. Thanks
for your suggestions. Changes since "take 1" are:
- Use the new -cpu option to specify cpu features.
- Read host cpuid directly, instead of parsing /proc/cpuinfo. This approach is
less Linux-centric and should work with other OSs too. It means however, that
the cpuid is not checked for old CPU bugs. In the future, qemu should
negotiate the actually-supported features with the virutalizing kernel
module.
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.83
diff -u -r1.83 pc.c
--- hw/pc.c 26 Aug 2007 17:51:39 - 1.83
+++ hw/pc.c 10 Sep 2007 06:54:00 -
@@ -666,7 +666,7 @@
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -683,7 +683,9 @@
/* init CPUs */
for(i = 0; i < smp_cpus; i++) {
+void apply_i386_cpu_model(CPUX86State *env, char *cpu_model);
env = cpu_init();
+apply_i386_cpu_model(env, cpu_model);
if (i != 0)
env->hflags |= HF_HALTED_MASK;
if (smp_cpus > 1) {
@@ -948,7 +950,7 @@
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -962,7 +964,7 @@
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.45
diff -u -r1.45 cpu.h
--- target-i386/cpu.h 11 Jul 2007 22:48:58 - 1.45
+++ target-i386/cpu.h 10 Sep 2007 06:54:00 -
@@ -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
===
RCS file: /sources/qemu/qemu/target-i386/helper2.c,v
retrieving revision 1.48
diff -u -r1.48 helper2.c
--- target-i386/helper2.c 31 Jul 2007 23:09:18 - 1.48
+++ target-i386/helper2.c 10 Sep 2007 06:54:00 -
@@ -45,40 +45,8 @@
#endif
#endif /* USE_CODE_COPY */
-CPUX86State *cpu_x86_init(void)
+static int set_guest_cpu_basic(CPUX86State *env)
{
-CPUX86State *env;
-static int inited;
-
-env = qemu_mallocz(sizeof(CPUX86State));
-if (!env)
-return NULL;
-cpu_exec_init(env);
-
-/* init various static tables */
-if (!inited) {
-inited = 1;
-optimize_flags_init();
-}
-#ifdef USE_CODE_COPY
-/* testing code for code copy case */
-{
-struct modify_ldt_ldt_s ldt;
-
-ldt.entry_number = 1;
-ldt.base_addr = (unsigned long)e
[Qemu-devel] question regarding odd CPU feature assignement
Line 132 of qemu/target-i386/helper2.c has /* currently not enabled for std i386 because not fully tested */ env->cpuid_ext2_features = (env->cpuid_features & 0x0183F3FF); Which smells like a typo: I see no reason to make cpuid_ext2_features a masked version of cpuid_features. Would someone care to elaborate? Thanks, Dan.
Re: [Qemu-devel] [PATCH] Intel cache info
On Sat, Sep 08, 2007 at 09:27:35PM +0200, Filip Navara wrote: > Fix the CPUID function 2 to correctly report cache info for the particular > processor. I chose the values closest to the ones reported in the AMD > registers. This is important for operating systems that detect cache line > width and later call CLFLUSH for each line. In the previous implementation > the values didn't specify L2 cache line width and so Darwin endlessly looped > trying to flush them. It would be nice to see the patch. I should probably include it in my patch that exposes host cpu features. Thanks, Dan.
Re: [kvm-devel] [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
On Fri, Aug 24, 2007 at 10:18:47PM +0200, Luca wrote: > On 8/23/07, Dan Kenigsberg <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 23, 2007 at 12:09:47AM +0200, Andi Kleen wrote: > > > > $ dmesg |grep -i hpet > > > > ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97) > > > > ACPI: HPET id: 0x8086a301 base: 0xfed0 > > > > hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 > > > > hpet0: 4 64-bit timers, 14318180 Hz > > > > hpet_resources: 0xfed0 is busy > > > > > > What kernel version was that? There was a bug that caused this pre .22 > > > > > > > I have vanilla 2.6.22.3 on that machine. > > Try: > cat /sys/devices/system/clocksource/clocksource0/available_clocksource > > do you see HPET listed twice? > No, only once. Is that wrong? # cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm jiffies tsc # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc Dan.
Re: [kvm-devel] [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
On Thu, Aug 23, 2007 at 12:09:47AM +0200, Andi Kleen wrote: > > $ dmesg |grep -i hpet > > ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97) > > ACPI: HPET id: 0x8086a301 base: 0xfed0 > > hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 > > hpet0: 4 64-bit timers, 14318180 Hz > > hpet_resources: 0xfed0 is busy > > What kernel version was that? There was a bug that caused this pre .22 > I have vanilla 2.6.22.3 on that machine. Thanks, Dan.
Re: [kvm-devel] [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
On Wed, Aug 22, 2007 at 02:34:24PM +0200, Andi Kleen wrote: > On Wed, Aug 22, 2007 at 10:03:32AM +0300, Avi Kivity wrote: > > Maybe the kernel is using the timer, so userspace can't. Just a guess. > > HPET has multiple timers (variable, but typically 2 or 4). The kernel > only uses timer 0. It's possible someone else in user space is using > it though. Try lsof /dev/hpet Thanks for the ideas; however even after I made the kernel use tsc as time source, and made sure that no one opens /dev/hpet, I fail to use HPET (with same errors as before) I now have $ dmesg |grep -i hpet ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97) ACPI: HPET id: 0x8086a301 base: 0xfed0 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 64-bit timers, 14318180 Hz hpet_resources: 0xfed0 is busy Any other idea? Dan.
[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
On Wed, Aug 22, 2007 at 06:38:18PM +0200, Luca wrote: > and I'm reading it from /proc/config.gz on the guest. > > > And a huge number of settime calls? > > Yes, maybe some QEMU timer is using an interval < 1ms? > Dan do you any any idea of what's going on? Not really...
Re: [kvm-devel] [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
On Tue, Aug 21, 2007 at 01:15:22PM -0700, Matthew Kent wrote: > On Tue, 2007-21-08 at 21:40 +0200, Luca wrote: > > On 8/21/07, Matthew Kent <[EMAIL PROTECTED]> wrote: > > > On Sat, 2007-18-08 at 01:11 +0200, Luca Tettamanti wrote: > > > > plain text document attachment (clock-hpet) > > > > Linux operates the HPET timer in legacy replacement mode, which means > > > > that > > > > the periodic interrupt of the CMOS RTC is not delivered (qemu won't be > > > > able > > > > to use /dev/rtc). Add support for HPET (/dev/hpet) as a replacement for > > > > the > > > > RTC; the periodic interrupt is delivered via SIGIO and is handled in the > > > > same way as the RTC timer. > > > > > > > > Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]> > > > > > > I must be missing something silly here.. should I be able to open more > > > than one instance of qemu with -clock hpet? Because upon invoking a > > > second instance of qemu HPET_IE_ON fails. > > > > It depends on your hardware. Theoretically it's possible, but I've yet > > to see a motherboard with more than one periodic timer. > > Ah thank you, after re-reading the docs I think I better understand > this. In a risk of being off-topic, maybe you can help me try the hpet support. When I try the hpet Documentation demo I get # ./hpet poll /dev/hpet 1 1000 -hpet: executing poll hpet_poll: info.hi_flags 0x0 hpet_poll, HPET_IE_ON failed while I have $ dmesg|grep -i HPET ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97) ACPI: HPET id: 0x8086a301 base: 0xfed0 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 64-bit timers, 14318180 Hz hpet_resources: 0xfed0 is busy Time: hpet clocksource has been installed. Any idea what I am misconfiguring? Thanks, Dan.
[Qemu-devel] Re: [kvm-devel] [PATCH] Dynamic ticks
Luca,
One more comment on your patch: the logic in the following condition
does not fit the comment bellow it.
On Mon, Aug 13, 2007 at 10:37:41PM +0200, Luca Tettamanti wrote:
> +if (use_dynamic_ticks() && dynticks_create_timer()) {
> +/* dynticks disabled or failed to create a timer, fallback
> + * to old code.
> + */
> +[old code follows]
One should have
if (!use_dynamic_ticks() || dynticks_create_timer()) {
Instead.
Regards,
Dan.
[Qemu-devel] Re: [PATCH] Dynamic ticks
On Mon, Aug 13, 2007 at 10:37:41PM +0200, Luca Tettamanti wrote: > > I like it ;) I have some comments (and a reworked patch at the end): > And thanks a lot for that. > > Plus, in this way you change the behaviour from "always try RTC under > Linux" to "don't use RTC is dynticks is enabled". > Is this what you really want? I don't know whether this is what should be done, but it's what I wanted. I was not looking for a dynamic-ticks solution for every available time source, and considered the system's POSIX timer as a good enough source. Am I wrong here?
[Qemu-devel] Re: [PATCH] Dynamic ticks
Thank you (Luca and Thiemo) for your prompt review and comments! On Tue, Aug 14, 2007 at 12:06:20AM +0100, Thiemo Seufer wrote: > Luca Tettamanti wrote: > [snip] > > I've implemented some of my suggestions in the following patch - rebased > > to kvm-userspace current git since it's easier to test (...ok, I'm lazy - > > but you get the idea): > > > > > > diff --git a/qemu/configure b/qemu/configure > > index 365b7fb..38373db 100755 > > --- a/qemu/configure > > +++ b/qemu/configure > > @@ -262,6 +262,8 @@ for opt do > >;; > >--enable-uname-release=*) uname_release="$optarg" > >;; > > + --disable-dynamic-ticks) dynamic_ticks="no" > > + ;; > > Is there a situation where the attempt to use dynticks is harmful? > Well, I cannot really say when and how much, but rearming the timer every shot has its price (especially when the guest is not idling). I thought that even just uselessly checking use_dynamic_ticks in every signal handler call would be frowned upon. Maybe you are right, and for the sake of code and build simplisity I should drop that ifdef altogether. Thanks, Dan.
[Qemu-devel] [PATCH] Dynamic ticks
"Dynamic ticks" in Qemu: have a SIGALRM generated only when it is
needed, instead of every 1 millisecond. This patch requires that the
host supports high resolution timers, since it arms a POSIX timer to the
nearest Qemu timer's expiry time (which might be rather near).
I tried to send a previous version of this patch yesterday, but luckily
it seems to have been eaten by qemu-devel list. I'd be happy to hear
your comments about it.
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.152
diff -u -r1.152 configure
--- configure 1 Aug 2007 00:09:31 - 1.152
+++ configure 13 Aug 2007 14:18:18 -
@@ -294,6 +294,8 @@
*) echo "undefined SPARC architecture. Exiting";exit 1;;
esac
;;
+ --disable-dynamic-ticks) dynamic_ticks="no"
+ ;;
esac
done
@@ -859,6 +861,9 @@
if [ "$build_docs" = "yes" ] ; then
echo "BUILD_DOCS=yes" >> $config_mak
fi
+if test "$dynamic_ticks" != "no" ; then
+ echo "#define DYNAMIC_TICKS 1" >> $config_h
+fi
# XXX: suppress that
if [ "$bsd" = "yes" ] ; then
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.323
diff -u -r1.323 vl.c
--- vl.c29 Jul 2007 17:57:25 - 1.323
+++ vl.c13 Aug 2007 14:18:19 -
@@ -793,6 +793,15 @@
/* frequency of the times() clock tick */
static int timer_freq;
#endif
+#ifdef DYNAMIC_TICKS
+/* If DYNAMIC_TICKS is defined (and use_dynamic_ticks selected) qemu does not
+ * attepmt to generate SIGALRM at a constant rate. Rather, the system timer is
+ * set to generate SIGALRM only when it is needed. DYNAMIC_TICKS reduces the
+ * number of SIGALRMs sent to idle dynamic-ticked guests. */
+static timer_t host_timer;
+static void rearm_host_timer(void);
+static int use_dynamic_ticks = 1;
+#endif
QEMUClock *qemu_new_clock(int type)
{
@@ -838,6 +847,10 @@
}
pt = &t->next;
}
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks)
+rearm_host_timer();
+#endif
}
/* modify the current timer so that it will be fired when current_time
@@ -897,6 +910,7 @@
/* run the callback (the timer list can be modified) */
ts->cb(ts->opaque);
}
+rearm_host_timer();
}
int64_t qemu_get_clock(QEMUClock *clock)
@@ -1004,7 +1018,12 @@
last_clock = ti;
}
#endif
-if (qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
+
+if (
+#ifdef DYNAMIC_TICKS
+use_dynamic_ticks ||
+#endif
+qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
qemu_get_clock(vm_clock)) ||
qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock))) {
@@ -1109,21 +1128,37 @@
act.sa_handler = host_alarm_handler;
sigaction(SIGALRM, &act, NULL);
-itv.it_interval.tv_sec = 0;
-itv.it_interval.tv_usec = 999; /* for i386 kernel 2.6 to get 1 ms */
-itv.it_value.tv_sec = 0;
-itv.it_value.tv_usec = 10 * 1000;
-setitimer(ITIMER_REAL, &itv, NULL);
-/* we probe the tick duration of the kernel to inform the user if
- the emulated kernel requested a too high timer frequency */
-getitimer(ITIMER_REAL, &itv);
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks) {
+struct sigevent ev;
+ev.sigev_value.sival_int = 0;
+ev.sigev_notify = SIGEV_SIGNAL;
+ev.sigev_signo = SIGALRM;
+if (timer_create(CLOCK_REALTIME, &ev, &host_timer))
+perror("timer_create");
+} else
+#endif /* DYNAMIC_TICKS */
+{
+itv.it_interval.tv_sec = 0;
+itv.it_interval.tv_usec = 999; /* for i386 kernel 2.6 to get 1 ms
*/
+itv.it_value.tv_sec = 0;
+itv.it_value.tv_usec = 10 * 1000;
+setitimer(ITIMER_REAL, &itv, NULL);
+/* we probe the tick duration of the kernel to inform the user if
+ the emulated kernel requested a too high timer frequency */
+getitimer(ITIMER_REAL, &itv);
+}
#if defined(__linux__)
/* XXX: force /dev/rtc usage because even 2.6 kernels may not
have timers with 1 ms resolution. The correct solution will
be to use the POSIX real time timers available in recent
2.6 kernels */
-if (itv.it_interval.tv_usec > 1000 || 1) {
+if (
+#ifdef DYNAMIC_TICKS
+!use_dynamic_ticks &&
+#endif
+(itv.it_interval.tv_usec > 1000 || 1)) {
/* try to use /dev/rtc to have a faster timer */
if (start_rtc_timer() < 0)
goto use_itimer;
@@ -6287,6 +6322,10 @@
cpu_enable_ticks();
vm_running = 1;
vm_state_notify(1);
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks)
+rearm_host_timer();
+#endif
}
[Qemu-devel] [PATCH] Dynamic ticks
"Dynamic ticks" in qemu: have a SIGALRM generated only when it is
needed, instead of every 1 millisecond. This patch requires that the
host supports high resolution timers, since it arms a POSIX timer to the
nearest Qemu timer's expiry time (which might be rather near).
Note that I raise a flag called dont_rearm_host_timer when I want to
inhibit redundant arming of the POSIX timer (see comment in sourcecode).
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.323
diff -u -r1.323 vl.c
--- vl.c29 Jul 2007 17:57:25 - 1.323
+++ vl.c12 Aug 2007 16:24:32 -
@@ -793,6 +793,16 @@
/* frequency of the times() clock tick */
static int timer_freq;
#endif
+#ifdef DYNAMIC_TICKS
+/* If DYNAMIC_TICKS is defined (and use_dynamic_ticks selected) qemu does not
+ * attepmt to generate SIGALRM at a constant rate. Rather, the system timer is
+ * set to generate SIGALRM only when it is needed. DYNAMIC_TICKS reduces the
+ * number of SIGALRMs sent to idle dynamic-ticked guests. */
+static timer_t host_timer;
+static void rearm_host_timer(void);
+static int dont_rearm_host_timer = 0;
+static int use_dynamic_ticks = 1;
+#endif
QEMUClock *qemu_new_clock(int type)
{
@@ -838,6 +848,10 @@
}
pt = &t->next;
}
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks)
+rearm_host_timer();
+#endif
}
/* modify the current timer so that it will be fired when current_time
@@ -846,6 +860,10 @@
{
QEMUTimer **pt, *t;
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks)
+dont_rearm_host_timer++;
+#endif
qemu_del_timer(ts);
/* add the timer in the sorted list */
@@ -863,6 +881,13 @@
ts->expire_time = expire_time;
ts->next = *pt;
*pt = ts;
+
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks) {
+dont_rearm_host_timer--;
+rearm_host_timer();
+}
+#endif
}
int qemu_timer_pending(QEMUTimer *ts)
@@ -886,6 +911,14 @@
{
QEMUTimer *ts;
+#ifdef DYNAMIC_TICKS
+/* callback functions that are run here may each try to rearm the timer. In
+ * oreder to avoid this, we raise the dont_rearm_host_timer flag.
+ * Alternatively, it is possible to go over all callback functions and make
+ * sure they do not call functions that rearm the system timer. */
+if (use_dynamic_ticks)
+dont_rearm_host_timer++;
+#endif
for(;;) {
ts = *ptimer_head;
if (!ts || ts->expire_time > current_time)
@@ -897,6 +930,12 @@
/* run the callback (the timer list can be modified) */
ts->cb(ts->opaque);
}
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks) {
+dont_rearm_host_timer--;
+rearm_host_timer();
+}
+#endif
}
int64_t qemu_get_clock(QEMUClock *clock)
@@ -1004,7 +1043,12 @@
last_clock = ti;
}
#endif
-if (qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
+
+if (
+#ifdef DYNAMIC_TICKS
+use_dynamic_ticks ||
+#endif
+qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
qemu_get_clock(vm_clock)) ||
qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock))) {
@@ -1102,28 +1146,44 @@
/* timer signal */
sigfillset(&act.sa_mask);
- act.sa_flags = 0;
+act.sa_flags = 0;
#if defined (TARGET_I386) && defined(USE_CODE_COPY)
act.sa_flags |= SA_ONSTACK;
#endif
act.sa_handler = host_alarm_handler;
sigaction(SIGALRM, &act, NULL);
-itv.it_interval.tv_sec = 0;
-itv.it_interval.tv_usec = 999; /* for i386 kernel 2.6 to get 1 ms */
-itv.it_value.tv_sec = 0;
-itv.it_value.tv_usec = 10 * 1000;
-setitimer(ITIMER_REAL, &itv, NULL);
-/* we probe the tick duration of the kernel to inform the user if
- the emulated kernel requested a too high timer frequency */
-getitimer(ITIMER_REAL, &itv);
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks) {
+struct sigevent ev;
+ev.sigev_value.sival_int = 0;
+ev.sigev_notify = SIGEV_SIGNAL;
+ev.sigev_signo = SIGALRM;
+if (timer_create(CLOCK_REALTIME, &ev, &host_timer))
+perror("timer_create");
+} else
+#endif /* DYNAMIC_TICKS */
+{
+itv.it_interval.tv_sec = 0;
+itv.it_interval.tv_usec = 999; /* for i386 kernel 2.6 to get 1 ms
*/
+itv.it_value.tv_sec = 0;
+itv.it_value.tv_usec = 10 * 1000;
+setitimer(ITIMER_REAL, &itv, NULL);
+/* we probe the tick duration of the kernel to inform the user if
+ the emulated kernel requested a too high timer frequency */
+getitimer(ITIMER_REAL, &itv);
+}
#if defined(__linux__)
/* XXX: force /dev/rtc usage because even 2.6 kernels may not
have timers wi
