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-ia64-devel

Re: [Xen-ia64-devel] Memory problem with mini-os

To: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Subject: Re: [Xen-ia64-devel] Memory problem with mini-os
From: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 2 Oct 2006 13:54:46 +0200
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 02 Oct 2006 04:55:11 -0700
Domainkey-signature: s=s768; d=fujitsu-siemens.com; c=nofws; q=dns; b=JAGAMolCNH+kx4cb0psvcLegqYgPbHxhTic/XfRMP6fR4e7YAdAxhLcSLSNDAW5h7LkvX/7mNKEm2PTmgboFFs+pFCBnPrQtSrfmIGW/fgSCvh1tyXs+kilMDt57VCv7;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200610020957.37609.Tristan.Gingold@xxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200610020935.21814.dietmar.hahn@xxxxxxxxxxxxxxxxxxx> <200610020957.37609.Tristan.Gingold@xxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.4
Am Montag, 2. Oktober 2006 09:57 schrieb Tristan Gingold:
> Le Lundi 02 Octobre 2006 09:35, Dietmar Hahn a écrit :
> > Hi,
> >
> > after my vacation I switched from xen-ia64 change-set 11039 to 11635.
> > And now I have a problem with my mini-os executing the efi/pal code
> > (currently the getTime - function from efi). Every time the function gets
> > called I get an trap 22 (Instruction access rights vector). The strange
> > thing is that the trap also occurs if I don't do the mapping of the pal
> > code.
> > I inserted some trace messages in vcpu_itr_i() in xen to see all
> > parameters. But it looks ok.
> > For a test I removed the call of in ia64_itr() in efi_map_pal_code() in
> > the linux code and nevertheless efi_gettimeofday() runs fine (linux as
> > domU). It seems, there is another tlb entry for this page.
> > I saw that the pal/efi stuff was reorganized in the new change-set.
> > Can anybody give me a hint where to look in the memory handling or do
> > some trace messages! I'm currently still not familiar enough with this
> > stuff.
>
> Hi,
>
> After your comments I have reorganized fw memory.
To much honour ;-),

> The PAL/SAL/EFI firmware is now between 0 and 4Kb.
> ACPI and system tables are between 4Kb and 12Kb.
> Because the size is very small there might be an entry in the TLB even
> without the itr.
>
> I think you should start debugging gu understand where and why the fault
> occurs.  You may modify Xen to disp more details when a fault is reflected.
>
> Tristan.

I think I understand the problem!
I use the Alternate Data TLB trap for the data translations needed for 
efi/pal/sal/acpi. These translations are done with access rights RW. In XEN 
ITC and DTC seem to be unified, so the data tlb entry is used for the 
translation of the efi-code. And there is no X bit set -> trap 22.
If I set RWX for the access rights of the data translations all runs well.
The better way is a ptc.l before mapping of the pal code via a itr.i!
Thanks.

DIetmar.

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

<Prev in Thread] Current Thread [Next in Thread>