Yes, it is a CPU feature, and yes you can select the exception vector
prefix with the MSR[IP] bit which should be set by a hardware reset. The
initial value seems wrong in qemu but that seems to fixed by the
machine-specific initialization. The 'none' machine, however, just uses
generic code and do
n -machine == none. Yet another
bug, it seems. The NIP and MSR seem wrong, however.
I can generate an empty ppc_rom.bin and fool a prep machine under
2.11.1:
till@tillp1 $ ls -l empty.bin
-rw-r--r-- 1 till till 0 Aug 8 12:03 empty.bin
till@tillp1 $ qemu-system-ppc -bios ./empty.bin -cpu 7400 -ma
>From looking at the source code of 5.1.0-rc3
(target/ppc/translate_init.inc.c) it seems that this is still an issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/812398
Title:
powerpc 7450 MMU in
This did never occur again for me. So this can get closed.
** Changed in: qemu (Ubuntu)
Status: Triaged => Invalid
** Changed in: qemu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https
changing the guest config to enable paravirt seems to do the trick!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1037675
Title:
Guest Kernel Panic if using "-cpu host" in qemu-kvm 1.1.1
Status in
i forgot to mention that the PID was 27374
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1037675
Title:
Guest Kernel Panic if using "-cpu host" in qemu-kvm 1.1.1
Status in QEMU:
New
Bug descrip
i started trace-cmd as suggested on http://www.linux-
kvm.org/page/Tracing and started the vm. after the panic i aborted
trace-cmd and here is the trace file
** Attachment added: "trace from trace-cmd"
https://bugs.launchpad.net/qemu/+bug/1037675/+attachment/3306241/+files/trace.dat.tar.bz2
-
ok getting the serial console to work was not that hard. here is the
relevant serial output of the failing guest (full output is attached as
file):
[0.010706] mce: CPU supports 10 MCE banks
[0.011279] ACPI: Core revision 20110623
[0.014769] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1
** Attachment added: "guest output of kernel panic (serial console output)"
https://bugs.launchpad.net/qemu/+bug/1037675/+attachment/3305265/+files/serial_out.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launch
thx for the patience, i am currently very busy, therefore this took a
bit longer than it was planed:
- using a non hardened kernel (gentoo-sources-3.3.8) does not resolve
the issue
therefore i need to use the serial console, which is somewhat new to
me. i will do this as soon as i find some time
sorry for the not very usefull information i provides above.
i will try to reproduce the the failure with a vailla kernel (host) in
a few days. currently the server is in use and cannot be restarted.
the kernel panic was in the guest (thought this is clear by "my vm
panic"). If it is reproducable
** Attachment added: "kernel panic screenshot"
https://bugs.launchpad.net/bugs/1037675/+attachment/3264111/+files/kernel_panic.png
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1037675
Title:
G
Public bug reported:
After Upgrading to qemu-kvm-1.1.1-r1 from version 1.0.1-r1 my virtual
machines (running gentoo linux) panic at intel_pmu_init. (detailed
information including stacktrace are in the uploaded screenshot). When i
remove the "-cpu host" option, the system starts normally.
the com
Public bug reported:
According to the man page, spice can be only used via TCP/IP in opposite
to VNC, which can also be configured to listen on a unix domain socket.
To make it easy to use spice without exposing the interface, please
support unix domain sockets as well. I can try to provide a pat
bootloader/
The stuff that goes into the dummy 'bios' is qemu_fakerom.S and
qemu_fakeres.c
Regards
- Till
On 07/17/2011 05:34 PM, Andreas Färber wrote:
> Hi,
>
> Am 16.07.2011 um 23:49 schrieb till:
>
>> I have a proprietary ROM implementing system calls that are e
Public bug reported:
The 7540 family of PPCs' MMU can update TLBs using hardware search (like
a 604 or 7400) but also using a software algorithm. The mechanism used
is defined by HID0[STEN].
By default (CPU reset) HID0 is set to 0x8000 (BTW; another small bug, qemu
doesn't set the hardwired
Google for MPC7450UM.pdf and MPC7410UM.pdf. These two documents cover
the
7441, 7445, 7451, 7455, 7457, 7447, 7448 and the 7410 and 7400 CPUs,
respectively.
For all these, Alex' description applies. However, (and I made a mistake in my
original post),
the setting affected is
env->hreset_excp_pr
Public bug reported:
I have a proprietary ROM implementing system calls that are executed via
the 'SC' instruction.
I use qemu-0.14.1,
qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel
That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400
(CPU=0x000c0209)
I'm afraid I don't understand. My the problem and fix doesn't address mtmsr at
all.
It just makes sure MSR_POW is cleared in MSR when an exception occurs.
Do you mean MSR_POW should masked from MSR before saving it to SRR1?
That's already taken care of (target-ppc/helper.c:2074 [qemu-0.12.4]).
-
Public bug reported:
QEMU VERSION: 0.12.4
According to FreeScale's 'Programming Environments Manual for 32-bit
Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005],
section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4
fails to do so.
Resetting the bit
** Patch added: "Suggested fix"
http://launchpadlibrarian.net/52250654/ppc-msr_pow-clear.diff
--
ppc fails to clear MSR_POW when incurring exception
https://bugs.launchpad.net/bugs/608107
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEM
;error = 0x01;
ide_set_irq(s);
break;
but if I look at some ATA-3 (draft) document I found
linked from wikipedia
(here:
http://www.t10.org/t13/project/d2008r7b-ATA-3.pdf
)
I find (pp 45,46) that the READY bit in fact should be set.
??
Regards
-- Till
(PS please CC-me
22 matches
Mail list logo
