WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Itsuro ODA <oda@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: handle x86_64 xen code/data relocation
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Tue, 20 May 2008 14:45:18 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, kexec@xxxxxxxxxxxxxxxxxxx, crash-utility@xxxxxxxxxx
Delivery-date: Mon, 19 May 2008 21:45:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080520131910.308D.ODA@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080422154506.BDB1.ODA@xxxxxxxxxxxxx> <20080520035837.GA29290@xxxxxxxxxxxx> <20080520131910.308D.ODA@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17+20080114 (2008-01-14)
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