Hey there,
Any chance the MSR[SF] mixed code issue fix gets addressed at some point ?
(Apparently there was a fix but it was breaking some tests for some
unknown reason)...
--Ivan
On 3/10/2021 5:09 AM, David Gibson wrote:
The following changes since commit b2ae1009d7cca2701e17eae55ae2d44fd2
On 3/11/2021 2:47 AM, David Gibson wrote:
Sorry, I've forgotten this issue. If you had a patch, can you resend
it please.
Not mine.. (I reported it, but can't remember who sent it)...
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 2609e4082e..4a05e4e544 100644
--- a/target/ppc/cpu.
Hello people,
I have the following issue : I'm using an OS (not linux) on a
qemu-system-ppc64. (in my case a Power8 qemu target with a x86_64 TCG
target)
This OS provides a set of NARROW/WIDE (MSR[SF]) agnostic code snippets
in the 1st 64K of addresses (so they can be called using the PPC 'b
Richard,
Reviewed-by: Ivan Warren
Thanks a million !
--Ivan
On 1/24/2021 4:24 AM, Richard Henderson wrote:
Use the cs_base field, because it happens to be the same
size as hflags (and MSR, from which hflags is derived).
In translate, extract most bits from a local hflags variable.
Mark
On 10/8/2019 3:35 PM, David Hildenbrand wrote:
On 08.10.19 14:11, Cornelia Huck wrote:
On Tue, 08 Oct 2019 11:19:25 -
Ivan Warren via wrote:
Public bug reported:
When using go on s390x on Debian x64 (buster) (host) and debian s390x
(sid) (guest) I run into the following problem :
The
Public bug reported:
When using go on s390x on Debian x64 (buster) (host) and debian s390x
(sid) (guest) I run into the following problem :
The following occurs while trying to build a custom project :
go: github.com/FactomProject/basen@v0.0.0-20150613233007-fe3947df716e:
Get
https://proxy.golan
I was looking for a simpler method (without using go), but curl/wget and
whatnot don't seem to have any problem.. There must be something go is
doing that is different.
My guess (but ONLY a guess) is that the "go" TLS code might be doing
some dynamic checking on the z/Arch facility list (STFLE ?)
Since wget/curl use the openssl library - which (unless a specific
engine is specified) uses the lowest common denominator - it will work
even when z/Arch VX is present.. However, "golang" may be using a
different technique (and may not be using openssl at all) - or invoke
openssl with a specific e
Looks fixed to me ! The issue no longer shows even without specifying
vx=off
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847232
Title:
qemu TCG in s390x mode issue with calculating HASH
Status
I will exercise this thoroughly ! The go application involved is itself
a blockchain signing/verification application, so I suspect it will be a
good exercise (codenotary.io)
Thanks for looking into this and fixing this !
--Ivan
--
You received this bug notification because you are a member of
All,
Submitting proposal :
Per Power ISA 3.02B Book III at pages 1029 and 1030, bit 15 of the
slbmfee and slbmfev instructions is now assigned to an implementation
specific bit and is no longer reserved - meaning it can be set to 1 but
can probably be safely ignored.
2.07B still indicates b
My previous message might have felt through the cracks due to some
improper formating.
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 4a5de28036..85f8b147ba 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -7064,8 +7064,8 @@ GE
some none Linux operating systems do set
this bit to 1 when entering the debugger.
So it is likely it is implemented on those systems
but wasn't yet documented.
Signed-off-by: Ivan Warren
---
The original creator of the patch is "Zhuowei Zhang"
(https://twitter.com/zhuowei) but
n Thu, 18 Jul 2019 14:44:49 +0200
Ivan Warren wrote:
Allow bit 15 to be 1 in the slbmfee and slbmfev in TCG
as per Power ISA 3.0B (Power 9) Book III pages 1029 and 1030.
Per this specification, bit 15 is implementation specific
so it may be 1, but can probably ne safely ignored.
Another typo fr
Le 7/19/2019 à 3:34 AM, David Gibson a écrit :
On Thu, Jul 18, 2019 at 10:15:52PM +0200, Ivan Warren wrote:
Le 7/18/2019 à 7:19 PM, Greg Kurz a écrit :
We usually mention the subsystem name in the subject, ie.
target/ppc: Allow bit 15 to be set to 1 on slbmfee and slbmfev
Gotcha ! Still
Got gdb for ppc64 to work and connect to qemu... Here is what I am
getting when doing a "info all-registers"
r0 0x0 0
r1 0xf1000816b0036890 17365889056675948688
r2 0x32b5d2053173536
r3 0x33854001664
r4 0x2dc
>From qemu monitor :
(qemu) info tlb
info tlb
SLB ESIDVSID
0 0x0800 0x04002400
3 0xf10005000800 0x40500400
4 0xf1001800 0x41000400
5 0xf10008000800 0x40800400
6 0xf1
This is the result at the same breakpoint under 3.1.0 (note the
difference in the TLB) (notably Segment Lookaside Buffer entry #1)
(qemu) info tlb
info tlb
SLB ESIDVSID
0 0x0800 0x04002400
1 0xf0002800 0x000802001080
3
It might be a red herring...
The AIX Boot procedure under 3.1.0 issues a
LED{814}
which it doesn't issue under 4.0.50 (so a different path is taken at
some point by the AIX kernel)
First I need to determine what AIX code 814 stands for (but it could be
auxiliary)
Before going into the ".dispat
According to git bisect :
git bisect bad
c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0 is the first bad commit
commit c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0
Author: Laurent Vivier
Date: Wed Dec 19 17:35:41 2018 +0100
spapr: Add H-Call H_HOME_NODE_ASSOCIATIVITY
H_HOME_NODE_ASSOCIATIVITY
For info :
I tried Removing the SPAPR H_HOME_NODE_ASSOCIATIVITY H-call support (Not
saying it shouldn't be implemented for CPU hotplug support) and AIX 7.2
boots again. with the latest QEMU (as of
8c1ecb590497b0349c550607db923972b37f6963 - git pulled 2019/05/29 @
around 06H30 GMT)
There must be a
I also have a regression issue between 3.1.0 and 4.0.0 (actually latest
git) on qemu-system-ppc64 but it involves an AIX guest instead (fail to
boot). Should I open a new ticket or hop on this one ?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscri
Same thing here using https://github.com/dgibson/qemu/commits/ppc-
for-4.1 ... It might be a completely different problem (athough it looks
like a MMU problem).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.ne
Forgot that part (debugger output)
KDB(0)> wherre^H ^H^H ^He^M
si_pvthread+00 STACK:^M
[0008F418]dispatch+98 (0338, 02DC3838,^M
F1000816B0036CF0 [??])^M
[00234E34]flih_util+000440 ()^M
Exception (02743408) ^M
iar : 00AD0088 msr : 80001032
Public bug reported:
Built from source on a debian system
Linux db08 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
Last git commit (from queued gdibson repository)
starting AIX 7.2 TL 2 SP 2 with the following : (the inst
** Tags added: ppc64
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829682
Title:
QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX
Status in QEMU:
New
Bug description:
Built from
Currently at :
QEMU emulator version 4.0.50 (v2.8.0-rc0-19525-ga4f667b671-dirty)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1
27 matches
Mail list logo
