Dom0 xen support in Fedora 15?
by M A Young
I am trying to work out whether it is practical to propose Dom0 xen
support as a feature for Fedora 15.
The kernel situation is that Domain 0 has been accepted upstream for
2.6.37. Assuming a 3 month kernel release cycle, F15 will most likely ship
with a 2.6.37.x kernel, with 2.6.38 coming out either after the F15
release or just before but too late to be included. If the plan to get key
xen drivers into 2.6.38 succeeds, then F15 may be become usable as a
Domain 0 system at some point during its lifetime as the kernel package in
a Fedora version typically has one major update.
If the kernel team accept backported patches then it might just be
possible to ship F15 with usable Domain 0 support but the timescale for
that would be very tight.
The other thing we would need to consider is what needs to be done to make
xen friendly enough to be usable by an ordinary user. The page
https://fedoraproject.org/wiki/Features/XenPvopsDom0 contains plans from
when dom0 xen support was expected to make a quick return to Fedora, but
they are a couple of years old now so probably need updating.
I think as a minimum we would need a way to add a dom0 enabled grub entry
for a kernel, rather than requiring the user to hand edit the grub file.
We should also make sure that xen works with the other Fedora
virtualisation tools.
What do others think about this? For example is it achievable as a
feature, is it too early and better to wait for F16, and what else should
we aim to do to make xen usable in Fedora?
Michael Young
13 years, 3 months
XenPvopsDom0, Fedora 15 Feature
by W. Michael Petullo
I just completed some updates of https://fedoraproject.org/wiki/Features/XenPvopsDom0.
I would like to submit this to the Fedora Feature Wranglers on Wednesday
as a proposed feature for Fedora 15. If you are interested, please review
the document and provide feedback. If you are a previous editor of the
page, I hope you don't mind me trying to move this forward. I will
appreciate any comments.
Thanks,
--
Mike
:wq
13 years, 4 months
Xen and grubby
by W. Michael Petullo
As far as I can tell, Fedora's grubby does not yet support the GRUB
syntax required by Xen, e.g.,
title Fedora (2.6.32.23-170.1.xendom0.fc12.x86_64)
root (hd0,0)
kernel /xen-4.0.1.gz
==> module /vmlinuz-2.6.32.23-170.1.xendom0.fc12.x86_64 ...
==> module /initramfs-2.6.32.23-170.1.xendom0.fc12.x86_64.img
I don't think it supports multiple "module" keywords.
I am presently working on extending grubby to allow something like the
following (note that the --add-kernel parameter name might change):
grubby --add-multiboot=/boot/xen.gz --mbargs="[xen arguments]" \
--add-kernel=/boot/vmlinuz-2.6.32.23-170.1.xendom0.fc12.x86_64 \
--args="[kernel arguments]" \
--add-kernel=/boot/initramfs-2.6.32.23-170.1.xendom0.fc12.x86_64.img \
--title="Xen Hypervisor"
Does this make sense?
How could we tie this into anaconda kernel upgrades? I am thinking of
adding something to /etc/sysconfig/kernel that new-kernel-pkg would
look for. If the flag is present, then new-kernel-pkg could use the
extended grubby syntax. The Fedora Wiki's XenPvopsDom0 document mentions
/etc/sysconfig/xen instead, is this up to date? Should we use this
instead of /etc/sysconfig/kernel?
--
Mike
:wq
13 years, 4 months
Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel
by Boris Derzhavets
Dmesg log is attached :-
[ 42.140012] WARNING: at lib/debugobjects.c:259 debug_print_object+0x5b/0x63()
[ 42.140012] Hardware name: System Product Name
[ 42.140012] ODEBUG: free active (active state 0) object type: percpu_counter
[ 42.140012] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat deflate zlib_deflate ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_generic twofish_x86_64 twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel tunnel6 af_key sunrpc bridge stp llc ipv6 evtchn xenfs uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel r8169 mii snd_hda_codec snd_hwdep shpchp snd_seq snd_seq_device snd_pcm microcode snd_timer iTCO_wdt i2c_i801 asus_atk0110 snd iTCO_vendor_support soundcore snd_page_alloc pata_acpi firewire_ohci firewire_core ata_generic crc_itu_t pata_jmicron radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
scsi_wait_scan]
[ 42.140012] Pid: 53, comm: kworker/u:6 Not tainted 2.6.37-0.1.rc1.git0.xendom0.fc14.x86_64 #1
[ 42.140012] Call Trace:
[ 42.140012] [<ffffffff81051d68>] warn_slowpath_common+0x85/0x9d
[ 42.140012] [<ffffffff81051e23>] warn_slowpath_fmt+0x46/0x48
[ 42.140012] [<ffffffff812573e9>] debug_print_object+0x5b/0x63
[ 42.140012] [<ffffffff81257c1f>] debug_check_no_obj_freed+0x99/0x18a
[ 42.140012] [<ffffffff8107d997>] ? arch_local_save_flags+0xb/0xd
[ 42.140012] [<ffffffff810822b4>] ? debug_check_no_locks_freed+0x11c/0x138
[ 42.140012] [<ffffffff813f76b8>] ? net_free+0x2c/0x31
[ 42.140012] [<ffffffff81123804>] kmem_cache_free+0x6f/0x10b
[ 42.140012] [<ffffffff813f76b8>] net_free+0x2c/0x31
[ 42.140012] [<ffffffff813f7835>] cleanup_net+0x178/0x197
[ 42.140012] [<ffffffff81068d8f>] process_one_work+0x1f4/0x361
[ 42.140012] [<ffffffff81068cfb>] ? process_one_work+0x160/0x361
[ 42.140012] [<ffffffff813f76bd>] ? cleanup_net+0x0/0x197
[ 42.140012] [<ffffffff8106a1a8>] worker_thread+0x104/0x1a4
[ 42.140012] [<ffffffff8106a0a4>] ? worker_thread+0x0/0x1a4
[ 42.140012] [<ffffffff8106dbee>] kthread+0xa0/0xa8
[ 42.140012] [<ffffffff81082165>] ? trace_hardirqs_on_caller+0x10b/0x12f
[ 42.140012] [<ffffffff8100ab64>] kernel_thread_helper+0x4/0x10
[ 42.140012] [<ffffffff814b23d0>] ? restore_args+0x0/0x30
[ 42.140012] [<ffffffff8100ab60>] ? kernel_thread_helper+0x0/0x10
[ 42.140012] ---[ end trace c2d2451e1a620a4f ]---
[ 42.140012] BUG: sleeping function called from invalid context at kernel/mutex.c:278
[ 42.140012] in_atomic(): 0, irqs_disabled(): 1, pid: 53, name: kworker/u:6
[ 42.140012] 2 locks held by kworker/u:6/53:
[ 42.140012] #0: (netns){+.+.+.}, at: [<ffffffff81068cfb>] process_one_work+0x160/0x361
[ 42.140012] #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff81068cfb>] process_one_work+0x160/0x361
[ 42.140012] irq event stamp: 7666
[ 42.140012] hardirqs last enabled at (7665): [<ffffffff81123756>] kfree+0x11f/0x136
[ 42.140012] hardirqs last disabled at (7666): [<ffffffff811237cd>] kmem_cache_free+0x38/0x10b
[ 42.140012] softirqs last enabled at (7620): [<ffffffff8141ea6c>] netlink_release+0x1f3/0x208
[ 42.140012] softirqs last disabled at (7618): [<ffffffff8141ea54>] netlink_release+0x1db/0x208
[ 42.140012] Pid: 53, comm: kworker/u:6 Tainted: G W 2.6.37-0.1.rc1.git0.xendom0.fc14.x86_64 #1
[ 42.140012] Call Trace:
[ 42.140012] [<ffffffff810807a8>] ? print_irqtrace_events+0xa0/0xa4
[ 42.140012] [<ffffffff81043256>] __might_sleep+0x103/0x108
[ 42.140012] [<ffffffff814b0512>] mutex_lock_nested+0x25/0x43
[ 42.140012] [<ffffffff8125ae02>] percpu_counter_destroy+0x3c/0x66
[ 42.140012] [<ffffffff8125ae42>] percpu_counter_fixup_free+0x16/0x32
[ 42.140012] [<ffffffff8125723b>] debug_object_fixup+0x1e/0x2b
[ 42.140012] [<ffffffff81257c54>] debug_check_no_obj_freed+0xce/0x18a
[ 42.140012] [<ffffffff810822b4>] ? debug_check_no_locks_freed+0x11c/0x138
[ 42.140012] [<ffffffff813f76b8>] ? net_free+0x2c/0x31
[ 42.140012] [<ffffffff81123804>] kmem_cache_free+0x6f/0x10b
[ 42.140012] [<ffffffff813f76b8>] net_free+0x2c/0x31
[ 42.140012] [<ffffffff813f7835>] cleanup_net+0x178/0x197
[ 42.140012] [<ffffffff81068d8f>] process_one_work+0x1f4/0x361
[ 42.140012] [<ffffffff81068cfb>] ? process_one_work+0x160/0x361
[ 42.140012] [<ffffffff813f76bd>] ? cleanup_net+0x0/0x197
[ 42.140012] [<ffffffff8106a1a8>] worker_thread+0x104/0x1a4
[ 42.140012] [<ffffffff8106a0a4>] ? worker_thread+0x0/0x1a4
[ 42.140012] [<ffffffff8106dbee>] kthread+0xa0/0xa8
[ 42.140012] [<ffffffff81082165>] ? trace_hardirqs_on_caller+0x10b/0x12f
[ 42.140012] [<ffffffff8100ab64>] kernel_thread_helper+0x4/0x10
[ 42.140012] [<ffffffff814b23d0>] ? restore_args+0x0/0x30
[ 42.140012] [<ffffffff8100ab60>] ? kernel_thread_helper+0x0/0x10
Boris
--- On Fri, 11/5/10, M A Young <m.a.young(a)durham.ac.uk> wrote:
From: M A Young <m.a.young(a)durham.ac.uk>
Subject: [Fedora-xen] 2.6.37-rc1 dom0 kernel
To: xen(a)lists.fedoraproject.org
Date: Friday, November 5, 2010, 7:32 PM
I have built another test kernel (2.6.37-0.1.rc1.git0.xendom0.fc15) to
play with at http://koji.fedoraproject.org/koji/taskinfo?taskID=2581020 .
As with the previous kernel this is entirely based on the upstream kernel
and Fedora kernel patches, and is probably close to what the Fedora 15
kernel will look like soon. I haven't tested it yet.
Michael Young
--
xen mailing list
xen(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen
13 years, 5 months
