Re: [PATCH 1/2] KVM: arm64: Clean out the odd handling of completer_addr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Oliver,

On Fri, Oct 28, 2022 at 08:34:47AM +0000, Oliver Upton wrote:
> The layout of struct pkvm_mem_transition is a bit weird; the destination
> address for the transition is actually stashed in the initiator address
> context. Even weirder so, that address is thrown inside a union and
> return from helpers by use of an out pointer.
> 
> Rip out the whole mess and move the destination address into the
> destination context sub-struct. No functional change intended.
> 
> Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx>
> ---
>  arch/arm64/kvm/hyp/nvhe/mem_protect.c | 70 ++++++++++-----------------
>  1 file changed, 25 insertions(+), 45 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 1e78acf9662e..3636a24e1b34 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -393,17 +393,12 @@ struct pkvm_mem_transition {
>  		enum pkvm_component_id	id;
>  		/* Address in the initiator's address space */
>  		u64			addr;
> -
> -		union {
> -			struct {
> -				/* Address in the completer's address space */
> -				u64	completer_addr;
> -			} host;
> -		};
>  	} initiator;
>  
>  	struct {
>  		enum pkvm_component_id	id;
> +		/* Address in the completer's address space */
> +		u64			addr;
>  	} completer;
>  };

I'm reasonably sure we'll end up putting this back like we had it as we gain
support for guest-initiatied transitions, where we have to walk the guest
stage-2 page-table to figure out the physical address of the memory being
shared, which is the host (completer's) IPA thanks to the identity mapping
there.

So here's what I'll do: I'll post a v6 of the EL2 state series, and I'll
include this at the end (before the RFC patch) and let Marc decide whether
to go ahead with it. I do agree that it cleans things up for now but, as
above, I think that's likely to be a short-lived change.

Sound reasonable?

Cheers,

Will
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux