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/ta
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/hel
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:1
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 informat
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 i
"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 ca
"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
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
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".
>
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
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 op
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
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
> > h
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 OEMHPE
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.
Wo
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
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->
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 p
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
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.
Anot
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"
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/1151
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
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 th
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.or
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
> m
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 forw
(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
+++ v
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 patc
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
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
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 re
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.
>
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 10064
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!
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, si
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 sim
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
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 cl
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 l
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_
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
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.
&
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
>
> Stil
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] << 2
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-&g
49 matches
Mail list logo
