| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [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
|
|
|
| |
|
Home