linux-kernel - Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

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] [day] [month] [year] [list]

Message-ID: <56A959C0.70103@oracle.com>
Date:	Wed, 27 Jan 2016 18:58:56 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	Takashi Iwai <tiwai@...e.de>, Avi Kivity <avi@...hat.com>,
	Joerg Roedel <jroedel@...e.de>,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...e.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Cooper <andrew.cooper3@...rix.com>
Cc:	David Vrabel <david.vrabel@...rix.com>,
	Juergen Gross <jgross@...e.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Rusty Russell <rusty@...tcorp.com.au>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	xen-devel@...ts.xenproject.org,
	Roger Pau Monné <roger.pau@...rix.com>
Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/27/2016 02:00 PM, Luis R. Rodriguez wrote:
> On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
>> Worth mentioning here also is hpa's clarification on when subarch type
>> PC (0) should be used: [it should be used if the hardware is]
>> "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
>> a special boot flow" -- does that fit HVMLite's description so far? If
>> so then The Xen subarch may need to be redefined as well to be clear
>> what it means. I don't think we need to be precise but at the very
>> least cover grounds to enable the definitions to meet its actual use
>> to not confuse users.
> Another thing to consider for HVMlite is that if the 0 subarch (PC) is
> used in light of my linker table work and x86's use of it with the
> subarch and supported subarch bitmask, is that it would also mean
> HVMLite would run all routines currently pegged as needing PC type
> (the current KVM and bare metal path) and it would mean not running
> anything only pegged with Xen subarch type (but note that today Xen
> doesn't even set the subarch type). If there is nothing in common
> between PV and HVMlite (no x86 init calls to share), and if HVMLite
> *can* call *alllllllll* PC init calls, then by all means this is fine,

Yes, that's the idea. HVMlite jumps to startup_32|64 from the stub and 
runs from there with subarch 0.

-boris

> and if we just need to distinguish stuff between PC types that's fine,
> it may still be possible to further extend hypervisor_type to the x86
> init calls I'm adding as another supported_hyper_types to ensure even
> though a subarch is being used, that we also check the supported
> hypervisor type as well.
>
>   Luis