linux-kernel - Re: [PATCH v2 3/4] x86/kvm/hyper-v: direct mode for synthetic timers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Nov 2018 09:43:35 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Roman Kagan <rkagan@...tuozzo.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org,
        Radim Krčmář <rkrcmar@...hat.com>,
        linux-kernel@...r.kernel.org,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>, x86@...nel.org,
        "Michael Kelley (EOSG)" <Michael.H.Kelley@...rosoft.com>
Subject: Re: [PATCH v2 3/4] x86/kvm/hyper-v: direct mode for synthetic timers

On 27/11/18 20:05, Roman Kagan wrote:
>>> Capabilities are a well-established and unambiguous negotiation
>>> mechanism, why invent another one?  Besides, not all features map
>>> conveniently onto cpuid bits, e.g. currently we have two versions of
>>> SynIC support, which differ in the way the userspace deals with it, but
>>> not in the cpuid bits we expose in the guest.  IMO such an ioctl would
>>> bring more complexity rather than less.
>>
>> Yes, in that case (for bugfixes basically) you'd have to use
>> capabilities.  But if the feature is completely hidden to userspace
>> except for the CPUID bit, it seems like a ioctl would be more consistent
>> with the rest of the KVM API.
> 
> So there will be some features that are more equal than others?

Well, it's already like that.  Some features have to be explicitly
KVM_ENABLE_CAP'd because userspace has to be aware of them.  But in many
cases they can be enabled blindly, and in that case a CPUID-based API
can help.

The CPUID-based API already works well for processor features, MSRs, KVM
paravirt features, etc.  Unfortunately we cannot just reuse
KVM_GET_SUPPORTED_CPUID because userspace expects KVM features to be at
0x40000000 rather than Hyper-V ones.

> I think that it's the current scheme which is more consistent: there are
> features that are implemented in KVM, and there are caps for negotiating
> them with userspace, and then -- separately -- there's a mix of bits to
> show to the guest in response to CPUID, which only the userspace has to
> bother with.

The only issue is how to present the "features that are implemented in
KVM".  Since they _are_ expressed as CPUID bits, it makes sense if
userspace only has to know about those instead of having both
capabilities and CPUID bits.

Paolo