linux-kernel - Re: [RFC PATCH v2 0/2] KVM: x86: Allow Qemu/KVM to use PVH entry point

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]

Message-ID: <a506ad26-5e33-d99d-64a8-cefc3fa42c87@oracle.com>
Date:   Fri, 8 Dec 2017 14:21:45 -0500
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Maran Wilson <maran.wilson@...cle.com>, pbonzini@...hat.com,
        jgross@...e.com, roger.pau@...rix.com, andrew.cooper3@...rix.com,
        hch@...radead.org, x86@...nel.org, xen-devel@...ts.xenproject.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        rkrcmar@...hat.com, JBeulich@...e.com
Subject: Re: [RFC PATCH v2 0/2] KVM: x86: Allow Qemu/KVM to use PVH entry
 point

On 12/07/2017 05:45 PM, Maran Wilson wrote:
>
> Juergen also had a suggestion to split the different hypervisor types
> early and use a common set of service functions instead of special casing
> xen_guest everywhere.
>
> There are certainly less special cases in this version of the patch, but
> if we still think it's important to split things up between common, Xen,
> and KVM components, then I would appreciate a suggestion on how best that
> can be done. Are we talking about just re-factoring functions in the
> existing file? Or do we need to go all the way and pull all the PVH entry
> code out of xen directories and find a home for it somewhere else so that
> we can use kernels built without CONFIG_XEN to start KVM guests via the
> PVH entry point. If the latter, any suggestions for which common files or
> directories I can move this stuff to?

I wonder whether the time has come for arch/x86/virt/

xen/
kvm/
hyperv/
kernel/paravirt*
kernel/cpu/hypervisor.c

-boris