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: Tue, 21 May 2013 08:14:38 +0100 Message-ID: <519B3AFE02000078000D77E6@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> <5194AEE402000078000D6A33@nat28.tlf.novell.com> <20130517190119.736d23c7@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130517190119.736d23c7@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 18.05.13 at 04:01, Mukesh Rathor wrote: > On Thu, 16 May 2013 09:03:16 +0100 > "Jan Beulich" wrote: > >> >>> On 16.05.13 at 03:58, Mukesh Rathor >> >>> wrote: >> > On Wed, 15 May 2013 13:12:56 +0100 >> > "Jan Beulich" wrote: >> > >> >> > + { >> >> > + 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. > > Not sure if you are referring to just changes in elf_load_image(): > > + if ( opt_dom0pvh ) > + { > + unsigned long addr = (unsigned long)dst; > + early_pvh_copy_or_zero(addr, src, filesz); > + early_pvh_copy_or_zero(addr + filesz, NULL, memsz - filesz); > + > + return 0; > + } > + > rc = raw_copy_to_guest(dst, src, filesz); > > or all changes including construct_dom0() also? The part above is particularly ugly, but indeed I think you can only get all or nothing here. > As the comment says, for elf_load_image() we need early_pvh_copy_or_zero > because it's too early in boot and construct_dom0() is running on idle > vcpu where curr points to. > > If that doesn't address your concern, please elaborate. The fact that we're running on the idle vCPU here isn't any different for PV Dom0. As much as PV Dom0 setup temporarily switches to Dom0's page tables, I would imagine PVH Dom0 setup could do so too, provided you don't lift the address space restrictions (which in theory you could do, but in practice I don't see any need for). That should allow having the PVH changes to Dom0 setup be a single code fragment (adjusting Dom0 page tables from using machine addresses to physical ones _after_ all other setup was done). Jan