WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] /dev/mem

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] /dev/mem
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 24 Jan 2006 17:26:44 +0100
Delivery-date: Tue, 24 Jan 2006 16:34:59 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

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).

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).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>