[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |