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: <20160413185010.GX1990@wotan.suse.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ