Re: [Xen-ia64-devel] RE: vcpu_translate issue

[Matt Chapman <matthewc@xxxxxxxxxxxxxxx>]

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