From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 3/3] xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl Date: Fri, 24 Aug 2012 13:00:41 +0100 Message-ID: <50376CE9.1040401@citrix.com> References: <1345742026-10569-1-git-send-email-david.vrabel@citrix.com> <1345742026-10569-4-git-send-email-david.vrabel@citrix.com> <20120823194000.GA11652@phenom.dumpdata.com> <503761FA.3050606@citrix.com> <20120824114147.GF11007@konrad-lan.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120824114147.GF11007@konrad-lan.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Andres Lagar-Cavilla , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 24/08/12 12:41, Konrad Rzeszutek Wilk wrote: >>>> +struct privcmd_mmapbatch_v2 { >>>> + unsigned int num; /* number of pages to populate */ >>> >>> unsigend int? Not 'u32'? >>>> + domid_t dom; /* target domain */ >>>> + __u64 addr; /* virtual address */ >>>> + const xen_pfn_t __user *arr; /* array of mfns */ >>>> + int __user *err; /* array of error codes */ >>> >>> int? Not a specific type? >> >> It's an existing interface supported by classic Xen kernels and >> currently being used by libxc. So while I agree that it's not the best >> interface, I don't think it can be changed. It's also the same as struct privcmd_mmapbatch except for the extra 'err' field and 'arr' being const. > How does it work with a 64-bit dom0 and 32-bit userspace? Is the libxc > smart enough to figure out the size of the structure? privcmd doesn't support compat ioctls because there there is nothing doing the translation of the hypercalls from the 32-bit to 64-bit ABI -- the hypervisor won't do it as the hypercalls are called from the 64-bit kernel. 64 bit Xen, 64 bit dom0, 32 bit tools has never worked for this reason. I think Ian Campbell had some hacky patches for this but he may not want to admit to them. ;) David