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

[Xen-devel] Readonly memory for guest domain


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Peter Teoh" <htmldeveloper@xxxxxxxxx>
  • Date: Wed, 12 Sep 2007 09:22:31 +0800
  • Delivery-date: Tue, 11 Sep 2007 18:23:10 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=pS8r1fVMLY8jrJXOYncNy39gO9WXd5Onr//JvjfS5rLSWmFlKIY05+9jlIN/22E3yvnrBCw2BjnCFKRaiNT7P7xxeIR38b8GvfJA0+CF+vohDs2PbPRwOjBz2Z8w4XJK9vLme3rZx0MPO1gptzSJ8KfWSF2u/WUQzmTNn4CCaUI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Current Xen design is that the guest domain have readonly access to the memory mapped for them.   Documentation say it is not safe for them to be writable.   Why?
 
Is it so as to trigger a trap exception whenever writing is made to it?   This is the optimal answer :-).
 
And since it is not "safe" what checks are done in Xen hypervisor against these "dangers", ie, enumerate the potential dangers?   I cannot think of any, as a newbie in Xen.   My logic is that if the pages have been assigned as owned by a domain, just let it do whatever it wants to, and so therefore should not trigger any privilege trap condition (or VM exit condition, in the HVM case).
 
In the traditional Linux model, once a memory is mapped for user process, non-root  user included, it can be mapped as writable.   So why is this discrepancy in the case of Xen?
 
By taking away this readonly restriction, I think Xen hypervisor will have a lot of performance to gain.  
 
Please share your thoughts?   Apologies for the questions from a newbie.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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