| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
On 24 Jan 2006, at 16:26, Jan Beulich wrote:
Wouldn't it be more reasonable to have /dev/mem represent machine
addresses only outside of the range of physical memory
assigned to a VM, and physical addresses inside this range? That way,
more consistent behavior should be achieved to
native systems.
What I'm seeing is that accesses to /dev/mem offset 0x100000 get a
failure in __direct_remap_pfn_range() (including, if
debugging is turned on, two log messages from the hypervisor). If
these accesses went to kernel memory instead,
consumers of this interface would get exactly what they get on a
native OS.
Does anyone sane peek /dev/mem to get at kernel code/data? I doubt it.
Further I would think that such map attempts shouldn't even make it to
the hypervisor, thus avoiding the log messages
(which I started looking into only because I thought they might
indicate a latent bug of some sort). This would,
however, require knowledge in the kernel which addresses (or address
ranges) represent physical memory (rather than
potential I/O memory regions).
Non-debug Xen builds don;t print those messages so won't scare users.
Finally, while following the involved code paths, I noted a check that
is made in __ioremap, by calling
is_local_lowmem(). It would seem to me that calling this function just
for the first address is insufficient - the range
specified may begin in non-lowmem but end in lowmem. Or it may begin
in lowmem and end in non-lowmem, in which case I
would think that virt_to_page() wouldn't work correctly anymore
(permitting, say, an erroneous dd command issued by root
to result in an oops or maybe worse things).
It's assumed people using those interfaces know what they're doing. How
can a 'dd' end up in __ioremap() anyway?
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home