qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Bharata B Rao <bharata@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	sam.bobroff@au1.ibm.com, rnsastry@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH v2 2/4] spapr: Unregister HPT savevm handlers for radix guests
Date: Mon, 22 May 2017 12:35:08 +1000	[thread overview]
Message-ID: <20170522023508.GI30246@umbus.fritz.box> (raw)
In-Reply-To: <1495172439-1504-3-git-send-email-bharata@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 6815 bytes --]

On Fri, May 19, 2017 at 11:10:37AM +0530, Bharata B Rao wrote:
> HPT gets created by default for TCG guests and later when the guest turns
> out to be a radix guest, the HPT is destroyed when guest does
> H_REGISTER_PROC_TBL hcall. Let HTAB savevm handlers registration and
> unregistration follow the same model so that we don't end up having
> unrequired HTAB savevm handlers for radix guests.
> 
> This also ensures that HTAB savevm handlers seemlessly get destroyed and
> recreated like HTAB itself when hash guest reboots.
> 
> HTAB savevm handlers registration/unregistration is now done from
> spapr_reallocate_hpt() which itself is called from one of the
> savevm_htab_handlers.htab_load(). To cater to this circular dependency
> spapr_reallocate_hpt() is made global.
> 
> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>


Weirdly, diff seems to have done a terrible job at minimizing the
patch below.  AFAICT this is really just a one line addition to
spapr_free_hpt() and spapr_reallocate_hpt().

> ---
>  hw/ppc/spapr.c         | 99 +++++++++++++++++++++++++-------------------------
>  include/hw/ppc/spapr.h |  2 +
>  2 files changed, 52 insertions(+), 49 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 91f7434..daf335c 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1233,53 +1233,7 @@ void spapr_free_hpt(sPAPRMachineState *spapr)
>      spapr->htab = NULL;
>      spapr->htab_shift = 0;
>      close_htab_fd(spapr);
> -}
> -
> -static void spapr_reallocate_hpt(sPAPRMachineState *spapr, int shift,
> -                                 Error **errp)
> -{
> -    long rc;
> -
> -    /* Clean up any HPT info from a previous boot */
> -    spapr_free_hpt(spapr);
> -
> -    rc = kvmppc_reset_htab(shift);
> -    if (rc < 0) {
> -        /* kernel-side HPT needed, but couldn't allocate one */
> -        error_setg_errno(errp, errno,
> -                         "Failed to allocate KVM HPT of order %d (try smaller maxmem?)",
> -                         shift);
> -        /* This is almost certainly fatal, but if the caller really
> -         * wants to carry on with shift == 0, it's welcome to try */
> -    } else if (rc > 0) {
> -        /* kernel-side HPT allocated */
> -        if (rc != shift) {
> -            error_setg(errp,
> -                       "Requested order %d HPT, but kernel allocated order %ld (try smaller maxmem?)",
> -                       shift, rc);
> -        }
> -
> -        spapr->htab_shift = shift;
> -        spapr->htab = NULL;
> -    } else {
> -        /* kernel-side HPT not needed, allocate in userspace instead */
> -        size_t size = 1ULL << shift;
> -        int i;
> -
> -        spapr->htab = qemu_memalign(size, size);
> -        if (!spapr->htab) {
> -            error_setg_errno(errp, errno,
> -                             "Could not allocate HPT of order %d", shift);
> -            return;
> -        }
> -
> -        memset(spapr->htab, 0, size);
> -        spapr->htab_shift = shift;
> -
> -        for (i = 0; i < size / HASH_PTE_SIZE_64; i++) {
> -            DIRTY_HPTE(HPTE(spapr->htab, i));
> -        }
> -    }
> +    unregister_savevm_live(NULL, "spapr/htab", spapr);
>  }
>  
>  void spapr_setup_hpt_and_vrma(sPAPRMachineState *spapr)
> @@ -1879,6 +1833,55 @@ static SaveVMHandlers savevm_htab_handlers = {
>      .load_state = htab_load,
>  };
>  
> +void spapr_reallocate_hpt(sPAPRMachineState *spapr, int shift,
> +                                 Error **errp)
> +{
> +    long rc;
> +
> +    /* Clean up any HPT info from a previous boot */
> +    spapr_free_hpt(spapr);
> +
> +    rc = kvmppc_reset_htab(shift);
> +    if (rc < 0) {
> +        /* kernel-side HPT needed, but couldn't allocate one */
> +        error_setg_errno(errp, errno,
> +                         "Failed to allocate KVM HPT of order %d (try smaller maxmem?)",
> +                         shift);
> +        /* This is almost certainly fatal, but if the caller really
> +         * wants to carry on with shift == 0, it's welcome to try */
> +    } else if (rc > 0) {
> +        /* kernel-side HPT allocated */
> +        if (rc != shift) {
> +            error_setg(errp,
> +                       "Requested order %d HPT, but kernel allocated order %ld (try smaller maxmem?)",
> +                       shift, rc);
> +        }
> +
> +        spapr->htab_shift = shift;
> +        spapr->htab = NULL;
> +    } else {
> +        /* kernel-side HPT not needed, allocate in userspace instead */
> +        size_t size = 1ULL << shift;
> +        int i;
> +
> +        spapr->htab = qemu_memalign(size, size);
> +        if (!spapr->htab) {
> +            error_setg_errno(errp, errno,
> +                             "Could not allocate HPT of order %d", shift);
> +            return;
> +        }
> +
> +        memset(spapr->htab, 0, size);
> +        spapr->htab_shift = shift;
> +
> +        for (i = 0; i < size / HASH_PTE_SIZE_64; i++) {
> +            DIRTY_HPTE(HPTE(spapr->htab, i));
> +        }
> +    }
> +    register_savevm_live(NULL, "spapr/htab", -1, 1,
> +                         &savevm_htab_handlers, spapr);
> +}
> +
>  static void spapr_boot_set(void *opaque, const char *boot_device,
>                             Error **errp)
>  {
> @@ -2341,8 +2344,6 @@ static void ppc_spapr_init(MachineState *machine)
>       * interface, this is a legacy from the sPAPREnvironment structure
>       * which predated MachineState but had a similar function */
>      vmstate_register(NULL, 0, &vmstate_spapr, spapr);
> -    register_savevm_live(NULL, "spapr/htab", -1, 1,
> -                         &savevm_htab_handlers, spapr);
>  
>      /* used by RTAS */
>      QTAILQ_INIT(&spapr->ccs_list);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index f875dc4..e581c4a 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -637,6 +637,8 @@ void spapr_hotplug_req_remove_by_count_indexed(sPAPRDRConnectorType drc_type,
>                                                 uint32_t count, uint32_t index);
>  void *spapr_populate_hotplug_cpu_dt(CPUState *cs, int *fdt_offset,
>                                      sPAPRMachineState *spapr);
> +void spapr_reallocate_hpt(sPAPRMachineState *spapr, int shift,
> +                                 Error **errp);
>  
>  /* rtas-configure-connector state */
>  struct sPAPRConfigureConnectorState {

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2017-05-22  3:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19  5:40 [Qemu-devel] [RFC PATCH v2 0/4] ppc/spapr: Fix migration of radix guests Bharata B Rao
2017-05-19  5:40 ` [Qemu-devel] [RFC PATCH v2 1/4] migration: Introduce unregister_savevm_live() Bharata B Rao
2017-05-19  7:33   ` David Gibson
2017-05-19 13:14     ` Laurent Vivier
2017-05-22  2:36       ` David Gibson
2017-05-19  5:40 ` [Qemu-devel] [RFC PATCH v2 2/4] spapr: Unregister HPT savevm handlers for radix guests Bharata B Rao
2017-05-22  2:35   ` David Gibson [this message]
2017-05-19  5:40 ` [Qemu-devel] [RFC PATCH v2 3/4] spapr: Make h_register_process_table hcall flags global Bharata B Rao
2017-05-21 18:48   ` Laurent Vivier
2017-05-22  2:41     ` David Gibson
2017-05-19  5:40 ` [Qemu-devel] [RFC PATCH v2 4/4] spapr: Fix migration of Radix guests Bharata B Rao
2017-05-19  6:36   ` Bharata B Rao
2017-05-22  2:44     ` David Gibson
2017-05-22  4:15       ` Bharata B Rao
2017-05-22  6:30   ` [Qemu-devel] [Qemu-ppc] " Suraj Jitindar Singh
2017-05-23  4:48     ` Bharata B Rao
2017-05-23  8:42       ` Suraj Jitindar Singh
2017-05-23  9:00         ` Bharata B Rao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170522023508.GI30246@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rnsastry@linux.vnet.ibm.com \
    --cc=sam.bobroff@au1.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).