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

Re: [Xen-devel] /dev/mem

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.