Yes, exactly. And since ImageHandler has this:
    def getDomainShadowMemory(self, mem_kb):
        """@return The minimum shadow memory required, in KiB, for a domain 
        with mem_kb KiB of RAM."""
        # PV domains don't need any shadow memory
        return 0

PPC_LinuxImageHandler derives from LinuxImageHandler derives from
ImageHandler, so I don't understand how you're seeing a non-0 number
from self.image.getDomainShadowMemory(m) below.

On Mon, 2006-08-21 at 17:09 -0400, Jimi Xenidis wrote:
> I suppose the other possible fix would be to make sure that on  
> powerpc sets sm to 0 on line 1288:
>              # get the domain's shadow memory requirement
>              sm = int(math.ceil(self.image.getDomainShadowMemory(m) /  
> 1024.0))
>              if self.info['shadow_memory'] > sm:
>                  sm = self.info['shadow_memory']
> 
> I dunno where that comes from.
> 
> Also we spoke about using this to initialize the htab,  so once we  
> get the memory stuff straightened out then we need can come up with  
> the right value here.
> -JX
> 
> On Aug 21, 2006, at 4:58 PM, Jimi Xenidis wrote:
> 
> >
> > On Aug 21, 2006, at 4:00 PM, Hollis Blanchard wrote:
> >
> >> On Sun, 2006-08-20 at 13:28 -0400, Jimi Xenidis wrote:
> >>> Hollis, I'm sure you have a better way to do this in the TCL.
> >>> I'll be adding some shadow ops to the hypervisor, mainly to make  
> >>> sure
> >>> everyone knows that it is disabled, but this TCL was still  
> >>> problematic.
> >>> -JX
> >>>
> >>> On Aug 20, 2006, at 1:12 PM, Xen patchbot-xenppc-unstable wrote:
> >>>
> >>>> # HG changeset patch
> >>>> # User Jimi Xenidis <[EMAIL PROTECTED]>
> >>>> # Node ID a7abc95d4ce4177acd9cfbd58476d521352f9ff7
> >>>> # Parent  6b9124f9d89d58eb81847813dc0043ba3896b919
> >>>> [TOOLS] avoid shadow ops for POWERPC
> >>>>
> >>>> Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
> >>>> ---
> >>>>  tools/python/xen/xend/XendDomainInfo.py |    9 ++++++---
> >>>>  1 files changed, 6 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff -r 6b9124f9d89d -r a7abc95d4ce4 tools/python/xen/xend/
> >>>> XendDomainInfo.py
> >>>> --- a/tools/python/xen/xend/XendDomainInfo.py    Sun Aug 20 13:02:16
> >>>> 2006 -0400
> >>>> +++ b/tools/python/xen/xend/XendDomainInfo.py    Sun Aug 20 13:06:37
> >>>> 2006 -0400
> >>>> @@ -1293,9 +1293,12 @@ class XendDomainInfo:
> >>>>              # Make sure there's enough RAM available for the  
> >>>> domain
> >>>>              balloon.free(m + sm * 1024)
> >>>>
> >>>> -            # Set up the shadow memory
> >>>> -            sm = xc.shadow_mem_control(self.domid, mb=sm)
> >>>> -            self.info['shadow_memory'] = sm
> >>>> +            if os.uname()[4] in ('ppc64'):
> >>>> +                self.info['shadow_memory'] = 0
> >>>> +            else:
> >>>> +                # Set up the shadow memory
> >>>> +                sm = xc.shadow_mem_control(self.domid, mb=sm)
> >>>> +                self.info['shadow_memory'] = sm
> >>>>
> >>>>              init_reservation = self.info['memory'] * 1024
> >>>>              if os.uname()[4] in ('ia64', 'ppc64'):
> >>
> >> Would a workaround on the Xen side make this unnecessary? In fact it
> >> seems the current Xen code should already work, since xend will only
> >> call PPC's shadow_mem_control() with mb=0.
> >>
> >> Can we back out the patch above?
> >
> > Actually, the xen code sees a non-zero value, thats when I made the  
> > python change.
> > -JX
> >
> >
> >
> > _______________________________________________
> > Xen-ppc-devel mailing list
> > Xen-ppc-devel@lists.xensource.com
> > http://lists.xensource.com/xen-ppc-devel
> 
> 
> _______________________________________________
> Xen-ppc-devel mailing list
> Xen-ppc-devel@lists.xensource.com
> http://lists.xensource.com/xen-ppc-devel
-- 
Hollis Blanchard
IBM Linux Technology Center


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

Reply via email to