linux-kernel - Re: [Xen-devel] [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

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: <56A6425F.4070203@oracle.com>
Date:	Mon, 25 Jan 2016 10:42:23 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>, konrad.wilk@...cle.com
Cc:	xen-devel@...ts.xenproject.org, mcgrof@...e.com,
	linux-kernel@...r.kernel.org, roger.pau@...rix.com
Subject: Re: [Xen-devel] [PATCH v1 02/12] xen/hvmlite: Factor out common
 kernel init code

On 01/25/2016 06:04 AM, David Vrabel wrote:
> On 22/01/16 21:35, Boris Ostrovsky wrote:
>> HVMlite guests (to be introduced in subsequent patches) share most
>> of the kernel initialization code with PV(H).
> Where possible, HVMlite should share initialization with bare metal/HVM
> and not PV(H).

This is really platform initialization, for HVMlite it's invoked as 
x86_init.oem.arch_setup(). Things like xen_setup_features(), 
xen_init_apic() etc.

I suppose I can move it to xen_hvm_guest_init() but then we will have 
some amount of code duplication. There is also a chunk of code there (in 
xen_init_kernel()) that will probably be used for HVMlite dom0.

>
> Sharing any code with the existing PVH code isn't useful, since PVH
> support will be removed.

There is nothing PVH-specific, I said "(H)" mostly because that code is 
the same is PV.

-boris