RE: [Xen-ia64-devel] [RFC] P2M/VP design memo

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

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