Dom0 no longer boots for me with the latest changes. Normally I
would get errors like:
Setting up X server socket directory /tmp/.X11-unix...vcpu_translate: bad
address 0000000000000000, viip=2000000000604390, vipsr=0000001308026018,
iip=a0000001002d46e0, ipsr=0000101208226018 continuing
done.
Setting up ICE socket directory /tmp/.ICE-unix...(XEN) vcpu_translate: bad
address 0000000000000000, viip=2000000000604390, vipsr=0000001308026038,
iip=a0000001002d46e0, ipsr=0000101208226038 continuing
done.
...
Starting Distributed Compiler Daemon: distccd(XEN) vcpu_translate: bad address
0000000000000000, viip=2000000000604390, vipsr=0000001308026038,
iip=a0000001002d46e0, ipsr=0000101208226038 continuing
.
and it would keep booting, whereas with the latest vcpu_translate
changes it dies there. The reason being that vcpu_translate
no longer inserts a physical mapping in the "bad address" case...
previously it would just map page 0 at 0 and Linux would keep
going :)
This raises two issues:
- The null-pointer dereferences in __strncpy_from_user, which
is the root cause of this. Does anyone know the cause? Maybe
it's normal? Usually it would just return -EFAULT to the user,
so maybe it's just libc/application brokenness that happens on
real hardware too.
- Xen handling of NULL pointer dereferences is wrong. If I recall
correctly from vNUMA, we should be delivering a NaT consumption
fault, because Linux maps a NaTpage at 0. Ideally the NaTpage
memory attribute should be propagated into the real mapping, and
then we can reflect the NaT consumption fault directly to Linux.
If we deliver a TLB miss as we are doing, Linux will just try to
repeatedly reinsert that mapping.
Matt
On Wed, Nov 09, 2005 at 01:38:26PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> Hmmm... by changing the metaphysical address handling code
> in vcpu_translate, I seem to have uncovered a latent bug:
> Sometimes vcpu_translate is being called with a virtual
> address even though the domain is in metaphysical mode.
> Previously these were incorrectly(?) just direct mapped.
>
> Rather than back out the changes, I have changed the panic
> to a printk. If you see some "vcpu_translate: bad physical
> address" messages, don’t be surprised, but you can ignore
> it unless you want to help track down and fix the problem.
>
> Mmap09 is not printing this message so the problem is
> (apparently) unrelated.
>
> Dan
>
> > -----Original Message-----
> > From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
> > Of Magenheimer, Dan (HP Labs Fort Collins)
> > Sent: Wednesday, November 09, 2005 11:29 AM
> > To: Xu, Anthony
> > Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [Xen-ia64-devel] RE: vcpu_translate issue
> >
> > FYI, in case anyone else might look at this:
> >
> > I made a fix so that vcpu_translate supports region0
> > (and doesn't print out the message), but ltp-mmap09
> > still doesn't work (goes into a silent infinite loop).
> >
> > I don't have access to a hardware debugger right
> > now so have committed the change in case anyone
> > else is able to look at mmap09 in more detail.
> >
> > Dan
> >
> > > -----Original Message-----
> > > From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> > > Sent: Friday, November 04, 2005 11:56 PM
> > > To: Magenheimer, Dan (HP Labs Fort Collins)
> > > Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: RE: vcpu_translate issue
> > >
> > > Dan,
> > >
> > > I just want to run some testcases like ltp to make dom0 more
> > > stable. If this is the case I have no choice but to defer
> > those tests.
> > >
> > >
> > > Thanks
> > > Anthony
> > >
> > > >-----Original Message-----
> > > >From: Magenheimer, Dan (HP Labs Fort Collins)
> > > [mailto:dan.magenheimer@xxxxxx]
> > > >Sent: 2005年11月4日 22:13
> > > >To: Xu, Anthony
> > > >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > > >Subject: RE: vcpu_translate issue
> > > >
> > > >The warning is there because the current code doesn't yet
> > > >work properly for a region 0 virtual address. Even
> > > >if you remove the printf, I don't think ltp mmap09 will
> > > >work properly because the current code assumes
> > > >incorrectly that every region 0 access is a guest
> > > >physical access. Bug! I think this is the first time
> > > >we have seen a region 0 virtual address.
> > > >
> > > >Also, the printf is very good at catching problems when
> > > >there is a new bug in Xen so it would be nice to
> > > >keep the printf. Perhaps it could be tied to a
> > > >Xen command line option: warnregion0. E.g.
> > > >
> > > >if (metaphysical) {
> > > > if (address >> 61)
> > > > panic_domain(("bad metaphysical address")
> > > > else {
> > > > ... existing phys translate code
> > > > }
> > > >{
> > > >else if (!(address >> 61) && warnregion0) {
> > > > printf
> > > >}
> > > >
> > > >I think this code will also fix region 0 virtual addresses
> > > >(because it properly falls through to the rest of
> > > >vcpu_translate).
> > > >
> > > >> -----Original Message-----
> > > >> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> > > >> Sent: Friday, November 04, 2005 3:20 AM
> > > >> To: Magenheimer, Dan (HP Labs Fort Collins)
> > > >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > > >> Subject: vcpu_translate issue
> > > >>
> > > >> Dan,
> > > >>
> > > >> In vcpu_translate function, if guest address is within region
> > > >> 0 and guest is in virtual mode, vcpu_translate will print
> > > >> warning message and don't translate. It seems you assume
> > > >> guest will not access this kind of address, but actually
> > > >> guest application can allocate region 0 address spaces by
> > > >> using system call mmap.
> > > >>
> > > >> You can try testcase mmap09 of ltp on both native and xen0 to
> > > >> find out this.
> > > >>
> > > >> So, Can we remove this code segment in vcpu_translate?
> > > >>
> > > >> Thanks,
> > > >> Anthony.
> > > >>
> > > >>
> > >
> >
> _______________________________________________
> 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
|
Home