xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v1 4/8]: PVH setup changes...
Date: Tue, 25 Sep 2012 09:22:24 -0400	[thread overview]
Message-ID: <20120925132214.GA20515@phenom.dumpdata.com> (raw)
In-Reply-To: <20120921121752.5fa80b35@mantra.us.oracle.com>

On Fri, Sep 21, 2012 at 12:17:52PM -0700, Mukesh Rathor wrote:
> 
> ---
>  arch/x86/xen/setup.c |   51 ++++++++++++++++++++++++++++++++++++++++++-------
>  1 files changed, 43 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index ead8557..fba442e 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -26,6 +26,7 @@
>  #include <xen/interface/memory.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/features.h>
> +#include "mmu.h"
>  #include "xen-ops.h"
>  #include "vdso.h"
>  
> @@ -222,6 +223,26 @@ static void __init xen_set_identity_and_release_chunk(
>  	*identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> +/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> + * are released as part of this 1:1 mapping hypercall back to the dom heap. We
> + * don't use the xen_do_chunk() PV does above because when P2M/EPT/NPT is 
> + * updated, the mfns are already lost as part of the p2m update.
> + * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> + */
> +static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> +		unsigned long end_pfn, unsigned long *released, 
> +		unsigned long *identity)
> +{
> +	unsigned long pfn;
> +	int numpfns=1, add_mapping=1;
> +
> +	for (pfn = start_pfn; pfn < end_pfn; pfn++)
> +		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> +
> +	*released += end_pfn - start_pfn;

So this will feed in the populate method that will try to populate back
the amount that were released (xen_populate_chunk). Is that OK? You
mention that we do not want to call 'xen_do_chunk()' but the
'xen_populate_chunk' would do that for XENMEM_populate_physmap call.

The modifcation of *released also ends up modifying the "xen_released_pages"
value which is a global value that the balloon driver ends up using so
we have to be carefull?

Perhaps we should just do this (on top of this patch) for right now:

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..3d33ac6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -103,6 +103,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* The xen_set_clr_mmio_pvh_pte did the job for us. */
+		if (release)
+			return end - start;
+		/* And we do not populate back here.. Meaning that the
+ 		 * later balloon driver can do it based on xen_released_pages.
+ 		 * This will be fixed in the future. */
+		return 0;
+	}
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
 		unsigned long mfn = pfn_to_mfn(pfn);


> +	*identity += end_pfn - start_pfn;
> +}
> +
>  static unsigned long __init xen_set_identity_and_release(
>  	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
>  {
> @@ -230,6 +251,7 @@ static unsigned long __init xen_set_identity_and_release(
>  	unsigned long identity = 0;
>  	const struct e820entry *entry;
>  	int i;
> +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	/*
>  	 * Combine non-RAM regions and gaps until a RAM region (or the
> @@ -251,11 +273,16 @@ static unsigned long __init xen_set_identity_and_release(
>  			if (entry->type == E820_RAM)
>  				end_pfn = PFN_UP(entry->addr);
>  
> -			if (start_pfn < end_pfn)
> -				xen_set_identity_and_release_chunk(
> -					start_pfn, end_pfn, nr_pages,
> -					&released, &identity);
> -
> +			if (start_pfn < end_pfn) {
> +				if (xlated_phys) {
> +					xen_pvh_identity_map_chunk(start_pfn, 
> +						end_pfn, &released, &identity);
> +				} else {
> +					xen_set_identity_and_release_chunk(
> +						start_pfn, end_pfn, nr_pages,
> +						&released, &identity);

Might as well just move this in the xen_set_identity_and_release_chunk
function. Meaning, leave this function along and just modify
xen_set_identity_and_release_chunk to do the modifications, like this:


diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..3db3f46 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -103,6 +103,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* The xen_set_clr_mmio_pvh_pte did the job for us. */
+		if (release)
+			return end - start;
+		/* And we do not populate back here.. Meaning that the
+ 		 * later balloon driver can do it based on xen_released_pages.
+ 		 * This will be fixed in the future. */
+		return 0;
+	}
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -218,11 +227,15 @@ static void __init xen_set_identity_and_release_chunk(
 	 * If the PFNs are currently mapped, the VA mapping also needs
 	 * to be updated to be 1:1.
 	 */
-	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
-		(void)HYPERVISOR_update_va_mapping(
-			(unsigned long)__va(pfn << PAGE_SHIFT),
-			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
-
+	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
+		if (xen_feature(XENFEAT_auto_translated_physmap)) {
+			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1, 1);
+		} else {
+			(void)HYPERVISOR_update_va_mapping(
+				(unsigned long)__va(pfn << PAGE_SHIFT),
+				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
+		}
+	}
 	if (start_pfn < nr_pages)
 		*released += xen_release_chunk(
 			start_pfn, min(end_pfn, nr_pages));
> +				}
> +			}
>  			start = end;
>  		}
>  	}
> @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
>  #endif /* CONFIG_X86_64 */
>  }
>  
> -void __init xen_arch_setup(void)
> +/* Non auto translated PV domain, ie, it's not PVH. */
> +static __init void inline xen_non_pvh_arch_setup(void)
>  {
> -	xen_panic_handler_init();
> -
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
>  
> @@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
>  
>  	xen_enable_sysenter();
>  	xen_enable_syscall();
> +}
> +
> +/* This function not called for HVM domain */
> +void __init xen_arch_setup(void)
> +{
> +	xen_panic_handler_init();
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		xen_non_pvh_arch_setup();
>  

I am not sure what the syscall functions have to do with parsing of the
E820.

You should split this patch in two - one that deals with the E820
parsing and another that deails with the setup of syscalls.

>  #ifdef CONFIG_ACPI
>  	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> -- 
> 1.7.2.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

  parent reply	other threads:[~2012-09-25 13:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-21 19:17 [PATCH v1 4/8]: PVH setup changes Mukesh Rathor
2012-09-24 12:14 ` Stefano Stabellini
2012-09-24 22:48   ` Mukesh Rathor
2012-09-25 13:22 ` Konrad Rzeszutek Wilk [this message]
2012-10-02 10:51 ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120925132214.GA20515@phenom.dumpdata.com \
    --to=konrad@kernel.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=Xen-devel@lists.xensource.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mukesh.rathor@oracle.com \
    --cc=stefano.stabellini@eu.citrix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).