Message ID | 92d87ead72556e946d7fa6775c509de8b6d11935.camel@linux.ibm.com (mailing list archive) |
---|---|
State | RFC |
Headers | show |
Series | powerpc/pseries/vas: VAS/NXGZIP support with LPM | expand |
Haren Myneni <haren@linux.ibm.com> writes: > Before migration starts, all secondary CPUs will be offline which > can invoke VAS DLPAR event. I don't understand this statement, so I can't evaluate the patch. The current LPM implementation does not offline any CPUs.
On Fri, 2022-01-14 at 11:59 -0600, Nathan Lynch wrote: > Haren Myneni <haren@linux.ibm.com> writes: > > > Before migration starts, all secondary CPUs will be offline which > > can invoke VAS DLPAR event. > > I don't understand this statement, so I can't evaluate the patch. The > current LPM implementation does not offline any CPUs. Thanks for your comment. My mistake.. VAS notifier with of_reconfig_notifier_register() is called during migration for other events. VAS notifier has a bug ( https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-December/238333.html ) and will fix it: if ((action == OF_RECONFIG_ATTACH_NODE) || (action == OF_RECONFIG_DETACH_NODE)) intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len); As the current LPM notifier does not freeze the system, thought of ignoring DLPAR CPU hotplug event with this migration_in_progress flag. I will fix this as well and repost DLPAR NXGZIP series. Thanks Haren
diff --git a/arch/powerpc/platforms/pseries/vas.c b/arch/powerpc/platforms/pseries/vas.c index d2d7202a4f4e..1a10c1904aaa 100644 --- a/arch/powerpc/platforms/pseries/vas.c +++ b/arch/powerpc/platforms/pseries/vas.c @@ -30,6 +30,7 @@ static bool copypaste_feat; static struct vas_caps vascaps[VAS_MAX_FEAT_TYPE]; static DEFINE_MUTEX(vas_pseries_mutex); +static bool migration_in_progress; static long hcall_return_busy_check(long rc) { @@ -349,8 +350,11 @@ static struct vas_window *vas_allocate_window(int vas_id, u64 flags, * same fault IRQ is not freed by the OS before. */ mutex_lock(&vas_pseries_mutex); - rc = allocate_setup_window(txwin, (u64 *)&domain[0], - cop_feat_caps->win_type); + if (migration_in_progress) + rc = -EBUSY; + else + rc = allocate_setup_window(txwin, (u64 *)&domain[0], + cop_feat_caps->win_type); mutex_unlock(&vas_pseries_mutex); if (rc) goto out; @@ -771,6 +775,9 @@ int vas_reconfig_capabilties(u8 type) return -ENOMEM; mutex_lock(&vas_pseries_mutex); + if (migration_in_progress) + goto out; + rc = h_query_vas_capabilities(H_QUERY_VAS_CAPABILITIES, vcaps->feat, (u64)virt_to_phys(hv_caps)); if (rc) @@ -866,6 +873,11 @@ static int vas_migrate_windows(bool suspend) mutex_lock(&vas_pseries_mutex); + if (suspend) + migration_in_progress = true; + else + migration_in_progress = false; + for (i = 0; i < VAS_MAX_FEAT_TYPE; i++) { vcaps = &vascaps[i]; caps = &vcaps->caps;
Before migration starts, all secondary CPUs will be offline which can invoke VAS DLPAR event. So disable VAS DLPAR event with migration_in_progress flag during suspend and enable after resume operations. The current partition migration implementation does not freeze the user space and the user space can continue open VAS windows. So when migration_in_progress flag is enabled, VAS open window API returns -EBUSY. Signed-off-by: Haren Myneni <haren@linux.ibm.com> --- arch/powerpc/platforms/pseries/vas.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)