From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
JBeulich@suse.com
Subject: Re: [V1 PATCH 06/11] PVH dom0: construct_dom0 changes
Date: Thu, 14 Nov 2013 18:21:43 -0800 [thread overview]
Message-ID: <20131114182143.4941871d@mantra.us.oracle.com> (raw)
In-Reply-To: <20131112161331.GC11354@phenom.dumpdata.com>
On Tue, 12 Nov 2013 11:13:31 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 08, 2013 at 05:23:31PM -0800, Mukesh Rathor wrote:
> > This patch changes construct_dom0 to boot in PVH mode. Changes
> > need to support it are also included here.
> >
> > Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
> > ---
> > xen/arch/x86/domain_build.c | 224
> > +++++++++++++++++++++++++++++++++++++++----
> > xen/arch/x86/domctl.c | 2 +- xen/arch/x86/mm/hap/hap.c
> > | 15 +++ xen/include/asm-x86/hap.h | 1 +
> > xen/include/xen/domain.h | 3 +
> > 5 files changed, 227 insertions(+), 18 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain_build.c
> > b/xen/arch/x86/domain_build.c index c9ff680..d7c62d1 100644
> > --- a/xen/arch/x86/domain_build.c
> > +++ b/xen/arch/x86/domain_build.c
> > @@ -35,6 +35,7 @@
> > #include <asm/setup.h>
> > #include <asm/bzimage.h> /* for bzimage_parse */
> > #include <asm/io_apic.h>
> > +#include <asm/hap.h>
> >
> > #include <public/version.h>
> >
> > @@ -307,6 +308,140 @@ static void __init
> > process_dom0_ioports_disable(void) }
> > }
> >
> > +/*
> > + * Set the 1:1 map for all non-RAM regions for dom 0. Thus, dom0
> > will have
> > + * the entire io region mapped in the EPT/NPT.
> > + *
> > + * PVH FIXME: The following doesn't map MMIO ranges when they sit
> > above the
> > + * highest E820 covered address.
> > + */
> > +static __init void pvh_map_all_iomem(struct domain *d)
> > +{
> > + unsigned long start_pfn, end_pfn, end = 0, start = 0;
> > + const struct e820entry *entry;
> > + unsigned int i, nump;
> > + int rc;
> > +
> > + for ( i = 0, entry = e820.map; i < e820.nr_map; i++, entry++ )
> > + {
> > + end = entry->addr + entry->size;
> > +
> > + if ( entry->type == E820_RAM || entry->type ==
> > E820_UNUSABLE ||
> > + i == e820.nr_map - 1 )
> > + {
> > + start_pfn = PFN_DOWN(start);
> > +
> > + /* Unused RAM areas are marked UNUSABLE, so skip it
> > too */
> > + if ( entry->type != E820_RAM && entry->type !=
> > E820_UNUSABLE )
>
> The conditional above is of: if ( .. == E820_RAM || .. E820_UNUSABLE )
>
> why not replicate it here as well? This way it follows the same logic:
>
> if ( entry->type == E820_RAM || entry->type == E820_UNUSABLE)
> end_pfn = PFN_UP(entry->addr);
> else
> end_pfn = PFN_UP(end);
Yeah, OK.
> > + end_pfn = PFN_UP(end);
> > + else
> > + end_pfn = PFN_UP(entry->addr);
> > +
> > + if ( start_pfn < end_pfn )
> > + {
> > + nump = end_pfn - start_pfn;
> > + /* Add pages to the mapping */
> > + rc = update_memory_mapping(d, start_pfn,
> > start_pfn, nump, 1);
> > + BUG_ON(rc);
> > + }
> > + start = end;
> > + }
> > + }
> > +
> > + /* If the e820 ended under 4GB, we must map the remaining
> > space upto 4GB */
>
> Could you explain a bit more of 'why'? What if the machine only has
> 3GB and we want to boot dom0 with 512MB.
That's fine. We are mapping the non-ram region, beyond last e820 entry.
Jan, you had pointed this out in earlier review. With the other patch
addressing mmio space above last e820 mapping, this will not be needed
anymore right? can I just remove it from the next patch version then?
thanks
Mukesh
next prev parent reply other threads:[~2013-11-15 2:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-09 1:23 [V1 PATCH 0/11]: PVH dom0 Mukesh Rathor
2013-11-09 1:23 ` [V1 PATCH 01/11] PVH dom0: set eflags resvd bit #1 Mukesh Rathor
2013-11-12 16:19 ` Konrad Rzeszutek Wilk
2013-11-12 16:24 ` Jan Beulich
2013-11-12 16:31 ` Konrad Rzeszutek Wilk
2013-11-09 1:23 ` [V1 PATCH 02/11] PVH dom0: Allow physdevops for PVH dom0 Mukesh Rathor
2013-11-09 1:23 ` [V1 PATCH 03/11] PVH dom0: iommu related changes Mukesh Rathor
2013-11-12 16:08 ` Jan Beulich
2013-11-15 1:43 ` Mukesh Rathor
2013-11-15 7:36 ` Jan Beulich
2013-11-09 1:23 ` [V1 PATCH 04/11] PVH dom0: create update_memory_mapping() function Mukesh Rathor
2013-11-12 16:12 ` Jan Beulich
2013-11-15 1:59 ` Mukesh Rathor
2013-11-15 7:38 ` Jan Beulich
2013-11-09 1:23 ` [V1 PATCH 05/11] PVH dom0: move some pv specific code to static functions Mukesh Rathor
2013-11-09 1:23 ` [V1 PATCH 06/11] PVH dom0: construct_dom0 changes Mukesh Rathor
2013-11-12 16:13 ` Konrad Rzeszutek Wilk
2013-11-15 2:21 ` Mukesh Rathor [this message]
2013-11-15 7:59 ` Jan Beulich
2013-11-12 16:35 ` Jan Beulich
2013-11-15 2:34 ` Mukesh Rathor
2013-11-15 7:40 ` Jan Beulich
2013-11-09 1:23 ` [V1 PATCH 07/11] PVH dom0: implement XENMEM_add_to_physmap_range for x86 Mukesh Rathor
2013-11-12 16:46 ` Jan Beulich
2013-11-09 1:23 ` [V1 PATCH 08/11] PVH dom0: Introduce p2m_map_foreign Mukesh Rathor
2013-11-12 16:16 ` Konrad Rzeszutek Wilk
2013-11-09 1:23 ` [V1 PATCH 09/11] PVH dom0: Add and remove foreign pages Mukesh Rathor
2013-11-12 16:58 ` Jan Beulich
2013-11-09 1:23 ` [V1 PATCH 10/11] PVH dom0: add opt_dom0pvh to setup.c Mukesh Rathor
2013-11-12 16:18 ` Konrad Rzeszutek Wilk
2013-11-14 11:38 ` [V1 PATCH 0/11]: PVH dom0 Roger Pau Monné
2013-11-14 22:42 ` Mukesh Rathor
2013-11-15 7:55 ` Jan Beulich
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=20131114182143.4941871d@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=JBeulich@suse.com \
--cc=Xen-devel@lists.xensource.com \
--cc=keir.xen@gmail.com \
--cc=konrad.wilk@oracle.com \
--cc=tim@xen.org \
/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).