All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Doron <arilou@gmail.com>
To: Roman Kagan <rvkagan@yandex-team.ru>,
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org,
	vkuznets@redhat.com
Subject: Re: [PATCH v11 6/7] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls
Date: Wed, 13 May 2020 15:39:26 +0300	[thread overview]
Message-ID: <20200513123926.GL2862@jondnuc> (raw)
In-Reply-To: <20200512153353.GB9944@rvkaganb.lan>

On 12/05/2020, Roman Kagan wrote:
>On Fri, Apr 24, 2020 at 02:37:45PM +0300, Jon Doron wrote:
>> There is another mode for the synthetic debugger which uses hypercalls
>> to send/recv network data instead of the MSR interface.
>>
>> This interface is much slower and less recommended since you might get
>> a lot of VMExits while KDVM polling for new packets to recv, rather
>> than simply checking the pending page to see if there is data avialble
>> and then request.
>>
>> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> Signed-off-by: Jon Doron <arilou@gmail.com>
>> ---
>>  arch/x86/kvm/hyperv.c | 28 ++++++++++++++++++++++++++++
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>> index 524b5466a515..744bcef88c70 100644
>> --- a/arch/x86/kvm/hyperv.c
>> +++ b/arch/x86/kvm/hyperv.c
>> @@ -1832,6 +1832,34 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>>  		}
>>  		ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
>>  		break;
>> +	case HVCALL_POST_DEBUG_DATA:
>> +	case HVCALL_RETRIEVE_DEBUG_DATA:
>> +		if (unlikely(fast)) {
>> +			ret = HV_STATUS_INVALID_PARAMETER;
>> +			break;
>> +		}
>> +		fallthrough;
>> +	case HVCALL_RESET_DEBUG_SESSION: {
>> +		struct kvm_hv_syndbg *syndbg = vcpu_to_hv_syndbg(vcpu);
>> +
>> +		if (!syndbg->active) {
>> +			ret = HV_STATUS_INVALID_HYPERCALL_CODE;
>> +			break;
>> +		}
>> +
>> +		if (!(syndbg->options & HV_X64_SYNDBG_OPTION_USE_HCALLS)) {
>> +			ret = HV_STATUS_OPERATION_DENIED;
>> +			break;
>> +		}
>> +		vcpu->run->exit_reason = KVM_EXIT_HYPERV;
>> +		vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
>> +		vcpu->run->hyperv.u.hcall.input = param;
>> +		vcpu->run->hyperv.u.hcall.params[0] = ingpa;
>> +		vcpu->run->hyperv.u.hcall.params[1] = outgpa;
>> +		vcpu->arch.complete_userspace_io =
>> +				kvm_hv_hypercall_complete_userspace;
>> +		return 0;
>> +	}
>
>I'd personally just push every hyperv hypercall not recognized by the
>kernel to userspace.  Smth like this:
>
>diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>index bcefa9d4e57e..f0404df0f488 100644
>--- a/arch/x86/kvm/hyperv.c
>+++ b/arch/x86/kvm/hyperv.c
>@@ -1644,6 +1644,48 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> 		}
> 		kvm_vcpu_on_spin(vcpu, true);
> 		break;
>+	case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
>+		if (unlikely(fast || !rep_cnt || rep_idx)) {
>+			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+			break;
>+		}
>+		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>+		break;
>+	case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
>+		if (unlikely(fast || rep)) {
>+			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+			break;
>+		}
>+		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>+		break;
>+	case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX:
>+		if (unlikely(fast || !rep_cnt || rep_idx)) {
>+			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+			break;
>+		}
>+		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>+		break;
>+	case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX:
>+		if (unlikely(fast || rep)) {
>+			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+			break;
>+		}
>+		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>+		break;
>+	case HVCALL_SEND_IPI:
>+		if (unlikely(rep)) {
>+			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+			break;
>+		}
>+		ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, false, fast);
>+		break;
>+	case HVCALL_SEND_IPI_EX:
>+		if (unlikely(fast || rep)) {
>+			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+			break;
>+		}
>+		ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
>+		break;
> 	case HVCALL_SIGNAL_EVENT:
> 		if (unlikely(rep)) {
> 			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>@@ -1653,12 +1695,8 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> 		if (ret != HV_STATUS_INVALID_PORT_ID)
> 			break;
> 		/* fall through - maybe userspace knows this conn_id. */
>-	case HVCALL_POST_MESSAGE:
>-		/* don't bother userspace if it has no way to handle it */
>-		if (unlikely(rep || !vcpu_to_synic(vcpu)->active)) {
>-			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>-			break;
>-		}
>+	default:
>+		/* forward unrecognized hypercalls to userspace */
> 		vcpu->run->exit_reason = KVM_EXIT_HYPERV;
> 		vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
> 		vcpu->run->hyperv.u.hcall.input = param;
>@@ -1667,51 +1705,6 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> 		vcpu->arch.complete_userspace_io =
> 				kvm_hv_hypercall_complete_userspace;
> 		return 0;
>-	case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
>-		if (unlikely(fast || !rep_cnt || rep_idx)) {
>-			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>-			break;
>-		}
>-		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>-		break;
>-	case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
>-		if (unlikely(fast || rep)) {
>-			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>-			break;
>-		}
>-		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>-		break;
>-	case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX:
>-		if (unlikely(fast || !rep_cnt || rep_idx)) {
>-			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>-			break;
>-		}
>-		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>-		break;
>-	case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX:
>-		if (unlikely(fast || rep)) {
>-			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>-			break;
>-		}
>-		ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>-		break;
>-	case HVCALL_SEND_IPI:
>-		if (unlikely(rep)) {
>-			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>-			break;
>-		}
>-		ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, false, fast);
>-		break;
>-	case HVCALL_SEND_IPI_EX:
>-		if (unlikely(fast || rep)) {
>-			ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>-			break;
>-		}
>-		ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
>-		break;
>-	default:
>-		ret = HV_STATUS_INVALID_HYPERCALL_CODE;
>-		break;
> 	}
>
> 	return kvm_hv_hypercall_complete(vcpu, ret);
>
>(would also need a kvm cap for that)
>
>Roman.

This looks like a good idea, but I think it should be part of another 
patchset, I could revise one once this is in and expose a new CAP, and 
we need to make sure QEMU can handle this and wont just crash getting 
these additional exits.

-- Jon.

  reply	other threads:[~2020-05-13 12:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 11:37 [PATCH v11 0/7] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron
2020-04-24 11:37 ` [PATCH v11 1/7] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit Jon Doron
2020-05-13  8:42   ` Roman Kagan
2020-04-24 11:37 ` [PATCH v11 2/7] x86/kvm/hyper-v: Simplify addition for custom cpuid leafs Jon Doron
2020-05-13  9:24   ` Roman Kagan
2020-05-13 12:49     ` Jon Doron
2020-05-29 11:13       ` Paolo Bonzini
2020-04-24 11:37 ` [PATCH v11 3/7] x86/hyper-v: Add synthetic debugger definitions Jon Doron
2020-04-24 11:37 ` [PATCH v11 4/7] x86/kvm/hyper-v: Add support for synthetic debugger capability Jon Doron
2020-05-29 10:46   ` Paolo Bonzini
2020-05-29 12:08     ` Vitaly Kuznetsov
2020-05-29 12:17       ` Paolo Bonzini
2020-04-24 11:37 ` [PATCH v11 5/7] x86/kvm/hyper-v: enable hypercalls without hypercall page with syndbg Jon Doron
2020-05-13  9:57   ` Roman Kagan
2020-05-13 12:37     ` Jon Doron
2020-05-29 10:48   ` Paolo Bonzini
2020-04-24 11:37 ` [PATCH v11 6/7] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls Jon Doron
2020-05-12 15:33   ` Roman Kagan
2020-05-13 12:39     ` Jon Doron [this message]
2020-04-24 11:37 ` [PATCH v11 7/7] KVM: selftests: update hyperv_cpuid with SynDBG tests Jon Doron
2020-05-07  3:01 ` [PATCH v11 0/7] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron
2020-05-07  7:57   ` Paolo Bonzini

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=20200513123926.GL2862@jondnuc \
    --to=arilou@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=rvkagan@yandex-team.ru \
    --cc=vkuznets@redhat.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.