From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kvm/x86: reserve bit KVM_HINTS_PHYS_ADDRESS_SIZE_DATA_VALID
Date: Tue, 13 Sep 2022 11:40:30 +0200 [thread overview]
Message-ID: <87a673r4s1.fsf@redhat.com> (raw)
In-Reply-To: <YxtTfn+cckhBY+BW@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Fri, Sep 09, 2022, Vitaly Kuznetsov wrote:
...
>> While this certainly looks like an overkill here, we could probably add
>> new, VMM-spefific CPUID leaves to KVM, e.g.
>>
>> 0x4000000A: VMM signature
>> 0x4000000B: VMM features
>> 0x4000000C: VMM quirks
>> ...
>>
>> this way VMMs (like QEMU) could identify themselves and suggest VMM
>> specific things to guests without KVM's involvement. Just if 'fw_cfg' is
>> not enough)
>
> I don't think KVM needs to get involved in that either. The de facto hypervisor
> CPUID standard already allows for multiple hypervisors/VMMs to announce themselves
> to the guest, e.g. QEMU could add itself as another VMM using 0x40000100 (shifted
> as necessary to accomodate KVM+Hyper-V).
True, VMM can just use another hypervisor space (+0x100) but we can view
it from a slightly different angle: KVM itself is insufficient to run
VMs, there's always a VMM in the background, we may want to provide a
"standard" for its information meaning guests won't need to search for
VMMs signature[s] but can directly refer to "standardized" leaves.
(All this is a purely theoretical discussion at this point, we need a
good reason to introduce this first).
--
Vitaly
next prev parent reply other threads:[~2022-09-13 9:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 11:41 [PATCH] kvm/x86: reserve bit KVM_HINTS_PHYS_ADDRESS_SIZE_DATA_VALID Gerd Hoffmann
2022-09-08 14:52 ` Sean Christopherson
2022-09-09 5:02 ` Gerd Hoffmann
2022-09-09 9:02 ` Vitaly Kuznetsov
2022-09-09 14:53 ` Sean Christopherson
2022-09-13 9:40 ` Vitaly Kuznetsov [this message]
2022-09-21 13:42 ` Gerd Hoffmann
2022-09-21 15:00 ` Sean Christopherson
2022-09-21 16:32 ` Jim Mattson
2022-09-22 5:40 ` Xiaoyao Li
2022-09-22 12:24 ` 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=87a673r4s1.fsf@redhat.com \
--to=vkuznets@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/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.