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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> 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