All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Joey Gouly <joey.gouly@arm.com>,
	kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	nd@arm.com
Subject: Re: [PATCH 08/18] KVM: arm64: nv: Handle HCR_EL2.NV system register traps
Date: Fri, 24 Feb 2023 19:03:21 +0000	[thread overview]
Message-ID: <86v8jqx4w6.wl-maz@kernel.org> (raw)
In-Reply-To: <Y/kDp9nYrAmYuh6y@linux.dev>

On Fri, 24 Feb 2023 18:36:23 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> Hi Joey,
> 
> On Fri, Feb 24, 2023 at 05:39:15PM +0000, Joey Gouly wrote:
> > I'm having an issue with this commit where a VCPU is getting a CNTVOFF_EL2 set
> > to 0, so it sees the same time as the host system, and the other VCPU has the
> > correct offset.
> 
> Yikes!
> 
> > The flow of execution looks like this:
> > 	KVM_CREATE_VCPU 0 (VMM) ->
> > 		kvm_timer_vcpu_init ->
> > 			update_vtimer_cntvoff (VCPU0.CNTVOFF_EL2=kvm_phys_timer_read)
> > 	KVM_ARM_VCPU_INIT (VMM) ->
> > 		kvm_arch_vcpu_ioctl_vcpu_init ->
> > 			kvm_vcpu_set_target ->
> > 				kvm_reset_vcpu ->
> > 					kvm_reset_sys_regs (VCPU0.CNTVOFF_EL2=0)
> > 
> > 	KVM_CREATE_VCPU 1 (VMM) ->
> > 		kvm_timer_vcpu_init ->
> > 			update_vtimer_cntvoff (VCPU0.CNTVOFF_EL2=VCPU1.CNTVOFF_EL2=kvm_phys_timer_read)
> > 	KVM_ARM_VCPU_INIT (VMM) ->
> > 		kvm_arch_vcpu_ioctl_vcpu_init ->
> > 			kvm_vcpu_set_target ->
> > 				kvm_reset_vcpu ->
> > 					kvm_reset_sys_regs (VCPU1.CNTVOFF_EL2=0)
> > 
> > 	At this point VCPU0 has CNTVOFF_EL2 == kvm_phys_timer_read, and VCPU1
> > 	has CNTVOFF_EL2 == 0.
> > 
> > The VCPUs having different CNTVOFF_EL2 valuess is just a symptom of the fact that
> > CNTVOFF_EL2 is now reset in kvm_reset_sys_regs.
> 
> Right, and the fundamental problem at hand is that we used CNTVOFF_EL2
> to stash the _host's_ offset even though we are trying to change the
> meaning of it to be part of the virtual EL2's context.

What is driving me nuts is that I have never managed to reproduce the
problem so far. I guess I have too much crap in my tree to spot it...

> 
> > The following patch gets it booting again, but I'm sure it's not the right fix.
> 
> I'd rather we just break the host away from using the shadow reg
> altogether and separately track the host offset. As it so happens Marc
> has a patch that does exactly that [*].

Yup, might as well fix that *and* kill the lock inversion issue in one
go...

> Marc, do you want to resend that patch in isolation addressing the
> feedback and link to this bug report?
> 
> [*] https://lore.kernel.org/kvmarm/20230216142123.2638675-6-maz@kernel.org/

Joey, could you please give that patch a go, just to be on the safe
side?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Joey Gouly <joey.gouly@arm.com>,
	kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	nd@arm.com
Subject: Re: [PATCH 08/18] KVM: arm64: nv: Handle HCR_EL2.NV system register traps
Date: Fri, 24 Feb 2023 19:03:21 +0000	[thread overview]
Message-ID: <86v8jqx4w6.wl-maz@kernel.org> (raw)
In-Reply-To: <Y/kDp9nYrAmYuh6y@linux.dev>

On Fri, 24 Feb 2023 18:36:23 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> Hi Joey,
> 
> On Fri, Feb 24, 2023 at 05:39:15PM +0000, Joey Gouly wrote:
> > I'm having an issue with this commit where a VCPU is getting a CNTVOFF_EL2 set
> > to 0, so it sees the same time as the host system, and the other VCPU has the
> > correct offset.
> 
> Yikes!
> 
> > The flow of execution looks like this:
> > 	KVM_CREATE_VCPU 0 (VMM) ->
> > 		kvm_timer_vcpu_init ->
> > 			update_vtimer_cntvoff (VCPU0.CNTVOFF_EL2=kvm_phys_timer_read)
> > 	KVM_ARM_VCPU_INIT (VMM) ->
> > 		kvm_arch_vcpu_ioctl_vcpu_init ->
> > 			kvm_vcpu_set_target ->
> > 				kvm_reset_vcpu ->
> > 					kvm_reset_sys_regs (VCPU0.CNTVOFF_EL2=0)
> > 
> > 	KVM_CREATE_VCPU 1 (VMM) ->
> > 		kvm_timer_vcpu_init ->
> > 			update_vtimer_cntvoff (VCPU0.CNTVOFF_EL2=VCPU1.CNTVOFF_EL2=kvm_phys_timer_read)
> > 	KVM_ARM_VCPU_INIT (VMM) ->
> > 		kvm_arch_vcpu_ioctl_vcpu_init ->
> > 			kvm_vcpu_set_target ->
> > 				kvm_reset_vcpu ->
> > 					kvm_reset_sys_regs (VCPU1.CNTVOFF_EL2=0)
> > 
> > 	At this point VCPU0 has CNTVOFF_EL2 == kvm_phys_timer_read, and VCPU1
> > 	has CNTVOFF_EL2 == 0.
> > 
> > The VCPUs having different CNTVOFF_EL2 valuess is just a symptom of the fact that
> > CNTVOFF_EL2 is now reset in kvm_reset_sys_regs.
> 
> Right, and the fundamental problem at hand is that we used CNTVOFF_EL2
> to stash the _host's_ offset even though we are trying to change the
> meaning of it to be part of the virtual EL2's context.

What is driving me nuts is that I have never managed to reproduce the
problem so far. I guess I have too much crap in my tree to spot it...

> 
> > The following patch gets it booting again, but I'm sure it's not the right fix.
> 
> I'd rather we just break the host away from using the shadow reg
> altogether and separately track the host offset. As it so happens Marc
> has a patch that does exactly that [*].

Yup, might as well fix that *and* kill the lock inversion issue in one
go...

> Marc, do you want to resend that patch in isolation addressing the
> feedback and link to this bug report?
> 
> [*] https://lore.kernel.org/kvmarm/20230216142123.2638675-6-maz@kernel.org/

Joey, could you please give that patch a go, just to be on the safe
side?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-02-24 19:03 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09 17:58 [PATCH 00/18] KVM: arm64: Prefix patches for NV support Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 01/18] arm64: Add ARM64_HAS_NESTED_VIRT cpufeature Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 02/18] KVM: arm64: Use the S2 MMU context to iterate over S2 table Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-11  1:00   ` Andre Przywara
2023-02-11  1:00     ` Andre Przywara
2023-02-09 17:58 ` [PATCH 03/18] KVM: arm64: nv: Introduce nested virtualization VCPU feature Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 04/18] KVM: arm64: nv: Reset VCPU to EL2 registers if VCPU nested virt is set Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 05/18] KVM: arm64: nv: Allow userspace to set PSR_MODE_EL2x Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 06/18] KVM: arm64: nv: Add EL2 system registers to vcpu context Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 07/18] KVM: arm64: nv: Add nested virt VCPU primitives for vEL2 VCPU state Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 08/18] KVM: arm64: nv: Handle HCR_EL2.NV system register traps Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-24 17:39   ` Joey Gouly
2023-02-24 17:39     ` Joey Gouly
2023-02-24 18:36     ` Oliver Upton
2023-02-24 18:36       ` Oliver Upton
2023-02-24 19:03       ` Marc Zyngier [this message]
2023-02-24 19:03         ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 09/18] KVM: arm64: nv: Support virtual EL2 exceptions Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 10/18] KVM: arm64: nv: Inject HVC exceptions to the virtual EL2 Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 11/18] KVM: arm64: nv: Handle trapped ERET from " Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 12/18] KVM: arm64: nv: Handle PSCI call via smc from the guest Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-11 10:07   ` Oliver Upton
2023-02-11 10:07     ` Oliver Upton
2023-02-11 10:31     ` Marc Zyngier
2023-02-11 10:31       ` Marc Zyngier
2023-02-11 18:17       ` Oliver Upton
2023-02-11 18:17         ` Oliver Upton
2023-02-09 17:58 ` [PATCH 13/18] KVM: arm64: nv: Add accessors for SPSR_EL1, ELR_EL1 and VBAR_EL1 from virtual EL2 Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 14/18] KVM: arm64: nv: Emulate PSTATE.M for a guest hypervisor Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 15/18] KVM: arm64: nv: Allow a sysreg to be hidden from userspace only Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 16/18] KVM: arm64: nv: Emulate EL12 register accesses from the virtual EL2 Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 17/18] KVM: arm64: nv: Filter out unsupported features from ID regs Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 18/18] KVM: arm64: nv: Only toggle cache for virtual EL2 when SCTLR_EL2 changes Marc Zyngier
2023-02-09 17:58   ` Marc Zyngier
2023-02-13 22:26 ` [PATCH 00/18] KVM: arm64: Prefix patches for NV support Oliver Upton
2023-02-13 22:26   ` Oliver Upton

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=86v8jqx4w6.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nd@arm.com \
    --cc=oliver.upton@linux.dev \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.