Hi Tristan,
vcpu->arch.metaphysical_saved_rr0 is the mangled version of rr[0].
The difference of this patch is whether the machine rr is set or not.
Before the patch:
IA64FAULT vcpu_itc_d(VCPU * vcpu, u64 pte, u64 itir, u64 ifa)
{
BOOLEAN swap_rr0 = (!(ifa >> 61) && PSCB(vcpu, metaphysical_mode));
...
if (swap_rr0)
/// at this point, machine rr0 is metaphysical_rr0.
set_one_rr(0, PSCB(vcpu, rrs[0]));
/// so, above set_one_rr() expects to set machine rr0 to PSCB(vcpu, rrs[0])
vcpu_itc_no_srlz(vcpu, 2, ifa, pteval, pte, _itir.itir, &entry);
if (swap_rr0)
set_metaphysical_rr0();
/// restore machine rr0
...
}
int set_one_rr(unsigned long rr, unsigned long val)
{
...
if (rreg == 0) {
/// below assignment is useless. it's already set before.
v->arch.metaphysical_saved_rr0 = vmMangleRID(newrrv.rrval);
/// this is the case of metaphysical_mode.
if (!PSCB(v,metaphysical_mode))
set_rr(rr,newrrv.rrval);
/// namely, set_one_rr does nothing.
...
}
-- Kouya
tgingold@xxxxxxx writes:
> Quoting Kouya Shimura <kouya@xxxxxxxxxxxxxx>:
>
> > On PV domain with metaphysical mode, emulation of itc.d in region 0
> > doesn't work well and inserts an wrong TC entry.
> > Because set_one_rr() doesn't set the machine region register.
> > i.e. metaphyisical_rr0 is used instead of guest's rr[0].
> >
> > This bug causes Dom0/U crash when an application uses region 0.
> > Actually I met the crash when I was building open GFW (java uses
> > region 0).
>
> I am a little bit puzzled. Isn't saved_rr0 supposed to be the mangled
> version
> of rr[0] ? Either this patch should be a no-op or the bug is somewhere else
> (or I am wrong).
>
> Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home