From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
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 v1 6/6] spapr: Fix migration of Radix guests
Date: Thu, 18 May 2017 10:33:05 +0530 [thread overview]
Message-ID: <20170518050305.GF3446@in.ibm.com> (raw)
In-Reply-To: <20170517072031.GO15596@umbus.fritz.box>
On Wed, May 17, 2017 at 05:20:31PM +1000, David Gibson wrote:
> On Wed, May 17, 2017 at 12:45:39PM +0530, Bharata B Rao wrote:
> > On Wed, May 17, 2017 at 05:00:49PM +1000, David Gibson wrote:
> > > On Wed, May 17, 2017 at 09:19:22AM +0530, Bharata B Rao wrote:
> > > > Fix migration of radix guests by ensuring that we issue
> > > > KVM_PPC_CONFIGURE_V3_MMU for radix case post migration.
> > > >
> > > > Reported-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
> > > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > > > ---
> > > > hw/ppc/spapr.c | 15 +++++++++++++++
> > > > hw/ppc/spapr_hcall.c | 1 +
> > > > include/hw/ppc/spapr.h | 1 +
> > > > 3 files changed, 17 insertions(+)
> > > >
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index 05abfc1..dd1d687 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -1443,6 +1443,20 @@ static int spapr_post_load(void *opaque, int version_id)
> > > > err = spapr_rtc_import_offset(&spapr->rtc, spapr->rtc_offset);
> > > > }
> > > >
> > > > + if (spapr->patb_entry) {
> > > > + if (kvmppc_has_cap_mmu_radix() && kvm_enabled()) {
> > > > + err = kvmppc_configure_v3_mmu(POWERPC_CPU(first_cpu),
> > > > + spapr->patb_flags &
> > > > + SPAPR_PROC_TABLE_RADIX,
> > > > + spapr->patb_flags &
> > > > + SPAPR_PROC_TABLE_GTSE,
> > >
> > > You should be able to work out the things you need here from
> > > patb_entry without adding the new patb_flags field.
> >
> > kvmppc_configure_v3_mmu() needs two bools: radix and gtse. The radix
> > bit can be implied from patb_entry, I needed patb_flags to get the
> > gtse value. Not immediately obvious of how to get gtse bit from patb_entry,
> > but let me take a relook.
>
> Oh, sorry, you can't get GTSE from the patb_entry, but you can get it
> from the LPCR.
So I need to get GTSE from LPCR at the target after the LPCR has been updated
from the incoming stream (via vmstate_ppc_cpu vmsd). However we are also
in the middle of processing the incoming stream here (via spapr_post_load).
Can we be sure that spapr_post_load() processing happens after all
SPRs (and hence LPCR) have been updated via vmstate_ppc_cpu vmsd handlers ?
Also, in addition to issuing KVM_PPC_CONFIGURE_V3_MMU, should we be
walking all the CPUs and setting the LPCR_UPRT and LPCR_GTSE bits like how
H_REGISTER_PROC_TBL does ?
Regards,
Bharata.
next prev parent reply other threads:[~2017-05-18 5:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-17 3:49 [Qemu-devel] [RFC PATCH v1 0/6] ppc/spapr: Fix migration of radix guests Bharata B Rao
2017-05-17 3:49 ` [Qemu-devel] [RFC PATCH v1 1/6] migration: Fix unregister_savevm() Bharata B Rao
2017-05-17 6:43 ` David Gibson
2017-05-17 10:12 ` Bharata B Rao
2017-05-17 3:49 ` [Qemu-devel] [RFC PATCH v1 2/6] migration: Introduce unregister_savevm_live() Bharata B Rao
2017-05-17 6:45 ` David Gibson
2017-05-17 7:21 ` Bharata B Rao
2017-05-17 3:49 ` [Qemu-devel] [RFC PATCH v1 3/6] spapr: Make h_register_process_table hcall flags global Bharata B Rao
2017-05-17 3:49 ` [Qemu-devel] [RFC PATCH v1 4/6] spapr: Consolidate HPT freeing code into a routine Bharata B Rao
2017-05-17 6:55 ` David Gibson
2017-05-17 3:49 ` [Qemu-devel] [RFC PATCH v1 5/6] spapr: Unregister HPT savevm handlers for radix guests Bharata B Rao
2017-05-17 6:59 ` David Gibson
2017-05-17 7:18 ` Bharata B Rao
2017-05-17 7:23 ` David Gibson
2017-05-17 3:49 ` [Qemu-devel] [RFC PATCH v1 6/6] spapr: Fix migration of Radix guests Bharata B Rao
2017-05-17 7:00 ` David Gibson
2017-05-17 7:15 ` Bharata B Rao
2017-05-17 7:20 ` David Gibson
2017-05-18 5:03 ` Bharata B Rao [this message]
2017-05-18 5:50 ` David Gibson
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=20170518050305.GF3446@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=david@gibson.dropbear.id.au \
--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).