On 26/4/23 12:59, Paolo Bonzini wrote:
On 4/25/23 15:38, Thomas Huth wrote:
- CPU types have different suffixes between the -x86_64 and -i386
variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
about this in the new qemu-system-i386 symlink run mode?
- The code in target/i386
Hi,
did you compile on yourself? Downloaded from some website?
Regards,
Frediano
Il giorno dom 29 ott 2023 alle ore 20:13 Joachim Roden
ha scritto:
<<< text/html; charset=UTF-8: Unrecognized >>>
On 25/4/23 15:38, Thomas Huth wrote:
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. And with
the 32-bit x86 host support being deprecated now, it is possible to
deprecate the qemu-system-i386 binary now, too
gt; I wonder if we should take this a step further and rename
> > > > > qemu-system-x86_64
> > > > > to qemu-system-x86! Distros can if they wish create symlinks to both
> > > > > qemu-system-i386 and qemu-system-x86_64.
> > > >
> &g
create symlinks to both
qemu-system-i386 and qemu-system-x86_64.
I can't help feeling this just creates a new upgrade burden for distros
for no obvious win.
We can create the symlinks on install as well during the deprecation
period. It doesn't have to be done by distros.
What's the actual win
create symlinks to both
qemu-system-i386 and qemu-system-x86_64.
I can't help feeling this just creates a new upgrade burden for distros
for no obvious win.
We can create the symlinks on install as well during the deprecation
period. It doesn't have to be done by distros.
What's the actual win
they wish create symlinks to both
> > > qemu-system-i386 and qemu-system-x86_64.
> >
> > I can't help feeling this just creates a new upgrade burden for distros
> > for no obvious win.
>
> We can create the symlinks on install as well during the deprecation
> period.
On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé wrote:
> > I wonder if we should take this a step further and rename qemu-system-x86_64
> > to qemu-system-x86! Distros can if they wish create symlinks to both
> > qemu-system-i386 and qemu-system-x86_64.
>
> I can'
On Wed, Apr 26, 2023 at 12:59:13PM +0200, Paolo Bonzini wrote:
> On 4/25/23 15:38, Thomas Huth wrote:
> > - CPU types have different suffixes between the -x86_64 and -i386
> >variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
> >about this in the new qem
On 4/27/23 10:13, Thomas Huth wrote:
On 26/04/2023 12.59, Paolo Bonzini wrote:
On 4/25/23 15:38, Thomas Huth wrote:
- CPU types have different suffixes between the -x86_64 and -i386
variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
about this in the new qemu-system-i386
On 26/04/2023 12.59, Paolo Bonzini wrote:
On 4/25/23 15:38, Thomas Huth wrote:
- CPU types have different suffixes between the -x86_64 and -i386
variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
about this in the new qemu-system-i386 symlink run mode?
- The code in target
On 4/25/23 15:38, Thomas Huth wrote:
- CPU types have different suffixes between the -x86_64 and -i386
variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
about this in the new qemu-system-i386 symlink run mode?
- The code in target/i386/tcg/sysemu/smm_helper.c looks like
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. And with
the 32-bit x86 host support being deprecated now, it is possible to
deprecate the qemu-system-i386 binary now, too.
With regards to 32-bit KVM support
Allow running qemu-system-x86_64 in 32-bit-only mode (by renaming
or symlinking the binary to "qemu-system-i386"). After doing this,
qemu-system-x86_64 should be a proper superset of qemu-system-i386
(apart from 32-bit KVM support, which however is not really required
anymore,
386/cpu.c
> > > > around line 637:
> > > >
> > > > #ifdef TARGET_X86_64
> > > > #define TCG_EXT2_X86_64_FEATURES (CPUID_EXT2_SYSCALL | CPUID_EXT2_LM)
> > > > #else
> > > > #define TCG_EXT2_X86_64_FEATURES 0
> > >
oming from in the code.
I think I just spotted this by accident in target/i386/cpu.c
around line 637:
#ifdef TARGET_X86_64
#define TCG_EXT2_X86_64_FEATURES (CPUID_EXT2_SYSCALL | CPUID_EXT2_LM)
#else
#define TCG_EXT2_X86_64_FEATURES 0
#endif
Hmm, so right now the difference between qemu-system-i386 and
q
gt; > > coming from in the code.
> > >
> > > I think I just spotted this by accident in target/i386/cpu.c
> > > around line 637:
> > >
> > > #ifdef TARGET_X86_64
> > > #define TCG_EXT2_X86_64_FEATURES (CPUID_EXT2_SYSCALL | CPUID_EXT2_LM)
&
oming from in the code.
I think I just spotted this by accident in target/i386/cpu.c
around line 637:
#ifdef TARGET_X86_64
#define TCG_EXT2_X86_64_FEATURES (CPUID_EXT2_SYSCALL | CPUID_EXT2_LM)
#else
#define TCG_EXT2_X86_64_FEATURES 0
#endif
Hmm, so right now the difference between qemu-system-i38
I've not figured out where that difference is
> > coming from in the code.
>
> I think I just spotted this by accident in target/i386/cpu.c
> around line 637:
>
> #ifdef TARGET_X86_64
> #define TCG_EXT2_X86_64_FEATURES (CPUID_EXT2_SYSCALL | CPUID_EXT2_LM)
> #else
>
On 06/03/2023 10.27, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
[...] If a 32-bit CPU guest
+environment should be enforced, you can switch off the "long mode" CPU
+flag, e.g. with ``-cpu max,lm=off``.
I had the idea to check this today and this is
proper superset of the qemu-system-i386 binary. With the
> > > 32-bit host support being deprecated, it is now also possible to
> > > deprecate the qemu-system-i386 binary.
> > >
> > > With regards to 32-bit KVM support in the x86 Linux kernel,
> > > t
On 06/03/2023 10.27, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. With the
32-bit host support being deprecated, it is now
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
> Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
> binary is a proper superset of the qemu-system-i386 binary. With the
> 32-bit host support being deprecated, it is now also possible to
> deprecate the
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. With the
32-bit host support being deprecated, it is now also possible to
deprecate the qemu-system-i386 binary.
With regards to 32-bit KVM support in the x86 Linux
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. With the
32-bit host support being deprecated, it is now also possible to
deprecate the qemu-system-i386 binary.
With regards to 32-bit KVM support in the x86 Linux
2-bit variant now, so that we can finally stop wasting our
> > time
> > and CI minutes with this.
>
> The first sentence isn't quite true wrt to KVM. Change slightly to:
>
> Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
> binary is a proper supers
d CI minutes with this.
The first sentence isn't quite true wrt to KVM. Change slightly to:
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. With the
32-bit host support being deprecated, it is now also possible to
deprecate the
,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 12
1 file changed, 12 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs
On 2/27/23 23:00, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote:
Removing support for building on 32 bit systems seems like a pity - it's
one of a small number of ways to run 64 bit binaries on 32 bit systems,
and the maintainance overhead is quite
host support, and for qemu-system-i386 emulator binary, as
although they're related they are independant features with
differing impact. eg removing qemu-system-i386 affects all
host architectures, not merely 32-bit x86 host, so I think we
can explain the impact more clearly if we separate them
On Tue, Feb 28, 2023 at 12:34:19PM +0100, Markus Armbruster wrote:
> If it's not worth arguing, then we merge Thomas's patch.
I don't mind but it's just a doc patch isn't it? If what we want to do
is to stop doing make check on a 32 bit container and just to do
make then let's patch the relevant
"Michael S. Tsirkin" writes:
> On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
>> The question to answer: Is 32 bit x86 worth its upkeep? Two
>> sub-questions: 1. Is it worth the human attention? 2. Is it worth
>> (scarce!) CI minutes?
>
> 3. Is it worth arguing about?
If
On Tue, Feb 28, 2023 at 06:24:02AM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 28, 2023 at 12:12:22PM +0100, Thomas Huth wrote:
> > On 28/02/2023 11.51, Michael S. Tsirkin wrote:
> > > On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
> > > > The question to answer: Is 32 bit
On Tue, Feb 28, 2023 at 12:12:22PM +0100, Thomas Huth wrote:
> On 28/02/2023 11.51, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
> > > The question to answer: Is 32 bit x86 worth its upkeep? Two
> > > sub-questions: 1. Is it worth the human
On 28/02/2023 11.51, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
The question to answer: Is 32 bit x86 worth its upkeep? Two
sub-questions: 1. Is it worth the human attention? 2. Is it worth
(scarce!) CI minutes?
3. Is it worth arguing about?
On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
> The question to answer: Is 32 bit x86 worth its upkeep? Two
> sub-questions: 1. Is it worth the human attention? 2. Is it worth
> (scarce!) CI minutes?
3. Is it worth arguing about?
--
MST
;> > > > > > > On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé
>> > > > > > > wrote:
>> > > > > > > > I feel like we should have separate deprecation entries for the
>> > > > > > > > i68
, Daniel P. Berrangé
> > > > > > > wrote:
> > > > > > > > I feel like we should have separate deprecation entries for the
> > > > > > > > i686 host support, and for qemu-system-i386 emulator binary, as
> > > >
ue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
> > > > > On 27/02/2023 21.12, Michael S. Tsirkin wrote:
> > > > > > On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> > > > > > > I feel like we should have separate d
:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary, as
although they're related they are independant features with
differing impact. eg removing qemu-system
on, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> > > > > I feel like we should have separate deprecation entries for the
> > > > > i686 host support, and for qemu-system-i386 emulator binary, as
> > > > > although they're related they
On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote:
> > Removing support for building on 32 bit systems seems like a pity - it's
> > one of a small number of ways to run 64 bit binaries on 32 bit systems,
> > and the maintainance overhead is quite small.
>
> It's not that small.
host support, and for qemu-system-i386 emulator binary, as
> > > although they're related they are independant features with
> > > differing impact. eg removing qemu-system-i386 affects all
> > > host architectures, not merely 32-bit x86 host, so I think we
> &g
gt; I feel like we should have separate deprecation entries for the
> > > > i686 host support, and for qemu-system-i386 emulator binary, as
> > > > although they're related they are independant features with
> > > > differing impact. eg removing qemu-system-i386 affect
upport, and for qemu-system-i386 emulator binary, as
> > > although they're related they are independant features with
> > > differing impact. eg removing qemu-system-i386 affects all
> > > host architectures, not merely 32-bit x86 host, so I think we
> &g
KVM support in the x86 Linux kernel,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 13 +
1 file changed, 13 insertions
On 27/02/2023 21.12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary, as
although they're related they are independant
On 27/02/2023 23.32, Philippe Mathieu-Daudé wrote:
On 27/2/23 21:12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary
On 27/2/23 21:12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary, as
although they're related they are independant features
,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs
On 2/27/23 10:12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary, as
although they're related they are independant features
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> I feel like we should have separate deprecation entries for the
> i686 host support, and for qemu-system-i386 emulator binary, as
> although they're related they are independant features with
> differing impact. eg r
do not need a recent
> qemu-system-i386 binary here:
>
> https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
>
> Signed-off-by: Thomas Huth
> ---
> docs/about/deprecated.rst | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/docs/about/
Hardly anybody still uses 32-bit x86 hosts today, so we should
start deprecating them to finally have less test efforts.
With regards to 32-bit KVM support in the x86 Linux kernel,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y
He Zhe writes:
(Cc: Paolo)
> Hi All,
>
> We are experiencing a general protection fault with qemu-system-i386 as
> follow.
> This can be reproduced with kernel v5.15 and latest v6.2-rc3 as we found so
> far.
>
> It would work well i
Hi All,
We are experiencing a general protection fault with qemu-system-i386 as follow.
This can be reproduced with kernel v5.15 and latest v6.2-rc3 as we found so far.
It would work well if we reverted the commit
2f8a21d8ff3af484a37edc8ea61d127ec1529ab5 ("target/i386: Enable AVX cpuid
e
> > > locally, but am unable to:
> > >
> > > $ uname -a
> > > Linux server 6.0.15-default #1 SMP PREEMPT_DYNAMIC Sat Dec 31 07:52:52 CET
> > > 2022 x86_64 x86_64 x86_64 GNU/Linux
> > > $ linux32 chroot .
> > > $ uname -a
> > &
2022 i686 GNU/Linux
$ cd qemu
$ file ./build/qemu-system-i386
./build/qemu-system-i386: ELF 32-bit LSB shared object, Intel 80386, version
1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux
3.2.0, BuildID[sha1]=f75e20572be5c604c121de4497397665c168aa4c, with
debug_info
ot .
> $ uname -a
> Linux server 6.0.15-default #1 SMP PREEMPT_DYNAMIC Sat Dec 31 07:52:52 CET
> 2022 i686 GNU/Linux
> $ cd qemu
> $ file ./build/qemu-system-i386
> ./build/qemu-system-i386: ELF 32-bit LSB shared object, Intel 80386, version
> 1 (SYSV), dynamically linked
6.0.15-default #1 SMP PREEMPT_DYNAMIC Sat Dec 31 07:52:52
CET 2022 x86_64 x86_64 x86_64 GNU/Linux
$ linux32 chroot .
$ uname -a
Linux server 6.0.15-default #1 SMP PREEMPT_DYNAMIC Sat Dec 31 07:52:52
CET 2022 i686 GNU/Linux
$ cd qemu
$ file ./build/qemu-system-i386
./build/qemu-system-i386: ELF
t; > QEMU 7.2.0 when run on 32-bit x86 architecture fails with:
> >
> > i586$ qemu-system-i386 -enable-kvm
> > qemu-system-i386: Could not install MSR_CORE_THREAD_COUNT handler: Success
> > i586$ qemu-system-x86_64 -enable-kvm
> > qemu-system-x86_64: Could not insta
t; i586$ qemu-system-i386 -enable-kvm
> qemu-system-i386: Could not install MSR_CORE_THREAD_COUNT handler: Success
> i586$ qemu-system-x86_64 -enable-kvm
> qemu-system-x86_64: Could not install MSR_CORE_THREAD_COUNT handler: Success
>
> Minimal reproducer is `qemu-system-i386 -
Hi,
QEMU 7.2.0 when run on 32-bit x86 architecture fails with:
i586$ qemu-system-i386 -enable-kvm
qemu-system-i386: Could not install MSR_CORE_THREAD_COUNT handler: Success
i586$ qemu-system-x86_64 -enable-kvm
qemu-system-x86_64: Could not install MSR_CORE_THREAD_COUNT handler: Success
255 + 1))} QTEST_QEMU_IMG=./qemu-img
> G_TEST_DBUS_DAEMON=/home/peter.maydell/qemu/tests/dbus-vmstate-daemon.sh
> QTEST_QEMU_BINARY=./qemu-system-i386
> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon
> tests/qtest/qos-test --tap -k' &&
> MALLOC_PERTURB_=${MALL
>
> > I think from grep that this must be the vhost-user-blk test.
>
> I've also now seen this on qemu-system-i386 guest x86-64 Linux host:
Your two stack traces look very different to me, the common thing is
just that one process requests something and the other seems to have
ignored it and
ll wrote:
>>>
>>>I've noticed recently that intermittently 'make check' will hang on
>>>my aarch32 test system (really an aarch64 box with an aarch32 chroot).
>>>
>>>I think from grep that this must be the vhost-user-blk test.
>>
>>I've also
gt;>I've noticed recently that intermittently 'make check' will hang on
> >>>my aarch32 test system (really an aarch64 box with an aarch32 chroot).
> >>>
> >>>I think from grep that this must be the vhost-user-blk test.
> >>
> >>I've also now s
cpu usage when guest is idle on qemu-system-i386
Status in QEMU:
Expired
Bug description:
When running Windows XP in qemu-system-i386, the cpu usage of QEMU is
about 100% even when the guest CPU usage is close to 2%. The host cpu
usage should be low when the guest cpu usage is low.
Comm
with an aarch32 chroot).
I think from grep that this must be the vhost-user-blk test.
I've also now seen this on qemu-system-i386 guest x86-64 Linux host:
Good to to know that! This makes it much easier for me to debug this
issue.
Which i386 image do you use for the guest? Could you share
be the vhost-user-blk test.
I've also now seen this on qemu-system-i386 guest x86-64 Linux host:
Good to to know that! This makes it much easier for me to debug this
issue.
Process tree:
petmay01 28992 0.0 0.0 123812 8612 ?Sl 14:46 0:01
\_ tests/qtest/qos
use I
couldn't find the right magic to boot off the debian cdrom with kvm.
Thanks for the instructions! Since this issue is also reproducible on
qemu-system-i386 guest x86-64 Linux host according to Peter's new email,
I'll check it on i386 guest first.
r~
--
Best regards,
Coiby
14:46 0:00
| \_ ./qemu-system-i386 -qtest
unix:/tmp/qtest-28992.sock -qtest-log /dev/null -chardev
socket,path=/tmp/qtest-28992.qmp,id=char0 -mon
chardev=char0,mode=control -display none -M pc -device
vhost-user-blk-pci,id=drv0,chardev=char1,addr=4.0 -object
memory-backend-memfd,id=mem,
On 7/11/21 7:21 AM, Peter Maydell wrote:
On Sun, 11 Jul 2021 at 14:23, Richard Henderson
wrote:
I believe that I had to perform the install under tcg because I couldn't find
the right
magic to boot off the debian cdrom with kvm.
Weird, it ought not in theory to care...
Looking back at the
On Sun, 11 Jul 2021 at 14:23, Richard Henderson
wrote:
> I believe that I had to perform the install under tcg because I couldn't find
> the right
> magic to boot off the debian cdrom with kvm.
Weird, it ought not in theory to care...
-- PMM
On 7/11/21 5:16 AM, Peter Maydell wrote:
On Sun, 11 Jul 2021 at 13:10, Coiby Xu wrote:
Hi Peter,
On Sat, Jul 10, 2021 at 02:30:36PM +0100, Peter Maydell wrote:
I've noticed recently that intermittently 'make check' will hang on
my aarch32 test system (really an aarch64 box with an aarch32
On Sun, 11 Jul 2021 at 13:10, Coiby Xu wrote:
>
> Hi Peter,
>
> On Sat, Jul 10, 2021 at 02:30:36PM +0100, Peter Maydell wrote:
> >I've noticed recently that intermittently 'make check' will hang on
> >my aarch32 test system (really an aarch64 box with an aarch32 chroot).
>
> I have a newbie
-daemon.sh
QTEST_QEMU_BINARY=./qemu-system-i386
QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon
tests/qtest/qos-test --tap -k' &&
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
QTEST_QEMU_IMG=./qemu-img
G_TEST_DBUS_DAEMON=/home/peter.maydell/qemu/te
-daemon.sh
QTEST_QEMU_BINARY=./qemu-system-i386
QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon
tests/qtest/qos-test --tap -k' &&
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
QTEST_QEMU_IMG=./qemu-img
G_TEST_DBUS_DAEMON=/home/peter.maydell/qemu/tests/dbus
emu-system-i386/x86_64 crash with 1 MB guest RAM
Status in QEMU:
Expired
Bug description:
When launching qemu-system-i386 or qemu-system-x86_64 with 1 MB of RAM
allocated to the guest (-m 1) and no guest image specified, QEMU will
crash while trying to "execute code outside of RAM or RO
emu-system-i386 eats a lot of cpu after just few hours, with
sdl,gl=on
Status in QEMU:
Expired
Bug description:
I already send this email to qemu-disc...@nongnu.org , but I can't see
it arriving in archives, so here is copy.
Hello, all!
I use qemu-system-i386/qemu-system_x86
Bug watch added: gitlab.com/qemu-project/qemu/-/issues #302
https://gitlab.com/qemu-project/qemu/-/issues/302
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913510
Title:
[Fuzz] qemu-system-i386 vir
red
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #300
https://gitlab.com/qemu-project/qemu/-/issues/300
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1908062
Title:
qemu-system-i386 vir
QEMU.
https://bugs.launchpad.net/bugs/1914667
Title:
High cpu usage when guest is idle on qemu-system-i386
Status in QEMU:
Incomplete
Bug description:
When running Windows XP in qemu-system-i386, the cpu usage of QEMU is
about 100% even when the guest CPU usage is close to 2%. The host cpu
QEMU.
https://bugs.launchpad.net/bugs/1908062
Title:
qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached
failed again
Status in QEMU:
Incomplete
Bug description:
When I was fuzzing virtio-vga device of the latest QEMU (1758428, Dec
12, built with --enable-sanitizers --e
n: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525
Title:
qemu-system-i386 eats a lot of cpu after just few hours, with
sdl,gl=on
Status in QEMU:
n: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1587211
Title:
qemu-system-i386/x86_64 crash with 1 MB guest RAM
Status in QEMU:
Incomplete
Bug des
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1914667
Title:
High cpu usage when guest is idle on qemu-system-i386
Status in QEMU:
New
Bug description:
When running Windows XP in qemu-system-i386, t
> On Feb 5, 2021, at 4:08 PM, Programmingkid wrote:
>
>
>
>> On Feb 5, 2021, at 3:49 PM, Michael S. Tsirkin wrote:
>>
>> On Fri, Feb 05, 2021 at 03:25:00PM -0500, Programmingkid wrote:
>>> Hi, I'm noticing that my Windows XP Service Pack 3 VM is caus
which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1914667
Title:
High cpu usage when guest is idle on qemu-system-i386
Status in QEMU:
New
Bug description:
When running Windows XP in qemu-system-i386, the cpu usage of QEMU is
about 100% even when the guest CPU usage is close
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1861946
Title:
qemu-4.2.0 qemu-system-i386 not receive scancode 86 of spanish
keybo
On Fri, Feb 05, 2021 at 04:08:26PM -0500, Programmingkid wrote:
>
>
> > On Feb 5, 2021, at 3:49 PM, Michael S. Tsirkin wrote:
> >
> > On Fri, Feb 05, 2021 at 03:25:00PM -0500, Programmingkid wrote:
> >> Hi, I'm noticing that my Windows XP Service Pack 3 VM
The qemu 5.1.0 version solved this problem.
Bug solved.
Many Thanks to qemu group and Stefan Weil.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1861946
Title:
qemu-4.2.0 qemu-system-i386
> On Feb 5, 2021, at 3:49 PM, Michael S. Tsirkin wrote:
>
> On Fri, Feb 05, 2021 at 03:25:00PM -0500, Programmingkid wrote:
>> Hi, I'm noticing that my Windows XP Service Pack 3 VM is causing
>> qemu-system-i386 to experience 100% host cpu usage even when the gu
For version 5.2 of qemu-system-i386 the instruction the guest is busy
executing over and over again is this: addb %al, (%eax)
For version 2.10.1 this is the instruction that is being executed when the
guest is idle:
add %al,(%eax)
--
You received this bug notification because you are a member
% and the host usage was around 14%.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1914667
Title:
High cpu usage when guest is idle on qemu-system-i386
Status in QEMU:
New
Bug description:
When running
Public bug reported:
When running Windows XP in qemu-system-i386, the cpu usage of QEMU is
about 100% even when the guest CPU usage is close to 2%. The host cpu
usage should be low when the guest cpu usage is low.
Command: qemu-system-i386 -hda
Using this command also shows around 100% host
Public bug reported:
--[ Reproducer
cat << EOF | ./build/qemu-system-i386 -machine q35,accel=qtest -nodefaults \
-device virtio-mouse -display none -qtest stdio
outl 0xcf8 0x8820
outl 0xcfc 0xe0004000
outl 0xcf8 0x8804
outb 0xcfc 0x02
write 0xe000400c 0x4 0x003fe62e
write 0xe00040
** Tags added: fuzzer
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1908062
Title:
qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached
failed again
Status in QEMU:
New
Bug
emu system i386 poor performance on e5500 core
Status in QEMU:
Expired
Bug description:
I had been tested with generic core net building or with mtune e5500 but i
have the same result: performances
are extremly low compared with other classes of powerpc cpu.
The strange is the 5020 2ghz in
1 - 100 of 189 matches
Mail list logo
