[Xen-devel] Re: handle x86_64 xen code/data relocation

[Simon Horman <horms@xxxxxxxxxxxx>]

On Tue, May 20, 2008 at 01:39:26PM +0900, Itsuro ODA wrote:
> Hi all,
> 
> On Tue, 20 May 2008 13:58:39 +1000
> Simon Horman <horms@xxxxxxxxxxxx> wrote:
> 
> > On Tue, Apr 22, 2008 at 05:32:03PM +0900, Itsuro ODA wrote:
> > > Hi all,
> > > 
> > > Recent version of xen (ex. RHEL5.2, 3.2.0) on the x86_64
> > > moves the physical(machine) address of xen code/data area after 
> > > the system started up. The start address of this is stored in
> > > 'xen_phys_start'. Thus to get a machine address of a xen text symbol
> > > from its virtual address, calculate 
> > > "va - __XEN_VIRT_START +  xen_phys_start".
> > > 
> > > crash and makedumpfile command need the value of xen_phys_start.
> > > They know the virtual address of 'xen_phys_start' symbol but
> > > no way to extract the value of xen_phys_start.
> > > 
> > > I think adding the xen_phys_start value to the CRASHINFO ElfNote
> > > section at first. (Plan A: patch for xen hypervisor code attaced)
> > > It is smallest modification necessary over all.
> > > 
> > > On the other hand there is a opinion that it is better to upgrade
> > > a user-package than a hypervisor or kernel package.
> > > The xen_phys_start value can be got from /proc/iomem.
> > >     -------------------------------------------------------
> > >     # cat /proc/iomem
> > >     ...
> > >       7e600000-7f5fffff : Hypervisor code and data  *** this line
> > >     ...
> > >     -------------------------------------------------------
> > > So the kexec-tools can handle it theoretically.
> > > 
> > > The Plan B is that kexec-tools adds another ElfNote section which
> > > holds the xen_phys_start value. The attached patch works well
> > > though I am concern about it is a bit tricky.
> > > 
> > > Which plan is better ?  Or more good implementation ?
> > > Please comment.
> > > 
> > > (note that crash and makedumpfile modification is same degree
> > > for both plan.)
> > 
> > Hi Oda-san,
> > 
> > I think that in terms of simplicity plan A is a clear
> > winner. That is assuming tha the changes to crash
> > and makedumpfile are more or less the same for both
> > plan A and plan B.
> 
> The changes to crash and makedumpfile is almost same
> for both plan A and plan B.
> 
> Yes, Plan A is simple.
> The point under discussion is that the already released 
> versions of xen need to apply the fix, and from the view point
> of the users for such versions they may prefer to update 
> the kexec-tools rather than the hypervisor.
> 
> > However, if there is a reason that it makes sense to include
> > the change in kexec-tools and make a fresh release, I'm happy to do so.
> 
> Thanks.
> 
> I am concerned about the changes of the Plan B is little tricky. 
> So I will think that the changes become simpler or more reasonable.

Yes, i am concerned about that too.

-- 
宝曼 西門 (ホウマン・サイモン) | Simon Horman (Horms)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel