This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] passing hypercall parameters by pointer

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "Hollis Blanchard" <hollisb@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] passing hypercall parameters by pointer
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 18 Aug 2005 14:56:15 +0800
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>
Delivery-date: Thu, 18 Aug 2005 06:54:36 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWjZVq2w3oCeTJVTs67J8Weva1pcAABoQkQABN6iwA=
Thread-topic: [Xen-devel] passing hypercall parameters by pointer
>From: Ian Pratt
>Sent: Thursday, August 18, 2005 4:44 AM
>> On PowerPC though, the hypervisor runs in real mode (no MMU 
>> translation).  
>> Unlike x86, PowerPC exceptions arrive in real mode, and also 
>> PowerPC does not force a TLB flush when switching between 
>> real and virtual modes. So a virtual address is pretty much 
>> worthless as a hypervisor parameter; performing the MMU 
>> translation in software is infeasible.
>I think I'd prefer to hide all of this by co-operation between the
>kernel and the hypervisor's copy to/from user.
>The kernel can easily translate a virtual address and length into a
>of psuedo-phyiscal frame numbers and initial offset. Xen's copy from
>user function can then use this list when doing its work.

So this is a common concern for hypervisor residing in a different
address space as guest. For PowerPC, it's real mode (hypervisor) VS
virtual mode (guest). For vmx domain, hypervisor has its own monitor
page table separated from shadow page table. Expect the final solution
to be uniform too. ;-)

See if I understand your suggestion closely here. Previous Xiaofeng's
patch has following flow when accessing guest address space:
- Search gva in guest page table to get pfn
- Get mfn by pfn
- map mfn into hypervisor's space
- Then directly access the new va'

Then your suggestion is to make gva->pfn search happening in guest. And
hypervisor will still have rest steps to manipulate monitor page table
first and then access new va'. (PowerPC will access mfn directly).
Finally in either option, copy_from/to_user becomes a memcpy to a new
va' without exception happening.

Now, question comes out. The pseudo-physical frame number list itself
also presents as a parameter to hypervisor, and there's no promise that
this list will be confined in single page. You also need extra info in
this list if multiple parameters are pointers. How to access this
scalable list effectively seems to be same puzzle as the subject. For
x86 people may set a maximum limitation, but how about 64bit platform?
Good example is always get_pfn_list, which always breaks assumption for
size of parameter. ;-)


Xen-devel mailing list