[Xen-devel] Added as CC - [#29506] [Xen-announce] Xen Security Advisory 209 (CVE-2017-2620) - cirrus_bitblt_cputovideo does not check if memory region is safe

[Proteon Mailing Lists]

 Xen.org security team submitted a new ticket to Firelay/Proteon Support Portal 
and requested that we copy you   Ticket Description:  -BEGIN PGP SIGNED 
MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2017-2620 / XSA-209
  version 3

   cirrus_bitblt_cputovideo does not check if memory region is safe

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine
cirrus_bitblt_cputovideo fails to check wethehr the specified memory
region is safe.

IMPACT
==

A malicious guest administrator can cause an out of bounds memory
write, very likely exploitable as a privilege escalation.

VULNERABLE SYSTEMS
==

Versions of qemu shipped with all Xen versions are vulnerable.

Xen systems running on x86 with HVM guests, with the qemu process
running in dom0 are vulnerable.

Only guests provided with the "cirrus" emulated video card can exploit
the vulnerability.  The non-default "stdvga" emulated video card is
not vulnerable.  (With xl the emulated video card is controlled by the
"stdvga=" and "vga=" domain configuration options.)

ARM systems are not vulnerable.  Systems using only PV guests are not
vulnerable.

For VMs whose qemu process is running in a stub domain, a successful
attacker will only gain the privileges of that stubdom, which should
be only over the guest itself.

Both upstream-based versions of qemu (device_model_version="qemu-xen")
and `traditional' qemu (device_model_version="qemu-xen-traditional")
are vulnerable.

MITIGATION
==

Running only PV guests will avoid the issue.

Running HVM guests with the device model in a stubdomain will mitigate
the issue.

Changing the video card emulation to stdvga (stdvga=1, vga="stdvga",
in the xl domain configuration) will avoid the vulnerability.

CREDITS
===

This issue was discovered by Gerd Hoffmann of Red Hat.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa209-qemuu.patch   qemu-xen, qemu upstream
(no backport yet)qemu-xen-traditional

$ sha256sum xsa209*
167af9ed7163fa7cf4abb52f865290ced3163c7684151bdc1324eb5e534faf13  
xsa209-qemut.patch
297578aa43c3e6b21333f1b859fd1d3e68e77b3cadbadd20cfeca8426df3  
xsa209-qemuu.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

However, deployment of the "stdvga" mitigation (changing the video
card emulation to stdvga) is NOT permitted (except where all the
affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.  This is because this produces a guest-visible
change which will indicate which component contains the vulnerability.

Additionally, distribution of updated software is prohibited (except
to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJYrBl3AAoJEIP+FMlX6CvZ6LMIALETwnX9w8SifkvuYY3jotwp
nQWY8ztJkMnai9X10RN6SeVf2dCpXLhATPuPGORgRiZJEuBaGHEsHa00i63FQBSL
PaOAgzN1GY+u16Ygv2e3vPcN8mO55A6zcFErF2oLsrfdNsG4pJTwn7bMEjZiqSyG
R9xIC6KiA1nojsZO+ynmRvHxFP6epySRayO0PZAGS75LdmEKVxClE3dAeMW77WNv
dAs3Qi14hB5BmdryK5f1STk8r2b3UsN1pbvao8odiEWFaB9tPo273gj5RdfnEV3t
EzTvH37Q3C4YFoTFx8p6fY5ejHNh4AeSyi9yE7lWtKhDZw56UhdfMmYIgDaKpig=
=RBpg
-END PGP SIGNATURE-


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Aug 3, 2016, at 02:01 AM, Jan Beulich wrote:
> > with the 'baseline' as referenced + a patched kernel
> > 
> > > Can you try
> > >((void *)(md) + (m)->desc_size - 1) < (m)->map_end;
> >\
> > 
> > with efi cmd line opts: +"/mapbs"
> > 
> > The system now boots correctly

fyi, there's at least one disagreement re: the suggested - and ack'd as working 
- patch,

  https://lists.opensuse.org/opensuse-kernel/2016-08/msg8.html

"That's incorrect IMO. Either -1 or <. Not both -1 and <."

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Aug 3, 2016, at 07:50 AM, li...@ssl-mail.com wrote:
> So *today's* simplest working combination seems to be 

After the sytem is booted with

+ patched kernel
- /mapbs
+ efi=no-rs

I now get tons of these at serial console

(XEN) [2016-08-03 15:23:25] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:23:39] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:23:57] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:24:11] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:24:30] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:24:43] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:25:02] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:25:15] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:25:34] d1v0 Over-allocation for domain 1: 524545 > 
524544

That's with logging set to

loglvl=warning guest_loglvl=none/warning

Not sure it matters other than being useless noise.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

> > A #GP fault in firmware code. Not much we can do about, I'm afraid,
> > except for having you go with one of the mentioned workarounds

I tried

+ efi=no-rs
+ efi=attr=uc

on the Xen cmd line.

With efi=attr=uc, crashes on reboot with or without /mapbs

With efi=no-rs, reboots OK with or without /mapbs

So *today's* simplest working combination seems to be 

- /mapbs, + efi=no-rs

Two weeks  or so ago, it was just

+ /mapbs

> > (and perhaps getting in touch with the BIOS vendor).

The BIOS vendor refuses to talk to end users.  They deflect to the Motherboard 
vendor.

The motherboard vendor is Supermicro.  We have four different servers running 
on their motherboards.

Supermicro are not interested in a small user's problems.  Their responses have 
included

- we don't support linux
- we don't support Xen
- use Microsoft WIndows
- we don't write the BIOS. there's nothing we can do.

and finally just ignoring our emails.

At least Supermicro, being a 'server grade' mobo provider, has tech support you 
can get to that seem aware of linux & Xen.

The 'consumer grade' providers were just completely hopeless the moment you 
mention linux, xen, and or server.

And to be honest, what exactly would *I* tell them?  "It doesn't work"? It's 
not like I have any real idea what's broken in detail or how to fix it.

Unless devs that know what they're talking about, and are from a big vendor or 
project with visible presence or clout, get in touch with them nothing will 
change. 

> One bit you snipped was
> 
> (XEN) [2016-08-03 13:06:54] Xen code around <9e746340>
> (9e746340):
> (XEN) [2016-08-03 13:06:54]  00 00 00 00 00 00 00 00 <00> 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00
> (XEN) [2016-08-03 13:06:54] Xen stack trace from rsp=83008ce27dc0:
> 
> which shows that the EFI firmware has ended up in a block of zeroes. 
> This clearly isn't conducive to its overall health.

What options to the Xen or EFI command line can fix that?
Or is that a Xen or kernel code fix?
Or again a "BIOS issue"?

Fwiw 3 of those 4 servers are now being migrated to other Hypervisor/Container 
platforms.

So far KVM, FreeBSD and Microsoft are all booting & rebooting on UEFI hardware 
OK. Or at least not seeing crashes.  Haven't gotten much further in testing 
than that yet.

I'm not clear why 'BIOS' problems are only showing up when we use Xen, and only 
since 'recent' upgrades (it was working a few weeks ago), and now need (at 
least) efi=no-rs when they didn't before.

If I tell Supermicro that their motherboard works on these other platforms, 
particularly Microsoft, but not with Xen, I'm pretty sure I know exactly what 
they'll say.  And as an enduser I don't have the detailed knowledge to argue 
with them.  Let alone get them to do anything about it.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Aug 3, 2016, at 02:01 AM, Jan Beulich wrote:
> Thanks. Does the use of /mapbs really matter for booting? I was
> assuming it would be relevant only for shutdown/reboot?

It has no effect on boot. With or without the "/mapbs" it boots Xen OK.

Without the "/mapbs" the system used to crash on reboot, but still continued 
with a reboot.  Reboot with the "/mapbs" was OK.

Now, even with the "/mapbs" the system crashes on reboot.


[  196.052042] reboot: Restarting system
(XEN) [2016-08-03 13:06:54] Hardware Dom0 shutdown: rebooting machine
(XEN) [2016-08-03 13:06:54] APIC error on CPU0: 40(00)
(XEN) [2016-08-03 13:06:54] [ Xen-4.7.0_09-454  x86_64  debug=n  
Not tainted ]
(XEN) [2016-08-03 13:06:54] CPU:0
(XEN) [2016-08-03 13:06:54] RIP:e008:[<9e746340>] 
9e746340
(XEN) [2016-08-03 13:06:54] RFLAGS: 00010202   CONTEXT: 
hypervisor (d0v0)
(XEN) [2016-08-03 13:06:54] rax: 9e746340   rbx: 
   rcx: 
(XEN) [2016-08-03 13:06:54] rdx:    rsi: 
   rdi: 
(XEN) [2016-08-03 13:06:54] rbp:    rsp: 
83008ce27dc0   r8:  
(XEN) [2016-08-03 13:06:54] r9:     r10: 
   r11: 
(XEN) [2016-08-03 13:06:54] r12:    r13: 
0cf9   r14: 0065
(XEN) [2016-08-03 13:06:54] r15: 8300   cr0: 
80050033   cr4: 001526e0
(XEN) [2016-08-03 13:06:54] cr3: 00084b4e5000   cr2: 
9e746340
(XEN) [2016-08-03 13:06:54] ds:    es:    fs:    gs:    
ss: e010   cs: e008
(XEN) [2016-08-03 13:06:54] Xen code around <9e746340> 
(9e746340):
(XEN) [2016-08-03 13:06:54]  00 00 00 00 00 00 00 00 <00> 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00
(XEN) [2016-08-03 13:06:54] Xen stack trace from rsp=83008ce27dc0:
(XEN) [2016-08-03 13:06:55]9efe42f6 0cf9 
82d08022f741 efff
(XEN) [2016-08-03 13:06:55]82d0807fe000 00084b4e5000 
82d08022f94a 00085da98000
(XEN) [2016-08-03 13:06:55] 0007 
e008 0292
Initializing Adapter 0

...
XEN) [2016-08-03 13:30:44] Xen call trace:
(XEN) [2016-08-03 13:30:44][<9e7463c6>] 9e7463c6
(XEN) [2016-08-03 13:30:44][] 
i387.c#_vcpu_save_fpu+0x86/0x190
(XEN) [2016-08-03 13:30:44][] 
efi_reset_system+0x3a/0x60
(XEN) [2016-08-03 13:30:44][] 
machine_restart+0x208/0x2d0
(XEN) [2016-08-03 13:30:44][] 
hwdom_shutdown+0x7d/0xf0
(XEN) [2016-08-03 13:30:44][] 
domain_shutdown+0xf1/0x100
(XEN) [2016-08-03 13:30:44][] 
do_sched_op+0x1b2/0x460
(XEN) [2016-08-03 13:30:44][] 
lstar_enter+0x9b/0xa0
(XEN) [2016-08-03 13:30:44]
(XEN) [2016-08-03 13:30:44]
(XEN) [2016-08-03 13:30:44] 
(XEN) [2016-08-03 13:30:44] Panic on CPU 0:
(XEN) [2016-08-03 13:30:44] GENERAL PROTECTION FAULT
(XEN) [2016-08-03 13:30:44] [error_code=]
(XEN) [2016-08-03 13:30:44] 

And still reboots.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

> > Can you try
> > 
> >  ((void *)(md) + (m)->desc_size - 1) < 
> > (m)->map_end;   \
> > 
> > instead?

with the 'baseline' as referenced + a patched kernel

> Can you try
>((void *)(md) + (m)->desc_size - 1) < (m)->map_end;
   \

with efi cmd line opts: +"/mapbs"

The system now boots correctly

uname -rm
4.7.0-6-default x86_64

xl list
NameID   Mem VCPUs  
State   Time(s)
Domain-0 0  4096 1 
r-  52.4
g1   1  2049 1 
-b  15.0
g2   2  1025 1 
-b  15.5
g3   3  1025 1 
-b  16.2
g4   4  1025 1 
-b  19.6

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] What distros have Xen 4.7 packages that work on UEFI hardware?

[lists]

> The level of support you get is somewhat proportional to the amount of money 
> you spend.

I shared that comment here, and the immediate follow-on response was:

"Great.  Money's not the problem. Which commercial entity provides a supported 
solution?"

We're happy to consider Oracle, Redhat, Ubuntu or XenServer for commercial 
distros.

Debian too, if there's commercial support.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Tue, Aug 2, 2016, at 07:50 AM, Jan Beulich wrote:
> - one with some suitable variant of reboot=

What exactly is "some suitable variant of reboot" ?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Tue, Aug 2, 2016, at 07:13 AM, Jan Beulich wrote:
> > You keep stating what you don't see.
> 
> Because you keep being vague...

I have attempted to provide everything that's been asked of me.

If you don't like it that's fine.  State with specificity what it is you want.

> Unless /mapbs really produces an _exactly_ identical crash, I'd like to
> see that boot's output at maximum log level. I don't recall "efi=no-rs"
> having been mentioned before on this thread, but yes, I'd expect
> that one to help as much as the suggested "reboot=..." option, so
> if either doesn't, logs thereof would also be of interest.

You criticize MY vagueness then do this.

Identical crash to WHAT? WHICH boot's output?  WHAT do you consider maximum log 
level -- DIFFERENT than what I've already provided?

I am not a good mind reader, interpreter, guesser.

Just like I said I would, if & when you or someone else who cares to provides 
clear unequivocal set of options / cases that you want tested I will provide 
them.

Or do you really want a fishing expedition with every possible combination of 
every option?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Tue, Aug 2, 2016, at 06:38 AM, Jan Beulich wrote:
> Well, without going through the _full_ thread again, what I could
> easily find is
> 
> "So full console output from boot -> crash now doesn't look any different 
> than 
> 
>   https://lists.xen.org/archives/html/xen-devel/2016-07/msg02814.html 
> "
> 
> which doesn't tell me at all which combination of /mapbs and/or
> /noexitboot was used. Certainly in that run "efi=attr=uc" wasn't
> used. It in particular seems highly questionable to me that the
> reboot crash would look _exactly_ the same with /mapbs.

You keep stating what you don't see.

Afaict, there are four options that seem to have been talked about 

/mapbs & /noexitboot on the EFI cmd line

and

efi=attr=uc and ef=no-rs on the xen cmd line

I really don't want to keep guessing and reposting unnecessary information, and 
am TRYING to provide the right information.

Can you simply say what output you want?  What combination of options of efi 
cmd line, xen cmd line, and log options?

I will provide THAT.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Mon, Aug 1, 2016, at 11:57 PM, Jan Beulich wrote:
> Obviously it's not mentioned, as it's in the base tarball.

Not obvious at all.  What seemed obvious is that the changelog would show all 
the changes.

It doesn't and it wasn't mentioned.  Now I know.

> Can you try
> 
>((void *)(md) + (m)->desc_size - 1) < 
> (m)->map_end;   \
> 
> instead?

Sure, as soon as I can figure out how to successfully patch & build either the 
distro kernel, or a vanilla one that'll boot the system.

Can't do either one just yet.  Working on it.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Mon, Aug 1, 2016, at 11:36 PM, Jan Beulich wrote:
> yet without a full log thereof I can't judge

I've asked what that 'full log' should be

>>> Hmmm Could you provide full console dump from Xen and Linux kernel?
>
>Will serial console output with these options
>
>   kernel: earlyprintk=xen,keep debug loglevel=8
>   hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring

got an ack, then provided the serial console output with that set of log 
options.

Like I said I'm happy to try to provide what's needed.

If THAT is not the full log output that's needed, then what specifically is?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] What distros have Xen 4.7 packages that work on UEFI hardware?

[lists]

On Tue, Aug 2, 2016, at 12:06 AM, Jan Beulich wrote:
> I don't understand this distro related complaint. 

Possibly because it's not a complaint.  It's a question.

> Afaict the bug is in upstream Linux, and hence any distro will have the issue.
> expectation that freshly released Linux (or Xen) versions are
> completely bug free is simply wrong, as is your expectation that a
> solution will always be found within a couple of days, the more
> when quite a bit of back and forth is needed to even get all
> relevant data. As was validly said recently in the context of a
> different thread: The level of support you get is somewhat
> proportional to the amount of money you spend.

I don't have expectations here.  I have a question.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [BUG] Re: Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

Horse is already WAY out of the barn on this, but just realizing the 
instructions say to

> Please tag your subject line with a '[BUG]' prefix.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Fri, Jul 29, 2016, at 09:03 AM, Konrad Rzeszutek Wilk wrote:
> It may very well be added.
> 
> But having extra test-confirmation is always good.

looking at the patch

diff --git a/include/linux/efi.h b/include/linux/efi.h
index c2db3ca..f196dd0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1005,7 +1005,7 @@  extern int efi_memattr_apply_permissions(struct 
mm_struct *mm,
 /* Iterate through an efi_memory_map */
 #define for_each_efi_memory_desc_in_map(m, md) 
   \
for ((md) = (m)->map;   
   \
-(md) <= (efi_memory_desc_t *)((m)->map_end - 
(m)->desc_size); \
+((void *)(md) + (m)->desc_size) <= (m)->map_end;   
   \
 (md) = (void *)(md) + (m)->desc_size)

 /**

and in the source used in the distro build

wget 
https://build.opensuse.org/source/Kernel:stable/kernel-default/linux-4.7.tar.xz?rev=88182fafc706b2366e0251692bd4b7e7
tar zxf linux-4.7.tar.xz
cd linux-4.7/include/linux/
edit efi.h

it looks like the patch is in there already

1005/* Iterate through an efi_memory_map */
#define for_each_efi_memory_desc_in_map(m, md)  
   \
for ((md) = (m)->map;   
   \
>>>  ((void *)(md) + (m)->desc_size) <= 
>>> (m)->map_end;  \
 (md) = (void *)(md) + (m)->desc_size)

even if it's not mentioned in the changelog.

The binary built with this source crashes as reported.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] What distros have Xen 4.7 packages that work on UEFI hardware?

[lists]

I want to run Xen+Linux Dom0 host on server-grade UEFI hardware.

I want to use current stable releases of Xen (4.7) and Linux kernel (4.7).

I prefer to use distro packages when possible, but the current distro packages 
I use crash on Xen boot.

I can't keep having things down for days or weeks at a time and I can't get any 
response from the distro devs at all.

To get off this train I'm working on building my own Xen & Linux from source 
and getting that reliable enough for production here.  Not quite there yet.

In the meantime I should try other distros as alternatives too.

What distros, if any provide "official" and/or "regularly maintained" packages 
that are

(1) up-to-date with current stable releases of Xen and Kernel?
(2) known to work on UEFI hardware for Dom0 boot?
(3) can boot UEFI DomU guests?


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Fri, Jul 29, 2016, at 09:03 AM, Konrad Rzeszutek Wilk wrote:
> It may very well be added.

Just fyi, it's not in here.  Yet.

> But having extra test-confirmation is always good.

Right, and I'm glad to do that.  I'd like to.  Goal is to keep moving the ball 
forward.

And I've been testing what I've been asked to when I can do it with packages 
that I have and that work.

I just haven't figured out yet how to use their 'build system' to build a 
kernel and get it working to boot.

I built a kernel the 'upstream' way but that won't boot Xen at all.  Sure it's 
something I'm not doing right, I know.

So

(1) I'll keep trying to DIY and get something running
(2) As soon as the distro patches their packages with the patches you all say 
it should have, then I'll test them and report back

IF there's a different combination of different OS + packages for a Kernel 
version + Xen version that is known to work with UEFI Dom0 & UEFI Guests then 
I'm all ears.

A friend's starting to test KVM with QEMU + OVMF/UEFI on another box, and so 
far so good I guess.  I don't want to use it for a bunch of reasons, so I'm 
sticking it out in here.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Fri, Jul 29, 2016, at 08:42 AM, Konrad Rzeszutek Wilk wrote:
> did you apply the patch that Vitaly pointed out?

No.  It wasn't clear that it was anything more than a question to 
"double-check".   There wasn't any further comment on my reply.

I'm depending on working packages for now.  Like I said earlier building my own 
packages is something I haven't gotten to work to the point that I can boot up 
without causing other problems yet.

I'm trying to get to that point, but not there today.

If that's a 'must fix this' patch, then I don't quite get why it doesn't just 
get added to the distro packages.  The devs from the distro are obviously here.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote:
> This looks suspiciously like the issue which was fixed by c/s
> d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when
> setting early page table entries", but that fix is present in Linux 4.7.0
> 
> Can you check to see whether the commit is included in your kernel?
> 
> Failing that, can you find out exactly where the kernel crashed?  You
> need to manually decode 81f6374c with the debug symbols.
> 
> ~Andrew

Is an eventual fix to whatever is causing this crash likely in the kernel or 
Xen code?

I've managed to try a couple of different kernels, older version, with no luck. 
 Crash still happens.

Getting my hands on an older Xen package is turning out to be a bit tougher.  
Still working on it.

Not sure what specifically changed to break this , since this server clearly 
was running not that long ago.

I'd like to at least figure out what I can drop back to so I can get my server 
and guests back up and running.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On 07/28/2016 11:25 AM, li...@ssl-mail.com wrote:>
> Hmmm Could you provide full console dump from Xen and Linux kernel?
> 
> Will serial console output with these options
> 
>   kernel: earlyprintk=xen,keep debug loglevel=8
>   hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring
> 
> do?

I'll just assume it does.

So full console output from boot -> crash now doesn't look any different than 

https://lists.xen.org/archives/html/xen-devel/2016-07/msg02814.html

On 07/27/2016 08:50 AM, Andrew Cooper wrote
>> For the Linux crash, can you boot Linux with 
"earlyprintk=xen" and see
>> if that provides more help as to what went wrong?
>
>Here's serial console output with grub2 log parameters 
included as
>
>kernel: earlyprintk=xen,keep debug loglevel=8
>hypervisor: loglvl=all guest_loglvl=all sync_console 
console_to_ring


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

> Hmmm Could you provide full console dump from Xen and Linux kernel?

Will serial console output with these options

kernel: earlyprintk=xen,keep debug loglevel=8
hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring

do?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

anyone need any addl info from my end to help ?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Thu, Jul 28, 2016, at 07:09 AM, Vitaly Kuznetsov wrote:
> While I see that you're running linux-4.7 could you please double-check
> that it has the following:
> 
> commit 55f1ea15216a5a14c96738bd5284100a00ffa9dc
> Author: Vitaly Kuznetsov 
> Date:   Tue May 31 11:23:43 2016 +0100
> 
> efi: Fix for_each_efi_memory_desc_in_map() for empty memmaps

Checking here

  rpm -q --changelog kernel-default | egrep -i 
"55f1ea15|for_each_efi_memory_desc_in_map|kuznets|memmaps"

returns nothing.  Doesn't look like it's in there.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 05:28 PM, li...@ssl-mail.com wrote:
> 123   unsigned long long size = md->num_pages << 
> EFI_PAGE_SHIFT;

If I'm reading it right, that originated in this pull

DateMon, 16 May 2016 16:43:11 +0200
FromIngo Molnar <>
Subject [GIT PULL] EFI changes for v4.7
https://lkml.org/lkml/2016/5/16/244

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 11:36 AM, li...@ssl-mail.com wrote:
> On Wed, Jul 27, 2016, at 11:28 AM, Andrew Cooper wrote:
> > > I'm not sure if that's good enough.
> > 
> > Sadly not.  The debug symbols need to be specific to the exact binary
> > you booted.
> > 
> > Any change in the compilation will result in the translation being
> > useless.  What addr2line is doing is saying "which specific bit of
> > source code did the compiler/linker end up putting at $X".
> 
> Got it.  Weird that they don't put the .debuginfo rpms in there.  While I was 
> searching around kernel bug reports over at the distro there's lots of posts 
> telling people to debug.  Not sure then how you do it without the debug 
> symbols.
> 
> Guess you have to build your own kernel.

I got my hands on a 'matched set'

rpm -qa kernel-default\*
kernel-default-4.7.0-5.1.x86_64
kernel-default-devel-4.7.0-5.1.x86_64
kernel-default-debuginfo-4.7.0-5.1.x86_64

reboot to Xen, still crashes

(XEN) [2016-07-28 00:13:18] [ Xen-4.7.0_08-452  x86_64  
debug=n  Tainted:C ]
(XEN) [2016-07-28 00:13:18] CPU:0
>>> (XEN) [2016-07-28 00:13:18] RIP:e033:[]
(XEN) [2016-07-28 00:13:18] RFLAGS: 0246   EM: 1   
CONTEXT: pv guest (d0v0)
(XEN) [2016-07-28 00:13:18] rax:    rbx: 
   rcx: 00016f144000
(XEN) [2016-07-28 00:13:18] rdx: 0001   rsi: 
00016f144000   rdi: f000
(XEN) [2016-07-28 00:13:18] rbp: 0100   rsp: 
81e03e50   r8:  81efb0c0
(XEN) [2016-07-28 00:13:18] r9:     r10: 
   r11: 0001
(XEN) [2016-07-28 00:13:18] r12:    r13: 
   r14: 81e03f28
(XEN) [2016-07-28 00:13:18] r15:    cr0: 
80050033   cr4: 001526e0
(XEN) [2016-07-28 00:13:18] cr3: 000841e06000   cr2: 
0018
(XEN) [2016-07-28 00:13:18] ds:    es:    fs:    
gs:    ss: e02b   cs: e033
(XEN) [2016-07-28 00:13:18] Guest stack trace from 
rsp=81e03e50:

check ar the RIP addr

addr2line -e /usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug 
81f63eb0

/usr/src/debug/kernel-default-4.7.0/linux-4.7/linux-obj/../arch/x86/platform/efi/efi.c:123

in source

@ 
https://github.com/torvalds/linux/blob/v4.7/arch/x86/platform/efi/efi.c

...
void __init efi_find_mirror(void)
{
efi_memory_desc_t *md;
u64 mirror_size = 0, total_size = 0;

for_each_efi_memory_desc(md) {
unsigned long long start = md->phys_addr;
123 unsigned long long size = md->num_pages << 
EFI_PAGE_SHIFT;

total_size += size;
if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
memblock_mark_mirror(start, size);
mirror_size += size;
}
}
if (mirror_size)
pr_info("Memory: %lldM/%lldM mirrored memory\n",
mirror_size>>20, total_size>>20);
}
...

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 11:28 AM, Andrew Cooper wrote:
> > I'm not sure if that's good enough.
> 
> Sadly not.  The debug symbols need to be specific to the exact binary
> you booted.
> 
> Any change in the compilation will result in the translation being
> useless.  What addr2line is doing is saying "which specific bit of
> source code did the compiler/linker end up putting at $X".

Got it.  Weird that they don't put the .debuginfo rpms in there.  While I was 
searching around kernel bug reports over at the distro there's lots of posts 
telling people to debug.  Not sure then how you do it without the debug symbols.

Guess you have to build your own kernel.

That's one of the things I'm thinking of doing , along with Xen, eventually so 
I don't have to waste days hoping packages get fixed when someone helps out 
with a suggestion to try, like you did.  But I never got the "build it all 
yourself" working when I tried awhile ago.  

> I wouldn't worry too much - I expect (the lack of) the aforementioned
> changeset is the cause of your issues.

Ok we'll wait and see if there's an update to try, I guess.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 09:56 AM, Andrew Cooper wrote:
> >> Failing that, can you find out exactly where the kernel crashed?  You
> >> need to manually decode 81f6374c with the debug symbols.
> > Sure can try.  I'm gonna have to read-up on how .  Atm no clue.
> 
> addr2line -e /path/to/linux/debug/symbols 81f6374c

Thanks.

For whatever reason it the dev debug symbols aren't available for the official 
Kernel:Stable branch,


http://software.opensuse.org/package/kernel-default-debuginfo?search_term=kernel-default-debuginfo

unlike for the release 4.1.x kernel.

But there is this from an unofficial repo


https://build.opensuse.org/package/binaries/hardware:nvdimm/kernel-default?repository=openSUSE_Leap_42.1

I'm not sure if that's good enough.  Anyway if I directly install that one


http://download.opensuse.org/repositories/hardware:/nvdimm/openSUSE_Leap_42.1/x86_64/kernel-default-debuginfo-4.7.0-5.1.x86_64.rpm

Then

rpm -ql kernel-default-debuginfo | grep linux
/usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug

addr2line -e /usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug 
81f6374c

/usr/src/debug/kernel-default-4.7.0/linux-4.7/linux-obj/../arch/x86/mm/numa_emulation.c:444

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote:
> This looks suspiciously like the issue which was fixed by c/s
> d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when
> setting early page table entries", but that fix is present in Linux 4.7.0
> 
> Can you check to see whether the commit is included in your kernel?

This

 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.git/+/d6b186c1e2d852a92c43f090d0d8fad4704d51ef

looks like the Suse team was involved,

  Reviewed-by: Juergen Gross 

But checking this kernel

 rpm -q kernel-source
  kernel-source-4.7.0-4.1.g89a2ada.noarch
 rpm -q --changelog kernel-source | egrep -i "m2p|d6b186c1"
  - guarantee M2P to be invisible to user mode.

it doesn't look like it's in here.

> Failing that, can you find out exactly where the kernel crashed?  You
> need to manually decode 81f6374c with the debug symbols.

Sure can try.  I'm gonna have to read-up on how .  Atm no clue.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 08:50 AM, Andrew Cooper wrote:
> This disassembles to
> 
> callq  *0x8(%rax)
> 
> and %rax looks like an implausible value for a function pointer.  This
> particular issue is definitely an EFI firmware issue.

With all the reference to & around EFI I kinda figured ...

> I presume you mean an upgrade of the dom0 Linux kernel from 4.6.3 to 4.7.0?

Yep.

> > What other debug info can help figure out this specific problem?
> 
> This is first a Linux crash, followed by bad knock-on behaviour.
> 
> For the knockon behaviour, does Linux 4.6.3 encounter the same reboot crash 
> with Xen 4.7.0?

It didn't ... a week or so ago.  I.e. it was working fine.  Or at least I can 
say it wasn't crashing and I could boot Dom0 & my DomUs.

At the moment, I'm stuck in "use what the distro packaging provides"-land.

Which mean that I don't have a drop-back to 4.6.3 available.

Couple of things I'm gonna do to make sure that doesn't happen again in the 
future.  But for today - I'm stuck with 4.7 kernel.

> For the Linux crash, can you boot Linux with "earlyprintk=xen" and see
> if that provides more help as to what went wrong?

Here's serial console output with grub2 log parameters included as

kernel: earlyprintk=xen,keep debug loglevel=8
hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring


Loading Xen 4.7.0_08-452 with Linux 4.7.0-4.g89a2ada-default ...Loading Xen 
4.7.0_08-452 with Linux 4.7.0-4.g89a2ada-default ...

/EndEntire
/EndEntire
file path: file path: 
/ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor
(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 
/HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 
]]/HD(2,1000,96000,c5cc9661271ee648
,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)
/File(\EFI\OPENSUSE)/File(xen-4.7.0_08-452.efi)/File(xen-4.7.0_08-452.efi)/EndEntire
/EndEntire
Xen 4.7.0_08-452 (c/s ) EFI loader
Using configuration file 'xen-4.7.0_08-452.cfg'
vmlinuz-4.7.0-4.g89a2ada-default: 0x8bef9000-0x8c5064c0
initrd-4.7.0-4.g89a2ada-default: 0x8af57000-0x8bef8b2c
0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x92a25018
0x:0x03:0x00.0x0: ROM: 0x8000 bytes at 0x92a1c018
0x:0x0f:0x00.0x0: ROM: 0x10800 bytes at 0x929fb018
 __  ___  _   _ ___ ___   ___ _  _     
 \ \/ /___ _ __   | || | |___  / _ \   / _ \ ( _ )   | || || ___|___ \ 
  \  // _ \ '_ \  | || |_   / / | | | | | | |/ _ \ __| || ||___ \ __) |
  /  \  __/ | | | |__   _| / /| |_| | | |_| | (_) |__|__   _|__) / __/ 
 /_/\_\___|_| |_||_|(_)_/(_)___/___\___/ \___/  |_||/_|
  |_|  
(XEN) Xen version 4.7.0_08-452 (abu...@suse.de) (gcc (SUSE Linux) 4.8.5) 
debug=n Thu Jun 23 15:45:38 UTC 2016
(XEN) Latest ChangeSet: 
(XEN) Console output is synchronous.
(XEN) Bootloader: EFI
(XEN) Command line: dom0_mem=4096M,max:4096M dom0_max_vcpus=1 
dom0_vcpus_pin=true cpuidle=1 cpufreq=xen com1=115200,8n1,pci console=com1,vga 
console_timestamps consol
e_to_ring conring_size=64  log_buf_len=16M sched_debug apic_verbosity=verbose 
loglvl=all guest_loglvl=all noreboot=true sync_console=true 
(XEN) Video information:
(XEN)  VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 6 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 8000 (reserved)
(XEN)  8000 - 00048000 (usable)
(XEN)  00048000 - 00059000 (reserved)
(XEN)  00059000 - 0005f000 (usable)
(XEN)  0005f000 - 000a (reserved)
(XEN)  0010 - 8d93e000 (usable)
(XEN)  8d93e000 - 8d945000 (ACPI NVS)
(XEN)  8d945000 - 8e25a000 (reserved)
(XEN)  8e25a000 - 8e26 (usable)
(XEN)  8e26 - 8e6a1000 (reserved)
(XEN)  8e6a1000 - 91782000 (usable)
(XEN)  91782000 - 919ea000 (reserved)
(XEN)  919ea000 - 91a1d000 (usable)
(XEN)  91a1d000 - 91a7a000 (reserved)
(XEN)  91a7a000 - 91ae (usable)
(XEN)  91ae - 91b86000 (reserved)
(XEN)  91b86000 - 91bba000 (usable)
(XEN)  91bba000 - 91bbb000 (reserved)
(XEN)  91bbb000 - 91bbd000 (usable)
(XEN)  91bbd000 - 91bbe000 (reserved)
(XEN)  91bbe000 - 91bc6000 (usable)
(XEN)  91bc6000 - 91bc9000 (reserved)
(XEN)  91bc9000 - 91bdc000 (usable)
(XEN)  91bdc000 - 91be7000 (reserved)
(XEN)  91be7000 - 91c68000 (usable)
(XEN)  91c68000 - 91ce5000 (reserved)
(XEN)  91ce5000 - 91d2f000 (usable)
(XEN)  91d2f000 - 9208d000 (reserved)
(XEN)  9208d000 - 920d4000 

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

> What other debug info can help figure out this specific problem?

I found this post with some suggestions and additional references

  Troubleshooting UEFI related problems
   https://www.qubes-os.org/doc/uefi-troubleshooting/

I tried different combinations of

   /mapbs, /noexitboot

on the EFI cmd line, and 

efi=attr=uc

on the Xen command line.

None of them fix or look like they effect the crash.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

I'm running Xen-4.7.0_08-452 + linux kernel 4.7.0-4.g89a2ada-default on X86_64 
UEFI hardware.

If I boot without Xen hypervisor enabled it boots fine.

If I boot with Xen enabled it PANICs:

(XEN) [2016-07-26 22:05:33] Hardware Dom0 crashed: rebooting machine in 
5 seconds.
(XEN) [2016-07-26 22:05:33] APIC error on CPU0: 40(00)
(XEN) [2016-07-26 22:05:38] [ Xen-4.7.0_08-452  x86_64  debug=n  
Tainted:C ]
(XEN) [2016-07-26 22:05:38] CPU:0
(XEN) [2016-07-26 22:05:38] RIP:e008:[<9e7463c6>] 
9e7463c6
(XEN) [2016-07-26 22:05:38] RFLAGS: 00010202   CONTEXT: 
hypervisor (d0v0)
(XEN) [2016-07-26 22:05:38] rax: 0003   rbx: 
   rcx: 
(XEN) [2016-07-26 22:05:38] rdx: 9e7467a0   rsi: 
   rdi: 
(XEN) [2016-07-26 22:05:38] rbp:    rsp: 
83008ce27d78   r8:  83008ce27db8
(XEN) [2016-07-26 22:05:38] r9:  83008ce27da8   r10: 
   r11: 
(XEN) [2016-07-26 22:05:38] r12:    r13: 
0cf9   r14: 0065
(XEN) [2016-07-26 22:05:38] r15: 8300   cr0: 
80050033   cr4: 001526e0
(XEN) [2016-07-26 22:05:38] cr3: 00084b4f6000   cr2: 
0018
(XEN) [2016-07-26 22:05:38] ds:    es:    fs:    gs:    
ss:    cs: e008
(XEN) [2016-07-26 22:05:38] Xen code around <9e7463c6> 
(9e7463c6):
(XEN) [2016-07-26 22:05:38]  0f 48 8b 44 24 40 8b ce  50 08 3b d8 
0f 4c d8 48 ff c7 48 3b 7c 24 30
(XEN) [2016-07-26 22:05:38] Xen stack trace from rsp=83008ce27d78:
(XEN) [2016-07-26 22:05:38]83084b4b51c0  
 82d0801670f6
(XEN) [2016-07-26 22:05:38]83008ce27db0  
001526e0 0206
(XEN) [2016-07-26 22:05:38]0003 000841e06000 
 9efe42f6
(XEN) [2016-07-26 22:05:38]  
efff 82d0807fe000
(XEN) [2016-07-26 22:05:38]00084b4f6000 82d08022f94a 
000841e06000 
(XEN) [2016-07-26 22:05:38]0007 e008 
0296 
(XEN) [2016-07-26 22:05:38]fffe 82d08018bcc8 
 13880008
(XEN) [2016-07-26 22:05:38]83008ce27ea8  
83008ce27eb8 0003
(XEN) [2016-07-26 22:05:38]0003 83084b4b5000 
83084b4b51c0 
(XEN) [2016-07-26 22:05:38] 82d08012bf0d 
0003 82d08012bfaf
(XEN) [2016-07-26 22:05:38]81e03f28 82d080105871 
 83008ce27fff
(XEN) [2016-07-26 22:05:38]  
81e03f28 82d080105978
(XEN) [2016-07-26 22:05:38]830092826000 82d080197f8e 
0001 82d08022cc55
(XEN) [2016-07-26 22:05:38]  
81e03f28 
(XEN) [2016-07-26 22:05:38]  
0067 7ff0
(XEN) [2016-07-26 22:05:38] 0200 
 0001
(XEN) [2016-07-26 22:05:38]00016f141000 81efb2c0 
00016f141000 010e0004
(XEN) [2016-07-26 22:05:38]81f6374c e033 
0246 81e03e50
(XEN) [2016-07-26 22:05:38]e02b  
 
(XEN) [2016-07-26 22:05:38]  
830092826000 
(XEN) [2016-07-26 22:05:38] Xen call trace:
(XEN) [2016-07-26 22:05:38][<9e7463c6>] 9e7463c6
(XEN) [2016-07-26 22:05:38][] 
i387.c#_vcpu_save_fpu+0x86/0x190
(XEN) [2016-07-26 22:05:38][] 
efi_reset_system+0x3a/0x60
(XEN) [2016-07-26 22:05:38][] 
machine_restart+0x208/0x2d0
(XEN) [2016-07-26 22:05:38][] 
shutdown.c#maybe_reboot+0x3d/0x40
(XEN) [2016-07-26 22:05:38][] 
hwdom_shutdown+0x9f/0xf0
(XEN) [2016-07-26 22:05:38][] 
domain_shutdown+0xf1/0x100
(XEN) [2016-07-26 22:05:38][] 
__domain_crash_synchronous+0x18/0x30
(XEN) [2016-07-26 22:05:38][] 
asm_domain_crash_synchronous+0x3e/0x40
(XEN) [2016-07-26 22:05:38][] 
entry.o#handle_exception_saved+0x9b/0xa4
(XEN) [2016-07-26 22:05:38] 
(XEN) [2016-07-26 22:05:38] 
(XEN) [2016-07-26 22:05:38] 
(XEN) [2016-07-26 22:05:38] Panic on CPU 0:
(XEN) [2016-07-26 22:05:38] GENERAL 

Re: [Xen-devel] Nested Virt - Xen 4.4 through 4.6 - Hyper-V; Can't boot after enabling Hyper-V

[mailing lists]

Which portion of this is the unicorn?  Nested virtualization of Hyper-V
under Xen?  Or something else about my setup?

I did try to go down the path of evaluating a memory dump, however while
minidumps are enabled, they do not seem to be getting created on either of
my test systems when the message about needing to reboot is presented.

-- Bill

On Tue, Apr 7, 2015 at 12:19 PM, Andrew Cooper andrew.coop...@citrix.com
wrote:

  On 07/04/15 02:42, mailing lists wrote:

 Hi --

  I've been trying to get nested virtualization working with Xen so that I
 could boot Windows and use Hyper-V related features, however I have not had
 much success.  Using Windows 8.1 or Windows 2012r2, I'm able to install
 Windows, select and install Hyper-V features, and start rebooting.
 However, at that point, the Windows VM only partially boots, then drops me
 to a screen stating:

  Your PC needs to restart.
 Please hold down the power button.
 Error Code: 0x001E
 Parameters:
 0xC096
 0xF80315430485
 0x
 0x


  Restarting does not yield any different results.

  I've set up Xen in accordance with the notes for patches and config
 options here:

  http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen

  Trying Xen 4.4.2 stable, 4.5.1 staging, and 4.6 staging.  I applied the
 patch labeled (2/2) from the wiki link above, compiled, and used the three
 options provided for the DomU running Windows (hap, nestedhvm, and cpuid
 mask).  Windows installs and allows me to turn on HyperV features on all
 versions of Xen listed above, however all give the same or similar message
 on reboot... I'm never able to get to a running state.

  I've tried this on two separate systems.  One has an Intel E5-1620 v2,
 and the other is a n E5-1650 (original, v1 I guess).  All the
 virtualization options are enabled in the BIOS.

  If the cpuid mask is removed from the DomU config, Windows boots,
 however I'm unable to start any virtual machines (there was a message in
 the Windows event log about a component not being started in regards to
 Hyper V).

  Has anyone else run into similar issues?  Any thoughts on next steps?


 I am not aware of anyone who has successfully got a setup like this to
 work.

 From
 https://msdn.microsoft.com/en-us/library/windows/hardware/ff557408%28v=vs.85%29.aspx

 0x1E is KMODE_EXCEPTION_NOT_HANDLED.

 http://source.winehq.org/source/include/ntstatus.h suggests that
 0xC096 is STATUS_PRIVILEGED_INSTRUCTION.

 Your best bet for debugging this is to debug the minidump generated and
 see which driver 0xF80315430485 is a part of, and perhaps exactly what
 instruction 0xF80315430485 actually is.

 ~Andrew

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

Re: [Xen-devel] How to set full update mode in QEMU (in regards to display output)

[mailing lists]

As a shot in the dark, I went through vga.c for QEMU as distributed with
Xen, located each instance of the full_update variable, and set it to 1.
After recompiling, instead of a blank screen when the host is waiting for
login, I get a flickering message Waiting for display 1  That doesn't
seem to be the right answer...

On Tue, Apr 7, 2015 at 10:44 PM, mailing lists theli...@gmail.com wrote:

 Following the guide for nested virtualization here:

 http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen

 It states that one option for display issues is to force full update
 mode in QEMU.  How is that done?  I can't seem to find any documentation
 on it, and in the QEMU source, full_update isn't a config option.

 Does it require a code patch, or is there another way?

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

[Xen-devel] How to set full update mode in QEMU (in regards to display output)

[mailing lists]

Following the guide for nested virtualization here:

http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen

It states that one option for display issues is to force full update mode
in QEMU.  How is that done?  I can't seem to find any documentation on it,
and in the QEMU source, full_update isn't a config option.

Does it require a code patch, or is there another way?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Nested Virt - Xen 4.4 through 4.6 - Hyper-V; Can't boot after enabling Hyper-V

[mailing lists]

Hi --

I've been trying to get nested virtualization working with Xen so that I
could boot Windows and use Hyper-V related features, however I have not had
much success.  Using Windows 8.1 or Windows 2012r2, I'm able to install
Windows, select and install Hyper-V features, and start rebooting.
However, at that point, the Windows VM only partially boots, then drops me
to a screen stating:

Your PC needs to restart.
Please hold down the power button.
Error Code: 0x001E
Parameters:
0xC096
0xF80315430485
0x
0x


Restarting does not yield any different results.

I've set up Xen in accordance with the notes for patches and config options
here:

http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen

Trying Xen 4.4.2 stable, 4.5.1 staging, and 4.6 staging.  I applied the
patch labeled (2/2) from the wiki link above, compiled, and used the three
options provided for the DomU running Windows (hap, nestedhvm, and cpuid
mask).  Windows installs and allows me to turn on HyperV features on all
versions of Xen listed above, however all give the same or similar message
on reboot... I'm never able to get to a running state.

I've tried this on two separate systems.  One has an Intel E5-1620 v2, and
the other is a n E5-1650 (original, v1 I guess).  All the virtualization
options are enabled in the BIOS.

If the cpuid mask is removed from the DomU config, Windows boots, however
I'm unable to start any virtual machines (there was a message in the
Windows event log about a component not being started in regards to Hyper
V).

Has anyone else run into similar issues?  Any thoughts on next steps?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel