[XenPPC] Question? Re: [PATCH] Fix paddr_to_maddr panic message

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

On Aug 30, 2006, at 8:10 PM, apw@xxxxxxxxxx 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?
-JX


> Signed-off-by: Amos Waterland <apw@xxxxxxxxxx>
>
> ---
>
>  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
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel