Thread (94 messages) 94 messages, 5 authors, 2021-04-02

Re: [PATCH v4 02/46] KVM: PPC: Book3S HV: Add a function to filter guest LPCR bits

From: Nicholas Piggin <npiggin@gmail.com>
Date: 2021-04-01 13:28:43

Excerpts from Nicholas Piggin's message of April 1, 2021 7:32 pm:
Excerpts from Paul Mackerras's message of March 31, 2021 2:08 pm:
quoted
On Tue, Mar 23, 2021 at 11:02:21AM +1000, Nicholas Piggin wrote:
quoted
Guest LPCR depends on hardware type, and future changes will add
restrictions based on errata and guest MMU mode. Move this logic
to a common function and use it for the cases where the guest
wants to update its LPCR (or the LPCR of a nested guest).
[snip]
quoted
@@ -4641,8 +4662,9 @@ void kvmppc_update_lpcr(struct kvm *kvm, unsigned long lpcr, unsigned long mask)
 		struct kvmppc_vcore *vc = kvm->arch.vcores[i];
 		if (!vc)
 			continue;
+
 		spin_lock(&vc->lock);
-		vc->lpcr = (vc->lpcr & ~mask) | lpcr;
+		vc->lpcr = kvmppc_filter_lpcr_hv(vc, (vc->lpcr & ~mask) | lpcr);
This change seems unnecessary, since kvmppc_update_lpcr is called only
to update MMU configuration bits, not as a result of any action by
userspace or a nested hypervisor.  It's also beyond the scope of what
was mentioned in the commit message.
I didn't think it was outside the spirit of the patch, but yes
only the guest update LPCR case was enumerated. Would it be more 
consistent to add it to the changelog and leave it in here or would
you prefer it left out until there is a real use?
On second thoughts, I already left at least one other place without
such a check, so I now tend to agree with you. But I instead added
a test that just ensures the host is not out of synch with itself in
terms of what it can set the LPCR to.

Thanks,
Nick
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help