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

RE: [Xen-devel] Essay on an important Xen decision (long)


  • To: "Anthony Liguori" <aliguori@xxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Tue, 10 Jan 2006 16:22:21 -0800
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 11 Jan 2006 00:28:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYWH9v+NCuJk2P4QPqm4CkP9Q/x2QAJBIug
  • Thread-topic: [Xen-devel] Essay on an important Xen decision (long)

> You seem to conclude that the only possible solutions are making the 
> dom0 either P==M or P2M.  Is it not possible to make dom0 VP?
> 
> If the only issue for making dom0 VP is DMA, wouldn't it be easier to 
> modify the Linux DMA subsystem[1] to make a special hypercall to 
> essentially pin a VP to a particular MFN that could be used for the 
> DMA?  One could imagine the hypervisor reversing low memory 
> specifically 
> for DMA such that bounce buffers could be avoided too.
> [1] Realizing that I know very little about the Linux DMA 
> subsystem so I 
> don't know if this is outside the realm of possibilities.

Technically, if the guest source needs to be changed so that
some code deals with physical addresses and other code deals
with machine addresses, I would call that a flavor of P2M.

If the "DMA subsystem" is the only place where the mapping needs
to be done and the affected code can be cleanly isolated, your
suggestion is a good one.  I'm no expert on Linux DMA code
either, but I believe it isn't very clean.
 
> VP makes a lot of interesting memory optimizations 
> considerably easier 
> (memory compacting, swapping, etc.).

Yes, definitely, and oversubscription, different kinds of
migration, NUMA physical memory affinity migration, etc.

Dan

_______________________________________________
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®.