| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH]vbd/vnif paravirtulization driver hypervisorsuppo
> 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
|
|
|
| |
|
Home