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 [EMAIL PROTECTED]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
