Re: [Qemu-ppc] [PATCH 00/10] spapr: option vector re-work and memory unplug support

[David Gibson]

On Mon, Oct 24, 2016 at 11:47:26PM -0500, Michael Roth wrote:
> This series is based on David's ppc-for-2.8 branch, and is also available 
> from:
> 
>   https://github.com/mdroth/qemu/commits/spapr-hotplug-event-update
> 
> Changes since RFC:
>   * Submit as v1 now that PAPR Hotplug ACR is accepted
>   * Rebase on latest ppc-for-2.8 (with device-tree refactoring)
>   * address Patchew warnings
>   * add comments to clarify spapr->ov5/ov5_cas usage. (David)
>   * revise comment to clarify intent when setting spapr->ov5
>     OV5_HP_EVT bit. (Bharata)
>   * drop internal usage of spapr_ovec_from_bitmap() in favor of
>     directly assigning bitmap to sPAPROptionVector instances. (David)
>   * standardize meaning of 'vector_len' variable through spapr_ovec_*
>     functions to be the byte-wise length of option vectors entries,
>     and not including the preceeding length byte itself. (David)
>   * fix spapr_ovec_populate_dt() to parse up to OV_MAXBITS bits
>     rather than OV_MAXBITS - 1. (David)
>   * fix spapr_ovec_populate_dt() encode the minimum of 1 option
>     vector byte instead of the max of OV_MAXBYTES in cases where
>     no option bits are set. (David)
>   * add some comments to spapr_ovec_populate_dt() to clarify what
>     is being encoded into length byte of ibm,architecture-vec-5
>   * switch 'legacy-hotplug-events' option to
>     'modern-hotplug-events' (David)
>   * modify rtas_event_log_to_source() to check for OV5_HP_EVT
>     option rather than relying on whether the hotplug source is
>     specifically enabled. Assert the latter in cases where
>     OV5_HP_EVT is set. (Bharata)
>   * drop global EventSource list in favor of an sPAPREventSource
>     list field within sPAPRMachineState (David)
>   * add CPU unplug hook in mc->unplug_request (Bharata)
> 
> 
> Patches 1-4 address various deficiencies in how we currently handle option
> vectors via ibm,client-architecture-support. This is done here in preparation
> for a new option vector bit introduced later in this series, as well as a
> number of future option vector bits related to other features, but I can
> break this out into a separate series if preferred.

I've now merged these 4 (adjusting for a couple of tiny nits mentioned
in comments).

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature