| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] [RFC] P2M/VP design memo
Hi Isaku --
Excellent work on your design memo! I can see you have
studied the code a lot and have discovered some interesting
issues!
A few comments:
- I am glad you have the Terminology section as the terms
are often confusing. It might be good to add "Metaphysical
address" (same as pseudo physical address) as this term
was coined and used by the HP vBlades project and is used
in several places in the existing code). It might be
good to also define "guest physical address" and "machine
physical address" as these terms are used in Xen/ia64-VTI
code.
- You note in the DMA section that the code needs to be modified
to be machine aware, but there is another major issue that
should probably be noted explicitly: Physical pages that are
contiguous are not necessarily machine-contiguous. Thus it
is possible that programming a DMA device to place 64kb
into a contiguous physical buffer may need to be paravirtualized to
programming the DMA device to do a scatter-gather of multiple
pages at multiple machine addresses. I think Xen/x86 gets
around this with a hypercall to reassign machine pages to
physical pages to ensure the machine pages are contiguous?
In any case, this issue should probably be described in
the overview ("dom0 virtual physical model") section.
- Another point worth noting in the overview is that domain0
needs to have a page struct for every physical page. This
is the reason why we cannot support sparse/discontiguous
memory in domain0 right now. This could still be fixed in
P==M but would be difficult. It is easy in virtual physical.
- Your 64mb of contiguous (P==M+delta) idea is good, but I'm
not sure it will work because I don't know we can restrict
those pages to never be flipped.
However, it gave me an idea. I wonder if most of the Xenlinux
changes can be made first without actually changing the Xen
memory implementation. In other words, xenlinux *assumes* that
P!=M but it would still work if P==M. So all the xenlinux changes
could be made, and then we could debug them first by just adding
a one-page offset (and then later make all the xen changes so
that P!=M). If this works, maybe we can put those changes
directly into -ia64-unstable.hg.
- It looks like Fred has updated -Intel.hg to the same cset
as -ia64-unstable.hg. However, -unstable.hg has just moved
to 2.16.16-rc3 and -ia64-unstable will soon follow.
- Alex (and others in HP) has experience with the dma/swiotlb
code. Please let us know if we can help.
- I look forward to more info in the grant table and vbd/vnif/balloon
sections. I am also concerned about Rusty's interdomain
communication code as much of the grant table/vbd/vnif/balloon
code might change soon.
That's all for now! Once again, great work so far!
Dan
> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of Isaku Yamahata
> Sent: Wednesday, February 15, 2006 6:59 PM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-ia64-devel] [RFC] P2M/VP design memo
>
>
> Hi xen/ia64 developers.
>
> I've been working on P2M/VP in past few couple of weeks.
> I attached my P2M/VP design memo, please find it.
> The purpose to post this memo is to share/review the design
> with developers and then hopefully find a better one.
> Please comments/suggestions.
>
> notes on the terminology.
> I introduced a new term, bus address.
> However bus address doesn't seem so popular and widely accepted.
> If you have a better term in mind, please suggest.
> I'm willing to re-write this memo with a better terminology.
>
>
> Thanks.
>
> --
> yamahata
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home