xen September 2015

xen@lists.fedoraproject.org

4 participants
4 discussions

fedora virt list is closed. want to keep xen open?
by Cole Robinson 25 Sep '15

25 Sep '15

Hi xen folks, I just closed the virt@fedora list. See the discussion here where we decided to close it: https://lists.fedoraproject.org/pipermail/virt/2015-September/004292.html TLDR: it doesn't serve a compelling purpose nowadays, and questions are better directed to upstream lists or general fedora lists. How do folks feel about the xen list? Kinda strange timing since we just had a useful thread regarding my Xen-on-KVM issue, but that could have been a bug report too. But prior to that discussion, there hadn't been any mail here for over six months... If yall decide you want to leave the list open, that's fine with me. But then I'd like to hand off admin list access to someone else Thanks, Cole

2 4

Re: [Fedora-xen] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: Running fedora xen on top of KVM?
by Konrad Rzeszutek Wilk 22 Sep '15

22 Sep '15

On Sun, Sep 20, 2015 at 09:49:04PM -0700, Andy Lutomirski wrote: > On Fri, Sep 18, 2015 at 12:04 PM, Borislav Petkov <bp(a)alien8.de> wrote: > > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote: > >> In any event, Borislav, you must have typed rdmsr_safe for a reason :) > > > > Wasn't me: > > > > 6c62aa4a3c12 ("x86: make amd.c have 64bit support code") > > > > I think the error handling of rdmsrl_safe() was needed to do the pfn > > games which are done in the if-clause. > > I just tried it. rdmsrl_safe and friends definitely work fine in that > code. I think that Linux's Xen startup code is buggy and fails to set > up early exception handling. > > Try this (horribly whitespace damaged): > > static void __init early_identify_cpu(struct cpuinfo_x86 *c) > { > + u64 tmp; > #ifdef CONFIG_X86_64 > c->x86_clflush_size = 64; > c->x86_phys_bits = 36; > @@ -752,6 +753,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c) > c->cpu_index = 0; > filter_cpuid_features(c, false); > > + pr_err("trying to crash\n"); > + rdmsrl_safe(0x12345678, &tmp); > + > > It works fine. I bet it crashes on a Xen guest, though. I assume > that Xen just works in most cases by luck. (d31) mapping kernel into physical memory (d31) about to get started... (XEN) traps.c:3151: GPF (0000): ffff82d0801a31ed -> ffff82d08023c77b (XEN) traps.c:459:d31v0 Unhandled general protection fault fault/trap [#13] on VCPU 0 [ec=0000] (XEN) domain_crash_sync called from entry.S: fault at ffff82d080238213 create_bounce_frame+0x12b/0x13a (XEN) Domain 31 (vcpu#0) crashed on cpu#35: (XEN) ----[ Xen-4.5.0 x86_64 debug=n Not tainted ]---- (XEN) CPU: 35 (XEN) RIP: e033:[<ffffffff81041b64>] (XEN) RFLAGS: 0000000000000246 EM: 1 CONTEXT: pv guest (XEN) rax: 0000000000000000 rbx: ffffffff81c03e64 rcx: 0000000012345678 (XEN) rdx: ffffffff81c03de8 rsi: ffffffff81c03dec rdi: 0000000012345278 (XEN) rbp: ffffffff81c03e48 rsp: ffffffff81c03dd0 r8: 7420676e69797274 (XEN) r9: 6873617263206f74 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000012345678 r13: ffffffff81c03f00 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000001526f0 (XEN) cr3: 00000014e8c97000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff81c03dd0: (XEN) 0000000012345678 0000000000000000 0000000000000000 ffffffff81041b64 (XEN) 000000010000e030 0000000000010046 ffffffff81c03e18 000000000000e02b (XEN) ffffffff81041b5d ffffffff81c03e48 0000000000811809 0000000000000000 (XEN) 00000000000001a0 0000000001000000 ffffffff82009000 ffffffff81c03e68 (XEN) ffffffff81d211ea 0000000000000000 0000000000000000 ffffffff81c03ed8 (XEN) ffffffff81d1be59 ffffffff81c03ed8 ffffffff811892ab 0000000000000010 (XEN) ffffffff81c03ee8 ffffffff81c03ea8 697a696c61697469 ffffffff81f15442 (XEN) ffffffffffffffff ffffffff81db3900 0000000000000000 0000000000000000 (XEN) 0000000000000000 ffffffff81c03f28 ffffffff81d10f0a 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffff81c03f38 (XEN) ffffffff81d10603 ffffffff81c03ff8 ffffffff81d15f5c 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 ffd83a031f898b75 0000000022400800 0000000000000001 (XEN) 0000000000000000 0000000000000000 00010102464c457f 0000000000000000 (XEN) 00000001003e0003 0000000000000940 0000000000000040 00000000000012a0 (XEN) 0038004000000000 0011001200400004 0000000500000001 0000000000000000 [root@ovs107 ~]# (gdb) x/20i 0xffffffff81041b64 0xffffffff81041b64: rdmsr > > --Andy

1 0

Re: [Fedora-xen] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: Running fedora xen on top of KVM?
by Cole Robinson 18 Sep '15

18 Sep '15

On 09/18/2015 03:04 PM, Borislav Petkov wrote: > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote: >> Given that we can handle fixups in the decompressor, surely it >> wouldn't be so hard to make early GPF fixups work in the main kernel. > > Frankly, I still am wondering what a sensible use case of running xen > hypervisor/dom0 as a kvm guest would be. > Testing libvirt + virt-manager xen support without requiring a physical machine running xen. - Cole

1 0

Running fedora xen on top of KVM?
by Cole Robinson 17 Sep '15

17 Sep '15

Anyone know how to get fedora + xen running in a KVM VM? I'd like to be able to do basic xen/libxl/libvirt testing without needed to reboot a physical machine. Trying with F23 AMD host, F22+xen L1, trying to boot into xen in the L1 VM just reboots very soon after trying to boot the kernel. Tried disabling all virtio for L1 VM, disabling virt extensions for the L1 VM, but it didn't seem to change anything. Unfortunately the messages scroll by so quickly I can't tell what's happening right before it reboots, and all efforts to convince it to print more debugging haven't worked. FWIW this does work with rhel5+xen L1, but that's a world away at this point. So anyone know if it's even possible? Is there a trick to it? If not, suggestions on getting more debug output from xen + grub2? Thanks, Cole

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xen September 2015