Re: [Xen-ia64-devel] One unstablity in fast syscall path

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Mardi 13 Juin 2006 02:36, Tian, Kevin a écrit :
> Recently we kept seeing intermittent domU creation failure after
> creating
> VTI domain. After some debug, we found it caused by following
> changeset:
>
> changeset:   10238:b27139d8c1e1
> user:        awilliam@xxxxxxxxxxx
> date:        Sat Jun 03 11:16:47 2006 -0600
> summary:     [IA64] paravirtualize vdso
>
> There're several privileged accesses to vPSR in gate page, and
> previously it's done directly by triggering GP fault without xenlinux
> changes. Rev 10238 tries to para-virtualize those instructions by
> introducing two new hyperprivops. Now a simple assumption is forced to
> distinguish break immediate by checking vPSR.ic. People thought there's
> no break instruction with psr.ic off in xenlinux. So any break with
> vpsr.ic off
> is considered as a hyperprivop between domain and hypervisor. Based on
> this assumption, explicit vpsr.ic clearance is required before
> hypercall,
> and then recover required after.
>
> OK, that works, for most time because normally those hypercalls are
> issued within kernel text segment which is mapped by TR. So after
> hypervisor finished service for fast hypercall, xen can always RFI to
> exact
> resume point in xenlinux even when ITLB miss happens since that
> resume point can be found by vTR.
>
> However, gate page is not mapped by TR, and thus populating PSR.ic at
> non-TR-mapped segment is even mad in native environment. In our
> observation, when backing to gate page after servicing fast hypercall,
> ITLB miss happens but there's no guest entry in vTLB and VHPT. Thus
> xen injects a nested dtlb fault to xenlinux (vPSR.ic is still off) which
> is
> undesired to crash domU.
>
> That's the real problem, though we're not sure why this phenomenon is
> easier to be reproduced after creating VTI domain. Quick/easy solution
> can be to roll back above changeset to ensure tree stability first, and
> then
> community needs to think more robust solution later.
Good work !

After reading some Xen/ia64 source, I think we'd better not to use vpsr.ic for 
fast hypercall: it has some interractions with vpsr.ic flag!

I'd vote for creating a new paravirtualized register: xen_break (or 
xen_hyperprivop): when this new register is set, breaks are hyperprivop, when 
not set breaks are reflected.

Of course, changing the logic requires some work and careful checks.

Tristan.

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