Re: E5606 with no HVM; Assertion 'i == 1' failed at p2m-ept.c:524

["Mark van Dijk" <lists+xen@internecto.net>]

On Thu, 16 Aug 2012 09:11:50 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 15.08.12 at 22:39, Mark van Dijk <lists+xen@internecto.net>
> >>> wrote:
> > (XEN) Xen call trace:
> > (XEN)    [<ffff82c4801e1be9>] ept_get_entry+0x13a/0x28f
> > (XEN)    [<ffff82c4801da274>] __get_gfn_type_access+0x175/0x256
> > (XEN)    [<ffff82c4801b5a55>] hvm_hap_nested_page_fault+0x133/0x422
> > (XEN)    [<ffff82c4801d3c8e>] vmx_vmexit_handler+0x136b/0x1614
> > 
> > The entire log from boot to crash can be viewed at the following
> > link: http://pastebin.com/5wcH7GWR 
> 
> Unfortunately quite a few of the registers contain values that
> could sensibly be "i". Could you either disassemble the
> instructions around the place yourself to find out which one it
> is, or make the xen-syms file corresponding to this run available?

Hi Jan, I'm not capable to disassemble anything because my experience
with that is zero. So it's probably easier to give you the xen-syms
file, I posted it to a pastebin with a little detour:

curl http://sprunge.us/cGeL | openssl enc -a -d | \
 xz -d > xen-syms-4.2.0-rc3-pre

md5sum aa27f5aeea45f72cab88848e5996080e

> 
> I'm suspecting "i" to actually be 2, and the code not having got
> updated when 1Gb page support got added to PoD. You could
> hence alternatively also try the attached debugging patch,
> which - if my guess is right - may at once fix your problem.

Sure, I'll give that a go and let you know, thanks.

> However, because of this outright claiming that HVM doesn't
> work seems a little harsh - did you try running your guests
> without the use of PoD (i.e. with memory == maxmem)?

If it sounded like I meant to complain that HVM is broken then I
apologise, that's not what I meant. I meant it didn't work on my system
and I had no idea that this relates to maxmem. :)

I'll admit that I didn't try the hvm without the maxmem setting but the
VM has settings 'memory = 1024; maxmem = 4096'.

Mark