linux-kernel - Re: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes, elfnote changes, ...

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:	Fri, 12 Oct 2012 09:48:48 +0100
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Mukesh Rathor <mukesh.rathor@...cle.com>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"Xen-devel@...ts.xensource.com" <Xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes,
	elfnote changes, ...

On Thu, 2012-10-11 at 22:53 +0100, Mukesh Rathor wrote:
> PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate
> 
> Signed-off-by: Mukesh R <mukesh.rathor@...cle.com>

Since a S-o-b is a quasi-legal statement you probably ought to put your
full name here (I know it's obvious from the email address, but...)

> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..9323b8c 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && INTEL_IOMMU && EXPERIMENTAL

OOI why does the kernel side require an INTEL_IOMMU? I can see why the
hypervisor would need it but the guests (including dom0) can't actually
see the underlying IOMMU, can they?

> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMETNAL because the hypervisor interfaces

You've carried over my original "EXPERIMETNAL" typo.

> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..3e65ece 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include <xen/interface/elfnote.h>
>  #include <asm/xen/interface.h>
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "| writable_descriptor_tables" \
> +		     "| auto_translated_physmap" \
> +		     "| supervisor_mode_kernel" \
> +		     "| hvm_callback_vector"

It's pretty lame but it looks like elf_xen_parse_features doesn't
support stripping whitespace.

Since we need these features to be parsable by older hypervisors and
tools I think we're stuck with that snafu.

> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..3b9d5b6 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,16 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pvh_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **


--
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/