RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c

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

Sorry for the delay in responding to this...

First note that on the current (P==M) xen-ia64-unstable
tree, CONFIG_DOMAIN0_CONTIGUOUS is #define'd in domain.c.
It has been turned on since the alpha release in December
2004.

When I was first bringing up domain0 (in mid-2004 on ski),
domain0 was using VP.  When I started bringing up I/O
for domain0, I realized that if P==M, all domain0 I/O
would work without change, so added ifdef's for
CONFIG_DOMAIN0_CONTIGUOUS to test with P==M.  Since
it worked, CONFIG_DOMAIN0_CONTIGUOUS has been define'd
on and any domain0 code with CONFIG_DOMAIN0_CONTIGUOUS
off has likely bitrotted.

So I don't think current (P==M) xen-ia64-unstable will work
with CONFIG_DOMAIN0_CONTIGUOUS undef'd.  It should be
undef'd as part of Isaku's work to convert domain0
to VP.  HOWEVER... it may be possible and desirable
for much of Isaku's work to support both VP and P==M.
For non-I/O code, CONFIG_DOMAIN0_CONTIGUOUS could be
used (or possibly renamed) to select VP or P==M at
compile-time, at least until the conversion to VP+DMA
is complete.  This would allow at least some of Isaku's
VP code to coexist in the main xen-ia64-unstable tree
without breaking the current P==M model.

Dan

> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Tian, Kevin
> Sent: Monday, February 27, 2006 11:15 PM
> To: Isaku Yamahata; Dong, Eddie
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c
> 
> >From: Isaku Yamahata
> >Sent: 2006å2æ28æ 13:47
> >Hi.
> >
> >I think that construct_dom0() is broken for
> >CONFIG_DOMAIN0_CONTIGUOUS.
> >I had to modify it heavily to boot dom0 with P2M/VP model.
> >
> >For example
> >construct_dom0()
> >    ...
> >    memcpy(__va(pinitrd_start),initrd_start,initrd_len);
> >    This memcpy() assumes p==m.
> >
> >
> >I thought that CONFIG_DOMAIN0_CONTIGUOUS option was introduced
> >at the eary develpment stage and it remained just because
> >no one removed it. However I don't know its history.
> >
> 
> That option might be introduced because dom0 can have more memories
> spanning machine holes, even when p==m was the model that time. 
> To simplify the early design, thus limitation was added to 
> ensure constraints within one continuous trunk. So it should 
> be removed now as a step of 
> your P2M effort.
> 
> Thanks,
> Kevin
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel
> 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel