The following changes since commit fff3159900d2b95613a9cb75fc3703e67a674729:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190726'
into staging (2019-07-26 16:23:07 +0100)
are available in the Git repository at:
git://github.com/dgibson/qemu.git tags/ppc-for-4.1-2019
From: Greg Kurz
Commit 4812f2615288 tried to fix rollback path of xics_kvm_connect() but
it isn't enough. If we fail to create the KVM device, the guest fails
to boot later on with:
[0.010817] pci :00:00.0: Adding to iommu group 0
[0.010863] irq: unknown-1 didn't like hwirq-0x1200 to
From: Greg Kurz
Just to give an indication to the user that the error condition is
handled and how.
Reported-by: Satheesh Rajendran
Signed-off-by: Greg Kurz
Message-Id: <156398743479.546975.14566809803480887488.st...@bahia.lan>
Reviewed-by: Cédric Le Goater
Signed-off-by: David Gibson
---
h
On Sat, Jul 20, 2019 at 11:28:50AM +1000, Alexey Kardashevskiy wrote:
> QEMU already implements H_CAS called by SLOF. The existing handler
> prepares a diff FDT and SLOF applies it on top of its current tree.
> In SLOF-less setup when the user explicitly selected "bios=no",
> this updates the FDT f
On Fri, Jul 26, 2019 at 04:44:38PM +0200, Greg Kurz wrote:
> When freeing MSIs, we need to:
> - remove them from the machine's MSI bitmap
> - remove them from the IC backend
> - remove them from the PHB's MSI cache
>
> This is currently open coded in two places in rtas_ibm_change_msi(),
> and we'r
On Fri, Jul 26, 2019 at 04:44:33PM +0200, Greg Kurz wrote:
> Some recent tests with AIX guests showed that we don't tear down
> MSIs that were allocated with the "change-msi" RTAS call, when
> the guest is rebooted. This series teach PHBs to do the cleanup
> at reset time.
>
> This bug has always
My guess is that RFLAGS.ZF == 1 and one or a few of the checks on VMX controls
have failed. So far I have verified the following checks (26-2 and 26-3 in
Intel SDM Vol. 3C):
* Reserved bits in Pin-based VM execution controls are set according to
associated capabilities MSR
* Reserved bits in Pr
On Sat, 27 Jul 2019 at 13:24, Paolo Bonzini wrote:
>
> On 27/07/19 09:16, Markus Armbruster wrote:
> > We started with a single trace-events. That wasn't good, so we split it
> > up into one per directory. That isn't good, so what about splitting it
> > up into one per source file? Pass -DTRACE
Hello!
Max Reitz wrote in <156422889569.6195.873582563265040.malone@soybean\
.canonical.com>:
|Hi,
|
|Can you retry with any 4.1 release candidate (like 4.1.0-rc2)? (Or wait
|for the 4.1.0 release in hopefully about a week?) The error message
|sounds like it should be fixed by https://l
On 27/07/19 09:16, Markus Armbruster wrote:
> We started with a single trace-events. That wasn't good, so we split it
> up into one per directory. That isn't good, so what about splitting it
> up into one per source file? Pass -DTRACE_HEADER='"trace-DIR-FOO.h"
> instead of -DTRACE_HEADER='"trace
Hi,
Can you retry with any 4.1 release candidate (like 4.1.0-rc2)? (Or wait
for the 4.1.0 release in hopefully about a week?) The error message
sounds like it should be fixed by https://lists.nongnu.org/archive/html
/qemu-block/2019-05/msg00775.html .
Though I have no idea why you would hit tha
Hi
On Sat, Jul 27, 2019 at 10:16 AM Jan Kiszka wrote:
>
> From: Jan Kiszka
>
> I haven't been doing anything here for a long time, nor does my git repo
> still play a role.
>
> Signed-off-by: Jan Kiszka
too bad, we could still use some help ;)
thanks anyway!
Reviewed-by: Marc-André Lureau
Paolo Bonzini writes:
> On 13/07/19 16:15, Markus Armbruster wrote:
>>>In particular the tracing headers are using
>>> $(build_root)/$(>> "trace/trace-audio.h" and have sixty one-line forwarding headers in the
>>> source tree; for example "audio/trace.h" includes "trace/trace-
13 matches
Mail list logo
