linux-kernel - Re: [Xen-devel] HVMLite / PVHv2

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, 13 Apr 2016 20:50:10 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Roger Pau Monné <roger.pau@...rix.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	George Dunlap <george.dunlap@...rix.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Michael Chang <MChang@...e.com>,
	Julien Grall <julien.grall@....com>,
	Jan Beulich <JBeulich@...e.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Vojtěch Pavlík <vojtech@...e.cz>,
	Gary Lin <GLin@...e.com>,
	xen-devel <xen-devel@...ts.xenproject.org>,
	Jeffrey Cheung <JCheung@...e.com>,
	Charles Arndol <carnold@...e.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Jim Fehlig <jfehlig@...e.com>, joeyli <jlee@...e.com>,
	Borislav Petkov <bp@...en8.de>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Juergen Gross <jgross@...e.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	David Vrabel <david.vrabel@...rix.com>,
	Takashi Iwai <tiwai@...e.de>, jeffm@...e.com,
	torvalds@...ux-foundation.org,
	Julien Grall <julien.grall@...aro.org>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 13, 2016 at 11:54:29AM +0200, Roger Pau Monné wrote:
> On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
> > OK thanks for the clarification -- still no custom entries for Xen!
> > We should strive for that, at the very least.
> > 
> > You do have a point about the legacy stuff. There are two options there:
> > 
> >   * Fold legacy support under HVMLite -- which seems to be what we
> >     currently want to do (we should evaluate the implications and
> >     requirements here for that); or
> 
> I'm not following here. What does it mean to fold legacy support under 
> HVMlite? HVMlite doesn't have any legacy hardware, and that's the issue when 
> it comes to using native Linux entry points. Linux might expect some legacy 
> PC hardware to be always present, which is not true for HVMlite.
> 
> Could you please clarify this point?

It seems there is a confusion on terms used. By folding legacy support under
HVMLite I meant folding legacy PV path (classic PV with PV interfaces) under
HVMlite.

I got the impression that if we wanted to remove the old PV path we had to see
if we can address old classic PV x86 guests through HVMlite, otherwise we'd
have to live with the old PV path for the long term.

> >   * Leave legacy stuff on the old PV path; this may be something to
> >     bring to the table if we had in place a proactive solution to
> >     avoid further fallout from the architecture of the huge differences
> >     on the entries. The work I'm doing should help with that. (We should
> >     also evaluate the implications and requirements here for that as
> >     well).
> 
> Classic PV guests don't have legacy hardware at all, they just have PV 
> interfaces, so I'm even less sure of what this means.

Using the terms you use by "Leave legacy stuff on the old PV path" I meant 
not having to address classic PV guest support through HVMLite.

  Luis