[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-ia64-devel] Memory problem with mini-os
- To: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
- 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;
- List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
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.
> 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.
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!
Xen-ia64-devel mailing list