WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH]vbd/vnif paravirtulization driver hypervisorsuppo

To: "Ling, Xiaofeng" <xiaofeng.ling@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH]vbd/vnif paravirtulization driver hypervisorsupport]
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 10 Jun 2005 17:25:13 +0100
Delivery-date: Fri, 10 Jun 2005 16:24:21 +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: AcVskrAnUGUgb8rMQFquEEC+I8EvZgBQCRpwAADvKqA=
Thread-topic: [Xen-devel] [PATCH]vbd/vnif paravirtulization driver hypervisorsupport]
> Is this patch acceptable? 
> If yes, I'll continue to work out the other splitted patch.

I want a chance to think a bit more about the paravirtualized VT
drivers, and about paravirtualized drivers working in shadow_translate
mode in general.

Having to map the domain mem for the hypercall arguments in copy_*_user
is going to be painful anyhow -- we might want to register a page that
is permanently mapped into the hypervisor's address space and translate
in the vt-specific entry code.

Ian
 
> Xiaofeng Ling <mailto:xiaofeng.ling@xxxxxxxxx> wrote:
> > I'd like to split the patch into small ones, so that it can be 
> > clearer. Attach is the patch of adding support copy_to/from_guest.
> > 
> > Signed-off-by: Xiaofeng Ling <xiaofeng.ling@xxxxxxxxx>
> > 
> >   arch/x86/x86_32/usercopy.c       |   99
> > +++++++++++++++++++++++++++++++++++++++
> >   arch/x86/x86_64/usercopy.c       |   15 +++++
> >   include/asm-x86/x86_32/uaccess.h |    5 +
> >   include/asm-x86/x86_64/uaccess.h |    5 +
> >   4 files changed, 124 insertions(+)
> > 
> > 
> > Ling, Xiaofeng wrote:
> >> 
> >> Keir Fraser <mailto:Keir.Fraser@xxxxxxxxxxxx> wrote:
> >> 
> >>> On 3 Jun 2005, at 03:40, Xiaofeng Ling wrote:
> >>> 
> >>> 
> >>>> It's now all use shadow_mode_external, and use a permit 
> bitmap for 
> >>>> hypercall from vmx domain. Do you think it's now acceptable?
> >>>> It's against 1657.
> >>> guest
> >>> Still messy imo. When I said to split the path by 
> >>> shadow_mode_externel, I meant you should do it within the uaccess 
> >>> macros/functions; not in their callers.  guest
> >> 
> >> I've already done that for copy_from/to_user, but for 
> >> __copy_from/to_user I can not do that, because not all the caller 
> >> shall call copy_from/to_guest
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>