qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation


From: Stuart Anderson
Subject: Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation
Date: Fri, 6 Jul 2007 14:45:51 -0400 (EDT)

On Fri, 6 Jul 2007, Stuart Anderson wrote:

Moreover, I believe using similar functions as Linux for memory access (copyfromuser, copytouser, get_user, put_user) would be cleaner.

This makes sense. That code that I sent was based on the idea that I was
just extending the model that was already there, instead of giving it a
complete overhaul. I'll look into how much work the overhaul would be.

After some digging, the one "design-level" issue I have found is that the
current lock_user_struct() and the new lock_and_check_user_struct(),
interfaces are based on the assumption that we need to map addresses
between guest and host, so they provide a place to call g2h() and return the
new address. This is different from copy_{to|from}_user(), which assumes
all addresses are valid as is, but that the system just needs to ensure
they are correctly mapped in for the data copy.

Contrary to this, cpu-all.h has the following comment & code:

#define GUEST_BASE 0

/* All direct uses of g2h and h2g need to go away for usermode softmmu.  */
#define g2h(x) ((void *)((unsigned long)(x) + GUEST_BASE))
#define h2g(x) ((target_ulong)(x - GUEST_BASE))

It appears that g2h() and h2g() are mostly no-ops, with the typecasting
being the only possible useful part remaining.

So, the question is:

        Can I simplify this code to assume that guest and
        host addresses coexist and use the copy_*_user() or
        just the access_ok() interfaces?

This would be one step closer to eliminating the use of g2h() and h2g() in
the usermode code as is suggested by the comment in cpu-all.h.

One other comment to make, is that in most cases, a simple copy is not
sufficient. Unlike the real Linux kernel, in many places, we are doing
structure mapping instead of a simple buffer copy.


                                Stuart

Stuart R. Anderson                               address@hidden
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                 BD03 0A62 E534 37A7 9149




reply via email to

[Prev in Thread] Current Thread [Next in Thread]