[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XenPPC] [xenppc-unstable] [TOOLS] avoid shadow ops for POWERPC
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 <jimix@xxxxxxxxxxxxxx> > >>>> # Node ID a7abc95d4ce4177acd9cfbd58476d521352f9ff7 > >>>> # Parent 6b9124f9d89d58eb81847813dc0043ba3896b919 > >>>> [TOOLS] avoid shadow ops for POWERPC > >>>> > >>>> Signed-off-by: Jimi Xenidis <jimix@xxxxxxxxxxxxxx> > >>>> --- > >>>> 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@xxxxxxxxxxxxxxxxxxx > > http://lists.xensource.com/xen-ppc-devel > > > _______________________________________________ > Xen-ppc-devel mailing list > Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-ppc-devel -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-ppc-devel mailing list Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ppc-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |