Public bug reported:
Hello,
I see the following when try to run qemu from master as the following:
# ./x86_64-softmmu/qemu-system-x86_64 --version
QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
#
tpr_shadow vnmi ept vpid
> bugs:
> bogomips: 6133.55
> clflush size: 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
> To manage notifications about this bug go to:
> https://bugs.lau
2017-02-06 22:38 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2017-02-06 21:05 GMT+03:00 Dr. David Alan Gilbert <dgilb...@redhat.com>:
>>>> So you didn't mention this was running inside VMWare; it looks to me as if
>>>> that's rejecting t
lm ida arat epb dtherm tpr_shadow vnmi ept vpid
> bugs:
> bogomips : 6133.55
> clflush size: 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
> To manage notifications about this bug go to:
>
at epb dtherm tpr_shadow vnmi ept vpid
> bugs:
> bogomips: 6133.55
> clflush size: 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
> To manage notifications about this bug go to:
>
bogomips: 6133.55
> clflush size: 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions
--
With best
pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor
> lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid
> bugs:
> bogomips: 6133.55
> clflush size: 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virt
** Attachment added: "dmesg"
https://bugs.launchpad.net/qemu/+bug/1661386/+attachment/4814179/+files/dmesg-4.0
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1661386
Title:
Assertion `ret ==
** Attachment added: "x86info.txt"
https://bugs.launchpad.net/qemu/+bug/1661386/+attachment/4815388/+files/x86info.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1661386
Title:
Assertion
** Attachment added: "dmesg-loglevel9"
https://bugs.launchpad.net/qemu/+bug/1661386/+attachment/4815387/+files/dmesg-loglevel9
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1661386
Title:
_tsc
> aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor
> lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid
> bugs:
> bogomips: 6133.55
> clflush size: 64
> cache_alignment : 64
> address sizes
Hi,
I've attached the files with logs you requested. Could you comment them
somehow?
x86info says that IA32_PERF is not enabled:
Performance MSRs:
MSR_IA32_PERF_STATUS: 0x0
MSR_IA32_MISC_ENABLE: 0x0 [Enabled: ]
--
You received this bug notification because you are a member of qemu-
se36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm
> constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc
> aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor
> lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid
> bugs:
> b
2017-07-23 12:54 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2017-02-08 11:49 GMT+03:00 Paolo Bonzini <bonz...@gnu.org>:
>>> Does qemu follow recommendations from section 4.3?
>>
>> All that QEMU does is initialize MSR values and QEMU is talking
Well, last_avail_idx equals to shadow_avail_idx and both of them are 1
at the qemu side. So, only one request is transferred.
I wonder why, probably something is badly cached, but new avail_idx
(which is supposed to become 2) is never shown up.
2018-02-20 15:49 GMT+03:00 Matwey V. Kornilov
The same story with 4.15.4 host kernel.
2018-02-21 11:58 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> Well, last_avail_idx equals to shadow_avail_idx and both of them are 1
> at the qemu side. So, only one request is transferred.
> I wonder why, probably something
Well, I've found that on qemu side VirtQueue for virtio_blk device
infinitely calls virtio_blk_handle_vq() where virtio_blk_get_request()
(virtqueue_pop() in essens) always returns NULL.
2018-02-18 15:26 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> ** Attachm
virtqueue_pop() returns NULL due to virtio_queue_empty_rcu() returns
true all the time.
2018-02-20 14:47 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> Well, I've found that on qemu side VirtQueue for virtio_blk device
> infinitely calls virtio_blk_handl
Hi,
Sorry in advance, if wrong maillist.
Where may I find comprehensive description how virtualization CPU
extensions (like VMX) interact with CPU data caches as well as
corresponding qemu implementation details? I've looked through
memory_ldst.inc.c with little success.
I am trying to debug
Public bug reported:
Hello,
I am running qemu from master git branch on x86_64 host with kernel is
4.4.114. I've found that commit
9a4c0e220d8a "hw/virtio-pci: fix virtio behaviour"
introduces an regression with the following command:
qemu-system-x86_64 -enable-kvm -nodefaults
** Attachment added: ".build.initrd.kvm"
https://bugs.launchpad.net/qemu/+bug/1750229/+attachment/5057654/+files/.build.initrd.kvm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1750229
Title:
** Attachment added: ".build.kernel.kvm"
https://bugs.launchpad.net/qemu/+bug/1750229/+attachment/5057653/+files/.build.kernel.kvm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1750229
Title:
I've also check qemu-arm with the same test code. Surprisingly, I see
correct result:
pwrite ret = 0
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810433
Title:
aarch64-linux-user master:
gt;
>return 0;
> }
>
>
> Please note, that the same binary executable prints different output at
> native aarch64 platform and under aarch64-linux-user
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1810433/+subscriptions
Hello,
I am running the same application compiled for aarch64 and armv7l on
x86_64 platform using qemu-user-linux tools.
I see dramatic performance difference (30 times) between emulated
architectures: aarch64 runs for ~4 minutes, armv7l runs for ~2 hours.
I do understand that CPU architecture
** Attachment added: "Test case source file"
https://bugs.launchpad.net/qemu/+bug/1810433/+attachment/5226714/+files/main.c
** Description changed:
Hello,
I am running aarch64-linux-user from master, commit
20d6c7312f1b812bb9c750f4087f69ac8485cc90
And I've found the following
Public bug reported:
Hello,
I am running aarch64-linux-user from master, commit
20d6c7312f1b812bb9c750f4087f69ac8485cc90
And I've found the following inconsistent emulation of pwrite() call when
buf==NULL and len=0.
Minimal reproducible sample is the following:
#define _GNU_SOURCE
#include
** Attachment added: "Test binary statically compiled for aarch64"
https://bugs.launchpad.net/qemu/+bug/1810433/+attachment/5226715/+files/pwrite_test.aarch64
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
This has been fixed in the kernel
** 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/1750229
Title:
virtio-blk-pci regression: softlock in guest
Do you know how to fix it?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810433
Title:
aarch64-linux-user master: inconsistent pwrite behaviour
Status in QEMU:
New
Bug description:
Hello,
пт, 11 янв. 2019 г. в 12:52, Peter Maydell :
>
> On Thu, 10 Jan 2019 at 19:33, Matwey V. Kornilov
> wrote:
> > I am running the same application compiled for aarch64 and armv7l on
> > x86_64 platform using qemu-user-linux tools.
> >
> > I see dramatic performa
пт, 11 янв. 2019 г. в 22:24, Matwey V. Kornilov :
>
> пт, 11 янв. 2019 г. в 12:52, Peter Maydell :
> >
> > On Thu, 10 Jan 2019 at 19:33, Matwey V. Kornilov
> > wrote:
> > > I am running the same application compiled for aarch64 and armv7l on
> > > x
It would be great if you could fix it.
Also, there are probably should exist POSIX conformance test suites
around the world. As far as I understand, this particular issue could be
found by running such a test under qemu-linux-user. I mean what if there
are other similar issues?
--
You received
пн, 14 янв. 2019 г. в 13:24, Peter Maydell :
>
> On Sun, 13 Jan 2019 at 07:31, Matwey V. Kornilov
> wrote:
> >
> > пт, 11 янв. 2019 г. в 22:24, Matwey V. Kornilov :
> > > Indeed, qemu-arm from master runs for 4 minutes where 2.11 runs for 2
> > > hou
: 6133.55
> clflush size : 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management:
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions
--
With best regards,
Matwe
35 matches
Mail list logo
