Re: [Xen-devel] XEN 4.3.0 WINDOWS HVM 3GB RAM ISSUE

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sun, 2013-11-03 at 20:56 +0200, NiX wrote:
> > On Tue, 2013-10-22 at 23:07 +0300, NiX wrote:
> >> Hello list!
> >>
> >> ----------------------------------------------------------------------------------------------------
> >> The problem
> >> ----------------------------------------------------------------------------------------------------
> >>
> >> Windows 7 64bit nor Windows 2008 R2 Enterprise Server 64bit is not
> >> starting with more than 3GB of RAM in HVM mode
> >>
> >> As a reference:
> >>
> >> Ubuntu 64-bit server is starting without any issue with 5GB of RAM on
> >> this
> >> server in HVM mode
> >> And all PV guest can use as much RAM as available when using 64bit
> >> linux.
> >>
> >> ----------------------------------------------------------------------------------------------------
> >>
> >> System:
> >> > > CPU's: 2 x XEON X5450
> >> > > Motherboard: Intel Server Board S5000PSLSASR
> >> > > http://ark.intel.com/products/46544/Intel-Server-Board-S5000PSLSASR
> >>
> >> > > RAM: 16GB DDR2 ECC
> >> > > Dom0 OS: Debian 7.0 64bit
> >>
> >> ----------------------------------------------------------------------------------------------------
> >>
> >> xl create 10.100.12.10.cfg
> >
> > Does "xl -vvv create <the rest>" produce anything extra?
> >
> >> ----------------------------------------------------------------------------------------------------
> >> VM config
> >> ----------------------------------------------------------------------------------------------------
> > [...]
> >> shadow_memory=8
> >
> > Is there a reason you are overriding this instead of accepting the
> > default? I notice your xl dmesg has mention of running out of shadow
> > RAM, which might be related.
> 
> I remember reading that should help you to get a larger resolution when
> using VNC to access VPS console.

I don't think so, shadow_memory is used as part of the memory
virtualisation subsystem (either shadow paging or HAP), it has nothing
to do with console resolution AFAIK. You might be thinking of the
videoram option?

> 
> > [...]
> >> (XEN) common.c:1598: d10 failed to allocate from shadow
> >> pool<G><2>memory.c:132:d0 Could not allocate order=9 extent: id=10
> >> memflags=0 (2 of 4)
> >> (XEN) printk: 11634 messages suppressed.
> >
> >> (XEN) grant_table.c:350:d0 Bad flags (0) or dom (0). (expected dom 0)
> >> (XEN) common.c:1598: d11 failed to allocate from shadow
> >> pool<G><2>memory.c:132:d0 Could not allocate order=9 extent: id=11
> >> memflags=0 (2 of 4)
> >> (XEN) grant_table.c:350:d0 Bad flags (0) or dom (0). (expected dom 0)
> >
> > This looks like the root cause of the failure which xl reported. I
> > wonder if this could be a dom0 kernel issue. What are you running there?
> > Some sort of custom kernel with the grsec patches perhaps? Can you try
> > without those to rule out an incompatiblity?
> 
> I run there custom kernel 3.2.51-grsec but that have got nothing to do
> with the issue. I've tested it without custom kernel and/or grsec.
> 
> I just commented out #shadow_memory=8 and I can now start both Win7 and
> R2/2008 server with more than 4GB of RAM. Thank you for catching this
> 'error'.

Great.

> 
> >
> > I'm not at all sure why the type of guest would be related to anything
> > of that type though. A failure during domain build time like you are
> > seeing is too soon to even know what kind of guest it is going to be.
> > Could there be any options which differ between the configuration files
> > for your working and non-working guests?
> >
> > Ian.
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel