diff mbox series

[v1,1/1] KVM: s390/mm: Properly reset no-dat

Message ID 20231109123624.37314-1-imbrenda@linux.ibm.com
State New
Headers
Series [v1,1/1] KVM: s390/mm: Properly reset no-dat |

Commit Message

Claudio Imbrenda Nov. 9, 2023, 12:36 p.m. UTC 
  When the CMMA state needs to be reset, the no-dat bit also needs to be
reset. Failure to do so could cause issues in the guest, since the
guest expects the bit to be cleared after a reset.

Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
---
 arch/s390/mm/pgtable.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Claudio Imbrenda Nov. 9, 2023, 12:44 p.m. UTC | #1 
Sorry, I had copy-pasted the wrong email address for Gerald, fixed now

On Thu,  9 Nov 2023 13:36:24 +0100
Claudio Imbrenda <imbrenda@linux.ibm.com> wrote:

> When the CMMA state needs to be reset, the no-dat bit also needs to be
> reset. Failure to do so could cause issues in the guest, since the
> guest expects the bit to be cleared after a reset.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> ---
>  arch/s390/mm/pgtable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index 3bd2ab2a9a34..5cb92941540b 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -756,7 +756,7 @@ void ptep_zap_unused(struct mm_struct *mm, unsigned long addr,
>  		pte_clear(mm, addr, ptep);
>  	}
>  	if (reset)
> -		pgste_val(pgste) &= ~_PGSTE_GPS_USAGE_MASK;
> +		pgste_val(pgste) &= ~(_PGSTE_GPS_USAGE_MASK | _PGSTE_GPS_NODAT);
>  	pgste_set_unlock(ptep, pgste);
>  	preempt_enable();
>  }
Christian Borntraeger Nov. 9, 2023, 1:11 p.m. UTC | #2 
Am 09.11.23 um 13:36 schrieb Claudio Imbrenda:
> When the CMMA state needs to be reset, the no-dat bit also needs to be
> reset. Failure to do so could cause issues in the guest, since the
> guest expects the bit to be cleared after a reset.

This happens during reset of a guest (or whenever QEMU calls the CLR_CMMA thingi).
I think after reset a normal Linux guest has no DAT tables and very likely
a cpu reset (with explicit full guest flush) will happen. It will very likely
also set the CMMA state during boot before setting up its DAT tables.
So for the normal reboot this should be ok. But I can imagine cases that would
not be ok. So maybe add cc stable?
Nico Boehr Nov. 14, 2023, 4:24 p.m. UTC | #3 
Quoting Claudio Imbrenda (2023-11-09 13:36:24)
> When the CMMA state needs to be reset, the no-dat bit also needs to be
> reset. Failure to do so could cause issues in the guest, since the
> guest expects the bit to be cleared after a reset.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>

Please Cc stable and add my:

Reviewed-by: Nico Boehr <nrb@linux.ibm.com>
diff mbox series

Patch

diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 3bd2ab2a9a34..5cb92941540b 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -756,7 +756,7 @@  void ptep_zap_unused(struct mm_struct *mm, unsigned long addr,
 		pte_clear(mm, addr, ptep);
 	}
 	if (reset)
-		pgste_val(pgste) &= ~_PGSTE_GPS_USAGE_MASK;
+		pgste_val(pgste) &= ~(_PGSTE_GPS_USAGE_MASK | _PGSTE_GPS_NODAT);
 	pgste_set_unlock(ptep, pgste);
 	preempt_enable();
 }