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

[Xen-devel] Re: /dev/mem and /dev/kmem

  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 21 Mar 2007 16:33:27 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 21 Mar 2007 09:32:45 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdroM7likPLbLeXQOqVy+WGNgAmBgAE5k7gAAiPr2k=
  • Thread-topic: /dev/mem and /dev/kmem

On 21/3/07 12:35, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> So how about applications which simply use /dev/mem to map
> normal domain memory? Seems this breaks compatibility
> in user level though desired for above Xserver case... Or such
> case is rare?

This case seems not to occur in practise (no complaints so far and our
/dev/mem has had this limitation since day one). This is perhaps not
surprising: really not much good can come out of direct grokking of
kernel-maintained memory without the kernel's knowledge.

> BTW, I didn't find code to protect Xen to be mapped in this path,
> like in get_page_from_l1e(). Could you help pointing out?

Not sure how you mean. Only pages that explicitly are owned by a domain and
have a non-zero refcount can have get_page() succeed on them. So random
Xen-owned pages are safe.

 -- Keir

Xen-devel mailing list



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