From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Roman Kagan <rkagan@virtuozzo.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Liran Alon <liran.alon@oracle.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH RFC] i386/kvm: fix enlightened VMCS with fine-grained VMX feature enablement
Date: Tue, 07 Jan 2020 19:15:40 +0100 [thread overview]
Message-ID: <87imlnrv3n.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <7c4dcca1-a1e6-a00c-56fd-bcc6c8bcc474@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 07/01/20 13:08, Vitaly Kuznetsov wrote:
>> Honestly I forgot the story why we filtered out these features upon
>> eVMCS enablement in KVM. As there are no corresponding eVMCS fields,
>> there's no way a guest can actually use them.
>
> Well, mostly because we mimicked what Hyper-V was doing I guess.
>
An update from reverse-engineering trenches.
I ran some tests to see if we can just drop the filtering and there is
only one problematic control which Hyper-V enables:
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES
the problem with it is that we don't have 'apic_access_addr' field in
eVMCS ('virtual_apic_page_addr' is there). By running the same setup
with eVMCS disabled I figured out which address can be hardcoded to make
it boot. My guess was that the fields is present but not documented
properly, I tried scanning eVMCS for the value but with no luck so far.
I'll try to fish some information out of Microsoft.
--
Vitaly
next prev parent reply other threads:[~2020-01-07 18:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-02 20:39 [PATCH RFC] i386/kvm: fix enlightened VMCS with fine-grained VMX feature enablement Vitaly Kuznetsov
2020-01-07 8:31 ` Paolo Bonzini
2020-01-07 12:08 ` Vitaly Kuznetsov
2020-01-07 12:25 ` Paolo Bonzini
2020-01-07 18:15 ` Vitaly Kuznetsov [this message]
2020-01-07 21:23 ` Paolo Bonzini
2020-01-08 10:32 ` Vitaly Kuznetsov
2020-01-10 15:02 ` Vitaly Kuznetsov
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=87imlnrv3n.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=ehabkost@redhat.com \
--cc=liran.alon@oracle.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkagan@virtuozzo.com \
--cc=rth@twiddle.net \
/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.