From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 19/20] PVH xen: elf and iommu related changes to prep for dom0 PVH Date: Thu, 16 May 2013 09:03:16 +0100 Message-ID: <5194AEE402000078000D6A33@nat28.tlf.novell.com> References: <1368579168-30829-1-git-send-email-mukesh.rathor@oracle.com> <1368579168-30829-20-git-send-email-mukesh.rathor@oracle.com> <519397E802000078000D6718@nat28.tlf.novell.com> <20130515185817.27b83538@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130515185817.27b83538@mantra.us.oracle.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mukesh Rathor Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 16.05.13 at 03:58, Mukesh Rathor wrote: > On Wed, 15 May 2013 13:12:56 +0100 > "Jan Beulich" wrote: > >> >>> On 15.05.13 at 02:52, Mukesh Rathor >> >>> wrote: >> > --- a/xen/arch/x86/setup.c >> > +++ b/xen/arch/x86/setup.c >> > @@ -60,6 +60,10 @@ integer_param("maxcpus", max_cpus); >> > static bool_t __initdata disable_smep; >> > invbool_param("smep", disable_smep); >> > >> > +/* Boot dom0 in PVH mode */ >> > +bool_t __initdata opt_dom0pvh; >> > +boolean_param("dom0pvh", opt_dom0pvh); >> >> Does this really belong here (instead of domain_build.c)? > > Yes, so we can pass the flag to domain_create() which sets the guest type: > > domcr_flags = (opt_dom0pvh ? DOMCRF_pvh | DOMCRF_hap : 0); > domcr_flags |= DOMCRF_s3_integrity; > dom0 = domain_create(0, domcr_flags, 0); The symbol is global, so use sites don't matter. And I continue to think that logically it belongs into domain_build.c. >> > + { >> > + unsigned long addr = (unsigned long)dst; >> > + early_pvh_copy_or_zero(addr, src, filesz); >> > + early_pvh_copy_or_zero(addr + filesz, NULL, memsz - >> > filesz); >> >> And anyway - repeating my earlier complaint - I don't see why this >> is necessary. In fact I don't see why most of the PV Dom0 building >> code can't be used unchanged for PVH: There's no real need for >> lifting the few restrictions that apply, and hence there needn't be >> any fear of colliding address spaces. > > Hmm... thats the best way I could come up with. If you want to prototype > something and replace what I've got, it's perfectly ok by me. There's nothing to prototype - just use the code that's there for PV Dom0. Jan