From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: hypercall_xlat_continuation() Date: Thu, 28 May 2009 20:01:08 -0700 Message-ID: <4A1F4FF4.1010904@oracle.com> References: <1243118659.26568.37.camel@localhost.localdomain> <4A1DF87A.5050008@oracle.com> Reply-To: mukesh.rathor@oracle.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4A1DF87A.5050008@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Jan Beulich List-Id: xen-devel@lists.xenproject.org Mukesh Rathor wrote: > > > Ian Campbell wrote: >> On Sat, 2009-05-23 at 06:17 -0400, Keir Fraser wrote: >>> On 22/05/2009 22:58, "Mukesh Rathor" wrote: >>> >>>> Ok. Even if I can't make it clearer, at least I'll add few lines of >>>> comments >>>> explaining what's going on, after (and if) I figure it out. >>>> >>>> Jan, >>>> >>>> It seems assumption is made that a 64bit dom0 will not have a 32bit >>>> app making >>>> hypercall? >>>> >>>> BUG_ON(*reg != (unsigned int)*reg); <==== >>> You know that all the 'xlat' stuff in Xen is for 32-bit guests >>> running on >>> 64-bit hypervisor, right? 64-bit dom0 would never execute this logic. >> >> It's worth noting though that I don't believe a 32 bit dom0 toolstack on >> a 64 bit kernel on a 64 bit hypervisor will work. In particular the >> privcmd "make a hypercall" ioctl doesn't do any compat translation so 32 >> bit xend and friends can't make hypercalls that way and I think the >> MMAPBATCH privcmd doesn't work either. >> >> I'm sure there are other cases too (blktap user<->kernel ring layout >> maybe?). >> >> Ian. > > Thanks Ian for good explanation of hypercall_xlat_continuation(). > > yeah, I'm just exploring that right now. There is MMAPBATCH_32, btw, in > dom0 that looks like was implemented by PPC folks. Also, MMAP_32. > I was able to start PV guest without network. Not sure if that was > because of compatibility or some other issue. I'm just looking at MMAP > stuff right now, think I finally figured out the chain of calls from > libxc to hyp to dom0 ... ia32_sys_call_table to compat_sys_ioctl to > handler to do_ioctl32_pointer .. whew!! > > Thanks, > Mukesh > yeah, looks like privcmd_ioctl_32() only fixes the wrapper struct. The PFN array still is 32bit pfn's, and privcmd_ioctl() expects 64bits. So, in a dilemma now, not sure if I should fix it up in privcmd_ioctl_32() or change privcmd_ioctl() which will take some time to reverse engineer. Not sure how many things I'll discover, if it's too many, it may not be worth it in the end. Thanks, Mukesh