- Original Message -
> From: "Cédric Le Goater"
> To: "Alexey Kardashevskiy" , "Alex Williamson"
> , "Timothy Pearson"
>
> Cc: "l...@suse.de:PowerPC" , "qemu-devel"
> , "Frederic Barrat"
>
Correction -- the desynchronization appears to be on the DisINTx line.
Host:
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- From: "
All,
I've been struggling for some time with what is looking like a potential bug in
QEMU/KVM on the POWER9 platform. It appears that in XIVE mode, when the
in-kernel IRQ chip is enabled, an external device that rapidly asserts IRQs via
the legacy INTx level mechanism will only receive one
Public bug reported:
When attempting to pass a Vega 56 GPU to a virtualized guest using QEMU
3.1 on ppc64el (POWER9), the guest is unable to initialize the GPU.
Further digging reveals the driver attempting to allocate a large BAR,
which then fails:
[6.058544] [drm] PCI I/O BAR is not found.
Is this the correct place to file kvm-pr bug reports?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738691
Title:
Guest kernel crashes with kvm_pr on POWER8
Status in QEMU:
New
Bug
Public bug reported:
When attempting to use the kvm_pr module with QEMU 2.10 on a POWER8
host, Debian and Ubuntu guests hang and show crashes.
Host kernel is 4.14. Issue is observed with host kernels 4.9 and 4.13
as well; no other host kernels were tested.
Is this the correct place to report a
Public bug reported:
MTTCG support is notably absent for x86_64 guests. The last Wiki update
on MTTCG was back in 2015, and I am having some difficulty determining
the current status of the underlying requirements to enable this feature
on x86 hosts.
For instance, has support for strong-on-weak
Nope, looks good here. As a note to other commenters, this won't work
unless you are using a kernel compiled with the 4k page size -- default
for PPC64 is 64k.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Public bug reported:
qemu-x86_66 GIT HEAD fails on a userspace application that requires
memfd_create with:
"qemu: Unsupported syscall: 319".
memfd_create support needs to be implemented in QEMU.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug
| 148 +++
> 43 files changed, 7107 insertions(+), 776 deletions(-)
> create mode 100644 tcg/aarch64/tcg-target.opc.h
> create mode 100644 tcg/i386/tcg-target.opc.h
> create mode 100644 tcg/tcg-gvec-desc.h
> create mode 100644 tcg/tcg-op-gvec.h
> create mode 100644 accel/tcg/tcg-runtime-gvec.c
> create mode 100644 tcg/tcg-op-gvec.c
> create mode 100644 tcg/tcg-op-vec.c
>
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
Public bug reported:
When attempting to run wineserver on a 64-bit ppc64el host via QEMU's
user-mode i386 emulation, a file locking operation fails.
Command line:
qemu-i386-static /usr/lib/wine-development/wineserver32
Output:
wineserver: fcntl /tmp/.wine-0/server-17-14d21bf/lock: Invalid
Still seeing this issue. Only seems to happen with 4K pages on the
host. Any further debugging I could try?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1629618
Title:
QEMU causes host hang /
Unfortunately, the machine just crashed again. It seems related to the
use of 4K pages instead of the more typical 64K pages; the machine is
rock solid with 64K pages.
** Changed in: qemu
Status: Fix Released => New
--
You received this bug notification because you are a member of qemu-
After running 4.8 for the past week or so I think I can state the
problem is resolved at this point. The machine has not hard reset once
since the update, even after numerous host and VM reboots.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification
Host QEMU version: 1:2.6+dfsg-3.1
Host kernel version: 4.6.0
** Description changed:
QEMU causes a host hang / reset on PPC64EL when used in KVM + HV mode
(kvm_hv module).
After a random amount of uptime, starting new QEMU virtual machines will
cause the host to experience a soft CPU
Public bug reported:
QEMU causes a host hang / reset on PPC64EL when used in KVM + HV mode
(kvm_hv module).
After a random amount of uptime, starting new QEMU virtual machines will
cause the host to experience a soft CPU lockup. Depending on
configuration and other random factors the host will
** Attachment added: "Screenshot showing problem is also present in kernel
framebuffer mode"
https://bugs.launchpad.net/qemu/+bug/1546680/+attachment/4707706/+files/centos-big-endian-display-color-problem-kernel-framebuffer-fedora-24.png
--
You received this bug notification because you are
QEMU emulator version 2.6.0 (Debian 1:2.6+dfsg-3), Copyright (c)
2003-2008 Fabrice Bellard
qemu-system-ppc64 --enable-kvm -M pseries -cpu host -m 3G -cdrom Fedora-
Server-dvd-ppc64-24-1.2.iso
Fedora 24 Server
--
You received this bug notification because you are a member of qemu-
devel-ml,
Sounds very relevant, yes. Thanks for the link!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1594394
Title:
Using setreuid / setegid crashes x86_64 user-mode target
Status in QEMU:
New
Bug
I mostly filed the bug report since I was seeing multiple different
attempts to implement this, and even a proper patch series on the
mailing list, but no movement at all toward integrating this feature
into mainline qemu.
What would be needed to e.g. make the patch series on the mailing list
Public bug reported:
When setreuid() or setegid() are called from x86_64 target code in user
mode, qemu crashes inside the NPTL signal handlers. x86 targets do not
directly use a syscall to handle setreuid() / setegid(); instead the x86
NPTL implementation sets up a temporary data region in
Public bug reported:
SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are
translated to scalar instructions on the host instead of SIMD
instructions. It appears that there have been a few efforts to rectify
this [1], and even a submitted patch series, but all discussion has
1. It will only work with open drivers as their IOCTLs are documented.
2. i965+ is only supported. That is any haswell, ivybridge, etc. GPU will work.
3. X doesn't start yet, though this patch eliminates all the visible
unsupported DRM IOCTL calls as observed by setting QEMU_STRACE=1.
4. Intel
Note that x86_64 systems only offer the _rt signal handler variants,
so the legacy signal handlers remain unimplemented on this platform.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/signal.c | 302 +++-
Patch series sent to mailing list here:
http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05334.html
In particular, this patch handles the original signal handler problem:
http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05335.html
** Changed in: qemu
Status: New => In
This matches the calling conventions in the Linux kernel and
resolves select() hangs on i386/x86_64 guests.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/syscall.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b
Tested with ExtremeTuxRacer in guest with HDMI audio sink on host
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/ioctls.h| 72
linux-user/syscall.c | 1 +
linux-user/syscall_defs.h | 73
linux-user/syscall_types.h
Tested with ExtremeTuxRacer in guest with HDMI audio sink on host
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/ioctls.h| 72
linux-user/syscall.c | 1 +
linux-user/syscall_defs.h | 73
linux-user/syscall_types.h
Tested on a Radeon R290X with multiple 3D applications.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/ioctls.h| 45 +-
linux-user/syscall.c | 15
linux-user/syscall_defs.h | 45 +-
linux-user/syscall_types.h
size if applicable.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/syscall.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 1c17b74..2968b57 100644
--- a/linu
Tested on a Radeon R290X with multiple 3D applications.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/ioctls.h| 45 +-
linux-user/syscall.c | 15
linux-user/syscall_defs.h | 45 +-
linux-user/syscall_types.h
'd') IOCTLs in linux. With it and a corresponding architecture
chroot (say aarch64), I am able to successfully run a few 2D and
3D applications with native graphics acceleration. Some
notes/caveats are:
Timothy Pearson (6):
Add initial x86_64 signal handlers
QEMU
1. It will only work with open drivers as their IOCTLs are documented.
2. i965+ is only supported. That is any haswell, ivybridge, etc. GPU
will work.
3. X doesn't start yet, though this patch eliminates all the visible
unsupported DRM IOCTL calls as observed by setting QEMU_STRACE=1.
4. Intel
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/x86_64/termbits.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/linux-user/x86_64/termbits.h b/linux-user/x86_64/termbits.h
index 1c3445c..5fc4639 100644
--- a/linux-user/
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/x86_64/termbits.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/linux-user/x86_64/termbits.h b/linux-user/x86_64/termbits.h
index 1c3445c..5fc4639 100644
--- a/linux-user/
This matches the calling conventions in the Linux kernel and
resolves select() hangs on i386/x86_64 guests.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/syscall.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b
size if applicable.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/syscall.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 1c17b74..2968b57 100644
--- a/linu
Note that x86_64 systems only offer the _rt signal handler variants,
so the legacy signal handlers remain unimplemented on this platform.
Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
---
linux-user/signal.c | 302
+++-
acceleration. Some
notes/caveats are:
Timothy Pearson (6):
Add initial x86_64 signal handlers
QEMU does not currently support host pages that are larger than
guest pages, likely due to glibc using fixed mmap requests.
Pass select() arguments directly to do_select() on x86 platforms
Finally figured it out!
It's the page size. qemu user mode does NOT support a host page that is
greater than 4k on x86/x86_64 systems, despite some claims to the
contrary on older documentation pages.
I'll be updating the patch to print a clear warning on failure instead
of allowing corrupt
So after some further debugging effort it turns out while the page
allocator is unaware of the mapping (looks like the x86_64 NPTL
implementation never maps the thread ID memory?), g2h() does work on the
address, and in this case they map to the same value. I'll probably
submit a patch using g2h
qemu can locate the guest page with that address but it has a flags
field of all zero (no access, invalid). Any ideas?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using
On closer inspection maybe it's not that odd...the parent and child tid
pointers are in abi, not target, space. I'm going to assume direct
assignment is correct (using __put_user()) and proceed from there.
--
You received this bug notification because you are a member of qemu-
devel-ml, which
OK, the fundamental problem is that do_fork() uses put_user_u32() on
child_tidptr, but child_tidptr appears to be a host pointer. Treating
it as a host pointer (direct assignment) allows fork to proceed, but
this seems a bit odd to say the least.
Still investigating.
--
You received this bug
Yes, I saw that -- implementing the signal handlers fixed the hang and a
few other problems, but the assertion and subsequent SIGABORT/SIGSEGV
are still present. Currently attempting to track down the fork()
issues.
--
You received this bug notification because you are a member of qemu-
** Changed in: qemu
Assignee: (unassigned) => Timothy Pearson (kb9vqf)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using qemu-x86_64-static fails on ppc64el
Sta
Can you point me to the correct location in the codebase / any available
resources on these handlers? I might be able to tackle this at a later
date, but am not currently familiar with qemu's codebase.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Are there any plans to implement these signal handlers?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using qemu-x86_64-static fails on ppc64el
Status in QEMU:
New
Bug
Public bug reported:
When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el
host to chroot into an amd64 environment, all commands fail with an
assertion error. /usr/bin/qemu-x86_64-static from the host was copied
into the chroot /usr/bin, and the host has multiformat support in
** Tags added: power8
** Tags removed: power8
** Tags added: ppc qemu vga
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1546680
Title:
Incorrect display colors when running big endian guest on
Public bug reported:
When running a big endian CentOS guest on a little endian host system
the display shows severe color issues, probably due to endianness not
being properly detected / switched in the emulated display hardware.
Little endian guests show no display issues on the same host
51 matches
Mail list logo
