On Aug 30, 2006, at 8:10 PM, [EMAIL PROTECTED] wrote:
I saw this fire once and was mightily confused by the "type" printed.
Thanks Amos, this pointed out a lot of INVALID_MFN cleanup that needed to be done, should push that soon. Amos, IIRC the address that actually _was_ printed was was a paddr of 0xc000000 (192Mib), too bad thats all the inof we have :(
Hollis, ASAICT the only way Amos could have gotten here (and passed the BUG() in pfn2mfn()) is if one of the user_copy routines tried to access a PFN_TYPE_REMOTE or PFN_TYPE_IO, that paddr is not an IO type so the question I have for you is: Is it possible for Xen (on behalf of a privileged domain) use a user_copy routine to access another domains memory?
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]> --- usercopy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -r e12aa1195f58 xen/arch/powerpc/usercopy.c --- a/xen/arch/powerpc/usercopy.c Wed Aug 30 18:35:20 2006 -0400 +++ b/xen/arch/powerpc/usercopy.c Wed Aug 30 20:08:35 2006 -0400 @@ -52,8 +52,8 @@ static unsigned long paddr_to_maddr(unsi case PFN_TYPE_LOGICAL: break; default: - panic("%s: called with bad memory address type: 0x%lx\n", - __func__, paddr); + panic("%s: address 0x%lx has bad address type: 0x%x\n", + __func__, paddr, mtype); break; } pa <<= PAGE_SHIFT;
_______________________________________________ Xen-ppc-devel mailing list Xenemail@example.com http://lists.xensource.com/xen-ppc-devel