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
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
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
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 ?)
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
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 lear
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 learning the process as I go. Next time I submit
something, I'll follow the guidelines more accurately.
On Thu,
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.
Power ISA 2.07B (Power 7/Power 8) indicates the bit is
reserved but so
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
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
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
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
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
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
>From qemu monitor :
(qemu) info tlb
info tlb
SLB ESIDVSID
0 0x0800 0x04002400
3 0xf10005000800 0x40500400
4 0xf1001800 0x41000400
5 0xf10008000800 0x40800400
6 0xf1
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
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
** 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
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
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
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
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
22 matches
Mail list logo
