linux-kernel - Re: [PATCH v8 0/7] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <63756df6-6f0b-fdfa-932e-b53d173da5be@redhat.com>
Date:   Thu, 6 Dec 2018 23:14:34 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Borislav Petkov <bp@...en8.de>
Cc:     Maran Wilson <maran.wilson@...cle.com>, x86@...nel.org,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, jgross@...e.com, bp@...e.de,
        dave.hansen@...ux.intel.com, davem@...emloft.net,
        gregkh@...uxfoundation.org, hpa@...or.com, jpoimboe@...hat.com,
        kirill.shutemov@...ux.intel.com, luto@...nel.org,
        mchehab@...nel.org, mingo@...hat.com, rdunlap@...radead.org,
        tglx@...utronix.de, thomas.lendacky@....com, hch@...radead.org,
        roger.pau@...rix.com, rkrcmar@...hat.com
Subject: Re: [PATCH v8 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 06/12/18 22:58, Boris Ostrovsky wrote:
> On 12/6/18 4:37 PM, Borislav Petkov wrote:
>> On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote:
>>> Thanks!  I should be able to post a Tested-by next Monday.  Boris, are
>>> you going to pick it up for 4.21?
>> Boris me or Boris O.?
>>
>> :-)
>>
> 
> O. ;-)
> 
> There are some minor changes in non-xen x86 code so it would be good to
> get x86 maintainers' ack.

It's not really code, only Kconfig (and I remarked on it just now), but
it doesn't hurt of course.

> And as far as qemu/qboot changes, should we assume that the general
> approach is acceptable? I understand that the patches will probably need
> to go through some iterations but I want to make sure we have a path
> forward there.

Yes, the general approach is fine.  I have already reviewed the qboot
parts, I guess we will also want an option ROM similar to
linuxboot/multiboot for SeaBIOS support but that's simple matter of
programming. :)

Paolo