Ian Pratt
2005-Jun-10 16:25 UTC
RE: [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@intel.com> 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@intel.com> > > > > 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@cl.cam.ac.uk> 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@lists.xensource.com http://lists.xensource.com/xen-devel