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
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
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
+++
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
---
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
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
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
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
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
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
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
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
-cpu option for x86 (initial patch by Dan Kenigsberg)
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.89r2=1.90
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemur1=1.51r2=1.52
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c
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)?
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
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,
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
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
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
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
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:
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
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
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
(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
+++
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
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
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
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 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
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
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
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
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
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
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.
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
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
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...
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
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
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
42 matches
Mail list logo
