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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

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