Subject: Re: Xen3 physical memory map/location for dom0
To: None <port-xen@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: port-xen
Date: 11/10/2006 00:23:26
On Fri, Nov 10, 2006 at 10:19:26AM +1100, Daniel Carosone wrote:
> On Fri, Nov 10, 2006 at 12:00:56AM +0100, Manuel Bouyer wrote:
> > > Is it something that can be influenced by the ELF headers of the dom0
> > > kernel? I know there were some changes recently (as part of the 3.0.3
> > > support) to load addresses and other possibly promising parameters..
> >
> > Actually putting a limit on dom0 memory may not be enough; a network buffer
> > from a domU can end up in the DMA descriptor of the network adapter
>
> Hm, I suppose so. Normally this would be a good thing. :-)
>
> Would it matter if the traffic was being bridged vs routed? Probably not.
>
> > > Any other clues?
> >
> > How does the driver deal with this limitation ? Does it work with a plain
> > i386 kernel ?
>
> It doesn't. There have been some unsucessful attempts at a bounce-buffer
> style solution in the driver, and some discussion of adding various kinds
> of more general "dma constraints" properties, but at present the driver
> just fails if used with >1G native. Both of these ideas would probably get
> even more complicated under Xen.
Not necesserely. If we can pass these constraint to bus_dma(9),
it can request appropriate memory to Xen, just like it does right now
for contigous memory or boundaries.
If this is solved by a ad-hoc solution in the driver, using direct
calls to uvm(9), then we'd also need ad-hoc calls to xen-specific functions.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--