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

[Xen-ia64-devel] RE: vcpu_translate issue


  • To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Wed, 9 Nov 2005 10:29:05 -0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 09 Nov 2005 18:29:49 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcXhKVAX2ekaVUdwQTebibJkSrMe9AAHl+SwACNje6AA4Tm6cA==
  • Thread-topic: 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

 


Rackspace

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