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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Looks good!  The original design for shared_info (previously
known in vBlades as PSCB=privileged state control block) was
for the address to be specified by the guest before it goes
virtual and to default to a fixed known architected value
if it went virtual without the call..  I don't think it is necessary to
restrict the default mapping to be not-readable -- if
Linux is happy with the architected default, it should just use it.

Note that it may be possible to move some things around
to make shared_archinfo contiguous so that it can share
the same TR.  I think there was some discussion about this
on xen-ia64-devel (along with the above design) some months back.

To be complete, the same mechanism should be used for Linux
to specify a default "break immediate" value for hypercalls.


> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Tristan Gingold
> Sent: Friday, May 05, 2006 3:23 AM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-ia64-devel] [Discussion]: dynamic shared_info_va
> 
> 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
> 

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