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

[Xen-ia64-devel] [Discussion]: dynamic shared_info_va

To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-ia64-devel] [Discussion]: dynamic shared_info_va
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Fri, 5 May 2006 11:22:47 +0200
Delivery-date: Fri, 05 May 2006 02:18:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Hi,

currently, shared_info_va (or SHAREDINFO_ADDR) is a constant defined in Xen 
and used (through asm-xsi-offsets.h) by Linux.
I am working on a patch to remove this restriction: Linux will set where to 
place shared_info (and shared_archinfo).

Pros:
* Enable the use of shared_info in VTi.
* Possible optimization in Linux (be addressable through addl instead of movl)
* Allow to relocate Xen without recompiling Linux

Problems:
* Absolute constants must be removed (boring but easy).
* In kernel: do a hypercall to set the address, no other changes expected.

* In Xen: there are few use of shared_archinfo_va: mostly in ivt.S and 
hypercall.S.  There are two possibles implementation:
- shared_info/archinfo is mapped twice (one for Xen and one for Linux).  Not 
really elegant, requires two additionnal TR.
- Xen use Linux mapping.  Therefore an additionnal read is required.  The 
slowdown should be negligeable.  The linux mapping may be either in a percpu 
variable, updated at each context switch or within arch_vcpu struct.  The 
later requires another additionnal read, so the former seems better.

* Bootstrap: Xen may use shared_archinfo before Linux set the address.  Two 
solutions: Xen extract the address from Linux binary, or Xen use a default 
mapping before Linux sets the mapping.  I prefer the later, it seems easier 
to implement (note: to avoid problems the default mapping is not readable by 
Linux).

* interrupt_mask_addr is also an issue.  First it is a security issue, because 
it is used by Xen in CPL=0 and may be modified by Linux.  I propose to change 
the name (and the value!): interrupt_mask_offset.  The base is to be defined 
(either shared_info_addr or interrupt_mask_offset itself).

* Mapping: it seems reasonable to require shared_info be mapped in region 7.  
This simplifies region handling by Xen.  Also Xen should prevent Linux to map 
shared_info in Xen space.

* itc/ptc/itr/ptr from Linux are not allowed within shared_info area, because 
this area is tr-mapped!

Comments are welcome.

Tristan.



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

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