[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Matt Chapman" <matthewc@xxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Thu, 10 Nov 2005 07:37:19 -0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 10 Nov 2005 15:37:16 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcXlxTxnQ2xyrsFCQtu4Z/X6MfU3hwARorug
  • Thread-topic: [Xen-ia64-devel] RE: vcpu_translate issue

> Dom0 no longer boots for me with the latest changes.  Normally I
> would get errors like:
> <snip>
> 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 :)

OK, I have pulled out a couple of changesets that I was using
to debug the mmap09 (access to region0) problem that I thought
were harmless.

> 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.

There are definitely a lot of programs that do null dereference.
Those that used to complain for me still worked after my change
so I thought my fix was correct (for null deref) but apparently
not.

> - 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.

Yes, this is probably related to the whole virtual region 0 address
problem that Anthony uncovered with ltp/mmap09.

Also, note that (see recent thread about NaT bits), reflection
of NaT consumption traps is entirely disabled right now.  That
may also be related (though an obvious-but-no-longer-correct
printf should be printed if one occurs).

Dan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.