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

RE: [Xen-devel] Review needed for "commonisation" ofcommon/grant_table.c

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <cwc22@xxxxxxxxx>
Subject: RE: [Xen-devel] Review needed for "commonisation" ofcommon/grant_table.c
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Mon, 13 Jun 2005 14:21:25 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 13 Jun 2005 21:21:03 +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
Thread-index: AcVuBlLakJ6ZKpDrS66Z9eBsen+ZAQAACwkgAAwg/8AAeuKgsAAA48NAAA2rMcA=
Thread-topic: [Xen-devel] Review needed for "commonisation" ofcommon/grant_table.c
> >I'm still not clear on the value of reference counts for Xen/ia64
> >since unprivileged domains do not have direct access to physical
> >memory.  Since this is an arch-dep discussion, let's switch this
> >discussion to xen-ia64-devel.
> 
> Front end in Domain N may share its own page list with 
> backend in Domain 0, to achieve maximum performance. Then 
> backend can read/write those shared pages directly. This 
> doesn't mean granting unprivileged domains direct access to 
> physical memory. Instead, this just adds two mappings to same 
> machine page for different domains. Access to that machine 
> page is still controlled by xen for each domain, but as you 
> can see, two domains actually own same machine page 
> simultaneously. This is why reference count is necessary, 
> since this is a common work model. You can take a look at 
> docs/misc/grant_tables.txt, which presents two outstanding 
> requirement for page sharing, thus for reference count.

I understand (I think) how it works on x86.  But the memory
model is somewhat different on ia64.  Domain 0 has access
to all of machine memory and can create a duplicate mapping
for any page of any unprivileged guest.  This is not controlled
by Xen (in the current implementation).  As long as a page
is shared between Domain 0 and Domain N, I don't see that
reference counts are necessary.

If pages are to be shared between two unprivileged domains,
there may be some value in reference counts.  But that doesn't
fit very well with the current frontend/backend model.

> I'm not sure whether your para-virtualization plan includes 
> frontend/backend model. Sorry for that confusion due to I 
> suddenly recalled a term "transparent para-virtualization" 
> mentioned by you sometime ago, but not exactly the details. 
> :) 'Yes' is welcome, because that's definitely required if 
> people want to speed up performance. 

Yes, definitely it will use a frontend/backend model.

Dan

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

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