Re: [Qemu-ppc] [PULL 0/3] ppc-for-2.6 queue 20160405

[Peter Maydell]

On 5 April 2016 at 03:17, David Gibson <address@hidden> wrote:
> The following changes since commit 2e3a76ae3e47d502f9f0c4424b719945fba9d459:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20160404' into staging (2016-04-04 
> 17:43:39 +0100)
>
> are available in the git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.6-20160405
>
> for you to fetch changes up to efdaf797de009e194db89dcd8b171fa35181a6f2:
>
>   vl: Move cpu_synchronize_all_states() into qemu_system_reset() (2016-04-05 
> 10:49:10 +1000)
>
> ----------------------------------------------------------------
> ppc patch queue for 2016-03-24
>
> Three bugfixes for target-ppc, pseries machine type and related devices.
>
> 1. Fix a bug in the core code where kvm_vcpu_dirty would not be set
>    before the very first system reset.  This meant that if things in
>    the reset path did their own cpu_synchronize_state() it would pull
>    stale data out of KVM.
>
>    On ppc this, in combination with a previous cleanup meant that the
>    MSR would be zeroed before entry, instead of correctly having the
>    SF (64-bit mode) bit set.
>
> 2. Allow immediate detach of hot-added PCI devices which haven't yet
>    been announced to the guest.
>
>    This fixes a regression: because of a case where we now defer
>    announcement of non-zero functions to the guest, an incorrect
>    hot-add of such a device can't be backed out until the add is
>    completed, which is counter-intuitive to say the least.
>
> 3. Fix migration of alternate interrupt locations.  The location of
>    interrupt vectors can be affected by the LPCR, and we weren't
>    correctly recalculating this after migration of a non-standard LPCR
>    value.
>
> ----------------------------------------------------------------
>
> Two of the three patches here began life as cleanups or preliminaries
> for new features, however they also fix real bugs.  They're
> sufficiently small that I don't think including them for 2.6 is any
> riskier than any other approach to fixing the bugs in question.

Applied, thanks.

-- PMM