From: Joao Martins <joao.m.martins@oracle.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Ankur Arora <ankur.a.arora@oracle.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Sean Christopherson <seanjc@google.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH 03/15] KVM: x86/xen: intercept xen hypercalls if enabled
Date: Sat, 5 Dec 2020 19:13:19 +0000 [thread overview]
Message-ID: <616173a3-586f-1156-9f53-28bdcdb665a6@oracle.com> (raw)
In-Reply-To: <9A93D396-9C77-4E57-A7E0-61BBEEB83658@infradead.org>
On 12/5/20 6:51 PM, David Woodhouse wrote:
> On 5 December 2020 18:42:53 GMT, Joao Martins <joao.m.martins@oracle.com> wrote:
>> I suppose it makes sense restricting to INTERCEPT_HCALL to make sure
>> that the kernel only
>> forwards the hcall if it is control off what it put there in the
>> hypercall page (i.e.
>> vmmcall/vmcall). hcall userspace exiting without INTERCEPT_HCALL would
>> break ABI over how
>> this ioctl was used before the new flag... In case
>> kvm_xen_hypercall_enabled() would
>> return true with KVM_XEN_HVM_CONFIG_HYPERCALL_MSR, as now it needs to
>> handle a new
>> userspace exit.
>
> Right.
>
>> If we're are being pedantic, the Xen hypercall MSR is a utility more
>> than a necessity as
>> the OS can always do without the hcall msr IIUC. But it is defacto used
>> by enlightened Xen
>> guests included FreeBSD.
>
> Not sure about that. Xen doesn't guarantee that the hypercall will be VMCALL; the ABI *is* ",use the hypercall page MSR and call it" I believe.
>
You might be right. I had always had the impression that the above was is geared towards
PV guests hypercalls IIRC which are not VMMCALL/VMCALL. Xen doesn't explicitly check you
initialized an hypercall page for HVM guests.
> But if they do just do the VMCALL, that *will* work as I have it, won't it?
>
It would work indeed.
What I was mentioning is the possibility that you let userspace fill the hcall page data,
while enabling hcall intercept () so 0x3 as xen hvm config flags i.e. you pass a blob with
hcall intercept set.
I think it's good as is given that interception is tied in with what you fill in the hcall
page.
>>
>> And adding:
>>
>> #define KVM_XEN_HVM_CONFIG_HYPERCALL_MSR (1 << 0)
>>
>> Of course, this is a nit for readability only, but it aligns with what
>> you write
>> in the docs update you do in the last patch.
>
> Yep, already there. Thanks.
>
next prev parent reply other threads:[~2020-12-05 19:14 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 1:18 [PATCH 00/15] KVM: Add Xen hypercall and shared info pages David Woodhouse
2020-12-04 1:18 ` [PATCH 01/15] KVM: Fix arguments to kvm_{un,}map_gfn() David Woodhouse
2020-12-04 18:27 ` Alexander Graf
2020-12-04 19:02 ` David Woodhouse
2020-12-04 1:18 ` [PATCH 02/15] KVM: x86/xen: fix Xen hypercall page msr handling David Woodhouse
2020-12-04 18:26 ` Alexander Graf
2020-12-04 18:54 ` David Woodhouse
2020-12-04 1:18 ` [PATCH 03/15] KVM: x86/xen: intercept xen hypercalls if enabled David Woodhouse
2020-12-04 18:26 ` Alexander Graf
2020-12-04 18:58 ` David Woodhouse
2020-12-05 18:42 ` Joao Martins
2020-12-05 18:51 ` David Woodhouse
2020-12-05 19:13 ` Joao Martins [this message]
2020-12-04 1:18 ` [PATCH 04/15] KVM: x86/xen: Fix coexistence of Xen and Hyper-V hypercalls David Woodhouse
2020-12-04 18:34 ` Alexander Graf
2020-12-04 19:04 ` David Woodhouse
2020-12-04 1:18 ` [PATCH 05/15] KVM: x86/xen: add KVM_XEN_HVM_SET_ATTR/KVM_XEN_HVM_GET_ATTR David Woodhouse
2020-12-04 1:18 ` [PATCH 06/15] KVM: x86/xen: latch long_mode when hypercall page is set up David Woodhouse
2020-12-04 18:38 ` Alexander Graf
2020-12-04 19:08 ` David Woodhouse
2020-12-04 1:18 ` [PATCH 07/15] KVM: x86/xen: add definitions of compat_shared_info, compat_vcpu_info David Woodhouse
2020-12-05 18:43 ` Joao Martins
2020-12-05 19:48 ` David Woodhouse
2020-12-04 1:18 ` [PATCH 08/15] KVM: x86/xen: register shared_info page David Woodhouse
2020-12-04 1:18 ` [PATCH 09/15] KVM: x86/xen: setup pvclock updates David Woodhouse
2020-12-04 1:18 ` [PATCH 10/15] xen: add wc_sec_hi to struct shared_info David Woodhouse
2020-12-04 1:18 ` [PATCH 11/15] KVM: x86/xen: update wallclock region David Woodhouse
2020-12-04 1:18 ` [PATCH 12/15] KVM: x86/xen: register vcpu info David Woodhouse
2020-12-04 1:18 ` [PATCH 13/15] KVM: x86/xen: register vcpu time info region David Woodhouse
2020-12-04 1:18 ` [PATCH 14/15] KVM: x86/xen: register runstate info David Woodhouse
2020-12-04 1:18 ` [PATCH 15/15] KVM: x86: declare Xen HVM shared info capability and add test case David Woodhouse
2020-12-04 9:11 ` [PATCH 16/15] KVM: Add documentation for Xen hypercall and shared_info updates David Woodhouse
2020-12-05 10:48 ` [PATCH 00/15] KVM: Add Xen hypercall and shared info pages David Woodhouse
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=616173a3-586f-1156-9f53-28bdcdb665a6@oracle.com \
--to=joao.m.martins@oracle.com \
--cc=ankur.a.arora@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=dwmw2@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox