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

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

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 22 Mar 2007 09:26:29 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 21 Mar 2007 18:26:05 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdroM7likPLbLeXQOqVy+WGNgAmBgAE5k7gAAiPr2kAEo0wMA==
  • Thread-topic: /dev/mem and /dev/kmem

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年3月22日 0:33
>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
>Xen-owned pages are safe.
> -- Keir

I just wanted to know how to prevent dom0 from mapping 
xen-owned pages. You're right and I missed the get_page() point here. :-)


Xen-devel mailing list



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