Hi,
I'm using qemu at the moment to run a system for debugging purposes. I
was wondering whether qemu does actually emulate the performance
counters on IA32. Every time i try to read the value out, it
consistently gives me zero even though i have written to the given model
specific register.
Th
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
On Sunday 09 September 2007, Alain Knaff (qemu) wrote:
> Workaround:
>
> Putting the following into the script:
> exec 3>/dev/null
> exec 4>/dev/null
> exec 5>/dev/null
> exec 6>/dev/null
better yet: for i in {3..6}; do exec $i>&-; done
Filip Navara wrote:
> Not sure if this is usefull, but the Darwin network driver uses the "flow
> control" registers, so it's not good idea to bail out and stop the emulation
> if they're accessed. The registers aren't vital for the EEPRO 100 operation,
> so no harm in ignoring them.
Could you mak
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/09/10 00:10:04
Modified files:
target-i386: helper2.c
Log message:
Fix the reported xlevel for Intel CPU, by Filip Navara.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i3
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/09/10 00:07:46
Modified files:
. : block-vmdk.c
Log message:
Fix VMDK 2GB bug, by Filip Navara.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/block-vmdk.c?cvsroot=qemu&r
Qemu does not close its filedescriptors (or setting the FD_CLOEXEC) when
invoking the /etc/qemu-ifup script.
Hence any background process spawned from there (such as a dhcpd) will
also inherit the open filedescriptor, preventing the relevant decide
(/dev/net/tup) to be reused later on:
If fo
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/09/09 21:16:01
Modified files:
hw : usb-hid.c usb-uhci.c
Log message:
Implement HID idle mode (avoids flooding guest with useless updates).
Fix UHCI NACK bug.
CVSWeb URLs:
h
Paul Brook wrote:
What you really want to do is ask your virtualization module what
features it supports.
Yes, that needs to be an additional filter.
I'd have thought that would be the *only* interesting set for autodetection.
Yes, you're right. It's pointless to issue cpuid
> > What you really want to do is ask your virtualization module what
> > features it supports.
>
> Yes, that needs to be an additional filter.
I'd have thought that would be the *only* interesting set for autodetection.
Paul
Avi Kivity wrote:
> >I agree. If the host OS has disabled a feature, it's a fair bet it's done
> >that for a reason.
>
> The reason may not be relevant to the guest.
For most guests the relevant features are those which work correctly
and efficiently on the virtual CPU.
If the host OS has disab
Paul Brook wrote:
On Sunday 09 September 2007, Jamie Lokier wrote:
Avi Kivity wrote:
Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
host-os' on the first bug report? I have a feeling we won't ever see it.
In other words, host-os is what _I'd_ implement bec
On Sunday 09 September 2007, Jamie Lokier wrote:
> Avi Kivity wrote:
> > Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
> > host-os' on the first bug report? I have a feeling we won't ever see it.
>
> In other words, host-os is what _I'd_ implement because I care too
> much a
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 p
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
Jamie Lokier wrote:
Avi Kivity wrote:
Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
host-os' on the first bug report? I have a feeling we won't ever see it.
I have a feeling you won't ever see it either, but not because it's a
missing feature.
Instead, I think
Avi Kivity wrote:
> Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
> host-os' on the first bug report? I have a feeling we won't ever see it.
I have a feeling you won't ever see it either, but not because it's a
missing feature.
Instead, I think a very small number of user
Jamie Lokier wrote:
Avi Kivity wrote:
Well, the guest will invoke its own workaround logic to disable buggy
features, so I see no issue here.
The guest can only do this if it has exactly the correct id
information for the host processor (e.g. "This is an Intel Pentium Pro
model XXX"),
Avi Kivity wrote:
> Well, the guest will invoke its own workaround logic to disable buggy
> features, so I see no issue here.
The guest can only do this if it has exactly the correct id
information for the host processor (e.g. "This is an Intel Pentium Pro
model XXX"), not just the list of safe t
Jamie Lokier wrote:
Anthony Liguori wrote:
I like this idea but I have some suggestions about the general approach.
I think instead of defining another machine type, it would be better to
just have a command line option like -cpuid that took a comma separate
string of features with "all" mean
20 matches
Mail list logo
