Re: [Xen-devel] [PATCH 0 of 1] PV-GRUB fix (actually MiniOS) when PV guest launched with vfb=[..] entry.

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 30 Jun 2010, Konrad Rzeszutek Wilk wrote:
> Hey Keir,
> 
> This patch fixes the conditions when a PV guest is launched using the
> PV-grub and if the 'vfb' entry is in the configuration file.
> 
> The patch has been tested with PV guests. I tried to test it with
> stubdomains but the stubdomains (before the patch and after the patch)
> hangs on:
> 
> [  319.039038] Pid: 4450, comm: qemu-dm Not tainted 2.6.32.15-kms.nv.10 #3 
> X8DTN
> [  319.046191] RIP: e030:[<ffffffff810093aa>]  [<ffffffff810093aa>] 
> hypercall_page+0x3aa/0x100b
> [  319.054641] RSP: e02b:ffff88008a72bb30  EFLAGS: 00000202
> [  319.059991] RAX: 0000000000000000 RBX: ffff88008b79f658 RCX: 
> ffffffff810093aa
> [  319.067147] RDX: ffff88008a72bb64 RSI: 00000000deadbeef RDI: 
> 00000000deadbeef
> [  319.074303] RBP: ffff88008a72bb68 R08: ffff8800b9fa1f00 R09: 
> 0000000000000000
> [  319.081459] R10: 00007fae7e9b2000 R11: 0000000000000202 R12: 
> 0000000000000001
> [  319.088617] R13: 00000000000010fe R14: 0000000000000000 R15: 
> 0000004a523a3b56
> [  319.095776] FS:  00007fae7fe1e700(0000) GS:ffff880004e06000(0000) 
> knlGS:0000000000000000
> [  319.103882] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  319.109656] CR2: 0000000002a53830 CR3: 000000008a774000 CR4: 
> 0000000000002660
> [  319.116815] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
> 0000000000000000
> [  319.123973] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
> 0000000000000400
> [  319.131133] Call Trace:
> [  319.133645]  [<ffffffff812b9d59>] ? xen_poll_irq_timeout+0x47/0x51
> [  319.139844]  [<ffffffff812b9d73>] xen_poll_irq+0x10/0x12
> [  319.145196]  [<ffffffff810100c4>] xen_spin_lock_slow+0xe5/0x193
> [  319.151142]  [<ffffffff8101020b>] __xen_spin_lock+0x99/0xcd
> [  319.156751]  [<ffffffff8101025c>] xen_spin_lock+0xb/0xd
> [  319.162017]  [<ffffffff81481152>] _spin_lock+0xe/0x12
> [  319.167105]  [<ffffffff812c2034>] mn_invl_range_start+0x30/0x118
> [  319.173140]  [<ffffffff811075a3>] 
> __mmu_notifier_invalidate_range_start+0x33/0x59
> [  319.180640]  [<ffffffff810ef041>] apply_to_page_range+0x4f/0x338
> [  319.186674]  [<ffffffff812c21cb>] ? find_grant_ptes+0x0/0x12e
> [  319.192451]  [<ffffffff81010229>] ? __xen_spin_lock+0xb7/0xcd
> [  319.198229]  [<ffffffff812c1f4a>] gntdev_mmap+0x130/0x1ea
> [  319.203669]  [<ffffffff810f5f91>] mmap_region+0x2a6/0x49f
> [  319.209106]  [<ffffffff811eebbc>] ? file_map_prot_check+0x9b/0xa7
> [  319.215225]  [<ffffffff810f641a>] do_mmap_pgoff+0x290/0x2f6
> [  319.220835]  [<ffffffff810e9e55>] sys_mmap_pgoff+0xf6/0x1b4
> [  319.226444]  [<ffffffff81016fdc>] sys_mmap+0x22/0x24
> [  319.231443]  [<ffffffff81012cb2>] system_call_fastpath+0x16/0x1b
> 
> Haven't tracked that one down :-(
> 
> Thought looking at the output of the stubdomain launch, it only
> initializes the blkfront, console, and netfront.
> 
> This patch touches the pcifront, fbfront and kbdfront so the patch
> should not impact the stubdomain functionality.

The patch is OK but I would rather fix the qemu backend properly than
modify all the possible frontends.

Regarding qemu stubdoms, this is a known problem:

http://old.nabble.com/-PATCH-1-of-1--stubdom-hanging-at-creation-td29013845.html



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel