Re: [PATCH 08/18] KVM: arm64: nv: Handle HCR_EL2.NV system register traps

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

 



On Fri, 24 Feb 2023 18:36:23 +0000,
Oliver Upton <oliver.upton@xxxxxxxxx> 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@xxxxxxxxxx/

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.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux