In commit 45def77ebf79, the order of function calls in kvm_fast_pio() was changed. This causes that the vm(XP,and also XP's iso img) failed to boot. This doesn't happen with win10 or ubuntu.
After revert the order, the vm(XP) succeedes to boot. In addition, the change of calls's order of kvm_fast_pio() in commit 45def77ebf79 has no obvious reason.
Fixes: 45def77ebf79 ("KVM: x86: update %rip after emulating IO") Cc: stable@vger.kernel.org Signed-off-by: Perr Zhang strongbox8@zoho.com --- arch/x86/kvm/x86.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index a0d1fc80ac5a..248753cb94a1 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6610,13 +6610,12 @@ static int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size,
int kvm_fast_pio(struct kvm_vcpu *vcpu, int size, unsigned short port, int in) { - int ret; + int ret = kvm_skip_emulated_instruction(vcpu);
if (in) - ret = kvm_fast_pio_in(vcpu, size, port); + return kvm_fast_pio_in(vcpu, size, port) && ret; else - ret = kvm_fast_pio_out(vcpu, size, port); - return ret && kvm_skip_emulated_instruction(vcpu); + return kvm_fast_pio_out(vcpu, size, port) && ret; } EXPORT_SYMBOL_GPL(kvm_fast_pio);
On Tue, Apr 30, 2019 at 10:24:23PM +0800, Perr Zhang wrote:
In commit 45def77ebf79, the order of function calls in kvm_fast_pio() was changed. This causes that the vm(XP,and also XP's iso img) failed to boot. This doesn't happen with win10 or ubuntu.
After revert the order, the vm(XP) succeedes to boot. In addition, the change of calls's order of kvm_fast_pio() in commit 45def77ebf79 has no obvious reason.
This Changelog fails to explain why the order is important and equally fails to inform the future reader of that code. So this very same thing will happen again in 6 months time or thereabout.
Fixes: 45def77ebf79 ("KVM: x86: update %rip after emulating IO") Cc: stable@vger.kernel.org Signed-off-by: Perr Zhang strongbox8@zoho.com
arch/x86/kvm/x86.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index a0d1fc80ac5a..248753cb94a1 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6610,13 +6610,12 @@ static int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, int kvm_fast_pio(struct kvm_vcpu *vcpu, int size, unsigned short port, int in) {
- int ret;
- int ret = kvm_skip_emulated_instruction(vcpu);
if (in)
ret = kvm_fast_pio_in(vcpu, size, port);
return kvm_fast_pio_in(vcpu, size, port) && ret;
ret = kvm_fast_pio_out(vcpu, size, port);- return ret && kvm_skip_emulated_instruction(vcpu);
return kvm_fast_pio_out(vcpu, size, port) && ret;} EXPORT_SYMBOL_GPL(kvm_fast_pio); -- 2.21.0
On Tue, Apr 30, 2019 at 04:32:01PM +0200, Peter Zijlstra wrote:
On Tue, Apr 30, 2019 at 10:24:23PM +0800, Perr Zhang wrote:
In commit 45def77ebf79, the order of function calls in kvm_fast_pio() was changed. This causes that the vm(XP,and also XP's iso img) failed to boot. This doesn't happen with win10 or ubuntu.
After revert the order, the vm(XP) succeedes to boot. In addition, the change of calls's order of kvm_fast_pio() in commit 45def77ebf79 has no obvious reason.
There are three reasons explicitly listed in the changelog:
Updating %rip prior to executing to userspace has several drawbacks:
- Userspace sees the wrong %rip on the exit, e.g. if PIO emulation fails it will likely yell about the wrong address. - Single step exits to userspace for are effectively dropped as KVM_EXIT_DEBUG is overwritten with KVM_EXIT_IO. - Behavior of PIO emulation is different depending on whether it goes down the fast path or the slow path.
This Changelog fails to explain why the order is important and equally fails to inform the future reader of that code. So this very same thing will happen again in 6 months time or thereabout.
There's a more precise fix submitted for this bug[1]. In theory v2 already went out, but I still don't see it posted to the KVM list. Either the KVM list or my mail client is being weird.
On Tue, Apr 30, 2019 at 07:57:24AM -0700, Sean Christopherson wrote:
There's a more precise fix submitted for this bug[1]. In theory v2 already went out, but I still don't see it posted to the KVM list. Either the KVM list or my mail client is being weird.
Thanks!
---- On Tue, 30 Apr 2019 22:32:01 +0800 Peter Zijlstra peterz@infradead.org wrote ----
On Tue, Apr 30, 2019 at 10:24:23PM +0800, Perr Zhang wrote:
In commit 45def77ebf79, the order of function calls in kvm_fast_pio() was changed. This causes that the vm(XP,and also XP's iso img) failed to boot. This doesn't happen with win10 or ubuntu.
After revert the order, the vm(XP) succeedes to boot. In addition, the change of calls's order of kvm_fast_pio() in commit 45def77ebf79 has no obvious reason.
This Changelog fails to explain why the order is important and equally fails to inform the future reader of that code. So this very same thing will happen again in 6 months time or thereabout.
I'm not familiar with KVM, don't know the particular reason.
Fixes: 45def77ebf79 ("KVM: x86: update %rip after emulating IO") Cc: stable@vger.kernel.org Signed-off-by: Perr Zhang strongbox8@zoho.com
arch/x86/kvm/x86.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index a0d1fc80ac5a..248753cb94a1 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6610,13 +6610,12 @@ static int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, int kvm_fast_pio(struct kvm_vcpu *vcpu, int size, unsigned short port, int in) {
- int ret;
- int ret = kvm_skip_emulated_instruction(vcpu);
if (in)
ret = kvm_fast_pio_in(vcpu, size, port);
return kvm_fast_pio_in(vcpu, size, port) && ret;
ret = kvm_fast_pio_out(vcpu, size, port);- return ret && kvm_skip_emulated_instruction(vcpu);
return kvm_fast_pio_out(vcpu, size, port) && ret;} EXPORT_SYMBOL_GPL(kvm_fast_pio); -- 2.21.0
linux-stable-mirror@lists.linaro.org
-
Perr Zhang -
Peter Zijlstra -
Sean Christopherson