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: <20131218165807.GB4630@phenom.dumpdata.com>
Date:	Wed, 18 Dec 2013 11:58:07 -0500
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
Cc:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	xen-devel@...ts.xenproject.org, boris.ostrovsky@...cle.com,
	linux-kernel@...r.kernel.org, jbeulich@...e.com,
	david.vrabel@...rix.com
Subject: Re: [Xen-devel] [PATCH v11 02/12] xen/pvh: Define what an PVH guest
 is.

On Wed, Dec 18, 2013 at 04:01:03PM +0000, Ian Campbell wrote:
> On Wed, 2013-12-18 at 14:55 +0000, Stefano Stabellini wrote:
> > On Wed, 18 Dec 2013, Stefano Stabellini wrote:
> > > On Tue, 17 Dec 2013, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor <mukesh.rathor@...cle.com>
> > > > 
> > > > Which is a PV guest with auto page translation enabled
> > > > and with vector callback. It is a cross between PVHVM and PV.
> > > > 
> > > > The Xen side defines PVH as (from docs/misc/pvh-readme.txt,
> > > > with modifications):
> > > > 
> > > > "* the guest uses auto translate:
> > > >  - p2m is managed by Xen
> > > >  - pagetables are owned by the guest
> > > >  - mmu_update hypercall not available
> > > > * it uses event callback and not vlapic emulation,
> > > > * IDT is native, so set_trap_table hcall is also N/A for a PVH guest.
> > > > 
> > > > For a full list of hcalls supported for PVH, see pvh_hypercall64_table
> > > > in arch/x86/hvm/hvm.c in xen.  From the ABI prespective, it's mostly a
> > > > PV guest with auto translate, although it does use hvm_op for setting
> > > > callback vector."
> > > > 
> > > > We don't have yet a Kconfig entry setup as we do not
> > > > have all the parts ready for it - so we piggyback
> > > > on the PVHVM config option. This scaffolding will
> > > > be removed later.
> > > > 
> > > > Signed-off-by: Mukesh Rathor <mukesh.rathor@...cle.com>
> > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > > 
> > > Could you please add an "&& CONFIG_X86"?
> > 
> > On second thought, given that it is just temporary and that PVHVM is not
> > defined on ARM, it could be OK. But maybe it is worth adding a small
> > comment on the fact that this is an x86-only option.
> 
> I wonder if it should be CONFIG_XEN_X86_{PVH,PVHVM} instead?

Originally it was CONFIG_XEN_X86_PVH but I figured it would be pointless
as most of the changes were in arch/x86 and that is by default x86.

And then once that work is stabilized, ARM can kind of do the same thing - have
an CONFIG_XEN_PVH that would (hopefully) have the same ABI as x86 PVH?

Thought, you kind of already do PVH in spirit. Is that what you were
alluding too? As ARM already boots in PV and the page table manipulations
are done by the hardware.

?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ