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] [Discussion]: dynamic shared_info_va

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [Discussion]: dynamic shared_info_va
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Fri, 5 May 2006 16:36:04 +0200
Delivery-date: Fri, 05 May 2006 07:32:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD5B2461F@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <516F50407E01324991DD6D07B0531AD5B2461F@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Vendredi 05 Mai 2006 16:09, Magenheimer, Dan (HP Labs Fort Collins) a écrit 
:
> 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.
Ok.

> 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.
I don't understand.  There are two areas: shared_info and shared_archinfo.
shared_info is per domain while shared_archinfo is per vcpu.

> To be complete, the same mechanism should be used for Linux
> to specify a default "break immediate" value for hypercalls.
Two possibilities:
encode immediate value in the __xen_guest section,
or use the imm of the first break (with a magic value).

Tristan.

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

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

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