>From: Matt Chapman
>Sent: 2005年11月10日 15:06
>.
>
>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 incorrect way should be abandoned, and we need inject fault into guest and
let guest kernel to handle it.
>
>- 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.
We shouldn't depend on guest specific behavior for such assumption. The
preferable way is always to search the vTLB to check corresponding attribute.
If it's mapped as NaTpage by guest, then inject NaT consumption, or else just
inject normal TLB miss to guest.
> If we deliver a TLB miss as we are doing, Linux will just try to
> repeatedly reinsert that mapping.
>
>Matt
I don't think so. Even on native environment, that NaTpage mapping may or may
not exist in TLB at any time, since it's only a TC entry. When it's in machine
TLB, fault on dereference to NULL pointer is accelerated. If not, normal TLB
miss is delivered to page fault handler which will also go to send a SEGV to
kill the process if write. In any way, mapping page 0 as NaTpage is only an
optimization from guest to accelerate fault on NULL pointer dereference.
Actually even when guest is linux, there's no assure that page 0 is always
mapped as NaTpage:
- When process is created, NaTpage attribute is forced only when
MMAP_PAGE_ZERO is not specified. From the comment, svr4 binaryhas such
exception.
- User application can use mmap to page 0 with MAP_FIXED flag. In that
case, do_mmap will override original NaTpage mapping with new vma and new
mapping. That's what mmap09 does today.
Thanks,
Kevin
>
>
>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
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home