[BUG] Xen vm kernel crash in get_free_entries.

[BUG] Xen vm kernel crash in get_free_entries.

[Astarta]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

Hello,

This is a some kind of a follow up to the 
http://lists.xen.org/archives/html/xen-devel/2013-09/msg03109.html (
Linux 3.11.1 HVM guest kernel crash when started with xl 
(get_free_entries)).

Looks like we've here the similar issue.

Xen VM with 3.8.13 kernel crashes in get_free_entries (kernel BUG at 
drivers/xen/grant-table.c:1181!), i.e in:
BUG_ON(grefs_per_grant_frame == 0);. 3.11.5 kernel behaves in exactly 
the same way.

Whole kernel log is attached. It does not contain  any "Grant tables 
using version" message.

Seems that gnttab_request_version() has was never executed, so 
grefs_per_grant_frame was never set.

Could you please advice on this issue?
I'm ready to provide any further information if required.

I'm not subscribed, so please add me to CC, so that I can see replies.


--
Marina

[-- Attachment #2: xen.log --]
[-- Type: text/x-log, Size: 13545 bytes --]

[root@xenserver62 ~]# xl console 117
Linux version 3.8.13-x86_64 (astarta@domain) (gcc version 4.4.3 ) #1 SMP Fri Oct 4 15:23:59 MSD 2013
Command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000003fbfffff] usable
BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
NX (Execute Disable) protection: active
SMBIOS 2.4 present.                                                                                                           
Hypervisor detected: Xen HVM                                                                                                  
Xen version 4.1.                                                                                                              
Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.                            
Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.                           
You might have to change the root device                                                                                      
from /dev/hd[a-d] to /dev/xvd[a-d]                                                                                            
in your root= kernel command line option
No AGP bridge found
e820: last_pfn = 0x3fc00 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [mem 0x000fb710-0x000fb71f] mapped at [ffff8800000fb710]
init_memory_mapping: [mem 0x00000000-0x3fbfffff]
RAMDISK: [mem 0x3c6d0000-0x3fbdffff]
ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
ACPI: XSDT 00000000fc00ef80 00044 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: FACP 00000000fc00ed40 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
ACPI: DSDT 00000000fc003040 0BC75 (v02    Xen      HVM 00000000 INTL 20090123)
ACPI: FACS 00000000fc003000 00040
ACPI: APIC 00000000fc00ee40 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
ACPI: HPET 00000000fc00ef20 00038 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: WAET 00000000fc00ef58 00028 (v01    Xen      HVM 00000000 HVML 00000000)
No NUMA configuration found
Faking a node at [mem 0x0000000000000000-0x000000003fbfffff]
Initmem setup node 0 [mem 0x00000000-0x3fbfffff]
  NODE_DATA [mem 0x3fbec000-0x3fbfffff]
Zone ranges:
  DMA      [mem 0x00010000-0x00ffffff]
  DMA32    [mem 0x01000000-0xffffffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00010000-0x0009dfff]
  node   0: [mem 0x00100000-0x3fbfffff]
ACPI: PM-Timer IO Port: 0x1f48
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
smpboot: Allowing 15 CPUs, 14 hotplug CPUs
e820: [mem 0x3fc00000-0xfbffffff] available for PCI devices
Booting paravirtualized kernel on Xen HVM
setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:15 nr_node_ids:1
PERCPU: Embedded 27 pages/cpu @ffff88003c400000 s78656 r8192 d23744 u131072
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256920
Policy zone: DMA32
Kernel command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
PID hash table entries: 4096 (order: 3, 32768 bytes)
__ex_table already sorted, skipping sort
Checking aperture...
No AGP bridge found
Memory: 963504k/1044480k available (3992k kernel code, 456k absent, 80520k reserved, 2581k data, 768k init)
SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1
Hierarchical RCU implementation.
        RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=15.
NR_IRQS:8448 nr_irqs:1208 16
Xen HVM callback vector for event delivery is enabled
Console: colour dummy device 80x25
console [tty0] enabled
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
console [ttyS0] enabled
tsc: Detected 1864.851 MHz processor
Calibrating delay loop (skipped), value calculated using timer frequency.. 3729.70 BogoMIPS (lpj=1864851)
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 256
mce: CPU supports 0 MCE banks
Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32
tlb_flushall_shift: -1
ACPI: Core revision 20121018
Switched APIC routing to physical flat.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
smpboot: CPU0: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz (fam: 06, model: 0f, stepping: 02)
installing Xen timer for CPU 0
Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only.
Brought up 1 CPUs
smpboot: Total of 1 processors activated (3729.70 BogoMIPS)
devtmpfs: initialized
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: No dock devices found.
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci_root PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
pci 0000:00:01.3: quirk: [io  0x1f40-0x1f7f] claimed by PIIX4 ACPI
 pci0000:00: ACPI _OSC support notification failed, disabling PCIe ASPM
 pci0000:00: Unable to request _OSC control (_OSC support mask: 0x08)
ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
xen/balloon: Initialising balloon driver.
xen-balloon: Initialising balloon driver.
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:02.0
PCI: Using ACPI for IRQ routing
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Switching to clocksource xen
pnp: PnP ACPI init
ACPI: bus type pnp registered
system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:01: [io  0x10c0-0x1141] has been reserved
system 00:01: [io  0xb044-0xb047] has been reserved
system 00:03: [io  0x08a0-0x08a3] has been reserved
system 00:03: [io  0x0cc0-0x0ccf] has been reserved
system 00:03: [io  0x04d0-0x04d1] has been reserved
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
Loading, please wait...
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:01.0: PIIX3: Enabling Passive Release
pci 0000:00:01.0: Activating ISA DMA hang workarounds
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 54336k freed
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 1987
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: framebuffer at 0xf0000000, mapped to 0xffffc90000200000, using 1875k, total 4096k
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
GHES: HEST is not enabled!
Event-channel device installed.
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
------------[ cut here ]------------
kernel BUG at drivers/xen/grant-table.c:1181!
invalid opcode: 0000 [#1] SMP 
Modules linked in:
CPU 0 
Pid: 1, comm: swapper/0 Not tainted 3.8.13-x86_64 #1 Xen HVM domU
RIP: 0010:[<ffffffff81251200>]  [<ffffffff81251200>] get_free_entries+0x2e0/0x300
RSP: 0000:ffff88003c205bd8  EFLAGS: 00010046
RAX: 0000000000000296 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000000003f5ea RDI: ffffffff817c0150
RBP: ffff88003c205c38 R08: 0000000000000000 R09: ffff88003f608060
R10: ffff88003fbec6c0 R11: 0000000000000008 R12: 0000000000000296
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff81643298
FS:  0000000000000000(0000) GS:ffff88003c400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000000160c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 1, threadinfo ffff88003c204000, task ffff88003c208000)
Stack:
 ffff88003fbec6c0 0000000000000002 000000103c205c88 0000000000000000
 ffff88003fbec000 0000000000000000 ffff88003c017440 ffff88003f608000
 000000000003f5ea 0000000000000000 0000000000000000 ffffffff81643298
Call Trace:
 [<ffffffff812512ce>] gnttab_grant_foreign_access+0x2e/0x70
 [<ffffffff812555ef>] xenbus_grant_ring+0x1f/0x50
 [<ffffffff812bf7ca>] talk_to_blkback+0xaa/0x350
 [<ffffffff812c1db6>] blkfront_probe+0x186/0x2b0
 [<ffffffff81258127>] xenbus_dev_probe+0x77/0x130
 [<ffffffff812afb13>] driver_probe_device+0x93/0x250
 [<ffffffff812afd63>] __driver_attach+0x93/0xa0
 [<ffffffff812afcd0>] ? driver_probe_device+0x250/0x250
 [<ffffffff812ae133>] bus_for_each_dev+0x83/0xa0
 [<ffffffff812af939>] driver_attach+0x19/0x20
 [<ffffffff812aead0>] bus_add_driver+0x1c0/0x250
 [<ffffffff816afac8>] ? brd_init+0x1d2/0x1d2
 [<ffffffff812b03b8>] driver_register+0x78/0x160
 [<ffffffff816afac8>] ? brd_init+0x1d2/0x1d2
 [<ffffffff81257f95>] xenbus_register_driver_common+0x15/0x20
 [<ffffffff8125a053>] xenbus_register_frontend+0x23/0x40
 [<ffffffff816afac8>] ? brd_init+0x1d2/0x1d2
 [<ffffffff816afb2a>] xlblk_init+0x62/0x86
 [<ffffffff816af8f6>] ? ramdisk_size+0x1a/0x1a
 [<ffffffff8100203d>] do_one_initcall+0x3d/0x170
 [<ffffffff816816df>] kernel_init_freeable+0x108/0x192
 [<ffffffff81681769>] ? kernel_init_freeable+0x192/0x192
 [<ffffffff813ceaa0>] ? rest_init+0x80/0x80
 [<ffffffff813ceaa9>] kernel_init+0x9/0xf0
 [<ffffffff813e1f3c>] ret_from_fork+0x7c/0xb0
 [<ffffffff813ceaa0>] ? rest_init+0x80/0x80
Code: 48 89 10 48 89 05 b1 ef 56 00 4d 85 f6 0f 84 cf fd ff ff 44 8b 2d 79 ef 56 00 4c 89 f0 eb ce 4c 8b 3d 5d ef 56 00 e9 2e ff ff ff <0f> 0b eb fe 0f 0b eb fe 48 c7 00 00 00 00 00 48 8b 78 10 ff 50 
RIP  [<ffffffff81251200>] get_free_entries+0x2e0/0x300
 RSP <ffff88003c205bd8>
---[ end trace aeae77e70a304f5f ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b




[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[David Vrabel]

On 16/10/13 07:28, Astarta wrote:
> Hello,
> 
> This is a some kind of a follow up to the
> http://lists.xen.org/archives/html/xen-devel/2013-09/msg03109.html (
> Linux 3.11.1 HVM guest kernel crash when started with xl
> (get_free_entries)).
> 
> Looks like we've here the similar issue.
> 
> Xen VM with 3.8.13 kernel crashes in get_free_entries (kernel BUG at
> drivers/xen/grant-table.c:1181!), i.e in:
> BUG_ON(grefs_per_grant_frame == 0);. 3.11.5 kernel behaves in exactly
> the same way.
> 
> Whole kernel log is attached. It does not contain  any "Grant tables
> using version" message.
> 
> Seems that gnttab_request_version() has was never executed, so
> grefs_per_grant_frame was never set.
> 
> Could you please advice on this issue?

I think you're missing the platform pci device required for PVHVM.
What's your VM's xl.cfg?

David

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Pasi Kärkkäinen]

On Wed, Oct 16, 2013 at 02:29:07PM +0100, David Vrabel wrote:
> On 16/10/13 07:28, Astarta wrote:
> > Hello,
> > 
> > This is a some kind of a follow up to the
> > http://lists.xen.org/archives/html/xen-devel/2013-09/msg03109.html (
> > Linux 3.11.1 HVM guest kernel crash when started with xl
> > (get_free_entries)).
> > 
> > Looks like we've here the similar issue.
> > 
> > Xen VM with 3.8.13 kernel crashes in get_free_entries (kernel BUG at
> > drivers/xen/grant-table.c:1181!), i.e in:
> > BUG_ON(grefs_per_grant_frame == 0);. 3.11.5 kernel behaves in exactly
> > the same way.
> > 
> > Whole kernel log is attached. It does not contain  any "Grant tables
> > using version" message.
> > 
> > Seems that gnttab_request_version() has was never executed, so
> > grefs_per_grant_frame was never set.
> > 
> > Could you please advice on this issue?
> 
> I think you're missing the platform pci device required for PVHVM.
> What's your VM's xl.cfg?
> 

Yes, exactly, I had "xen_platform_pci=0" in my VM's xl.cfg,
and I assume Astarta has aswell.

That is because I wanted to test *without* PVHVM, and that is a valid configuration imho..
(and works OK with xm/xend).

-- Pasi

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Astarta]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

On 10/16/2013 06:17 PM, Pasi Kärkkäinen wrote:
> On Wed, Oct 16, 2013 at 02:29:07PM +0100, David Vrabel wrote:
>> On 16/10/13 07:28, Astarta wrote:
>>> Hello,
>>>
>>> This is a some kind of a follow up to the
>>> http://lists.xen.org/archives/html/xen-devel/2013-09/msg03109.html (
>>> Linux 3.11.1 HVM guest kernel crash when started with xl
>>> (get_free_entries)).
>>>
>>> Looks like we've here the similar issue.
>>>
>>> Xen VM with 3.8.13 kernel crashes in get_free_entries (kernel BUG at
>>> drivers/xen/grant-table.c:1181!), i.e in:
>>> BUG_ON(grefs_per_grant_frame == 0);. 3.11.5 kernel behaves in exactly
>>> the same way.
>>>
>>> Whole kernel log is attached. It does not contain  any "Grant tables
>>> using version" message.
>>>
>>> Seems that gnttab_request_version() has was never executed, so
>>> grefs_per_grant_frame was never set.
>>>
>>> Could you please advice on this issue?
>> I think you're missing the platform pci device required for PVHVM.
>> What's your VM's xl.cfg?
>>
> Yes, exactly, I had "xen_platform_pci=0" in my VM's xl.cfg,
> and I assume Astarta has aswell.
>
> That is because I wanted to test *without* PVHVM, and that is a valid configuration imho..
> (and works OK with xm/xend).
>
> -- Pasi

Thanks for the suggestion, but there is no xl.cfg in /etc/xen/ (we're 
using Citrix XenServer Host 6.2.0-70446c
  on rhel 6.2), so there is no where to edit xen_platform_pci option.

I've attached output from xe vm-list params=all for one of the problem 
vm. Hope its also ok.

Also 3.6 kernel works well with that configuration. I can provide it's 
boot log if needed.

Please suggest.

--
Marina

[-- Attachment #2: vm.txt --]
[-- Type: text/plain, Size: 4467 bytes --]

uuid ( RO)                          : 64c9830e-6397-0bb0-81ea-de8cad8794a3
                    name-label ( RW): Windows Server 2012 (64-bit)
              name-description ( RW): 
                  user-version ( RW): 1
                 is-a-template ( RW): false
                 is-a-snapshot ( RO): false
                   snapshot-of ( RO): <not in database>
                     snapshots ( RO): 
                 snapshot-time ( RO): 19700101T00:00:00Z
                 snapshot-info ( RO): 
                        parent ( RO): <not in database>
                      children ( RO): 
             is-control-domain ( RO): false
                   power-state ( RO): halted
                 memory-actual ( RO): 1073709056
                 memory-target ( RO): <expensive field>
               memory-overhead ( RO): 11534336
             memory-static-max ( RW): 1073741824
            memory-dynamic-max ( RW): 1073741824
            memory-dynamic-min ( RW): 1073741824
             memory-static-min ( RW): 1073741824
              suspend-VDI-uuid ( RW): <not in database>
               suspend-SR-uuid ( RW): 1b40f2b4-3284-8dbf-a0fd-c93390c7c046
                  VCPUs-params (MRW): 
                     VCPUs-max ( RW): 1
              VCPUs-at-startup ( RW): 1
        actions-after-shutdown ( RW): Destroy
          actions-after-reboot ( RW): Restart
           actions-after-crash ( RW): Restart
                 console-uuids (SRO): 
                      platform (MRW): timeoffset: -25200; nx: true; acpi: 1; apic: true; pae: true; vga: std; videoram: 8; viridian: true; device_id: 0002
            allowed-operations (SRO): changing_dynamic_range; changing_shadow_memory; changing_static_range; make_into_template; destroy; export; start_on; start; clone; copy; snapshot
            current-operations (SRO): 
            blocked-operations (MRW): 
           allowed-VBD-devices (SRO): <expensive field>
           allowed-VIF-devices (SRO): <expensive field>
                possible-hosts ( RO): <expensive field>
               HVM-boot-policy ( RW): BIOS order
               HVM-boot-params (MRW): order: dc
         HVM-shadow-multiplier ( RW): 1.000
                     PV-kernel ( RW): 
                    PV-ramdisk ( RW): 
                       PV-args ( RW): 
                PV-legacy-args ( RW): 
                 PV-bootloader ( RW): 
            PV-bootloader-args ( RW): 
           last-boot-CPU-flags ( RO): vendor: GenuineIntel; features: 0000e3bd-bfebfbff-00000001-20100800
              last-boot-record ( RO): <expensive field>
                   resident-on ( RO): <not in database>
                      affinity ( RW): 5067bedc-cc4f-4631-9270-4ab9208acad6
                  other-config (MRW): vgpu_pci: ; base_template_name: Windows Server 2012 (64-bit); mac_seed: e17b7cd1-3a70-9b84-5c56-83f3e17c10ed; install-methods: cdrom
                        dom-id ( RO): -1
               recommendations ( RO): <restrictions><restriction field="memory-static-max" max="137438953472" /><restriction field="vcpus-max" max="16" /><restriction property="number-of-vbds" max="7" /><restriction property="number-of-vifs" max="7" /></restrictions>
                 xenstore-data (MRW): vm-data: 
    ha-always-run ( RW) [DEPRECATED]: false
           ha-restart-priority ( RW): 
                         blobs ( RO): 
                    start-time ( RO): 19700101T00:00:00Z
                  install-time ( RO): 20131009T13:30:57Z
                  VCPUs-number ( RO): 0
             VCPUs-utilisation (MRO): <expensive field>
                    os-version (MRO): <not in database>
            PV-drivers-version (MRO): <not in database>
         PV-drivers-up-to-date ( RO): <not in database>
                        memory (MRO): <not in database>
                         disks (MRO): <not in database>
                      networks (MRO): <not in database>
                         other (MRO): <not in database>
                          live ( RO): <not in database>
    guest-metrics-last-updated ( RO): <not in database>
      cooperative ( RO) [DEPRECATED]: <expensive field>
                          tags (SRW): 
                     appliance ( RW): <not in database>
                   start-delay ( RW): 0
                shutdown-delay ( RW): 0
                         order ( RW): 0
                       version ( RO): 0
                 generation-id ( RO): 836232628191772189:5239282750367167867



[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Astarta]

On 10/17/2013 12:55 PM, Astarta wrote:
> On 10/16/2013 06:17 PM, Pasi Kärkkäinen wrote:
>> On Wed, Oct 16, 2013 at 02:29:07PM +0100, David Vrabel wrote:
>>> On 16/10/13 07:28, Astarta wrote:
>>>> Hello,
>>>>
>>>> This is a some kind of a follow up to the
>>>> http://lists.xen.org/archives/html/xen-devel/2013-09/msg03109.html (
>>>> Linux 3.11.1 HVM guest kernel crash when started with xl
>>>> (get_free_entries)).
>>>>
>>>> Looks like we've here the similar issue.
>>>>
>>>> Xen VM with 3.8.13 kernel crashes in get_free_entries (kernel BUG at
>>>> drivers/xen/grant-table.c:1181!), i.e in:
>>>> BUG_ON(grefs_per_grant_frame == 0);. 3.11.5 kernel behaves in exactly
>>>> the same way.
>>>>
>>>> Whole kernel log is attached. It does not contain  any "Grant tables
>>>> using version" message.
>>>>
>>>> Seems that gnttab_request_version() has was never executed, so
>>>> grefs_per_grant_frame was never set.
>>>>
>>>> Could you please advice on this issue?
>>> I think you're missing the platform pci device required for PVHVM.
>>> What's your VM's xl.cfg?
>>>
>> Yes, exactly, I had "xen_platform_pci=0" in my VM's xl.cfg,
>> and I assume Astarta has aswell.
>>
>> That is because I wanted to test *without* PVHVM, and that is a valid 
>> configuration imho..
>> (and works OK with xm/xend).
>>
>> -- Pasi
>
> Thanks for the suggestion, but there is no xl.cfg in /etc/xen/ (we're 
> using Citrix XenServer Host 6.2.0-70446c
>  on rhel 6.2), so there is no where to edit xen_platform_pci option.
>
> I've attached output from xe vm-list params=all for one of the problem 
> vm. Hope its also ok.
>
> Also 3.6 kernel works well with that configuration. I can provide it's 
> boot log if needed.
>
> Please suggest.
>
> -- 
> Marina


will answer by myself. Setting platform:device_id to 1 manually helps 
the 3.11.5 kernel to boot.
I used xe command for this in the below way.
xe vm-param-set uuid=<VM UUID> platform:device_id=0001

The issue that platform:device_id is 0002 for citrix xen by default and 
the latest kernel doesnt boot in this configuration...

Where do we go from there?

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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Pasi Kärkkäinen]

On Thu, Oct 17, 2013 at 11:04:29PM +0400, Astarta wrote:
> On 10/17/2013 12:55 PM, Astarta wrote:
> >On 10/16/2013 06:17 PM, Pasi Kärkkäinen wrote:
> >>On Wed, Oct 16, 2013 at 02:29:07PM +0100, David Vrabel wrote:
> >>>On 16/10/13 07:28, Astarta wrote:
> >>>>Hello,
> >>>>
> >>>>This is a some kind of a follow up to the
> >>>>http://lists.xen.org/archives/html/xen-devel/2013-09/msg03109.html (
> >>>>Linux 3.11.1 HVM guest kernel crash when started with xl
> >>>>(get_free_entries)).
> >>>>
> >>>>Looks like we've here the similar issue.
> >>>>
> >>>>Xen VM with 3.8.13 kernel crashes in get_free_entries (kernel BUG at
> >>>>drivers/xen/grant-table.c:1181!), i.e in:
> >>>>BUG_ON(grefs_per_grant_frame == 0);. 3.11.5 kernel behaves in exactly
> >>>>the same way.
> >>>>
> >>>>Whole kernel log is attached. It does not contain  any "Grant tables
> >>>>using version" message.
> >>>>
> >>>>Seems that gnttab_request_version() has was never executed, so
> >>>>grefs_per_grant_frame was never set.
> >>>>
> >>>>Could you please advice on this issue?
> >>>I think you're missing the platform pci device required for PVHVM.
> >>>What's your VM's xl.cfg?
> >>>
> >>Yes, exactly, I had "xen_platform_pci=0" in my VM's xl.cfg,
> >>and I assume Astarta has aswell.
> >>
> >>That is because I wanted to test *without* PVHVM, and that is a
> >>valid configuration imho..
> >>(and works OK with xm/xend).
> >>
> >>-- Pasi
> >
> >Thanks for the suggestion, but there is no xl.cfg in /etc/xen/
> >(we're using Citrix XenServer Host 6.2.0-70446c
> > on rhel 6.2), so there is no where to edit xen_platform_pci option.
> >
> >I've attached output from xe vm-list params=all for one of the
> >problem vm. Hope its also ok.
> >
> >Also 3.6 kernel works well with that configuration. I can provide
> >it's boot log if needed.
> >
> >Please suggest.
> >
> >-- 
> >Marina
> 
> 
> will answer by myself. Setting platform:device_id to 1 manually
> helps the 3.11.5 kernel to boot.
> I used xe command for this in the below way.
> xe vm-param-set uuid=<VM UUID> platform:device_id=0001
> 
> The issue that platform:device_id is 0002 for citrix xen by default
> and the latest kernel doesnt boot in this configuration...
> 
> Where do we go from there?
>

Well, it's a Linux kernel bug, I assume, so it should be fixed.
More debugging is needed.

There is, and shouldn't be, a requirement to have Xen platform PCI device available..
That's how you enable/disable PVHVM, after all. 

-- Pasi

Re: [BUG] Xen vm kernel crash in get_free_entries.

[David Vrabel]

On 17/10/13 20:28, Pasi Kärkkäinen wrote:
> On Thu, Oct 17, 2013 at 11:04:29PM +0400, Astarta wrote:
>> On 10/17/2013 12:55 PM, Astarta wrote:
>>> On 10/16/2013 06:17 PM, Pasi Kärkkäinen wrote:
>>>> On Wed, Oct 16, 2013 at 02:29:07PM +0100, David Vrabel wrote:
>>>>> On 16/10/13 07:28, Astarta wrote:
>>>>>> Hello,
>>>>>>
>>>>>> This is a some kind of a follow up to the
>>>>>> http://lists.xen.org/archives/html/xen-devel/2013-09/msg03109.html (
>>>>>> Linux 3.11.1 HVM guest kernel crash when started with xl
>>>>>> (get_free_entries)).
>>>>>>
>>>>>> Looks like we've here the similar issue.
>>>>>>
>>>>>> Xen VM with 3.8.13 kernel crashes in get_free_entries (kernel BUG at
>>>>>> drivers/xen/grant-table.c:1181!), i.e in:
>>>>>> BUG_ON(grefs_per_grant_frame == 0);. 3.11.5 kernel behaves in exactly
>>>>>> the same way.
>>>>>>
>>>>>> Whole kernel log is attached. It does not contain  any "Grant tables
>>>>>> using version" message.
>>>>>>
>>>>>> Seems that gnttab_request_version() has was never executed, so
>>>>>> grefs_per_grant_frame was never set.
>>>>>>
>>>>>> Could you please advice on this issue?
>>>>> I think you're missing the platform pci device required for PVHVM.
>>>>> What's your VM's xl.cfg?
>>>>>
>>>> Yes, exactly, I had "xen_platform_pci=0" in my VM's xl.cfg,
>>>> and I assume Astarta has aswell.
>>>>
>>>> That is because I wanted to test *without* PVHVM, and that is a
>>>> valid configuration imho..
>>>> (and works OK with xm/xend).
>>>>
>>>> -- Pasi
>>>
>>> Thanks for the suggestion, but there is no xl.cfg in /etc/xen/
>>> (we're using Citrix XenServer Host 6.2.0-70446c
>>> on rhel 6.2), so there is no where to edit xen_platform_pci option.
>>>
>>> I've attached output from xe vm-list params=all for one of the
>>> problem vm. Hope its also ok.
>>>
>>> Also 3.6 kernel works well with that configuration. I can provide
>>> it's boot log if needed.
>>>
>>> Please suggest.
>>>
>>> -- 
>>> Marina
>>
>>
>> will answer by myself. Setting platform:device_id to 1 manually
>> helps the 3.11.5 kernel to boot.
>> I used xe command for this in the below way.
>> xe vm-param-set uuid=<VM UUID> platform:device_id=0001
>>
>> The issue that platform:device_id is 0002 for citrix xen by default
>> and the latest kernel doesnt boot in this configuration...
>>
>> Where do we go from there?
>>
> 
> Well, it's a Linux kernel bug, I assume, so it should be fixed.
> More debugging is needed.
> 
> There is, and shouldn't be, a requirement to have Xen platform PCI device available..
> That's how you enable/disable PVHVM, after all.

I suspect some of the changes for ARM has caused this (because ARM is
sort of PVHVM without a platform PCI device) but I had a quick look and
couldn't spot anything.  Stefano, any ideas?

David

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:

> I suspect some of the changes for ARM has caused this (because ARM is
> sort of PVHVM without a platform PCI device) but I had a quick look and
> couldn't spot anything.  Stefano, any ideas?

If there is no platform device then we should never be going anywhere
near any of the grant table code...

>From the log in the original post it looks like at least some parts of
the kernel think it is running PVHVM (i.e. it does the unplug and says
"Booting paravirtualized kernel on Xen HVM"). I don't think this should
not be the case if there is no platform pci device.

Could this be because XenServer uses this platform_device=2 thing, which
is enough to trigger some of the early setup (because the unplug
protocol is present on I/O ports 0x10) but then the PCI driver in Linux
doesn't know about this ID and so never initialises the rest of it?

Astarta, which of these configurations have you tried:

 - No platform device at all
 - Platform device with ID == 1
 - Platform device with ID == 2

and what happened with each?

Ian.

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Astarta]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

On 10/18/2013 01:46 PM, Ian Campbell wrote:
> On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:
>
>> I suspect some of the changes for ARM has caused this (because ARM is
>> sort of PVHVM without a platform PCI device) but I had a quick look and
>> couldn't spot anything.  Stefano, any ideas?
> If there is no platform device then we should never be going anywhere
> near any of the grant table code...
>
>  From the log in the original post it looks like at least some parts of
> the kernel think it is running PVHVM (i.e. it does the unplug and says
> "Booting paravirtualized kernel on Xen HVM"). I don't think this should
> not be the case if there is no platform pci device.
>
> Could this be because XenServer uses this platform_device=2 thing, which
> is enough to trigger some of the early setup (because the unplug
> protocol is present on I/O ports 0x10) but then the PCI driver in Linux
> doesn't know about this ID and so never initialises the rest of it?
>
> Astarta, which of these configurations have you tried:
>
>   - No platform device at all
>   - Platform device with ID == 1
>   - Platform device with ID == 2
>
> and what happened with each?
>
> Ian.
>

Hello Ian,

3.11.5 kernel boots OK if platform:device_id=0001 (see attached 
vm_boot_log_id1.txt and VM config vm_cfg_id1.txt)
3.11.5 kernel crashes if platform:device_id=0002 (see 
vm_boot_log_id2.txt mv_cfg_id2.txt).

Sorry, but I really dont know and cannot find in google how to test w/o 
platform:device_id at all. My system doesnt have xl.cfg in /etc/xen/ and 
I use xe utility to change parameters.
I've tried not to specify platform:device_id leaving it empty (i.e. xe 
vm-param-set uuid=<VM UUID> platform:device_id= ). Kernel crashes. see 
vm_boot_log_id_empty.txt and vm_cfg_id_empty.txt ).


Let me know if there's anything else I can do to shed some light to the 
problem.

--
Marina



[-- Attachment #2: vm_boot_log_id1.txt --]
[-- Type: text/plain, Size: 25631 bytes --]

[root@xenserver62 ~]# xl console 187
Linux version 3.11.5-x86_64 (astarta@domain) (gcc version 4.8.1 ) #1 SMP Fri Oct 18 02:27:44 MSD 2013
Command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000003fbfffff] usable
BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
Hypervisor detected: Xen HVM
Xen version 4.1.
Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
You might have to change the root device
from /dev/hd[a-d] to /dev/xvd[a-d]
in your root= kernel command line option
No AGP bridge found
e820: last_pfn = 0x3fc00 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [mem 0x000fb710-0x000fb71f] mapped at [ffff8800000fb710]
init_memory_mapping: [mem 0x00000000-0x000fffff]
init_memory_mapping: [mem 0x3c600000-0x3c7fffff]
init_memory_mapping: [mem 0x3c000000-0x3c5fffff]
init_memory_mapping: [mem 0x00100000-0x3bffffff]
init_memory_mapping: [mem 0x3c800000-0x3fbfffff]
RAMDISK: [mem 0x3c822000-0x3fbdffff]
ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
ACPI: XSDT 00000000fc00ef80 00044 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: FACP 00000000fc00ed40 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
ACPI: DSDT 00000000fc003040 0BC75 (v02    Xen      HVM 00000000 INTL 20090123)
ACPI: FACS 00000000fc003000 00040
ACPI: APIC 00000000fc00ee40 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
ACPI: HPET 00000000fc00ef20 00038 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: WAET 00000000fc00ef58 00028 (v01    Xen      HVM 00000000 HVML 00000000)
No NUMA configuration found
Faking a node at [mem 0x0000000000000000-0x000000003fbfffff]
Initmem setup node 0 [mem 0x00000000-0x3fbfffff]
  NODE_DATA [mem 0x3fbec000-0x3fbfffff]
Zone ranges:
  DMA      [mem 0x00001000-0x00ffffff]
  DMA32    [mem 0x01000000-0xffffffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00001000-0x0009dfff]
  node   0: [mem 0x00100000-0x3fbfffff]
ACPI: PM-Timer IO Port: 0x1f48
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
smpboot: Allowing 15 CPUs, 14 hotplug CPUs
e820: [mem 0x3fc00000-0xfbffffff] available for PCI devices
Booting paravirtualized kernel on Xen HVM
setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:15 nr_node_ids:1
PERCPU: Embedded 27 pages/cpu @ffff88003c600000 s80384 r8192 d22016 u131072
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256920
Policy zone: DMA32
Kernel command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
PID hash table entries: 4096 (order: 3, 32768 bytes)
Checking aperture...
No AGP bridge found
Memory: 964488K/1044084K available (4014K kernel code, 457K rwdata, 1260K rodata, 1032K init, 676K bss, 79596K reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1
Hierarchical RCU implementation.
        RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=15.
NR_IRQS:8448 nr_irqs:1208 16
xen:events: Xen HVM callback vector for event delivery is enabled
Console: colour dummy device 80x25
console [tty0] enabled
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
console [ttyS0] enabled
tsc: Detected 1864.851 MHz processor
Calibrating delay loop (skipped), value calculated using timer frequency.. 3729.70 BogoMIPS (lpj=1864851)
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 256
mce: CPU supports 0 MCE banks
Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32
tlb_flushall_shift: -1
ACPI: Core revision 20130517
ACPI: All ACPI Tables successfully acquired
Switched APIC routing to physical flat.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
smpboot: CPU0: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz (fam: 06, model: 0f, stepping: 02)
installing Xen timer for CPU 0
Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only.
Brought up 1 CPUs
smpboot: Total of 1 processors activated (3729.70 BogoMIPS)
devtmpfs: initialized
NET: Registered protocol family 16
ACPI: bus type PCI registered
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM
acpi PNP0A03:00: Unable to request _OSC control (_OSC support mask: 0x08)
acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
acpiphp: Slot [0] registered
acpiphp: Slot [1] registered
acpiphp: Slot [2] registered
acpiphp: Slot [3] registered
acpiphp: Slot [4] registered
acpiphp: Slot [5] registered
acpiphp: Slot [6] registered
acpiphp: Slot [7] registered
acpiphp: Slot [8] registered
acpiphp: Slot [9] registered
acpiphp: Slot [10] registered
acpiphp: Slot [11] registered
acpiphp: Slot [12] registered
acpiphp: Slot [13] registered
acpiphp: Slot [14] registered
acpiphp: Slot [15] registered
acpiphp: Slot [16] registered
acpiphp: Slot [17] registered
acpiphp: Slot [18] registered
acpiphp: Slot [19] registered
acpiphp: Slot [20] registered
acpiphp: Slot [21] registered
acpiphp: Slot [22] registered
acpiphp: Slot [23] registered
acpiphp: Slot [24] registered
acpiphp: Slot [25] registered
acpiphp: Slot [26] registered
acpiphp: Slot [27] registered
acpiphp: Slot [28] registered
acpiphp: Slot [29] registered
acpiphp: Slot [30] registered
acpiphp: Slot [31] registered
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
pci 0000:00:01.3: quirk: [io  0x1f40-0x1f7f] claimed by PIIX4 ACPI
ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
ACPI: Enabled 2 GPEs in block 00 to 1F
xen:balloon: Initialising balloon driver
xen_balloon: Initialising balloon driver
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:02.0
PCI: Using ACPI for IRQ routing
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Switched to clocksource xen
pnp: PnP ACPI init
ACPI: bus type PNP registered
system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:01: [io  0x10c0-0x1141] has been reserved
system 00:01: [io  0xb044-0xb047] has been reserved
system 00:03: [io  0x08a0-0x08a3] has been reserved
system 00:03: [io  0x0cc0-0x0ccf] has been reserved
system 00:03: [io  0x04d0-0x04d1] has been reserved
pnp: PnP ACPI: found 12 devices
ACPI: bus type PNP unregistered
Loading, please wait...
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:01.0: PIIX3: Enabling Passive Release
pci 0000:00:01.0: Activating ISA DMA hang workarounds
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 52984K (ffff88003c822000 - ffff88003fbe0000)
bounce pool size: 64 pages
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 1987
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: framebuffer at 0xf0000000, mapped to 0xffffc90000200000, using 1875k, total 4096k
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
GHES: HEST is not enabled!
xen:xen_evtchn: Event-channel device installed
xen:grant_table: Grant tables using version 1 layout
Grant table initialized
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
vbd vbd-5696: 19 xenbus_dev_probe on device/vbd/5696
blkfront: xvda: barrier: enabled; persistent grants: disabled; indirect descriptors: disabled;
 xvda: xvda1 xvda2
xen_netfront: Initialising Xen virtual ethernet driver
i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
input: PC Speaker as /devices/platform/pcspkr/input/input3
rtc_cmos 00:05: RTC can wake from S4
rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
rtc_cmos 00:05: alarms up to one day, 114 bytes nvram, hpet irqs
cpuidle: using governor ladder
cpuidle: using governor menu
hidraw: raw HID events driver (C) Jiri Kosina
nf_conntrack version 0.5.0 (7949 buckets, 31796 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP: cubic registered
Key type dns_resolver registered
xenbus_probe_frontend: Device with no driver: device/vbd/5696
rtc_cmos 00:05: setting system clock to 2013-10-18 02:54:50 UTC (1382064890)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 1032K (ffffffff81674000 - ffffffff81776000)
Write protecting the kernel read-only data: 6144k
Freeing unused kernel memory: 68K (ffff8800013ef000 - ffff880001400000)
Freeing unused kernel memory: 788K (ffff88000153b000 - ffff880001600000)
udev[42]: starting version 167
Checking for graphic mode...
$ /bin/syslogd -D
$ /bin/klogd
RunInsmod:343 running insmod for snapapi26 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/snapapi26.ko
snapapi26: module license 'Proprietary' taints kernel.
Disabling lock debugging due to kernel taint
snapapi_init: Snapapi(v.0.7.76) init OK. Session size 13648.
WaitInsmod:310 'snapapi26' was loaded: running=0
RunInsmod:343 running insmod for psmouse - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/psmouse.ko
$ /bin/getty 115200 tty2 -n -l /bin/sh
WaitInsmod:310 'psmouse' was loaded: running=0
RunInsmod:343 running insmod for floppy - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/floppy.ko
FDC 0 is a S82078B
WaitInsmod:310 'floppy' was loaded: running=0
RunInsmod:343 running insmod for scsi_mod - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/scsi_mod.ko
SCSI subsystem initialized
WaitInsmod:310 'scsi_mod' was loaded: running=0
RunInsmod:343 running insmod for sd_mod - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/sd_mod.ko
WaitInsmod:310 'sd_mod' was loaded: running=0
RunInsmod:343 running insmod for sg - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/sg.ko
WaitInsmod:310 'sg' was loaded: running=0
RunInsmod:343 running insmod for st - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/st.ko
st: Version 20101219, fixed bufsize 32768, s/g segs 256
WaitInsmod:310 'st' was loaded: running=0
RunInsmod:343 running insmod for libata - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/libata.ko
ACPI: bus type ATA registered
WaitInsmod:310 'libata' was loaded: running=0
RunInsmod:343 running insmod for ata_generic - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ata_generic.ko
WaitInsmod:310 'ata_generic' was loaded: running=0
RunInsmod:343 running insmod for ata_piix - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ata_piix.ko
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc220 irq 14
ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc228 irq 15
ata2.01: ATAPI: QEMU DVD-ROM, 0.10.2, max UDMA/100
ata2.01: configured for MWDMA2
scsi 1:0:1:0: CD-ROM            QEMU     QEMU DVD-ROM     0.10 PQ: 0 ANSI: 5
scsi 1:0:1:0: Attached scsi generic sg0 type 5
WaitInsmod:310 'ata_piix' was loaded: running=0
RunInsmod:343 running insmod for pata_acpi - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/pata_acpi.ko
WaitInsmod:310 'pata_acpi' was loaded: running=0
RunInsmod:343 running insmod for ide-core - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ide-core.ko
Uniform Multi-Platform E-IDE driver
WaitInsmod:310 'ide-core' was loaded: running=0
RunInsmod:343 running insmod for ide-pci-generic - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ide-pci-generic.ko
WaitInsmod:310 'ide-pci-generic' was loaded: running=0
RunInsmod:343 running insmod for piix - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/piix.ko
WaitInsmod:310 'piix' was loaded: running=0
RunInsmod:343 running insmod for ide-gd_mod - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ide-gd_mod.ko
ide-gd driver 1.18
WaitInsmod:310 'ide-gd_mod' was loaded: running=0
RunInsmod:343 running insmod for usb-common - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/usb-common.ko
WaitInsmod:310 'usb-common' was loaded: running=0
RunInsmod:343 running insmod for usbcore - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/usbcore.ko
ACPI: bus type USB registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
WaitInsmod:310 'usbcore' was loaded: running=0
tsc: Refined TSC clocksource calibration: 1864.849 MHz
RunInsmod:343 running insmod for uhci-hcd - #0
WaitInsmod:298 waiting loading: running=1
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input4
Using /lib/modules/uhci-hcd.ko
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:01.2: UHCI Host Controller
uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c200
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
WaitInsmod:310 'uhci-hcd' was loaded: running=0
RunInsmod:343 running insmod for cdrom - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/cdrom.ko
WaitInsmod:310 'cdrom' was loaded: running=0
RunInsmod:343 running insmod for sr_mod - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/sr_mod.ko
sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
cdrom: Uniform CD-ROM driver Revision: 3.20
WaitInsmod:310 'sr_mod' was loaded: running=0
RunInsmod:343 running insmod for ide-cd_mod - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ide-cd_mod.ko
ide-cd driver 5.00
WaitInsmod:310 'ide-cd_mod' was loaded: running=0
RunInsmod:343 running insmod for intel-gtt - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/intel-gtt.ko
WaitInsmod:310 'intel-gtt' was loaded: running=0
RunInsmod:343 running insmod for intel-agp - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/intel-agp.ko
WaitInsmod:310 'intel-agp' was loaded: running=0
RunInsmod:343 running insmod for af_packet - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/af_packet.ko
NET: Registered protocol family 17
WaitInsmod:310 'af_packet' was loaded: running=0
RunInsmod:343 running insmod for crc16 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/crc16.ko
WaitInsmod:310 'crc16' was loaded: running=0
RunInsmod:343 running insmod for crc-itu-t - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/crc-itu-t.ko
WaitInsmod:310 'crc-itu-t' was loaded: running=0
RunInsmod:343 running insmod for udf - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/udf.ko
WaitInsmod:310 'udf' was loaded: running=0
RunInsmod:343 running insmod for exportfs - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/exportfs.ko
WaitInsmod:310 'exportfs' was loaded: running=0
RunInsmod:343 running insmod for ext2 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ext2.ko
WaitInsmod:310 'ext2' was loaded: running=0
RunInsmod:343 running insmod for fat - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/fat.ko
WaitInsmod:310 'fat' was loaded: running=0
RunInsmod:343 running insmod for vfat - #0
WaitInsmod:298 waiting loading: running=1
usb 1-2: new full-speed USB device number 2 using uhci_hcd
Using /lib/modules/vfat.ko
WaitInsmod:310 'vfat' was loaded: running=0
RunInsmod:343 running insmod for fuse - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/fuse.ko
fuse init (API version 7.22)
WaitInsmod:310 'fuse' was loaded: running=0
RunInsmod:343 running insmod for isofs - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/isofs.ko
WaitInsmod:310 'isofs' was loaded: running=0
RunInsmod:343 running insmod for jbd2 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/jbd2.ko
WaitInsmod:310 'jbd2' was loaded: running=0
RunInsmod:343 running insmod for jbd - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/jbd.ko
WaitInsmod:310 'jbd' was loaded: running=0
RunInsmod:343 running insmod for ext3 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ext3.ko
WaitInsmod:310 'ext3' was loaded: running=0
RunInsmod:343 running insmod for jfs - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/jfs.ko
JFS: nTxBlock = 7963, nTxLock = 63710
WaitInsmod:310 'jfs' was loaded: running=0
RunInsmod:343 running insmod for libcrc32c - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/libcrc32c.ko
Using /lib/modules/crc32c.ko
WaitInsmod:310 'libcrc32c' was loaded: running=0
RunInsmod:343 running insmod for xfs - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/xfs.ko
SGI XFS with security attributes, large block/inode numbers, no debug enabled
WaitInsmod:310 'xfs' was loaded: running=0
RunInsmod:343 running insmod for mbcache - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/mbcache.ko
WaitInsmod:310 'mbcache' was loaded: running=0
RunInsmod:343 running insmod for ext4 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/ext4.ko
WaitInsmod:310 'ext4' was loaded: running=0
RunInsmod:343 running insmod for nls_utf8 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/nls_utf8.ko
WaitInsmod:310 'nls_utf8' was loaded: running=0
RunInsmod:343 running insmod for reiserfs - #0
WaitInsmod:298 waiting loading: running=1
RunInsmod:343 running insmod for usbhid - #0
Using /lib/modules/reiserfs.ko
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/usbhid.ko
WaitInsmod:310 'reiserfs' was loaded: running=0
RunInsmod:343 running insmod for sha256_generic - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/sha256_generic.ko
WaitInsmod:310 'sha256_generic' was loaded: running=0
RunInsmod:343 running insmod for mousedev - #0
WaitInsmod:298 waiting loading: running=1
input: QEMU 0.10.2 QEMU USB Tablet as /devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/input/input5
Using /lib/modules/mousedev.ko
mousedev: PS/2 mouse device common for all mice
WaitInsmod:310 'mousedev' was loaded: running=0
Detecting mouse...
skipping serial mouse detection on port 0
hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer [QEMU 0.10.2 QEMU USB Tablet] on usb-0000:00:01.2-2/input0
$ /bin/gpm -R -m /dev/mice -t imps2
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
WaitInsmod:310 'usbhid' was loaded: running=0
Checking for network adapter...
$ /bin/ifconfig lo 127.0.0.1
$ /bin/ifconfig lo up
RunInsmod:343 running insmod for async_tx - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/async_tx.ko
WaitInsmod:310 'async_tx' was loaded: running=0
RunInsmod:343 running insmod for async_memcpy - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/async_memcpy.ko
WaitInsmod:310 'async_memcpy' was loaded: running=0
RunInsmod:343 running insmod for dm-mod - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/dm-mod.ko
device-mapper: ioctl: 4.25.0-ioctl (2013-06-26) initialised: dm-devel@redhat.com
WaitInsmod:310 'dm-mod' was loaded: running=0
RunInsmod:343 running insmod for raid10 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/raid10.ko
md: raid10 personality registered for level 10
WaitInsmod:310 'raid10' was loaded: running=0
RunInsmod:343 running insmod for raid1 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/raid1.ko
md: raid1 personality registered for level 1
WaitInsmod:310 'raid1' was loaded: running=0
RunInsmod:343 running insmod for raid6_pq - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/raid6_pq.ko
raid6: sse2x1    2406 MB/s
raid6: sse2x2    3343 MB/s
raid6: sse2x4    4003 MB/s
raid6: using algorithm sse2x4 (4003 MB/s)
raid6: using ssse3x2 recovery algorithm
WaitInsmod:310 'raid6_pq' was loaded: running=0
RunInsmod:343 running insmod for async_raid6_recov - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/async_raid6_recov.ko
WaitInsmod:310 'async_raid6_recov' was loaded: running=0
RunInsmod:343 running insmod for xor - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/xor.ko
xor: measuring software checksum speed
   prefetch64-sse:   964.000 MB/sec
   generic_sse:   952.000 MB/sec
xor: using function: prefetch64-sse (964.000 MB/sec)
WaitInsmod:310 'xor' was loaded: running=0
RunInsmod:343 running insmod for async_xor - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/async_xor.ko
WaitInsmod:310 'async_xor' was loaded: running=0
RunInsmod:343 running insmod for async_pq - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/async_pq.ko
WaitInsmod:310 'async_pq' was loaded: running=0
RunInsmod:343 running insmod for raid456 - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/raid456.ko
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
WaitInsmod:310 'raid456' was loaded: running=0
RunInsmod:343 running insmod for dm-raid - #0
WaitInsmod:298 waiting loading: running=1
Using /lib/modules/dm-raid.ko
device-mapper: raid: Loading target version 1.5.2
WaitInsmod:310 'dm-raid' was loaded: running=0
$ /bin/dmraid -pay
$ /bin/lvm vgscan --mknodes --ignorelockingfailure
$ /bin/lvm vgchange -a y --ignorelockingfailure
$ /bin/ipwatchd -c /etc/ipwatchd.conf
$ /bin/avahi-daemon -D
$ /bin/getty 115200 tty1 -n -l /bin/sh


[-- Attachment #3: vm_boot_log_id2.txt --]
[-- Type: text/plain, Size: 14222 bytes --]

[root@xenserver62 ~]# xl console 189
Linux version 3.11.5-x86_64 (astarta@domain) (gcc version 4.8.1 ) #1 SMP Fri Oct 18 02:27:44 MSD 2013
Command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000003fbfffff] usable
BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
Hypervisor detected: Xen HVM
Xen version 4.1.
Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
You might have to change the root device
from /dev/hd[a-d] to /dev/xvd[a-d]
in your root= kernel command line option
No AGP bridge found
e820: last_pfn = 0x3fc00 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [mem 0x000fb710-0x000fb71f] mapped at [ffff8800000fb710]
init_memory_mapping: [mem 0x00000000-0x000fffff]
init_memory_mapping: [mem 0x3c600000-0x3c7fffff]
init_memory_mapping: [mem 0x3c000000-0x3c5fffff]
init_memory_mapping: [mem 0x00100000-0x3bffffff]
init_memory_mapping: [mem 0x3c800000-0x3fbfffff]
RAMDISK: [mem 0x3c822000-0x3fbdffff]
ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
ACPI: XSDT 00000000fc00ef80 00044 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: FACP 00000000fc00ed40 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
ACPI: DSDT 00000000fc003040 0BC75 (v02    Xen      HVM 00000000 INTL 20090123)
ACPI: FACS 00000000fc003000 00040
ACPI: APIC 00000000fc00ee40 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
ACPI: HPET 00000000fc00ef20 00038 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: WAET 00000000fc00ef58 00028 (v01    Xen      HVM 00000000 HVML 00000000)
No NUMA configuration found
Faking a node at [mem 0x0000000000000000-0x000000003fbfffff]
Initmem setup node 0 [mem 0x00000000-0x3fbfffff]
  NODE_DATA [mem 0x3fbec000-0x3fbfffff]
Zone ranges:
  DMA      [mem 0x00001000-0x00ffffff]
  DMA32    [mem 0x01000000-0xffffffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00001000-0x0009dfff]
  node   0: [mem 0x00100000-0x3fbfffff]
ACPI: PM-Timer IO Port: 0x1f48
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
smpboot: Allowing 15 CPUs, 14 hotplug CPUs
e820: [mem 0x3fc00000-0xfbffffff] available for PCI devices
Booting paravirtualized kernel on Xen HVM
setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:15 nr_node_ids:1
PERCPU: Embedded 27 pages/cpu @ffff88003c600000 s80384 r8192 d22016 u131072
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256920
Policy zone: DMA32
Kernel command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
PID hash table entries: 4096 (order: 3, 32768 bytes)
Checking aperture...
No AGP bridge found
Memory: 964488K/1044084K available (4014K kernel code, 457K rwdata, 1260K rodata, 1032K init, 676K bss, 79596K reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1
Hierarchical RCU implementation.
        RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=15.
NR_IRQS:8448 nr_irqs:1208 16
xen:events: Xen HVM callback vector for event delivery is enabled
Console: colour dummy device 80x25
console [tty0] enabled
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
console [ttyS0] enabled
tsc: Detected 1864.851 MHz processor
Calibrating delay loop (skipped), value calculated using timer frequency.. 3729.70 BogoMIPS (lpj=1864851)
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 256
mce: CPU supports 0 MCE banks
Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32
tlb_flushall_shift: -1
ACPI: Core revision 20130517
ACPI: All ACPI Tables successfully acquired
Switched APIC routing to physical flat.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
smpboot: CPU0: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz (fam: 06, model: 0f, stepping: 02)
installing Xen timer for CPU 0
Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only.
Brought up 1 CPUs
smpboot: Total of 1 processors activated (3729.70 BogoMIPS)
devtmpfs: initialized
NET: Registered protocol family 16
ACPI: bus type PCI registered
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM
acpi PNP0A03:00: Unable to request _OSC control (_OSC support mask: 0x08)
acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
acpiphp: Slot [0] registered
acpiphp: Slot [1] registered
acpiphp: Slot [2] registered
acpiphp: Slot [3] registered
acpiphp: Slot [4] registered
acpiphp: Slot [5] registered
acpiphp: Slot [6] registered
acpiphp: Slot [7] registered
acpiphp: Slot [8] registered
acpiphp: Slot [9] registered
acpiphp: Slot [10] registered
acpiphp: Slot [11] registered
acpiphp: Slot [12] registered
acpiphp: Slot [13] registered
acpiphp: Slot [14] registered
acpiphp: Slot [15] registered
acpiphp: Slot [16] registered
acpiphp: Slot [17] registered
acpiphp: Slot [18] registered
acpiphp: Slot [19] registered
acpiphp: Slot [20] registered
acpiphp: Slot [21] registered
acpiphp: Slot [22] registered
acpiphp: Slot [23] registered
acpiphp: Slot [24] registered
acpiphp: Slot [25] registered
acpiphp: Slot [26] registered
acpiphp: Slot [27] registered
acpiphp: Slot [28] registered
acpiphp: Slot [29] registered
acpiphp: Slot [30] registered
acpiphp: Slot [31] registered
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
pci 0000:00:01.3: quirk: [io  0x1f40-0x1f7f] claimed by PIIX4 ACPI
ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
ACPI: Enabled 2 GPEs in block 00 to 1F
xen:balloon: Initialising balloon driver
xen_balloon: Initialising balloon driver
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:02.0
PCI: Using ACPI for IRQ routing
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Switched to clocksource xen
pnp: PnP ACPI init
ACPI: bus type PNP registered
system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:01: [io  0x10c0-0x1141] has been reserved
system 00:01: [io  0xb044-0xb047] has been reserved
system 00:03: [io  0x08a0-0x08a3] has been reserved
system 00:03: [io  0x0cc0-0x0ccf] has been reserved
system 00:03: [io  0x04d0-0x04d1] has been reserved
pnp: PnP ACPI: found 12 devices
ACPI: bus type PNP unregistered
Loading, please wait...
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:01.0: PIIX3: Enabling Passive Release
pci 0000:00:01.0: Activating ISA DMA hang workarounds
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 52984K (ffff88003c822000 - ffff88003fbe0000)
bounce pool size: 64 pages
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 1987
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: framebuffer at 0xf0000000, mapped to 0xffffc90000200000, using 1875k, total 4096k
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
GHES: HEST is not enabled!
xen:xen_evtchn: Event-channel device installed
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
------------[ cut here ]------------
kernel BUG at drivers/xen/grant-table.c:1189!
invalid opcode: 0000 [#1] SMP 
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.5-x86_64 #1
Hardware name: Xen HVM domU, BIOS 4.1.5 06/14/2013
task: ffff88003c218000 ti: ffff88003c214000 task.ti: ffff88003c214000
RIP: 0010:[<ffffffff8125ac4f>]  [<ffffffff8125ac4f>] get_free_entries+0x2bf/0x2d0
RSP: 0000:ffff88003c215c08  EFLAGS: 00010046
RAX: 0000000000000282 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81811770
RBP: ffff88003c215c50 R08: fffffffffffffffe R09: 0000000000016010
R10: ffff88003fbec6c0 R11: 000000000000001d R12: 0000000000000282
R13: 000000000003f56d R14: 0000000000000000 R15: ffffffff81657158
FS:  0000000000000000(0000) GS:ffff88003c600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000000160c000 CR4: 00000000000006f0
Stack:
 0000000000000282 ffff88003c215ca8 ffff88003fbedb00 0000000000000030
 ffff88003f588000 0000000000000000 000000000003f56d 0000000000000000
 ffffffff81657158 ffff88003c215c80 ffffffff8125ac7e ffff88003f588000
Call Trace:
 [<ffffffff8125ac7e>] gnttab_grant_foreign_access+0x1e/0x60
 [<ffffffff8125fc45>] xenbus_grant_ring+0x15/0x50
 [<ffffffff812c8b6d>] talk_to_blkback+0xed/0x430
 [<ffffffff812c9c7a>] blkfront_probe+0x16a/0x280
 [<ffffffff81262c1e>] xenbus_dev_probe+0x7e/0x140
 [<ffffffff81264193>] xenbus_frontend_dev_probe+0x43/0x50
 [<ffffffff812ba171>] driver_probe_device+0x71/0x230
 [<ffffffff812ba3fb>] __driver_attach+0x8b/0x90
 [<ffffffff812ba370>] ? __device_attach+0x40/0x40
 [<ffffffff812b83a3>] bus_for_each_dev+0x63/0xa0
 [<ffffffff812b9cc9>] driver_attach+0x19/0x20
 [<ffffffff812b98e8>] bus_add_driver+0x1d8/0x270
 [<ffffffff812ba9df>] driver_register+0x6f/0x150
 [<ffffffff812624f5>] xenbus_register_driver_common+0x15/0x20
 [<ffffffff812645b3>] xenbus_register_frontend+0x23/0x40
 [<ffffffff816b7120>] ? brd_init+0x1db/0x1db
 [<ffffffff816b717f>] xlblk_init+0x5f/0x84
 [<ffffffff816b7120>] ? brd_init+0x1db/0x1db
 [<ffffffff81002112>] do_one_initcall+0x112/0x170
 [<ffffffff81066768>] ? parse_args+0x1f8/0x330
 [<ffffffff81688fd3>] kernel_init_freeable+0x10c/0x18d
 [<ffffffff81688893>] ? do_early_param+0x88/0x88
 [<ffffffff813da890>] ? rest_init+0x80/0x80
 [<ffffffff813da899>] kernel_init+0x9/0x180
 [<ffffffff813e7cfc>] ret_from_fork+0x7c/0xb0
 [<ffffffff813da890>] ? rest_init+0x80/0x80
Code: ff ff e8 1e 7e 18 00 48 8b 05 56 6b 5b 00 44 8b 2d 3b 6b 5b 00 e9 62 fe ff ff 66 90 b8 e4 ff ff ff e9 32 ff ff ff 44 89 c7 eb 8c <0f> 0b 0f 0b 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 
RIP  [<ffffffff8125ac4f>] get_free_entries+0x2bf/0x2d0
 RSP <ffff88003c215c08>
---[ end trace d9010cd2569c42eb ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b



[-- Attachment #4: vm_boot_log_id_empty.txt --]
[-- Type: text/plain, Size: 14222 bytes --]

[root@xenserver62 ~]# xl console 191
Linux version 3.11.5-x86_64 (astarta@domain) (gcc version 4.8.1 ) #1 SMP Fri Oct 18 02:27:44 MSD 2013
Command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000003fbfffff] usable
BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
Hypervisor detected: Xen HVM
Xen version 4.1.
Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
You might have to change the root device
from /dev/hd[a-d] to /dev/xvd[a-d]
in your root= kernel command line option
No AGP bridge found
e820: last_pfn = 0x3fc00 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [mem 0x000fb710-0x000fb71f] mapped at [ffff8800000fb710]
init_memory_mapping: [mem 0x00000000-0x000fffff]
init_memory_mapping: [mem 0x3c600000-0x3c7fffff]
init_memory_mapping: [mem 0x3c000000-0x3c5fffff]
init_memory_mapping: [mem 0x00100000-0x3bffffff]
init_memory_mapping: [mem 0x3c800000-0x3fbfffff]
RAMDISK: [mem 0x3c822000-0x3fbdffff]
ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
ACPI: XSDT 00000000fc00ef80 00044 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: FACP 00000000fc00ed40 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
ACPI: DSDT 00000000fc003040 0BC75 (v02    Xen      HVM 00000000 INTL 20090123)
ACPI: FACS 00000000fc003000 00040
ACPI: APIC 00000000fc00ee40 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
ACPI: HPET 00000000fc00ef20 00038 (v01    Xen      HVM 00000000 HVML 00000000)
ACPI: WAET 00000000fc00ef58 00028 (v01    Xen      HVM 00000000 HVML 00000000)
No NUMA configuration found
Faking a node at [mem 0x0000000000000000-0x000000003fbfffff]
Initmem setup node 0 [mem 0x00000000-0x3fbfffff]
  NODE_DATA [mem 0x3fbec000-0x3fbfffff]
Zone ranges:
  DMA      [mem 0x00001000-0x00ffffff]
  DMA32    [mem 0x01000000-0xffffffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00001000-0x0009dfff]
  node   0: [mem 0x00100000-0x3fbfffff]
ACPI: PM-Timer IO Port: 0x1f48
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
smpboot: Allowing 15 CPUs, 14 hotplug CPUs
e820: [mem 0x3fc00000-0xfbffffff] available for PCI devices
Booting paravirtualized kernel on Xen HVM
setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:15 nr_node_ids:1
PERCPU: Embedded 27 pages/cpu @ffff88003c600000 s80384 r8192 d22016 u131072
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256920
Policy zone: DMA32
Kernel command line: initrd=ramdisk.dat root=/dev/ram0 console=ttyS0,115200 console=tty0 vga=0x314 BOOT_IMAGE=kernel.dat 
PID hash table entries: 4096 (order: 3, 32768 bytes)
Checking aperture...
No AGP bridge found
Memory: 964488K/1044084K available (4014K kernel code, 457K rwdata, 1260K rodata, 1032K init, 676K bss, 79596K reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1
Hierarchical RCU implementation.
        RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=15.
NR_IRQS:8448 nr_irqs:1208 16
xen:events: Xen HVM callback vector for event delivery is enabled
Console: colour dummy device 80x25
console [tty0] enabled
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
console [ttyS0] enabled
tsc: Detected 1864.851 MHz processor
Calibrating delay loop (skipped), value calculated using timer frequency.. 3729.70 BogoMIPS (lpj=1864851)
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 256
mce: CPU supports 0 MCE banks
Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32
tlb_flushall_shift: -1
ACPI: Core revision 20130517
ACPI: All ACPI Tables successfully acquired
Switched APIC routing to physical flat.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
smpboot: CPU0: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz (fam: 06, model: 0f, stepping: 02)
installing Xen timer for CPU 0
Performance Events: unsupported p6 CPU model 15 no PMU driver, software events only.
Brought up 1 CPUs
smpboot: Total of 1 processors activated (3729.70 BogoMIPS)
devtmpfs: initialized
NET: Registered protocol family 16
ACPI: bus type PCI registered
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM
acpi PNP0A03:00: Unable to request _OSC control (_OSC support mask: 0x08)
acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
acpiphp: Slot [0] registered
acpiphp: Slot [1] registered
acpiphp: Slot [2] registered
acpiphp: Slot [3] registered
acpiphp: Slot [4] registered
acpiphp: Slot [5] registered
acpiphp: Slot [6] registered
acpiphp: Slot [7] registered
acpiphp: Slot [8] registered
acpiphp: Slot [9] registered
acpiphp: Slot [10] registered
acpiphp: Slot [11] registered
acpiphp: Slot [12] registered
acpiphp: Slot [13] registered
acpiphp: Slot [14] registered
acpiphp: Slot [15] registered
acpiphp: Slot [16] registered
acpiphp: Slot [17] registered
acpiphp: Slot [18] registered
acpiphp: Slot [19] registered
acpiphp: Slot [20] registered
acpiphp: Slot [21] registered
acpiphp: Slot [22] registered
acpiphp: Slot [23] registered
acpiphp: Slot [24] registered
acpiphp: Slot [25] registered
acpiphp: Slot [26] registered
acpiphp: Slot [27] registered
acpiphp: Slot [28] registered
acpiphp: Slot [29] registered
acpiphp: Slot [30] registered
acpiphp: Slot [31] registered
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
pci 0000:00:01.3: quirk: [io  0x1f40-0x1f7f] claimed by PIIX4 ACPI
ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
ACPI: Enabled 2 GPEs in block 00 to 1F
xen:balloon: Initialising balloon driver
xen_balloon: Initialising balloon driver
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:02.0
PCI: Using ACPI for IRQ routing
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Switched to clocksource xen
pnp: PnP ACPI init
ACPI: bus type PNP registered
system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:01: [io  0x10c0-0x1141] has been reserved
system 00:01: [io  0xb044-0xb047] has been reserved
system 00:03: [io  0x08a0-0x08a3] has been reserved
system 00:03: [io  0x0cc0-0x0ccf] has been reserved
system 00:03: [io  0x04d0-0x04d1] has been reserved
pnp: PnP ACPI: found 12 devices
ACPI: bus type PNP unregistered
Loading, please wait...
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:01.0: PIIX3: Enabling Passive Release
pci 0000:00:01.0: Activating ISA DMA hang workarounds
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 52984K (ffff88003c822000 - ffff88003fbe0000)
bounce pool size: 64 pages
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 1987
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: framebuffer at 0xf0000000, mapped to 0xffffc90000200000, using 1875k, total 4096k
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
GHES: HEST is not enabled!
xen:xen_evtchn: Event-channel device installed
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
------------[ cut here ]------------
kernel BUG at drivers/xen/grant-table.c:1189!
invalid opcode: 0000 [#1] SMP 
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.5-x86_64 #1
Hardware name: Xen HVM domU, BIOS 4.1.5 06/14/2013
task: ffff88003c218000 ti: ffff88003c214000 task.ti: ffff88003c214000
RIP: 0010:[<ffffffff8125ac4f>]  [<ffffffff8125ac4f>] get_free_entries+0x2bf/0x2d0
RSP: 0000:ffff88003c215c08  EFLAGS: 00010046
RAX: 0000000000000282 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81811770
RBP: ffff88003c215c50 R08: fffffffffffffffe R09: 0000000000016010
R10: ffff88003fbec6c0 R11: 000000000000001d R12: 0000000000000282
R13: 000000000003f56d R14: 0000000000000000 R15: ffffffff81657158
FS:  0000000000000000(0000) GS:ffff88003c600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000000160c000 CR4: 00000000000006f0
Stack:
 0000000000000282 ffff88003c215ca8 ffff88003fbedb00 0000000000000030
 ffff88003f588000 0000000000000000 000000000003f56d 0000000000000000
 ffffffff81657158 ffff88003c215c80 ffffffff8125ac7e ffff88003f588000
Call Trace:
 [<ffffffff8125ac7e>] gnttab_grant_foreign_access+0x1e/0x60
 [<ffffffff8125fc45>] xenbus_grant_ring+0x15/0x50
 [<ffffffff812c8b6d>] talk_to_blkback+0xed/0x430
 [<ffffffff812c9c7a>] blkfront_probe+0x16a/0x280
 [<ffffffff81262c1e>] xenbus_dev_probe+0x7e/0x140
 [<ffffffff81264193>] xenbus_frontend_dev_probe+0x43/0x50
 [<ffffffff812ba171>] driver_probe_device+0x71/0x230
 [<ffffffff812ba3fb>] __driver_attach+0x8b/0x90
 [<ffffffff812ba370>] ? __device_attach+0x40/0x40
 [<ffffffff812b83a3>] bus_for_each_dev+0x63/0xa0
 [<ffffffff812b9cc9>] driver_attach+0x19/0x20
 [<ffffffff812b98e8>] bus_add_driver+0x1d8/0x270
 [<ffffffff812ba9df>] driver_register+0x6f/0x150
 [<ffffffff812624f5>] xenbus_register_driver_common+0x15/0x20
 [<ffffffff812645b3>] xenbus_register_frontend+0x23/0x40
 [<ffffffff816b7120>] ? brd_init+0x1db/0x1db
 [<ffffffff816b717f>] xlblk_init+0x5f/0x84
 [<ffffffff816b7120>] ? brd_init+0x1db/0x1db
 [<ffffffff81002112>] do_one_initcall+0x112/0x170
 [<ffffffff81066768>] ? parse_args+0x1f8/0x330
 [<ffffffff81688fd3>] kernel_init_freeable+0x10c/0x18d
 [<ffffffff81688893>] ? do_early_param+0x88/0x88
 [<ffffffff813da890>] ? rest_init+0x80/0x80
 [<ffffffff813da899>] kernel_init+0x9/0x180
 [<ffffffff813e7cfc>] ret_from_fork+0x7c/0xb0
 [<ffffffff813da890>] ? rest_init+0x80/0x80
Code: ff ff e8 1e 7e 18 00 48 8b 05 56 6b 5b 00 44 8b 2d 3b 6b 5b 00 e9 62 fe ff ff 66 90 b8 e4 ff ff ff e9 32 ff ff ff 44 89 c7 eb 8c <0f> 0b 0f 0b 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 
RIP  [<ffffffff8125ac4f>] get_free_entries+0x2bf/0x2d0
 RSP <ffff88003c215c08>
---[ end trace db179bb220e08f6e ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b



[-- Attachment #5: vm_cfg_id1.txt --]
[-- Type: text/plain, Size: 4428 bytes --]

uuid ( RO)                          : 7315c945-8cfe-d4e7-01d4-784b085ec2e5
                    name-label ( RW): Windows Server 2008 R2 (64-bit)
              name-description ( RW): 
                  user-version ( RW): 1
                 is-a-template ( RW): false
                 is-a-snapshot ( RO): false
                   snapshot-of ( RO): <not in database>
                     snapshots ( RO): 
                 snapshot-time ( RO): 19700101T00:00:00Z
                 snapshot-info ( RO): 
                        parent ( RO): <not in database>
                      children ( RO): 
             is-control-domain ( RO): false
                   power-state ( RO): running
                 memory-actual ( RO): 1073709056
                 memory-target ( RO): <expensive field>
               memory-overhead ( RO): 11534336
             memory-static-max ( RW): 1073741824
            memory-dynamic-max ( RW): 1073741824
            memory-dynamic-min ( RW): 1073741824
             memory-static-min ( RW): 536870912
              suspend-VDI-uuid ( RW): <not in database>
               suspend-SR-uuid ( RW): 1b40f2b4-3284-8dbf-a0fd-c93390c7c046
                  VCPUs-params (MRW): 
                     VCPUs-max ( RW): 1
              VCPUs-at-startup ( RW): 1
        actions-after-shutdown ( RW): Destroy
          actions-after-reboot ( RW): Restart
           actions-after-crash ( RW): Restart
                 console-uuids (SRO): 987aeca8-9f5e-d8db-8c52-00aba4774746
                      platform (MRW): device_id: 0001; timeoffset: -25200; nx: true; acpi: 1; apic: true; pae: true; viridian: true
            allowed-operations (SRO): changing_dynamic_range; hard_reboot; hard_shutdown; pause; snapshot
            current-operations (SRO): 
            blocked-operations (MRW): 
           allowed-VBD-devices (SRO): <expensive field>
           allowed-VIF-devices (SRO): <expensive field>
                possible-hosts ( RO): <expensive field>
               HVM-boot-policy ( RW): BIOS order
               HVM-boot-params (MRW): order: dc
         HVM-shadow-multiplier ( RW): 1.000
                     PV-kernel ( RW): 
                    PV-ramdisk ( RW): 
                       PV-args ( RW): 
                PV-legacy-args ( RW): 
                 PV-bootloader ( RW): 
            PV-bootloader-args ( RW): 
           last-boot-CPU-flags ( RO): vendor: GenuineIntel; features: 0000e3bd-bfebfbff-00000001-20100800
              last-boot-record ( RO): <expensive field>
                   resident-on ( RO): 5067bedc-cc4f-4631-9270-4ab9208acad6
                      affinity ( RW): 5067bedc-cc4f-4631-9270-4ab9208acad6
                  other-config (MRW): vgpu_pci: ; base_template_name: Windows Server 2008 R2 (64-bit); mac_seed: 655ad7a3-86ae-737d-de57-0a3a3a7ca390; install-methods: cdrom
                        dom-id ( RO): 186
               recommendations ( RO): <restrictions><restriction field="memory-static-max" max="137438953472" /><restriction field="vcpus-max" max="16" /><restriction property="number-of-vbds" max="7" /><restriction property="number-of-vifs" max="7" /></restrictions>
                 xenstore-data (MRW): vm-data: 
    ha-always-run ( RW) [DEPRECATED]: false
           ha-restart-priority ( RW): 
                         blobs ( RO): 
                    start-time ( RO): 20131018T09:52:11Z
                  install-time ( RO): 20131010T07:36:42Z
                  VCPUs-number ( RO): 1
             VCPUs-utilisation (MRO): <expensive field>
                    os-version (MRO): <not in database>
            PV-drivers-version (MRO): <not in database>
         PV-drivers-up-to-date ( RO): <not in database>
                        memory (MRO): <not in database>
                         disks (MRO): <not in database>
                      networks (MRO): <not in database>
                         other (MRO): <not in database>
                          live ( RO): <not in database>
    guest-metrics-last-updated ( RO): <not in database>
      cooperative ( RO) [DEPRECATED]: <expensive field>
                          tags (SRW): 
                     appliance ( RW): <not in database>
                   start-delay ( RW): 0
                shutdown-delay ( RW): 0
                         order ( RW): 0
                       version ( RO): 0
                 generation-id ( RO): 1748081902140758664:2911606901546204682



[-- Attachment #6: vm_cfg_id2.txt --]
[-- Type: text/plain, Size: 4450 bytes --]

uuid ( RO)                          : 7315c945-8cfe-d4e7-01d4-784b085ec2e5
                    name-label ( RW): Windows Server 2008 R2 (64-bit)
              name-description ( RW): 
                  user-version ( RW): 1
                 is-a-template ( RW): false
                 is-a-snapshot ( RO): false
                   snapshot-of ( RO): <not in database>
                     snapshots ( RO): 
                 snapshot-time ( RO): 19700101T00:00:00Z
                 snapshot-info ( RO): 
                        parent ( RO): <not in database>
                      children ( RO): 
             is-control-domain ( RO): false
                   power-state ( RO): halted
                 memory-actual ( RO): 1073709056
                 memory-target ( RO): <expensive field>
               memory-overhead ( RO): 11534336
             memory-static-max ( RW): 1073741824
            memory-dynamic-max ( RW): 1073741824
            memory-dynamic-min ( RW): 1073741824
             memory-static-min ( RW): 536870912
              suspend-VDI-uuid ( RW): <not in database>
               suspend-SR-uuid ( RW): 1b40f2b4-3284-8dbf-a0fd-c93390c7c046
                  VCPUs-params (MRW): 
                     VCPUs-max ( RW): 1
              VCPUs-at-startup ( RW): 1
        actions-after-shutdown ( RW): Destroy
          actions-after-reboot ( RW): Restart
           actions-after-crash ( RW): Restart
                 console-uuids (SRO): 
                      platform (MRW): device_id: 0002; timeoffset: -25200; nx: true; acpi: 1; apic: true; pae: true; viridian: true
            allowed-operations (SRO): changing_dynamic_range; changing_shadow_memory; changing_static_range; make_into_template; destroy; export; start_on; start; clone; copy; snapshot
            current-operations (SRO): 
            blocked-operations (MRW): 
           allowed-VBD-devices (SRO): <expensive field>
           allowed-VIF-devices (SRO): <expensive field>
                possible-hosts ( RO): <expensive field>
               HVM-boot-policy ( RW): BIOS order
               HVM-boot-params (MRW): order: dc
         HVM-shadow-multiplier ( RW): 1.000
                     PV-kernel ( RW): 
                    PV-ramdisk ( RW): 
                       PV-args ( RW): 
                PV-legacy-args ( RW): 
                 PV-bootloader ( RW): 
            PV-bootloader-args ( RW): 
           last-boot-CPU-flags ( RO): vendor: GenuineIntel; features: 0000e3bd-bfebfbff-00000001-20100800
              last-boot-record ( RO): <expensive field>
                   resident-on ( RO): <not in database>
                      affinity ( RW): 5067bedc-cc4f-4631-9270-4ab9208acad6
                  other-config (MRW): vgpu_pci: ; base_template_name: Windows Server 2008 R2 (64-bit); mac_seed: 655ad7a3-86ae-737d-de57-0a3a3a7ca390; install-methods: cdrom
                        dom-id ( RO): -1
               recommendations ( RO): <restrictions><restriction field="memory-static-max" max="137438953472" /><restriction field="vcpus-max" max="16" /><restriction property="number-of-vbds" max="7" /><restriction property="number-of-vifs" max="7" /></restrictions>
                 xenstore-data (MRW): vm-data: 
    ha-always-run ( RW) [DEPRECATED]: false
           ha-restart-priority ( RW): 
                         blobs ( RO): 
                    start-time ( RO): 19700101T00:00:00Z
                  install-time ( RO): 20131010T07:36:42Z
                  VCPUs-number ( RO): 0
             VCPUs-utilisation (MRO): <expensive field>
                    os-version (MRO): <not in database>
            PV-drivers-version (MRO): <not in database>
         PV-drivers-up-to-date ( RO): <not in database>
                        memory (MRO): <not in database>
                         disks (MRO): <not in database>
                      networks (MRO): <not in database>
                         other (MRO): <not in database>
                          live ( RO): <not in database>
    guest-metrics-last-updated ( RO): <not in database>
      cooperative ( RO) [DEPRECATED]: <expensive field>
                          tags (SRW): 
                     appliance ( RW): <not in database>
                   start-delay ( RW): 0
                shutdown-delay ( RW): 0
                         order ( RW): 0
                       version ( RO): 0
                 generation-id ( RO): 1748081902140758664:2911606901546204682



[-- Attachment #7: vm_cfg_id_empty.txt --]
[-- Type: text/plain, Size: 4446 bytes --]

uuid ( RO)                          : 7315c945-8cfe-d4e7-01d4-784b085ec2e5
                    name-label ( RW): Windows Server 2008 R2 (64-bit)
              name-description ( RW): 
                  user-version ( RW): 1
                 is-a-template ( RW): false
                 is-a-snapshot ( RO): false
                   snapshot-of ( RO): <not in database>
                     snapshots ( RO): 
                 snapshot-time ( RO): 19700101T00:00:00Z
                 snapshot-info ( RO): 
                        parent ( RO): <not in database>
                      children ( RO): 
             is-control-domain ( RO): false
                   power-state ( RO): halted
                 memory-actual ( RO): 1073709056
                 memory-target ( RO): <expensive field>
               memory-overhead ( RO): 11534336
             memory-static-max ( RW): 1073741824
            memory-dynamic-max ( RW): 1073741824
            memory-dynamic-min ( RW): 1073741824
             memory-static-min ( RW): 536870912
              suspend-VDI-uuid ( RW): <not in database>
               suspend-SR-uuid ( RW): 1b40f2b4-3284-8dbf-a0fd-c93390c7c046
                  VCPUs-params (MRW): 
                     VCPUs-max ( RW): 1
              VCPUs-at-startup ( RW): 1
        actions-after-shutdown ( RW): Destroy
          actions-after-reboot ( RW): Restart
           actions-after-crash ( RW): Restart
                 console-uuids (SRO): 
                      platform (MRW): device_id: ; timeoffset: -25200; nx: true; acpi: 1; apic: true; pae: true; viridian: true
            allowed-operations (SRO): changing_dynamic_range; changing_shadow_memory; changing_static_range; make_into_template; destroy; export; start_on; start; clone; copy; snapshot
            current-operations (SRO): 
            blocked-operations (MRW): 
           allowed-VBD-devices (SRO): <expensive field>
           allowed-VIF-devices (SRO): <expensive field>
                possible-hosts ( RO): <expensive field>
               HVM-boot-policy ( RW): BIOS order
               HVM-boot-params (MRW): order: dc
         HVM-shadow-multiplier ( RW): 1.000
                     PV-kernel ( RW): 
                    PV-ramdisk ( RW): 
                       PV-args ( RW): 
                PV-legacy-args ( RW): 
                 PV-bootloader ( RW): 
            PV-bootloader-args ( RW): 
           last-boot-CPU-flags ( RO): vendor: GenuineIntel; features: 0000e3bd-bfebfbff-00000001-20100800
              last-boot-record ( RO): <expensive field>
                   resident-on ( RO): <not in database>
                      affinity ( RW): 5067bedc-cc4f-4631-9270-4ab9208acad6
                  other-config (MRW): vgpu_pci: ; base_template_name: Windows Server 2008 R2 (64-bit); mac_seed: 655ad7a3-86ae-737d-de57-0a3a3a7ca390; install-methods: cdrom
                        dom-id ( RO): -1
               recommendations ( RO): <restrictions><restriction field="memory-static-max" max="137438953472" /><restriction field="vcpus-max" max="16" /><restriction property="number-of-vbds" max="7" /><restriction property="number-of-vifs" max="7" /></restrictions>
                 xenstore-data (MRW): vm-data: 
    ha-always-run ( RW) [DEPRECATED]: false
           ha-restart-priority ( RW): 
                         blobs ( RO): 
                    start-time ( RO): 19700101T00:00:00Z
                  install-time ( RO): 20131010T07:36:42Z
                  VCPUs-number ( RO): 0
             VCPUs-utilisation (MRO): <expensive field>
                    os-version (MRO): <not in database>
            PV-drivers-version (MRO): <not in database>
         PV-drivers-up-to-date ( RO): <not in database>
                        memory (MRO): <not in database>
                         disks (MRO): <not in database>
                      networks (MRO): <not in database>
                         other (MRO): <not in database>
                          live ( RO): <not in database>
    guest-metrics-last-updated ( RO): <not in database>
      cooperative ( RO) [DEPRECATED]: <expensive field>
                          tags (SRW): 
                     appliance ( RW): <not in database>
                   start-delay ( RW): 0
                shutdown-delay ( RW): 0
                         order ( RW): 0
                       version ( RO): 0
                 generation-id ( RO): 1748081902140758664:2911606901546204682



[-- Attachment #8: Type: text/plain, Size: 126 bytes --]

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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Paul Durrant]

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Astarta
> Sent: 18 October 2013 11:32
> To: Ian Campbell; David Vrabel
> Cc: xen-devel@lists.xen.org; Stefano Stabellini
> Subject: Re: [Xen-devel] [BUG] Xen vm kernel crash in get_free_entries.
> 
> On 10/18/2013 01:46 PM, Ian Campbell wrote:
> > On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:
> >
> >> I suspect some of the changes for ARM has caused this (because ARM is
> >> sort of PVHVM without a platform PCI device) but I had a quick look and
> >> couldn't spot anything.  Stefano, any ideas?
> > If there is no platform device then we should never be going anywhere
> > near any of the grant table code...
> >
> >  From the log in the original post it looks like at least some parts of
> > the kernel think it is running PVHVM (i.e. it does the unplug and says
> > "Booting paravirtualized kernel on Xen HVM"). I don't think this should
> > not be the case if there is no platform pci device.
> >
> > Could this be because XenServer uses this platform_device=2 thing, which
> > is enough to trigger some of the early setup (because the unplug
> > protocol is present on I/O ports 0x10) but then the PCI driver in Linux
> > doesn't know about this ID and so never initialises the rest of it?
> >
> > Astarta, which of these configurations have you tried:
> >
> >   - No platform device at all
> >   - Platform device with ID == 1
> >   - Platform device with ID == 2
> >
> > and what happened with each?
> >
> > Ian.
> >
> 
> Hello Ian,
> 
> 3.11.5 kernel boots OK if platform:device_id=0001 (see attached
> vm_boot_log_id1.txt and VM config vm_cfg_id1.txt)
> 3.11.5 kernel crashes if platform:device_id=0002 (see
> vm_boot_log_id2.txt mv_cfg_id2.txt).
> 
> Sorry, but I really dont know and cannot find in google how to test w/o
> platform:device_id at all. My system doesnt have xl.cfg in /etc/xen/ and
> I use xe utility to change parameters.
> I've tried not to specify platform:device_id leaving it empty (i.e. xe
> vm-param-set uuid=<VM UUID> platform:device_id= ). Kernel crashes. see
> vm_boot_log_id_empty.txt and vm_cfg_id_empty.txt ).
> 

If you don't specify device_id in your platform parameters then XenServer QEMU will default to the standard value of 1, so it will be the same as upstream

  Paul

> 
> Let me know if there's anything else I can do to shed some light to the
> problem.
> 
> --
> Marina
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Paul Durrant]

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: 18 October 2013 10:46
> To: David Vrabel
> Cc: xen-devel@lists.xen.org; Astarta; Stefano Stabellini
> Subject: Re: [Xen-devel] [BUG] Xen vm kernel crash in get_free_entries.
> 
> On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:
> 
> > I suspect some of the changes for ARM has caused this (because ARM is
> > sort of PVHVM without a platform PCI device) but I had a quick look and
> > couldn't spot anything.  Stefano, any ideas?
> 
> If there is no platform device then we should never be going anywhere
> near any of the grant table code...
> 
> From the log in the original post it looks like at least some parts of
> the kernel think it is running PVHVM (i.e. it does the unplug and says
> "Booting paravirtualized kernel on Xen HVM"). I don't think this should
> not be the case if there is no platform pci device.
> 
> Could this be because XenServer uses this platform_device=2 thing, which
> is enough to trigger some of the early setup (because the unplug
> protocol is present on I/O ports 0x10) but then the PCI driver in Linux
> doesn't know about this ID and so never initialises the rest of it?
> 
> Astarta, which of these configurations have you tried:
> 
>  - No platform device at all
>  - Platform device with ID == 1
>  - Platform device with ID == 2
> 
> and what happened with each?
> 

device_id will be 2 only if you use a windows template - which you generally should not for hvm linux as that also has viridian=true.

  Paul

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Astarta]

On 10/18/2013 03:06 PM, Paul Durrant wrote:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Ian Campbell
>> Sent: 18 October 2013 10:46
>> To: David Vrabel
>> Cc: xen-devel@lists.xen.org; Astarta; Stefano Stabellini
>> Subject: Re: [Xen-devel] [BUG] Xen vm kernel crash in get_free_entries.
>>
>> On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:
>>
>>> I suspect some of the changes for ARM has caused this (because ARM is
>>> sort of PVHVM without a platform PCI device) but I had a quick look and
>>> couldn't spot anything.  Stefano, any ideas?
>> If there is no platform device then we should never be going anywhere
>> near any of the grant table code...
>>
>>  From the log in the original post it looks like at least some parts of
>> the kernel think it is running PVHVM (i.e. it does the unplug and says
>> "Booting paravirtualized kernel on Xen HVM"). I don't think this should
>> not be the case if there is no platform pci device.
>>
>> Could this be because XenServer uses this platform_device=2 thing, which
>> is enough to trigger some of the early setup (because the unplug
>> protocol is present on I/O ports 0x10) but then the PCI driver in Linux
>> doesn't know about this ID and so never initialises the rest of it?
>>
>> Astarta, which of these configurations have you tried:
>>
>>   - No platform device at all
>>   - Platform device with ID == 1
>>   - Platform device with ID == 2
>>
>> and what happened with each?
>>
> device_id will be 2 only if you use a windows template - which you generally should not for hvm linux as that also has viridian=true.
>
>    Paul

You're right. The problem VMs are running Windows OS (Win2008 R2 and 
Windows 2012), Linux here is a kind of Live CD from where these VMs are 
backuped.

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Friday, October 18, 2013, 1:06:52 PM, you wrote:

>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Ian Campbell
>> Sent: 18 October 2013 10:46
>> To: David Vrabel
>> Cc: xen-devel@lists.xen.org; Astarta; Stefano Stabellini
>> Subject: Re: [Xen-devel] [BUG] Xen vm kernel crash in get_free_entries.
>> 
>> On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:
>> 
>> > I suspect some of the changes for ARM has caused this (because ARM is
>> > sort of PVHVM without a platform PCI device) but I had a quick look and
>> > couldn't spot anything.  Stefano, any ideas?
>> 
>> If there is no platform device then we should never be going anywhere
>> near any of the grant table code...
>> 
>> From the log in the original post it looks like at least some parts of
>> the kernel think it is running PVHVM (i.e. it does the unplug and says
>> "Booting paravirtualized kernel on Xen HVM"). I don't think this should
>> not be the case if there is no platform pci device.
>> 
>> Could this be because XenServer uses this platform_device=2 thing, which
>> is enough to trigger some of the early setup (because the unplug
>> protocol is present on I/O ports 0x10) but then the PCI driver in Linux
>> doesn't know about this ID and so never initialises the rest of it?
>> 
>> Astarta, which of these configurations have you tried:
>> 
>>  - No platform device at all
>>  - Platform device with ID == 1
>>  - Platform device with ID == 2
>> 
>> and what happened with each?
>> 

> device_id will be 2 only if you use a windows template - which you generally should not for hvm linux as that also has viridian=true.

What option sets the device id to 2 in a cfg file ?
I have encountered it on the "normal" xen project as well, so it's not only xenserver.

No other related options in my cfg file as far as i see, only the xen_platform_pci=0

It seemed to be introduced in the 3.8 kernel series.

--
Sander

>   Paul

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Paul Durrant]

> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> Sent: 18 October 2013 12:28
> To: Paul Durrant
> Cc: Ian Campbell; David Vrabel; Stefano Stabellini; Astarta; xen-
> devel@lists.xen.org
> Subject: Re: [Xen-devel] [BUG] Xen vm kernel crash in get_free_entries.
> 
> 
> Friday, October 18, 2013, 1:06:52 PM, you wrote:
> 
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> >> bounces@lists.xen.org] On Behalf Of Ian Campbell
> >> Sent: 18 October 2013 10:46
> >> To: David Vrabel
> >> Cc: xen-devel@lists.xen.org; Astarta; Stefano Stabellini
> >> Subject: Re: [Xen-devel] [BUG] Xen vm kernel crash in get_free_entries.
> >>
> >> On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:
> >>
> >> > I suspect some of the changes for ARM has caused this (because ARM is
> >> > sort of PVHVM without a platform PCI device) but I had a quick look and
> >> > couldn't spot anything.  Stefano, any ideas?
> >>
> >> If there is no platform device then we should never be going anywhere
> >> near any of the grant table code...
> >>
> >> From the log in the original post it looks like at least some parts of
> >> the kernel think it is running PVHVM (i.e. it does the unplug and says
> >> "Booting paravirtualized kernel on Xen HVM"). I don't think this should
> >> not be the case if there is no platform pci device.
> >>
> >> Could this be because XenServer uses this platform_device=2 thing,
> which
> >> is enough to trigger some of the early setup (because the unplug
> >> protocol is present on I/O ports 0x10) but then the PCI driver in Linux
> >> doesn't know about this ID and so never initialises the rest of it?
> >>
> >> Astarta, which of these configurations have you tried:
> >>
> >>  - No platform device at all
> >>  - Platform device with ID == 1
> >>  - Platform device with ID == 2
> >>
> >> and what happened with each?
> >>
> 
> > device_id will be 2 only if you use a windows template - which you
> generally should not for hvm linux as that also has viridian=true.
> 
> What option sets the device id to 2 in a cfg file ?
> I have encountered it on the "normal" xen project as well, so it's not only
> xenserver.
> 

The device_id hack is only in XenServer.

  Paul

> No other related options in my cfg file as far as i see, only the
> xen_platform_pci=0
> 
> It seemed to be introduced in the 3.8 kernel series.
> 
> --
> Sander
> 
> >   Paul
> 
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Pasi Kärkkäinen]

On Fri, Oct 18, 2013 at 10:46:04AM +0100, Ian Campbell wrote:
> On Fri, 2013-10-18 at 10:31 +0100, David Vrabel wrote:
> 
> > I suspect some of the changes for ARM has caused this (because ARM is
> > sort of PVHVM without a platform PCI device) but I had a quick look and
> > couldn't spot anything.  Stefano, any ideas?
> 
> If there is no platform device then we should never be going anywhere
> near any of the grant table code...
> 
> From the log in the original post it looks like at least some parts of
> the kernel think it is running PVHVM (i.e. it does the unplug and says
> "Booting paravirtualized kernel on Xen HVM"). I don't think this should
> not be the case if there is no platform pci device.
> 
> Could this be because XenServer uses this platform_device=2 thing, which
> is enough to trigger some of the early setup (because the unplug
> protocol is present on I/O ports 0x10) but then the PCI driver in Linux
> doesn't know about this ID and so never initialises the rest of it?
> 
> Astarta, which of these configurations have you tried:
> 
>  - No platform device at all
>  - Platform device with ID == 1
>  - Platform device with ID == 2
> 
> and what happened with each?
> 

Just to clarify I didn't test with XenServer,
I was testing with upstream Xen 4.2.3, where xen_platform_pci=0 causes the crash..
but weirdly enough only when using xl.. with xm/xend it works OK with and without platform pci device.

-- Pasi

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Fri, 2013-10-18 at 17:15 +0300, Pasi Kärkkäinen wrote:
> I was testing with upstream Xen 4.2.3, where xen_platform_pci=0 causes the crash..

Please can you provide a guest dmesg of the crash as well as details of
your guest/host configuration.

Under the circumstances it seems like the qemu logs and the qemu command
line parameters used in both xl and xm cases would be useful too.

Ian.


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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Pasi Kärkkäinen]

On Fri, Oct 18, 2013 at 03:19:02PM +0100, Ian Campbell wrote:
> On Fri, 2013-10-18 at 17:15 +0300, Pasi Kärkkäinen wrote:
> > I was testing with upstream Xen 4.2.3, where xen_platform_pci=0 causes the crash..
> 
> Please can you provide a guest dmesg of the crash as well as details of
> your guest/host configuration.
> 
> Under the circumstances it seems like the qemu logs and the qemu command
> line parameters used in both xl and xm cases would be useful too.
> 

Yep, I will, Konrad already asked for those in the other thread.

The problem is i'm away from the testbox currently.. and it's not remotely accessibly.
but I'll post the logs/details later.

-- Pasi

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Friday, October 18, 2013, 4:19:02 PM, you wrote:

> On Fri, 2013-10-18 at 17:15 +0300, Pasi Kärkkäinen wrote:
>> I was testing with upstream Xen 4.2.3, where xen_platform_pci=0 causes the crash..

> Please can you provide a guest dmesg of the crash as well as details of
> your guest/host configuration.

> Under the circumstances it seems like the qemu logs and the qemu command
> line parameters used in both xl and xm cases would be useful too.

> Ian.


On a 3.12-rc5 kernel a straight revert of:
commit d0b4d64aadb9f4a90669848de9ef3819050a98cd xen/grant-table: correctly initialize grant table version 1

makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.

Dmesg of the guest still gives "booting a paravirtualized kernel on Xen HVM" .. but that is probably correct.

--
Sander





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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Astarta]

On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:
> Friday, October 18, 2013, 4:19:02 PM, you wrote:
>
>> On Fri, 2013-10-18 at 17:15 +0300, Pasi Kärkkäinen wrote:
>>> I was testing with upstream Xen 4.2.3, where xen_platform_pci=0 causes the crash..
>> Please can you provide a guest dmesg of the crash as well as details of
>> your guest/host configuration.
>> Under the circumstances it seems like the qemu logs and the qemu command
>> line parameters used in both xl and xm cases would be useful too.
>> Ian.
>
> On a 3.12-rc5 kernel a straight revert of:
> commit d0b4d64aadb9f4a90669848de9ef3819050a98cd xen/grant-table: correctly initialize grant table version 1
>
> makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
>
> Dmesg of the guest still gives "booting a paravirtualized kernel on Xen HVM" .. but that is probably correct.
>
> --
> Sander
>
>
>
>


Great catch!
I also confirm that 3.11.5 kernel boots just fine after reverting of 
'correctly initialize grant table version 1' patch.

Thank you :)

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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
> On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:

> > makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
> >
> Great catch!
> I also confirm that 3.11.5 kernel boots just fine after reverting of 
> 'correctly initialize grant table version 1' patch.

This could just be down to that patch adding some BUG_ONs to catch bad
things going on, e.g. the one in gnttab_expand which I think is being
hit here.

I have a feeling that it is still wrong (but just more benign) to be
hitting that call chain in a configuration where there is no platform
device driver running. IOW reverting that patch removes the obvious
symptom (blowing up) but not the root cause, i.e. the patch is doing its
job.

Ian.

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Saturday, October 19, 2013, 1:03:17 PM, you wrote:

> On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
>> On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:

>> > makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
>> >
>> Great catch!
>> I also confirm that 3.11.5 kernel boots just fine after reverting of 
>> 'correctly initialize grant table version 1' patch.

> This could just be down to that patch adding some BUG_ONs to catch bad
> things going on, e.g. the one in gnttab_expand which I think is being
> hit here.

> I have a feeling that it is still wrong (but just more benign) to be
> hitting that call chain in a configuration where there is no platform
> device driver running. IOW reverting that patch removes the obvious
> symptom (blowing up) but not the root cause, i.e. the patch is doing its
> job.

That was my suspicion too, but at least it seems like some starting point
of further debugging.
(and indication of the kernels affected since this commit went to stable as well)

Since i was still seeing the "Booting PV enabled guest on Xen HVM" is was wondering
what is supposed to happen when there are some combinations ....

xen HVM xen_platform_pci=0 + guest kernel without PV guest support and without xen pv drivers (net + block)

xen HVM xen_platform_pci=0 + guest kernel with PV guest support but without xen pv drivers (net + block)

xen HVM xen_platform_pci=0 + guest kernel with PV guest support and with xen pv drivers (net + block)
-- This is the configuration that hits the bug described here.

xen HVM xen_platform_pci=1 + guest kernel without PV guest support and without xen pv drivers (net + block)

xen HVM xen_platform_pci=1 + guest kernel with PV guest support and without xen pv drivers (net + block)

xen HVM xen_platform_pci=1 + guest kernel with PV guest support and with xen pv drivers (net + block)


Booting a guest kernel with PV support as HVM but without using PV doesn't seem possible with a .cfg option ?
(yes it's a hypothetical option (performance wise), as is running with a guest kernel which supports PV drivers,
 but not using them with xen_platform_pci=0 .. but it is useful for debugging )

--
Sander

> Ian.

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Matt Wilson]

On Sat, Oct 19, 2013 at 01:58:50PM +0200, Sander Eikelenboom wrote:
> 
> Saturday, October 19, 2013, 1:03:17 PM, you wrote:
> 
> > On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
> >> On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:
> 
> >> > makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
> >> >
> >> Great catch!
> >> I also confirm that 3.11.5 kernel boots just fine after reverting of 
> >> 'correctly initialize grant table version 1' patch.
> 
> > This could just be down to that patch adding some BUG_ONs to catch bad
> > things going on, e.g. the one in gnttab_expand which I think is being
> > hit here.
> 
> > I have a feeling that it is still wrong (but just more benign) to be
> > hitting that call chain in a configuration where there is no platform
> > device driver running. IOW reverting that patch removes the obvious
> > symptom (blowing up) but not the root cause, i.e. the patch is doing its
> > job.
> 
> That was my suspicion too, but at least it seems like some starting point
> of further debugging.
> (and indication of the kernels affected since this commit went to stable as well)
> 
> Since i was still seeing the "Booting PV enabled guest on Xen HVM" is was wondering
> what is supposed to happen when there are some combinations ....

This is the enlightenment code noticing that it's running in a HVM
guest under Xen via the hypervisor cpuid leaf (cpuid leaf
0x40000000).

> xen HVM xen_platform_pci=0 + guest kernel without PV guest support and without xen pv drivers (net + block)

This should work.

> xen HVM xen_platform_pci=0 + guest kernel with PV guest support but without xen pv drivers (net + block)

This should work.

> xen HVM xen_platform_pci=0 + guest kernel with PV guest support and with xen pv drivers (net + block)
> -- This is the configuration that hits the bug described here.

I don't see how this can be expected to work - the PV net and block
devices need the facilities that are initialized by the Xen platform
PCI device to operate. Of course it shouldn't crash either, it should
just use emulated devices instead of xen-netfront/xen-blkfront.

> xen HVM xen_platform_pci=1 + guest kernel without PV guest support and without xen pv drivers (net + block)

This should work.

> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and without xen pv drivers (net + block)

This should work.

> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and with xen pv drivers (net + block)

This should work.

> Booting a guest kernel with PV support as HVM but without using PV doesn't seem possible with a .cfg option ?
> (yes it's a hypothetical option (performance wise), as is running with a guest kernel which supports PV drivers,
>  but not using them with xen_platform_pci=0 .. but it is useful for debugging )

AFAICT the expected behavior would be to for the guest kernel to use
basic enlightenment for CPU operations (hotplug, timers) but no PV IO
support (net + block). But perhaps I'm missing something since you
theoretically don't need the PCI device if you have event channel
callback support in the guest kernel and sufficient support in the
hypervisor.

--msw

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Astarta]

[-- Attachment #1: Type: text/plain, Size: 4560 bytes --]

Hello,

Let me bring some new life to this discussion.

I've investigated a bit and found another way to make  kernels starting 
from 3.8.x to boot on the VMs with platform device_id 0002.
Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
patch is not necessary.

We can simply modify struct pci_device_id platform_pci_tbl[] (in 
drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
network are also recognized.

IMO, there is no need to add new fields with device id 0002 and device 
id 0000 to platform_pci_tbl[] , we can modify the existing one to use 
PCI_ANY_ID instead of PCI_DEVICE_ID_XEN_PLATFORM (which is 0001), so if 
we have PCI_VENDOR_ID_XEN there is no need to pay attention on device id.

So the patch is more than simple. See attached. I've tested the resulted 
kernel in my environment (with device ids 0002, 0001 and 0000) and it 
seems to work well.


--
Marina

On 10/21/2013 02:55 PM, Matt Wilson wrote:
> On Sat, Oct 19, 2013 at 01:58:50PM +0200, Sander Eikelenboom wrote:
>> Saturday, October 19, 2013, 1:03:17 PM, you wrote:
>>
>>> On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
>>>> On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:
>>>>> makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
>>>>>
>>>> Great catch!
>>>> I also confirm that 3.11.5 kernel boots just fine after reverting of
>>>> 'correctly initialize grant table version 1' patch.
>>> This could just be down to that patch adding some BUG_ONs to catch bad
>>> things going on, e.g. the one in gnttab_expand which I think is being
>>> hit here.
>>> I have a feeling that it is still wrong (but just more benign) to be
>>> hitting that call chain in a configuration where there is no platform
>>> device driver running. IOW reverting that patch removes the obvious
>>> symptom (blowing up) but not the root cause, i.e. the patch is doing its
>>> job.
>> That was my suspicion too, but at least it seems like some starting point
>> of further debugging.
>> (and indication of the kernels affected since this commit went to stable as well)
>>
>> Since i was still seeing the "Booting PV enabled guest on Xen HVM" is was wondering
>> what is supposed to happen when there are some combinations ....
> This is the enlightenment code noticing that it's running in a HVM
> guest under Xen via the hypervisor cpuid leaf (cpuid leaf
> 0x40000000).
>
>> xen HVM xen_platform_pci=0 + guest kernel without PV guest support and without xen pv drivers (net + block)
> This should work.
>
>> xen HVM xen_platform_pci=0 + guest kernel with PV guest support but without xen pv drivers (net + block)
> This should work.
>
>> xen HVM xen_platform_pci=0 + guest kernel with PV guest support and with xen pv drivers (net + block)
>> -- This is the configuration that hits the bug described here.
> I don't see how this can be expected to work - the PV net and block
> devices need the facilities that are initialized by the Xen platform
> PCI device to operate. Of course it shouldn't crash either, it should
> just use emulated devices instead of xen-netfront/xen-blkfront.
>
>> xen HVM xen_platform_pci=1 + guest kernel without PV guest support and without xen pv drivers (net + block)
> This should work.
>
>> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and without xen pv drivers (net + block)
> This should work.
>
>> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and with xen pv drivers (net + block)
> This should work.
>
>> Booting a guest kernel with PV support as HVM but without using PV doesn't seem possible with a .cfg option ?
>> (yes it's a hypothetical option (performance wise), as is running with a guest kernel which supports PV drivers,
>>   but not using them with xen_platform_pci=0 .. but it is useful for debugging )
> AFAICT the expected behavior would be to for the guest kernel to use
> basic enlightenment for CPU operations (hotplug, timers) but no PV IO
> support (net + block). But perhaps I'm missing something since you
> theoretically don't need the PCI device if you have event channel
> callback support in the guest kernel and sufficient support in the
> hypervisor.
>
> --msw


-- 
С уважением,
Astarta
Администратор Форума "Крысиный Бум"
http://rat.ru/forum/index.php

“The Linux philosophy is 'Laugh in the face of danger'.
Oops. Wrong One. 'Do it yourself'. Yes, that's it.”
(c) Linus Torvalds.


[-- Attachment #2: xen-platform_id.patch --]
[-- Type: text/x-patch, Size: 447 bytes --]

diff -up linux/drivers/xen/platform-pci.c.xen linux/drivers/xen/platform-pci.c
--- linux/drivers/xen/platform-pci.c.xen	2013-11-07 07:53:35.768941439 +0300
+++ linux/drivers/xen/platform-pci.c	2013-11-07 07:53:53.156815904 +0300
@@ -171,7 +171,7 @@ pci_out:
 }
 
 static struct pci_device_id platform_pci_tbl[] = {
-	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
+	{PCI_VENDOR_ID_XEN, PCI_ANY_ID,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> Hello,
> 
> Let me bring some new life to this discussion.
> 
> I've investigated a bit and found another way to make  kernels starting 
> from 3.8.x to boot on the VMs with platform device_id 0002.
> Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> patch is not necessary.
> 
> We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> network are also recognized.

I think this is just working around the problem, by avoiding the
situation where the error occurs. You could just as well switch to
platform device id < 2.

> IMO, there is no need to add new fields with device id 0002 and device 
> id 0000 to platform_pci_tbl[] , we can modify the existing one to use 
> PCI_ANY_ID instead of PCI_DEVICE_ID_XEN_PLATFORM (which is 0001), so if 
> we have PCI_VENDOR_ID_XEN there is no need to pay attention on device id.

That omits the possibility that a future rev might differ in some
meaningful way though.

Ian.

> 
> So the patch is more than simple. See attached. I've tested the resulted 
> kernel in my environment (with device ids 0002, 0001 and 0000) and it 
> seems to work well.
> 
> 
> --
> Marina
> 
> On 10/21/2013 02:55 PM, Matt Wilson wrote:
> > On Sat, Oct 19, 2013 at 01:58:50PM +0200, Sander Eikelenboom wrote:
> >> Saturday, October 19, 2013, 1:03:17 PM, you wrote:
> >>
> >>> On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
> >>>> On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:
> >>>>> makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
> >>>>>
> >>>> Great catch!
> >>>> I also confirm that 3.11.5 kernel boots just fine after reverting of
> >>>> 'correctly initialize grant table version 1' patch.
> >>> This could just be down to that patch adding some BUG_ONs to catch bad
> >>> things going on, e.g. the one in gnttab_expand which I think is being
> >>> hit here.
> >>> I have a feeling that it is still wrong (but just more benign) to be
> >>> hitting that call chain in a configuration where there is no platform
> >>> device driver running. IOW reverting that patch removes the obvious
> >>> symptom (blowing up) but not the root cause, i.e. the patch is doing its
> >>> job.
> >> That was my suspicion too, but at least it seems like some starting point
> >> of further debugging.
> >> (and indication of the kernels affected since this commit went to stable as well)
> >>
> >> Since i was still seeing the "Booting PV enabled guest on Xen HVM" is was wondering
> >> what is supposed to happen when there are some combinations ....
> > This is the enlightenment code noticing that it's running in a HVM
> > guest under Xen via the hypervisor cpuid leaf (cpuid leaf
> > 0x40000000).
> >
> >> xen HVM xen_platform_pci=0 + guest kernel without PV guest support and without xen pv drivers (net + block)
> > This should work.
> >
> >> xen HVM xen_platform_pci=0 + guest kernel with PV guest support but without xen pv drivers (net + block)
> > This should work.
> >
> >> xen HVM xen_platform_pci=0 + guest kernel with PV guest support and with xen pv drivers (net + block)
> >> -- This is the configuration that hits the bug described here.
> > I don't see how this can be expected to work - the PV net and block
> > devices need the facilities that are initialized by the Xen platform
> > PCI device to operate. Of course it shouldn't crash either, it should
> > just use emulated devices instead of xen-netfront/xen-blkfront.
> >
> >> xen HVM xen_platform_pci=1 + guest kernel without PV guest support and without xen pv drivers (net + block)
> > This should work.
> >
> >> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and without xen pv drivers (net + block)
> > This should work.
> >
> >> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and with xen pv drivers (net + block)
> > This should work.
> >
> >> Booting a guest kernel with PV support as HVM but without using PV doesn't seem possible with a .cfg option ?
> >> (yes it's a hypothetical option (performance wise), as is running with a guest kernel which supports PV drivers,
> >>   but not using them with xen_platform_pci=0 .. but it is useful for debugging )
> > AFAICT the expected behavior would be to for the guest kernel to use
> > basic enlightenment for CPU operations (hotplug, timers) but no PV IO
> > support (net + block). But perhaps I'm missing something since you
> > theoretically don't need the PCI device if you have event channel
> > callback support in the guest kernel and sufficient support in the
> > hypervisor.
> >
> > --msw
> 
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Konrad Rzeszutek Wilk]

On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > Hello,
> > 
> > Let me bring some new life to this discussion.
> > 
> > I've investigated a bit and found another way to make  kernels starting 
> > from 3.8.x to boot on the VMs with platform device_id 0002.
> > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > patch is not necessary.
> > 
> > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > network are also recognized.
> 
> I think this is just working around the problem, by avoiding the
> situation where the error occurs. You could just as well switch to
> platform device id < 2.

I am bit late to this discussion - but shouldn't there be something
in the kernel to deal with this?

> 
> > IMO, there is no need to add new fields with device id 0002 and device 
> > id 0000 to platform_pci_tbl[] , we can modify the existing one to use 
> > PCI_ANY_ID instead of PCI_DEVICE_ID_XEN_PLATFORM (which is 0001), so if 
> > we have PCI_VENDOR_ID_XEN there is no need to pay attention on device id.
> 
> That omits the possibility that a future rev might differ in some
> meaningful way though.
> 
> Ian.
> 
> > 
> > So the patch is more than simple. See attached. I've tested the resulted 
> > kernel in my environment (with device ids 0002, 0001 and 0000) and it 
> > seems to work well.
> > 
> > 
> > --
> > Marina
> > 
> > On 10/21/2013 02:55 PM, Matt Wilson wrote:
> > > On Sat, Oct 19, 2013 at 01:58:50PM +0200, Sander Eikelenboom wrote:
> > >> Saturday, October 19, 2013, 1:03:17 PM, you wrote:
> > >>
> > >>> On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
> > >>>> On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:
> > >>>>> makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
> > >>>>>
> > >>>> Great catch!
> > >>>> I also confirm that 3.11.5 kernel boots just fine after reverting of
> > >>>> 'correctly initialize grant table version 1' patch.
> > >>> This could just be down to that patch adding some BUG_ONs to catch bad
> > >>> things going on, e.g. the one in gnttab_expand which I think is being
> > >>> hit here.
> > >>> I have a feeling that it is still wrong (but just more benign) to be
> > >>> hitting that call chain in a configuration where there is no platform
> > >>> device driver running. IOW reverting that patch removes the obvious
> > >>> symptom (blowing up) but not the root cause, i.e. the patch is doing its
> > >>> job.
> > >> That was my suspicion too, but at least it seems like some starting point
> > >> of further debugging.
> > >> (and indication of the kernels affected since this commit went to stable as well)
> > >>
> > >> Since i was still seeing the "Booting PV enabled guest on Xen HVM" is was wondering
> > >> what is supposed to happen when there are some combinations ....
> > > This is the enlightenment code noticing that it's running in a HVM
> > > guest under Xen via the hypervisor cpuid leaf (cpuid leaf
> > > 0x40000000).
> > >
> > >> xen HVM xen_platform_pci=0 + guest kernel without PV guest support and without xen pv drivers (net + block)
> > > This should work.
> > >
> > >> xen HVM xen_platform_pci=0 + guest kernel with PV guest support but without xen pv drivers (net + block)
> > > This should work.
> > >
> > >> xen HVM xen_platform_pci=0 + guest kernel with PV guest support and with xen pv drivers (net + block)
> > >> -- This is the configuration that hits the bug described here.
> > > I don't see how this can be expected to work - the PV net and block
> > > devices need the facilities that are initialized by the Xen platform
> > > PCI device to operate. Of course it shouldn't crash either, it should
> > > just use emulated devices instead of xen-netfront/xen-blkfront.
> > >
> > >> xen HVM xen_platform_pci=1 + guest kernel without PV guest support and without xen pv drivers (net + block)
> > > This should work.
> > >
> > >> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and without xen pv drivers (net + block)
> > > This should work.
> > >
> > >> xen HVM xen_platform_pci=1 + guest kernel with PV guest support and with xen pv drivers (net + block)
> > > This should work.
> > >
> > >> Booting a guest kernel with PV support as HVM but without using PV doesn't seem possible with a .cfg option ?
> > >> (yes it's a hypothetical option (performance wise), as is running with a guest kernel which supports PV drivers,
> > >>   but not using them with xen_platform_pci=0 .. but it is useful for debugging )
> > > AFAICT the expected behavior would be to for the guest kernel to use
> > > basic enlightenment for CPU operations (hotplug, timers) but no PV IO
> > > support (net + block). But perhaps I'm missing something since you
> > > theoretically don't need the PCI device if you have event channel
> > > callback support in the guest kernel and sufficient support in the
> > > hypervisor.
> > >
> > > --msw
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > > Hello,
> > > 
> > > Let me bring some new life to this discussion.
> > > 
> > > I've investigated a bit and found another way to make  kernels starting 
> > > from 3.8.x to boot on the VMs with platform device_id 0002.
> > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > > patch is not necessary.
> > > 
> > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > > network are also recognized.
> > 
> > I think this is just working around the problem, by avoiding the
> > situation where the error occurs. You could just as well switch to
> > platform device id < 2.
> 
> I am bit late to this discussion - but shouldn't there be something
> in the kernel to deal with this?

Well, ideally the kernel wouldn't crash ;-)

I don't think it would be appropriate for Linux to bind to the device
with ID 2, since that has been assigned to a vendor
http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
it should be up to them to define the ABI of that device and provide a
Linux binding if they want.

Perhaps the unplug protocol
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html needs
expanding to blacklist products based on the presence absence of
whichever platform device subids there are.

I'm a bit confused because I thought the requirement was that the base
level platform device was always present and the secondary ones (like
the Citrix PV device with ID 2) would only ever be additional. Maybe I'm
wrong about that.

Ian.

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Wed, 2013-11-13 at 09:40 +0000, Ian Campbell wrote:
> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > > > Hello,
> > > > 
> > > > Let me bring some new life to this discussion.
> > > > 
> > > > I've investigated a bit and found another way to make  kernels starting 
> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
> > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > > > patch is not necessary.
> > > > 
> > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > > > network are also recognized.
> > > 
> > > I think this is just working around the problem, by avoiding the
> > > situation where the error occurs. You could just as well switch to
> > > platform device id < 2.
> > 
> > I am bit late to this discussion - but shouldn't there be something
> > in the kernel to deal with this?
> 
> Well, ideally the kernel wouldn't crash ;-)
> 
> I don't think it would be appropriate for Linux to bind to the device
> with ID 2, since that has been assigned to a vendor
> http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> it should be up to them to define the ABI of that device and provide a
> Linux binding if they want.
> 
> Perhaps the unplug protocol
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html needs
> expanding to blacklist products based on the presence absence of
> whichever platform device subids there are.
> 
> I'm a bit confused because I thought the requirement was that the base
> level platform device was always present and the secondary ones (like
> the Citrix PV device with ID 2) would only ever be additional. Maybe I'm
> wrong about that.

It turns out that some of the conclusions in 
http://lists.xen.org/archives/html/xen-devel/2013-11/msg01796.html
are relevant here, especially the subthread from
http://lists.xen.org/archives/html/xen-devel/2013-11/msg01842.html
onwards...

Ian.

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Konrad Rzeszutek Wilk]

On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > > > Hello,
> > > > 
> > > > Let me bring some new life to this discussion.
> > > > 
> > > > I've investigated a bit and found another way to make  kernels starting 
> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
> > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > > > patch is not necessary.
> > > > 
> > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > > > network are also recognized.
> > > 
> > > I think this is just working around the problem, by avoiding the
> > > situation where the error occurs. You could just as well switch to
> > > platform device id < 2.
> > 
> > I am bit late to this discussion - but shouldn't there be something
> > in the kernel to deal with this?
> 
> Well, ideally the kernel wouldn't crash ;-)

This patch should solve that (untested, but at least compile tested):
Please test it.

>From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Nov 2013 15:05:40 -0500
Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.

*TODO*

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c               |  2 +-
 drivers/input/misc/xen-kbdfront.c          |  4 ++++
 drivers/net/xen-netfront.c                 |  2 +-
 drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
 include/xen/platform_pci.h                 | 13 +++++++++++++
 5 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 432db1b..bcbaf0b 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	if (xen_hvm_domain() && !xen_platform_pci_unplug)
+	if (xen_err_out())
 		return -ENODEV;
 
 	if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index e21c181..9d250cf 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -29,6 +29,7 @@
 #include <xen/interface/io/fbif.h>
 #include <xen/interface/io/kbdif.h>
 #include <xen/xenbus.h>
+#include <xen/platform_pci.h>
 
 struct xenkbd_info {
 	struct input_dev *kbd;
@@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
 	if (xen_initial_domain())
 		return -ENODEV;
 
+	if (xen_err_out())
+		return -ENODEV;
+
 	return xenbus_register_frontend(&xenkbd_driver);
 }
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index e59acb1..be2744b 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -2115,7 +2115,7 @@ static int __init netif_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	if (xen_hvm_domain() && !xen_platform_pci_unplug)
+	if (xen_err_out())
 		return -ENODEV;
 
 	pr_info("Initialising Xen virtual ethernet driver\n");
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index 129bf84..b1c0f2a 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
 #ifndef MODULE
 static int __init boot_wait_for_devices(void)
 {
-	if (xen_hvm_domain() && !xen_platform_pci_unplug)
+	if (xen_err_out())
 		return -ENODEV;
 
 	ready_to_wait_for_devices = 1;
diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
index 438c256..a5bbd0b 100644
--- a/include/xen/platform_pci.h
+++ b/include/xen/platform_pci.h
@@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
 }
 
 extern int xen_platform_pci_unplug;
+static  bool xen_err_out(void)
+{
 
+	if (!xen_domain())
+		return true;
+
+	if (xen_hvm_domain()) {
+		if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
+			return true;
+		if (xen_platform_pci_unplug == 0)
+			return true;
+	}
+	return false;
+}
 #endif /* _XEN_PLATFORM_PCI_H */
-- 
1.8.3.1

> 
> I don't think it would be appropriate for Linux to bind to the device
> with ID 2, since that has been assigned to a vendor
> http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> it should be up to them to define the ABI of that device and provide a
> Linux binding if they want.
> 
> Perhaps the unplug protocol
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html needs
> expanding to blacklist products based on the presence absence of
> whichever platform device subids there are.
> 
> I'm a bit confused because I thought the requirement was that the base
> level platform device was always present and the secondary ones (like
> the Citrix PV device with ID 2) would only ever be additional. Maybe I'm
> wrong about that.
> 
> Ian.
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Tuesday, November 26, 2013, 9:08:47 PM, you wrote:

> On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
>> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
>> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
>> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
>> > > > Hello,
>> > > > 
>> > > > Let me bring some new life to this discussion.
>> > > > 
>> > > > I've investigated a bit and found another way to make  kernels starting 
>> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
>> > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
>> > > > patch is not necessary.
>> > > > 
>> > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
>> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
>> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
>> > > > network are also recognized.
>> > > 
>> > > I think this is just working around the problem, by avoiding the
>> > > situation where the error occurs. You could just as well switch to
>> > > platform device id < 2.
>> > 
>> > I am bit late to this discussion - but shouldn't there be something
>> > in the kernel to deal with this?
>> 
>> Well, ideally the kernel wouldn't crash ;-)

> This patch should solve that (untested, but at least compile tested):
> Please test it.

Hi Konrad,

I just gave it a shot on qemu-xen-traditional (since support for xen_platform_pci=0 is not upstream (yet))
It doesn't crash anymore on boot, but the guest now doesn't have any disks, so it ends in busybox because it can't find a root partition.
I would have expected it to be using qemu emulated disks now, but a "cat /proc/partitions" in busybox shows nothing.
But that's perhaps qemu code ejecting the emulated disks anyhow ...

In the config file i use:
 disk = [ 'phy:/dev/xen_vms/testvm,hda,w' ]

--
Sander

> From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Tue, 26 Nov 2013 15:05:40 -0500
> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.

> *TODO*

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkfront.c               |  2 +-
>  drivers/input/misc/xen-kbdfront.c          |  4 ++++
>  drivers/net/xen-netfront.c                 |  2 +-
>  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
>  include/xen/platform_pci.h                 | 13 +++++++++++++
>  5 files changed, 20 insertions(+), 3 deletions(-)

> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 432db1b..bcbaf0b 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>         if (!xen_domain())
>                 return -ENODEV;
>  
> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
> +       if (xen_err_out())
>                 return -ENODEV;
>  
>         if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index e21c181..9d250cf 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -29,6 +29,7 @@
>  #include <xen/interface/io/fbif.h>
>  #include <xen/interface/io/kbdif.h>
>  #include <xen/xenbus.h>
> +#include <xen/platform_pci.h>
>  
>  struct xenkbd_info {
>         struct input_dev *kbd;
> @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
>         if (xen_initial_domain())
>                 return -ENODEV;
>  
> +       if (xen_err_out())
> +               return -ENODEV;
> +
>         return xenbus_register_frontend(&xenkbd_driver);
>  }
>  
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index e59acb1..be2744b 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -2115,7 +2115,7 @@ static int __init netif_init(void)
>         if (!xen_domain())
>                 return -ENODEV;
>  
> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
> +       if (xen_err_out())
>                 return -ENODEV;
>  
>         pr_info("Initialising Xen virtual ethernet driver\n");
> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> index 129bf84..b1c0f2a 100644
> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
>  #ifndef MODULE
>  static int __init boot_wait_for_devices(void)
>  {
> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
> +       if (xen_err_out())
>                 return -ENODEV;
>  
>         ready_to_wait_for_devices = 1;
> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> index 438c256..a5bbd0b 100644
> --- a/include/xen/platform_pci.h
> +++ b/include/xen/platform_pci.h
> @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
>  }
>  
>  extern int xen_platform_pci_unplug;
> +static  bool xen_err_out(void)
> +{
>  
> +       if (!xen_domain())
> +               return true;
> +
> +       if (xen_hvm_domain()) {
> +               if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
> +                       return true;
> +               if (xen_platform_pci_unplug == 0)
> +                       return true;
> +       }
> +       return false;
> +}
>  #endif /* _XEN_PLATFORM_PCI_H */

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Tuesday, November 26, 2013, 11:00:15 PM, you wrote:


> Tuesday, November 26, 2013, 9:08:47 PM, you wrote:

>> On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
>>> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
>>> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
>>> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
>>> > > > Hello,
>>> > > > 
>>> > > > Let me bring some new life to this discussion.
>>> > > > 
>>> > > > I've investigated a bit and found another way to make  kernels starting 
>>> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
>>> > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
>>> > > > patch is not necessary.
>>> > > > 
>>> > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
>>> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
>>> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
>>> > > > network are also recognized.
>>> > > 
>>> > > I think this is just working around the problem, by avoiding the
>>> > > situation where the error occurs. You could just as well switch to
>>> > > platform device id < 2.
>>> > 
>>> > I am bit late to this discussion - but shouldn't there be something
>>> > in the kernel to deal with this?
>>> 
>>> Well, ideally the kernel wouldn't crash ;-)

>> This patch should solve that (untested, but at least compile tested):
>> Please test it.

> Hi Konrad,

> I just gave it a shot on qemu-xen-traditional (since support for xen_platform_pci=0 is not upstream (yet))
> It doesn't crash anymore on boot, but the guest now doesn't have any disks, so it ends in busybox because it can't find a root partition.
> I would have expected it to be using qemu emulated disks now, but a "cat /proc/partitions" in busybox shows nothing.
> But that's perhaps qemu code ejecting the emulated disks anyhow ...

Or i probably haven't got drivers for that compiled in .. let's have another look ..

> In the config file i use:
>  disk = [ 'phy:/dev/xen_vms/testvm,hda,w' ]

> --
> Sander

>> From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
>> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date: Tue, 26 Nov 2013 15:05:40 -0500
>> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.

>> *TODO*

>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  drivers/block/xen-blkfront.c               |  2 +-
>>  drivers/input/misc/xen-kbdfront.c          |  4 ++++
>>  drivers/net/xen-netfront.c                 |  2 +-
>>  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
>>  include/xen/platform_pci.h                 | 13 +++++++++++++
>>  5 files changed, 20 insertions(+), 3 deletions(-)

>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 432db1b..bcbaf0b 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>>         if (!xen_domain())
>>                 return -ENODEV;
>>  
>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>> +       if (xen_err_out())
>>                 return -ENODEV;
>>  
>>         if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>> index e21c181..9d250cf 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -29,6 +29,7 @@
>>  #include <xen/interface/io/fbif.h>
>>  #include <xen/interface/io/kbdif.h>
>>  #include <xen/xenbus.h>
>> +#include <xen/platform_pci.h>
>>  
>>  struct xenkbd_info {
>>         struct input_dev *kbd;
>> @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
>>         if (xen_initial_domain())
>>                 return -ENODEV;
>>  
>> +       if (xen_err_out())
>> +               return -ENODEV;
>> +
>>         return xenbus_register_frontend(&xenkbd_driver);
>>  }
>>  
>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> index e59acb1..be2744b 100644
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
>> @@ -2115,7 +2115,7 @@ static int __init netif_init(void)
>>         if (!xen_domain())
>>                 return -ENODEV;
>>  
>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>> +       if (xen_err_out())
>>                 return -ENODEV;
>>  
>>         pr_info("Initialising Xen virtual ethernet driver\n");
>> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
>> index 129bf84..b1c0f2a 100644
>> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
>> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
>> @@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
>>  #ifndef MODULE
>>  static int __init boot_wait_for_devices(void)
>>  {
>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>> +       if (xen_err_out())
>>                 return -ENODEV;
>>  
>>         ready_to_wait_for_devices = 1;
>> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
>> index 438c256..a5bbd0b 100644
>> --- a/include/xen/platform_pci.h
>> +++ b/include/xen/platform_pci.h
>> @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
>>  }
>>  
>>  extern int xen_platform_pci_unplug;
>> +static  bool xen_err_out(void)
>> +{
>>  
>> +       if (!xen_domain())
>> +               return true;
>> +
>> +       if (xen_hvm_domain()) {
>> +               if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
>> +                       return true;
>> +               if (xen_platform_pci_unplug == 0)
>> +                       return true;
>> +       }
>> +       return false;
>> +}
>>  #endif /* _XEN_PLATFORM_PCI_H */

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Tuesday, November 26, 2013, 11:00:15 PM, you wrote:


> Tuesday, November 26, 2013, 9:08:47 PM, you wrote:

>> On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
>>> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
>>> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
>>> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
>>> > > > Hello,
>>> > > > 
>>> > > > Let me bring some new life to this discussion.
>>> > > > 
>>> > > > I've investigated a bit and found another way to make  kernels starting 
>>> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
>>> > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
>>> > > > patch is not necessary.
>>> > > > 
>>> > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
>>> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
>>> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
>>> > > > network are also recognized.
>>> > > 
>>> > > I think this is just working around the problem, by avoiding the
>>> > > situation where the error occurs. You could just as well switch to
>>> > > platform device id < 2.
>>> > 
>>> > I am bit late to this discussion - but shouldn't there be something
>>> > in the kernel to deal with this?
>>> 
>>> Well, ideally the kernel wouldn't crash ;-)

>> This patch should solve that (untested, but at least compile tested):
>> Please test it.

> Hi Konrad,

> I just gave it a shot on qemu-xen-traditional (since support for xen_platform_pci=0 is not upstream (yet))
> It doesn't crash anymore on boot, but the guest now doesn't have any disks, so it ends in busybox because it can't find a root partition.
> I would have expected it to be using qemu emulated disks now, but a "cat /proc/partitions" in busybox shows nothing.
> But that's perhaps qemu code ejecting the emulated disks anyhow ...

Hi Konrad,

With the linux PATA modules compiled in it now also boots fine with qemu-xen-traditional and xen_platform_pci=0

Thanks,

Sander

> In the config file i use:
>  disk = [ 'phy:/dev/xen_vms/testvm,hda,w' ]

> --
> Sander

>> From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
>> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date: Tue, 26 Nov 2013 15:05:40 -0500
>> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.

>> *TODO*

>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  drivers/block/xen-blkfront.c               |  2 +-
>>  drivers/input/misc/xen-kbdfront.c          |  4 ++++
>>  drivers/net/xen-netfront.c                 |  2 +-
>>  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
>>  include/xen/platform_pci.h                 | 13 +++++++++++++
>>  5 files changed, 20 insertions(+), 3 deletions(-)

>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 432db1b..bcbaf0b 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>>         if (!xen_domain())
>>                 return -ENODEV;
>>  
>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>> +       if (xen_err_out())
>>                 return -ENODEV;
>>  
>>         if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>> index e21c181..9d250cf 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -29,6 +29,7 @@
>>  #include <xen/interface/io/fbif.h>
>>  #include <xen/interface/io/kbdif.h>
>>  #include <xen/xenbus.h>
>> +#include <xen/platform_pci.h>
>>  
>>  struct xenkbd_info {
>>         struct input_dev *kbd;
>> @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
>>         if (xen_initial_domain())
>>                 return -ENODEV;
>>  
>> +       if (xen_err_out())
>> +               return -ENODEV;
>> +
>>         return xenbus_register_frontend(&xenkbd_driver);
>>  }
>>  
>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> index e59acb1..be2744b 100644
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
>> @@ -2115,7 +2115,7 @@ static int __init netif_init(void)
>>         if (!xen_domain())
>>                 return -ENODEV;
>>  
>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>> +       if (xen_err_out())
>>                 return -ENODEV;
>>  
>>         pr_info("Initialising Xen virtual ethernet driver\n");
>> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
>> index 129bf84..b1c0f2a 100644
>> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
>> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
>> @@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
>>  #ifndef MODULE
>>  static int __init boot_wait_for_devices(void)
>>  {
>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>> +       if (xen_err_out())
>>                 return -ENODEV;
>>  
>>         ready_to_wait_for_devices = 1;
>> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
>> index 438c256..a5bbd0b 100644
>> --- a/include/xen/platform_pci.h
>> +++ b/include/xen/platform_pci.h
>> @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
>>  }
>>  
>>  extern int xen_platform_pci_unplug;
>> +static  bool xen_err_out(void)
>> +{
>>  
>> +       if (!xen_domain())
>> +               return true;
>> +
>> +       if (xen_hvm_domain()) {
>> +               if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
>> +                       return true;
>> +               if (xen_platform_pci_unplug == 0)
>> +                       return true;
>> +       }
>> +       return false;
>> +}
>>  #endif /* _XEN_PLATFORM_PCI_H */

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Konrad Rzeszutek Wilk]

Sander Eikelenboom <linux@eikelenboom.it> wrote:
>
>Tuesday, November 26, 2013, 11:00:15 PM, you wrote:
>
>
>> Tuesday, November 26, 2013, 9:08:47 PM, you wrote:
>
>>> On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
>>>> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
>>>> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
>>>> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
>>>> > > > Hello,
>>>> > > > 
>>>> > > > Let me bring some new life to this discussion.
>>>> > > > 
>>>> > > > I've investigated a bit and found another way to make 
>kernels starting 
>>>> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
>>>> > > > Reverting of
>xen-grant-table-correctly-initialize-grant-table-version-1 
>>>> > > > patch is not necessary.
>>>> > > > 
>>>> > > > We can simply modify struct pci_device_id platform_pci_tbl[]
>(in 
>>>> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device
>ids.
>>>> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly,
>disks and 
>>>> > > > network are also recognized.
>>>> > > 
>>>> > > I think this is just working around the problem, by avoiding
>the
>>>> > > situation where the error occurs. You could just as well switch
>to
>>>> > > platform device id < 2.
>>>> > 
>>>> > I am bit late to this discussion - but shouldn't there be
>something
>>>> > in the kernel to deal with this?
>>>> 
>>>> Well, ideally the kernel wouldn't crash ;-)
>
>>> This patch should solve that (untested, but at least compile
>tested):
>>> Please test it.
>
>> Hi Konrad,
>
>> I just gave it a shot on qemu-xen-traditional (since support for
>xen_platform_pci=0 is not upstream (yet))
>> It doesn't crash anymore on boot, but the guest now doesn't have any
>disks, so it ends in busybox because it can't find a root partition.
>> I would have expected it to be using qemu emulated disks now, but a
>"cat /proc/partitions" in busybox shows nothing.
>> But that's perhaps qemu code ejecting the emulated disks anyhow ...
>
>Hi Konrad,
>
>With the linux PATA modules compiled in it now also boots fine with
>qemu-xen-traditional and xen_platform_pci=0

Wohoooo! I will be tack on Tested and Reported by tag on it.

Thank you for quick testing!
>
>Thanks,
>
>Sander
>
>> In the config file i use:
>>  disk = [ 'phy:/dev/xen_vms/testvm,hda,w' ]
>
>> --
>> Sander
>
>>> From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00
>2001
>>> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date: Tue, 26 Nov 2013 15:05:40 -0500
>>> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow
>up.
>
>>> *TODO*
>
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>  drivers/block/xen-blkfront.c               |  2 +-
>>>  drivers/input/misc/xen-kbdfront.c          |  4 ++++
>>>  drivers/net/xen-netfront.c                 |  2 +-
>>>  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
>>>  include/xen/platform_pci.h                 | 13 +++++++++++++
>>>  5 files changed, 20 insertions(+), 3 deletions(-)
>
>>> diff --git a/drivers/block/xen-blkfront.c
>b/drivers/block/xen-blkfront.c
>>> index 432db1b..bcbaf0b 100644
>>> --- a/drivers/block/xen-blkfront.c
>>> +++ b/drivers/block/xen-blkfront.c
>>> @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>>>         if (!xen_domain())
>>>                 return -ENODEV;
>>>  
>>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>>> +       if (xen_err_out())
>>>                 return -ENODEV;
>>>  
>>>         if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
>>> diff --git a/drivers/input/misc/xen-kbdfront.c
>b/drivers/input/misc/xen-kbdfront.c
>>> index e21c181..9d250cf 100644
>>> --- a/drivers/input/misc/xen-kbdfront.c
>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>> @@ -29,6 +29,7 @@
>>>  #include <xen/interface/io/fbif.h>
>>>  #include <xen/interface/io/kbdif.h>
>>>  #include <xen/xenbus.h>
>>> +#include <xen/platform_pci.h>
>>>  
>>>  struct xenkbd_info {
>>>         struct input_dev *kbd;
>>> @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
>>>         if (xen_initial_domain())
>>>                 return -ENODEV;
>>>  
>>> +       if (xen_err_out())
>>> +               return -ENODEV;
>>> +
>>>         return xenbus_register_frontend(&xenkbd_driver);
>>>  }
>>>  
>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>> index e59acb1..be2744b 100644
>>> --- a/drivers/net/xen-netfront.c
>>> +++ b/drivers/net/xen-netfront.c
>>> @@ -2115,7 +2115,7 @@ static int __init netif_init(void)
>>>         if (!xen_domain())
>>>                 return -ENODEV;
>>>  
>>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>>> +       if (xen_err_out())
>>>                 return -ENODEV;
>>>  
>>>         pr_info("Initialising Xen virtual ethernet driver\n");
>>> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c
>b/drivers/xen/xenbus/xenbus_probe_frontend.c
>>> index 129bf84..b1c0f2a 100644
>>> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
>>> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
>>> @@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
>>>  #ifndef MODULE
>>>  static int __init boot_wait_for_devices(void)
>>>  {
>>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>>> +       if (xen_err_out())
>>>                 return -ENODEV;
>>>  
>>>         ready_to_wait_for_devices = 1;
>>> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
>>> index 438c256..a5bbd0b 100644
>>> --- a/include/xen/platform_pci.h
>>> +++ b/include/xen/platform_pci.h
>>> @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
>>>  }
>>>  
>>>  extern int xen_platform_pci_unplug;
>>> +static  bool xen_err_out(void)
>>> +{
>>>  
>>> +       if (!xen_domain())
>>> +               return true;
>>> +
>>> +       if (xen_hvm_domain()) {
>>> +               if (xen_platform_pci_unplug &
>(XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
>>> +                       return true;
>>> +               if (xen_platform_pci_unplug == 0)
>>> +                       return true;
>>> +       }
>>> +       return false;
>>> +}
>>>  #endif /* _XEN_PLATFORM_PCI_H */

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Wednesday, November 27, 2013, 12:05:01 AM, you wrote:

> Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>
>>Tuesday, November 26, 2013, 11:00:15 PM, you wrote:
>>
>>
>>> Tuesday, November 26, 2013, 9:08:47 PM, you wrote:
>>
>>>> On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
>>>>> On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
>>>>> > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
>>>>> > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
>>>>> > > > Hello,
>>>>> > > > 
>>>>> > > > Let me bring some new life to this discussion.
>>>>> > > > 
>>>>> > > > I've investigated a bit and found another way to make 
>>kernels starting 
>>>>> > > > from 3.8.x to boot on the VMs with platform device_id 0002.
>>>>> > > > Reverting of
>>xen-grant-table-correctly-initialize-grant-table-version-1 
>>>>> > > > patch is not necessary.
>>>>> > > > 
>>>>> > > > We can simply modify struct pci_device_id platform_pci_tbl[]
>>(in 
>>>>> > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device
>>ids.
>>>>> > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly,
>>disks and 
>>>>> > > > network are also recognized.
>>>>> > > 
>>>>> > > I think this is just working around the problem, by avoiding
>>the
>>>>> > > situation where the error occurs. You could just as well switch
>>to
>>>>> > > platform device id < 2.
>>>>> > 
>>>>> > I am bit late to this discussion - but shouldn't there be
>>something
>>>>> > in the kernel to deal with this?
>>>>> 
>>>>> Well, ideally the kernel wouldn't crash ;-)
>>
>>>> This patch should solve that (untested, but at least compile
>>tested):
>>>> Please test it.
>>
>>> Hi Konrad,
>>
>>> I just gave it a shot on qemu-xen-traditional (since support for
>>xen_platform_pci=0 is not upstream (yet))
>>> It doesn't crash anymore on boot, but the guest now doesn't have any
>>disks, so it ends in busybox because it can't find a root partition.
>>> I would have expected it to be using qemu emulated disks now, but a
>>"cat /proc/partitions" in busybox shows nothing.
>>> But that's perhaps qemu code ejecting the emulated disks anyhow ...
>>
>>Hi Konrad,
>>
>>With the linux PATA modules compiled in it now also boots fine with
>>qemu-xen-traditional and xen_platform_pci=0

> Wohoooo! I will be tack on Tested and Reported by tag on it.

> Thank you for quick testing!

Thanks , don't know if you want to consider it for stable as well, seems to be since the 3.8 series ..

--
Sander

>>
>>Thanks,
>>
>>Sander
>>
>>> In the config file i use:
>>>  disk = [ 'phy:/dev/xen_vms/testvm,hda,w' ]
>>
>>> --
>>> Sander
>>
>>>> From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00
>>2001
>>>> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Date: Tue, 26 Nov 2013 15:05:40 -0500
>>>> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow
>>up.
>>
>>>> *TODO*
>>
>>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> ---
>>>>  drivers/block/xen-blkfront.c               |  2 +-
>>>>  drivers/input/misc/xen-kbdfront.c          |  4 ++++
>>>>  drivers/net/xen-netfront.c                 |  2 +-
>>>>  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
>>>>  include/xen/platform_pci.h                 | 13 +++++++++++++
>>>>  5 files changed, 20 insertions(+), 3 deletions(-)
>>
>>>> diff --git a/drivers/block/xen-blkfront.c
>>b/drivers/block/xen-blkfront.c
>>>> index 432db1b..bcbaf0b 100644
>>>> --- a/drivers/block/xen-blkfront.c
>>>> +++ b/drivers/block/xen-blkfront.c
>>>> @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>>>>         if (!xen_domain())
>>>>                 return -ENODEV;
>>>>  
>>>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>>>> +       if (xen_err_out())
>>>>                 return -ENODEV;
>>>>  
>>>>         if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
>>>> diff --git a/drivers/input/misc/xen-kbdfront.c
>>b/drivers/input/misc/xen-kbdfront.c
>>>> index e21c181..9d250cf 100644
>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>> @@ -29,6 +29,7 @@
>>>>  #include <xen/interface/io/fbif.h>
>>>>  #include <xen/interface/io/kbdif.h>
>>>>  #include <xen/xenbus.h>
>>>> +#include <xen/platform_pci.h>
>>>>  
>>>>  struct xenkbd_info {
>>>>         struct input_dev *kbd;
>>>> @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
>>>>         if (xen_initial_domain())
>>>>                 return -ENODEV;
>>>>  
>>>> +       if (xen_err_out())
>>>> +               return -ENODEV;
>>>> +
>>>>         return xenbus_register_frontend(&xenkbd_driver);
>>>>  }
>>>>  
>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>>> index e59acb1..be2744b 100644
>>>> --- a/drivers/net/xen-netfront.c
>>>> +++ b/drivers/net/xen-netfront.c
>>>> @@ -2115,7 +2115,7 @@ static int __init netif_init(void)
>>>>         if (!xen_domain())
>>>>                 return -ENODEV;
>>>>  
>>>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>>>> +       if (xen_err_out())
>>>>                 return -ENODEV;
>>>>  
>>>>         pr_info("Initialising Xen virtual ethernet driver\n");
>>>> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c
>>b/drivers/xen/xenbus/xenbus_probe_frontend.c
>>>> index 129bf84..b1c0f2a 100644
>>>> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
>>>> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
>>>> @@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
>>>>  #ifndef MODULE
>>>>  static int __init boot_wait_for_devices(void)
>>>>  {
>>>> -       if (xen_hvm_domain() && !xen_platform_pci_unplug)
>>>> +       if (xen_err_out())
>>>>                 return -ENODEV;
>>>>  
>>>>         ready_to_wait_for_devices = 1;
>>>> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
>>>> index 438c256..a5bbd0b 100644
>>>> --- a/include/xen/platform_pci.h
>>>> +++ b/include/xen/platform_pci.h
>>>> @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
>>>>  }
>>>>  
>>>>  extern int xen_platform_pci_unplug;
>>>> +static  bool xen_err_out(void)
>>>> +{
>>>>  
>>>> +       if (!xen_domain())
>>>> +               return true;
>>>> +
>>>> +       if (xen_hvm_domain()) {
>>>> +               if (xen_platform_pci_unplug &
>>(XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
>>>> +                       return true;
>>>> +               if (xen_platform_pci_unplug == 0)
>>>> +                       return true;
>>>> +       }
>>>> +       return false;
>>>> +}
>>>>  #endif /* _XEN_PLATFORM_PCI_H */

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Tue, 2013-11-26 at 15:08 -0500, Konrad Rzeszutek Wilk wrote:
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 432db1b..bcbaf0b 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> +	if (xen_err_out())

I think !xen_has_pv_devices() or some such would be a better name.
> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> index 438c256..a5bbd0b 100644
> --- a/include/xen/platform_pci.h
> +++ b/include/xen/platform_pci.h
> @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
>  }
>  
>  extern int xen_platform_pci_unplug;
> +static  bool xen_err_out(void)

         ^ stray space, but I think you wanted an inline here anyway?

Or you could move this to arch/x86/xen/platform-pci-unplug.c and then
xen_platform_pci_unplug could be unexported, which seems like a good
thing to do if the logic to using it is as complex as below.

> +{
>  
> +	if (!xen_domain())
> +		return true;
> +
> +	if (xen_hvm_domain()) {
> +		if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
> +			return true;
> +		if (xen_platform_pci_unplug == 0)
> +			return true;

There are some cases where xen_unplug_emulated_devices doesn't update
xen_platform_pci_unplug, specifically when xen_emul_unplug contains
UNNECESSARY or NEVER. I think the above logic covers that case but it
might be simpler to always set it? At that point on the first if is
necessary?

> +	}
> +	return false;
> +}
>  #endif /* _XEN_PLATFORM_PCI_H */

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Konrad Rzeszutek Wilk]

On Wed, Nov 27, 2013 at 09:36:55AM +0000, Ian Campbell wrote:
> On Tue, 2013-11-26 at 15:08 -0500, Konrad Rzeszutek Wilk wrote:
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 432db1b..bcbaf0b 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> > -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> > +	if (xen_err_out())
> 
> I think !xen_has_pv_devices() or some such would be a better name.

<nods>
> > diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> > index 438c256..a5bbd0b 100644
> > --- a/include/xen/platform_pci.h
> > +++ b/include/xen/platform_pci.h
> > @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
> >  }
> >  
> >  extern int xen_platform_pci_unplug;
> > +static  bool xen_err_out(void)
> 
>          ^ stray space, but I think you wanted an inline here anyway?

Yup.
> 
> Or you could move this to arch/x86/xen/platform-pci-unplug.c and then
> xen_platform_pci_unplug could be unexported, which seems like a good
> thing to do if the logic to using it is as complex as below.

I was thinking about it - but then there is a bit of a problem with
!CONFIG_PVHVM && CONFIG_XEN_BLKFRONT for example. Which means that
platform-pci-unplug.c won't be built, but the xen-blkfront will and
it needs the xen_has_pv_devices()). Hence sticking it in a header.

> 
> > +{
> >  
> > +	if (!xen_domain())
> > +		return true;
> > +
> > +	if (xen_hvm_domain()) {
> > +		if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
> > +			return true;
> > +		if (xen_platform_pci_unplug == 0)
> > +			return true;
> 
> There are some cases where xen_unplug_emulated_devices doesn't update
> xen_platform_pci_unplug, specifically when xen_emul_unplug contains
> UNNECESSARY or NEVER. I think the above logic covers that case but it
> might be simpler to always set it? At that point on the first if is
> necessary?

<nods>

Thanks for your review!
> 
> > +	}
> > +	return false;
> > +}
> >  #endif /* _XEN_PLATFORM_PCI_H */
> 
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Ian Campbell]

On Wed, 2013-11-27 at 09:24 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 27, 2013 at 09:36:55AM +0000, Ian Campbell wrote:
> > On Tue, 2013-11-26 at 15:08 -0500, Konrad Rzeszutek Wilk wrote:
> > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > > index 432db1b..bcbaf0b 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
> > >  	if (!xen_domain())
> > >  		return -ENODEV;
> > >  
> > > -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> > > +	if (xen_err_out())
> > 
> > I think !xen_has_pv_devices() or some such would be a better name.
> 
> <nods>
> > > diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> > > index 438c256..a5bbd0b 100644
> > > --- a/include/xen/platform_pci.h
> > > +++ b/include/xen/platform_pci.h
> > > @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
> > >  }
> > >  
> > >  extern int xen_platform_pci_unplug;
> > > +static  bool xen_err_out(void)
> > 
> >          ^ stray space, but I think you wanted an inline here anyway?
> 
> Yup.
> > 
> > Or you could move this to arch/x86/xen/platform-pci-unplug.c and then
> > xen_platform_pci_unplug could be unexported, which seems like a good
> > thing to do if the logic to using it is as complex as below.
> 
> I was thinking about it - but then there is a bit of a problem with
> !CONFIG_PVHVM && CONFIG_XEN_BLKFRONT for example. Which means that
> platform-pci-unplug.c won't be built, but the xen-blkfront will and
> it needs the xen_has_pv_devices()). Hence sticking it in a header.

Is that not just a case of #define xen_has_pc_devices 1 with the
appropriate ifndef CONFIG_PVHVM in the header (the other case being the
prototype for the out of line version)? That's a pretty common pattern
for things which rely on a patricular CONFIG_FOO to be useful.

Ian.

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Konrad Rzeszutek Wilk]

On Wed, Nov 27, 2013 at 03:58:55PM +0000, Ian Campbell wrote:
> On Wed, 2013-11-27 at 09:24 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 27, 2013 at 09:36:55AM +0000, Ian Campbell wrote:
> > > On Tue, 2013-11-26 at 15:08 -0500, Konrad Rzeszutek Wilk wrote:
> > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > > > index 432db1b..bcbaf0b 100644
> > > > --- a/drivers/block/xen-blkfront.c
> > > > +++ b/drivers/block/xen-blkfront.c
> > > > @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
> > > >  	if (!xen_domain())
> > > >  		return -ENODEV;
> > > >  
> > > > -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> > > > +	if (xen_err_out())
> > > 
> > > I think !xen_has_pv_devices() or some such would be a better name.
> > 
> > <nods>
> > > > diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> > > > index 438c256..a5bbd0b 100644
> > > > --- a/include/xen/platform_pci.h
> > > > +++ b/include/xen/platform_pci.h
> > > > @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
> > > >  }
> > > >  
> > > >  extern int xen_platform_pci_unplug;
> > > > +static  bool xen_err_out(void)
> > > 
> > >          ^ stray space, but I think you wanted an inline here anyway?
> > 
> > Yup.
> > > 
> > > Or you could move this to arch/x86/xen/platform-pci-unplug.c and then
> > > xen_platform_pci_unplug could be unexported, which seems like a good
> > > thing to do if the logic to using it is as complex as below.
> > 
> > I was thinking about it - but then there is a bit of a problem with
> > !CONFIG_PVHVM && CONFIG_XEN_BLKFRONT for example. Which means that
> > platform-pci-unplug.c won't be built, but the xen-blkfront will and
> > it needs the xen_has_pv_devices()). Hence sticking it in a header.
> 
> Is that not just a case of #define xen_has_pc_devices 1 with the
> appropriate ifndef CONFIG_PVHVM in the header (the other case being the
> prototype for the out of line version)? That's a pretty common pattern
> for things which rely on a patricular CONFIG_FOO to be useful.

Yes. That would do it too (duh!)
> 
> Ian.
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Stefano Stabellini]

On Tue, 26 Nov 2013, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
> > On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> > > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > > > > Hello,
> > > > > 
> > > > > Let me bring some new life to this discussion.
> > > > > 
> > > > > I've investigated a bit and found another way to make  kernels starting 
> > > > > from 3.8.x to boot on the VMs with platform device_id 0002.
> > > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > > > > patch is not necessary.
> > > > > 
> > > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > > > > network are also recognized.
> > > > 
> > > > I think this is just working around the problem, by avoiding the
> > > > situation where the error occurs. You could just as well switch to
> > > > platform device id < 2.
> > > 
> > > I am bit late to this discussion - but shouldn't there be something
> > > in the kernel to deal with this?
> > 
> > Well, ideally the kernel wouldn't crash ;-)
> 
> This patch should solve that (untested, but at least compile tested):
> Please test it.
> 
> >From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Tue, 26 Nov 2013 15:05:40 -0500
> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
> 
> *TODO*
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkfront.c               |  2 +-
>  drivers/input/misc/xen-kbdfront.c          |  4 ++++
>  drivers/net/xen-netfront.c                 |  2 +-
>  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
>  include/xen/platform_pci.h                 | 13 +++++++++++++
>  5 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 432db1b..bcbaf0b 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> +	if (xen_err_out())
>  		return -ENODEV;
>  
>  	if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index e21c181..9d250cf 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -29,6 +29,7 @@
>  #include <xen/interface/io/fbif.h>
>  #include <xen/interface/io/kbdif.h>
>  #include <xen/xenbus.h>
> +#include <xen/platform_pci.h>
>  
>  struct xenkbd_info {
>  	struct input_dev *kbd;
> @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
>  	if (xen_initial_domain())
>  		return -ENODEV;
>  
> +	if (xen_err_out())
> +		return -ENODEV;

Why do we error out here? There is nothing to unplug in this case.


>  	return xenbus_register_frontend(&xenkbd_driver);
>  }
>  
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index e59acb1..be2744b 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -2115,7 +2115,7 @@ static int __init netif_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> +	if (xen_err_out())
>  		return -ENODEV;
>  
>  	pr_info("Initialising Xen virtual ethernet driver\n");
> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> index 129bf84..b1c0f2a 100644
> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
>  #ifndef MODULE
>  static int __init boot_wait_for_devices(void)
>  {
> -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> +	if (xen_err_out())
>  		return -ENODEV;
>  
>  	ready_to_wait_for_devices = 1;
> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> index 438c256..a5bbd0b 100644
> --- a/include/xen/platform_pci.h
> +++ b/include/xen/platform_pci.h
> @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
>  }
>  
>  extern int xen_platform_pci_unplug;
> +static  bool xen_err_out(void)
> +{

static inline


> +	if (!xen_domain())
> +		return true;
> +
> +	if (xen_hvm_domain()) {
> +		if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))

This check wasn't present before and I don't think should be present
now: xen_platform_pci_unplug cannot be set to XEN_UNPLUG_NEVER, see the
beginning of xen_unplug_emulated_devices. Also XEN_UNPLUG_UNNECESSARY is
meant to say that the user knows what she is doing and no unplug is
necessary to safely use PV drivers, see the commit message of
1dc7ce99b091a11cce0f34456c1ffcb928f17edd.


> +			return true;
> +		if (xen_platform_pci_unplug == 0)
> +			return true;
> +	}
> +	return false;
> +}
>  #endif /* _XEN_PLATFORM_PCI_H */

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Konrad Rzeszutek Wilk]

On Thu, Nov 28, 2013 at 02:56:53PM +0000, Stefano Stabellini wrote:
> On Tue, 26 Nov 2013, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
> > > On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> > > > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > Let me bring some new life to this discussion.
> > > > > > 
> > > > > > I've investigated a bit and found another way to make  kernels starting 
> > > > > > from 3.8.x to boot on the VMs with platform device_id 0002.
> > > > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > > > > > patch is not necessary.
> > > > > > 
> > > > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > > > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > > > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > > > > > network are also recognized.
> > > > > 
> > > > > I think this is just working around the problem, by avoiding the
> > > > > situation where the error occurs. You could just as well switch to
> > > > > platform device id < 2.
> > > > 
> > > > I am bit late to this discussion - but shouldn't there be something
> > > > in the kernel to deal with this?
> > > 
> > > Well, ideally the kernel wouldn't crash ;-)
> > 
> > This patch should solve that (untested, but at least compile tested):
> > Please test it.
> > 
> > >From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Tue, 26 Nov 2013 15:05:40 -0500
> > Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
> > 
> > *TODO*
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/block/xen-blkfront.c               |  2 +-
> >  drivers/input/misc/xen-kbdfront.c          |  4 ++++
> >  drivers/net/xen-netfront.c                 |  2 +-
> >  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
> >  include/xen/platform_pci.h                 | 13 +++++++++++++
> >  5 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 432db1b..bcbaf0b 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> > -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> > +	if (xen_err_out())
> >  		return -ENODEV;
> >  
> >  	if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
> > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> > index e21c181..9d250cf 100644
> > --- a/drivers/input/misc/xen-kbdfront.c
> > +++ b/drivers/input/misc/xen-kbdfront.c
> > @@ -29,6 +29,7 @@
> >  #include <xen/interface/io/fbif.h>
> >  #include <xen/interface/io/kbdif.h>
> >  #include <xen/xenbus.h>
> > +#include <xen/platform_pci.h>
> >  
> >  struct xenkbd_info {
> >  	struct input_dev *kbd;
> > @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
> >  	if (xen_initial_domain())
> >  		return -ENODEV;
> >  
> > +	if (xen_err_out())
> > +		return -ENODEV;
> 
> Why do we error out here? There is nothing to unplug in this case.

B/c otherwise the driver blows up when it acts on the XenBus and tries
to setup a grant. But the grant is initialized by the xen-platform-pci
which is not run.
> 
> 
> >  	return xenbus_register_frontend(&xenkbd_driver);
> >  }
> >  
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index e59acb1..be2744b 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -2115,7 +2115,7 @@ static int __init netif_init(void)
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> > -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> > +	if (xen_err_out())
> >  		return -ENODEV;
> >  
> >  	pr_info("Initialising Xen virtual ethernet driver\n");
> > diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> > index 129bf84..b1c0f2a 100644
> > --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> > +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> > @@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
> >  #ifndef MODULE
> >  static int __init boot_wait_for_devices(void)
> >  {
> > -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> > +	if (xen_err_out())
> >  		return -ENODEV;
> >  
> >  	ready_to_wait_for_devices = 1;
> > diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> > index 438c256..a5bbd0b 100644
> > --- a/include/xen/platform_pci.h
> > +++ b/include/xen/platform_pci.h
> > @@ -47,5 +47,18 @@ static inline int xen_must_unplug_disks(void) {
> >  }
> >  
> >  extern int xen_platform_pci_unplug;
> > +static  bool xen_err_out(void)
> > +{
> 
> static inline
> 
> 
> > +	if (!xen_domain())
> > +		return true;
> > +
> > +	if (xen_hvm_domain()) {
> > +		if (xen_platform_pci_unplug & (XEN_UNPLUG_UNNECESSARY | XEN_UNPLUG_NEVER))
> 
> This check wasn't present before and I don't think should be present
> now: xen_platform_pci_unplug cannot be set to XEN_UNPLUG_NEVER, see the
> beginning of xen_unplug_emulated_devices. Also XEN_UNPLUG_UNNECESSARY is
> meant to say that the user knows what she is doing and no unplug is
> necessary to safely use PV drivers, see the commit message of
> 1dc7ce99b091a11cce0f34456c1ffcb928f17edd.
> 
> 
> > +			return true;
> > +		if (xen_platform_pci_unplug == 0)
> > +			return true;
> > +	}
> > +	return false;
> > +}
> >  #endif /* _XEN_PLATFORM_PCI_H */
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Stefano Stabellini]

On Thu, 28 Nov 2013, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 28, 2013 at 02:56:53PM +0000, Stefano Stabellini wrote:
> > On Tue, 26 Nov 2013, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
> > > > On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> > > > > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > Let me bring some new life to this discussion.
> > > > > > > 
> > > > > > > I've investigated a bit and found another way to make  kernels starting 
> > > > > > > from 3.8.x to boot on the VMs with platform device_id 0002.
> > > > > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> > > > > > > patch is not necessary.
> > > > > > > 
> > > > > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> > > > > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> > > > > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> > > > > > > network are also recognized.
> > > > > > 
> > > > > > I think this is just working around the problem, by avoiding the
> > > > > > situation where the error occurs. You could just as well switch to
> > > > > > platform device id < 2.
> > > > > 
> > > > > I am bit late to this discussion - but shouldn't there be something
> > > > > in the kernel to deal with this?
> > > > 
> > > > Well, ideally the kernel wouldn't crash ;-)
> > > 
> > > This patch should solve that (untested, but at least compile tested):
> > > Please test it.
> > > 
> > > >From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
> > > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Date: Tue, 26 Nov 2013 15:05:40 -0500
> > > Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
> > > 
> > > *TODO*
> > > 
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/block/xen-blkfront.c               |  2 +-
> > >  drivers/input/misc/xen-kbdfront.c          |  4 ++++
> > >  drivers/net/xen-netfront.c                 |  2 +-
> > >  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
> > >  include/xen/platform_pci.h                 | 13 +++++++++++++
> > >  5 files changed, 20 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > > index 432db1b..bcbaf0b 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
> > >  	if (!xen_domain())
> > >  		return -ENODEV;
> > >  
> > > -	if (xen_hvm_domain() && !xen_platform_pci_unplug)
> > > +	if (xen_err_out())
> > >  		return -ENODEV;
> > >  
> > >  	if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
> > > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> > > index e21c181..9d250cf 100644
> > > --- a/drivers/input/misc/xen-kbdfront.c
> > > +++ b/drivers/input/misc/xen-kbdfront.c
> > > @@ -29,6 +29,7 @@
> > >  #include <xen/interface/io/fbif.h>
> > >  #include <xen/interface/io/kbdif.h>
> > >  #include <xen/xenbus.h>
> > > +#include <xen/platform_pci.h>
> > >  
> > >  struct xenkbd_info {
> > >  	struct input_dev *kbd;
> > > @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
> > >  	if (xen_initial_domain())
> > >  		return -ENODEV;
> > >  
> > > +	if (xen_err_out())
> > > +		return -ENODEV;
> > 
> > Why do we error out here? There is nothing to unplug in this case.
> 
> B/c otherwise the driver blows up when it acts on the XenBus and tries
> to setup a grant. But the grant is initialized by the xen-platform-pci
> which is not run.

I see. Adding this check must be the real purpose of the patch then?
In that case don't we need another check like this one in:

drivers/char/tpm/xen-tpmfront.c:xen_tpmfront_init
drivers/pci/xen-pcifront.c:pcifront_init

and for consistency (it doesn't use grants right now)

drivers/video/xen-fbfront.c:xenfb_init

?

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Sander Eikelenboom]

Friday, November 29, 2013, 12:54:16 PM, you wrote:

> On Thu, 28 Nov 2013, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 28, 2013 at 02:56:53PM +0000, Stefano Stabellini wrote:
>> > On Tue, 26 Nov 2013, Konrad Rzeszutek Wilk wrote:
>> > > On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
>> > > > On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
>> > > > > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
>> > > > > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
>> > > > > > > Hello,
>> > > > > > > 
>> > > > > > > Let me bring some new life to this discussion.
>> > > > > > > 
>> > > > > > > I've investigated a bit and found another way to make  kernels starting 
>> > > > > > > from 3.8.x to boot on the VMs with platform device_id 0002.
>> > > > > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
>> > > > > > > patch is not necessary.
>> > > > > > > 
>> > > > > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
>> > > > > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
>> > > > > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
>> > > > > > > network are also recognized.
>> > > > > > 
>> > > > > > I think this is just working around the problem, by avoiding the
>> > > > > > situation where the error occurs. You could just as well switch to
>> > > > > > platform device id < 2.
>> > > > > 
>> > > > > I am bit late to this discussion - but shouldn't there be something
>> > > > > in the kernel to deal with this?
>> > > > 
>> > > > Well, ideally the kernel wouldn't crash ;-)
>> > > 
>> > > This patch should solve that (untested, but at least compile tested):
>> > > Please test it.
>> > > 
>> > > >From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
>> > > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> > > Date: Tue, 26 Nov 2013 15:05:40 -0500
>> > > Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
>> > > 
>> > > *TODO*
>> > > 
>> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> > > ---
>> > >  drivers/block/xen-blkfront.c               |  2 +-
>> > >  drivers/input/misc/xen-kbdfront.c          |  4 ++++
>> > >  drivers/net/xen-netfront.c                 |  2 +-
>> > >  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
>> > >  include/xen/platform_pci.h                 | 13 +++++++++++++
>> > >  5 files changed, 20 insertions(+), 3 deletions(-)
>> > > 
>> > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> > > index 432db1b..bcbaf0b 100644
>> > > --- a/drivers/block/xen-blkfront.c
>> > > +++ b/drivers/block/xen-blkfront.c
>> > > @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
>> > >          if (!xen_domain())
>> > >           return -ENODEV;
>> > >  
>> > > -        if (xen_hvm_domain() && !xen_platform_pci_unplug)
>> > > +        if (xen_err_out())
>> > >           return -ENODEV;
>> > >  
>> > >          if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
>> > > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>> > > index e21c181..9d250cf 100644
>> > > --- a/drivers/input/misc/xen-kbdfront.c
>> > > +++ b/drivers/input/misc/xen-kbdfront.c
>> > > @@ -29,6 +29,7 @@
>> > >  #include <xen/interface/io/fbif.h>
>> > >  #include <xen/interface/io/kbdif.h>
>> > >  #include <xen/xenbus.h>
>> > > +#include <xen/platform_pci.h>
>> > >  
>> > >  struct xenkbd_info {
>> > >          struct input_dev *kbd;
>> > > @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
>> > >          if (xen_initial_domain())
>> > >           return -ENODEV;
>> > >  
>> > > +        if (xen_err_out())
>> > > +         return -ENODEV;
>> > 
>> > Why do we error out here? There is nothing to unplug in this case.
>> 
>> B/c otherwise the driver blows up when it acts on the XenBus and tries
>> to setup a grant. But the grant is initialized by the xen-platform-pci
>> which is not run.

> I see. Adding this check must be the real purpose of the patch then?
> In that case don't we need another check like this one in:

> drivers/char/tpm/xen-tpmfront.c:xen_tpmfront_init
> drivers/pci/xen-pcifront.c:pcifront_init

> and for consistency (it doesn't use grants right now)

> drivers/video/xen-fbfront.c:xenfb_init

> ?


Hi Konrad / Stefano,

Is there any follow up on this ?

--
Sander

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Konrad Rzeszutek Wilk]

On Mon, Dec 09, 2013 at 01:57:37PM +0100, Sander Eikelenboom wrote:
> 
> Friday, November 29, 2013, 12:54:16 PM, you wrote:
> 
> > On Thu, 28 Nov 2013, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Nov 28, 2013 at 02:56:53PM +0000, Stefano Stabellini wrote:
> >> > On Tue, 26 Nov 2013, Konrad Rzeszutek Wilk wrote:
> >> > > On Wed, Nov 13, 2013 at 09:40:58AM +0000, Ian Campbell wrote:
> >> > > > On Tue, 2013-11-12 at 10:56 -0500, Konrad Rzeszutek Wilk wrote:
> >> > > > > On Thu, Nov 07, 2013 at 01:47:03PM +0000, Ian Campbell wrote:
> >> > > > > > On Thu, 2013-11-07 at 09:20 +0400, Astarta wrote:
> >> > > > > > > Hello,
> >> > > > > > > 
> >> > > > > > > Let me bring some new life to this discussion.
> >> > > > > > > 
> >> > > > > > > I've investigated a bit and found another way to make  kernels starting 
> >> > > > > > > from 3.8.x to boot on the VMs with platform device_id 0002.
> >> > > > > > > Reverting of xen-grant-table-correctly-initialize-grant-table-version-1 
> >> > > > > > > patch is not necessary.
> >> > > > > > > 
> >> > > > > > > We can simply modify struct pci_device_id platform_pci_tbl[] (in 
> >> > > > > > > drivers/xen/platform-pci.c) to respect 0002 and 0000 device ids.
> >> > > > > > > That makes the kernel (3.8.x and 3.11.6) to boot correctly, disks and 
> >> > > > > > > network are also recognized.
> >> > > > > > 
> >> > > > > > I think this is just working around the problem, by avoiding the
> >> > > > > > situation where the error occurs. You could just as well switch to
> >> > > > > > platform device id < 2.
> >> > > > > 
> >> > > > > I am bit late to this discussion - but shouldn't there be something
> >> > > > > in the kernel to deal with this?
> >> > > > 
> >> > > > Well, ideally the kernel wouldn't crash ;-)
> >> > > 
> >> > > This patch should solve that (untested, but at least compile tested):
> >> > > Please test it.
> >> > > 
> >> > > >From f7d3581aa19a35ea3ff10b965b2b08843e923635 Mon Sep 17 00:00:00 2001
> >> > > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> > > Date: Tue, 26 Nov 2013 15:05:40 -0500
> >> > > Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
> >> > > 
> >> > > *TODO*
> >> > > 
> >> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> > > ---
> >> > >  drivers/block/xen-blkfront.c               |  2 +-
> >> > >  drivers/input/misc/xen-kbdfront.c          |  4 ++++
> >> > >  drivers/net/xen-netfront.c                 |  2 +-
> >> > >  drivers/xen/xenbus/xenbus_probe_frontend.c |  2 +-
> >> > >  include/xen/platform_pci.h                 | 13 +++++++++++++
> >> > >  5 files changed, 20 insertions(+), 3 deletions(-)
> >> > > 
> >> > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >> > > index 432db1b..bcbaf0b 100644
> >> > > --- a/drivers/block/xen-blkfront.c
> >> > > +++ b/drivers/block/xen-blkfront.c
> >> > > @@ -2074,7 +2074,7 @@ static int __init xlblk_init(void)
> >> > >          if (!xen_domain())
> >> > >           return -ENODEV;
> >> > >  
> >> > > -        if (xen_hvm_domain() && !xen_platform_pci_unplug)
> >> > > +        if (xen_err_out())
> >> > >           return -ENODEV;
> >> > >  
> >> > >          if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
> >> > > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> >> > > index e21c181..9d250cf 100644
> >> > > --- a/drivers/input/misc/xen-kbdfront.c
> >> > > +++ b/drivers/input/misc/xen-kbdfront.c
> >> > > @@ -29,6 +29,7 @@
> >> > >  #include <xen/interface/io/fbif.h>
> >> > >  #include <xen/interface/io/kbdif.h>
> >> > >  #include <xen/xenbus.h>
> >> > > +#include <xen/platform_pci.h>
> >> > >  
> >> > >  struct xenkbd_info {
> >> > >          struct input_dev *kbd;
> >> > > @@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
> >> > >          if (xen_initial_domain())
> >> > >           return -ENODEV;
> >> > >  
> >> > > +        if (xen_err_out())
> >> > > +         return -ENODEV;
> >> > 
> >> > Why do we error out here? There is nothing to unplug in this case.
> >> 
> >> B/c otherwise the driver blows up when it acts on the XenBus and tries
> >> to setup a grant. But the grant is initialized by the xen-platform-pci
> >> which is not run.
> 
> > I see. Adding this check must be the real purpose of the patch then?
> > In that case don't we need another check like this one in:
> 
> > drivers/char/tpm/xen-tpmfront.c:xen_tpmfront_init
> > drivers/pci/xen-pcifront.c:pcifront_init
> 
> > and for consistency (it doesn't use grants right now)
> 
> > drivers/video/xen-fbfront.c:xenfb_init
> 
> > ?
> 
> 
> Hi Konrad / Stefano,
> 
> Is there any follow up on this ?

I need to respin it. Um, will do that later on today. Thanks for
poking me!
> 
> --
> Sander
> 

Re: [BUG] Xen vm kernel crash in get_free_entries.

[Matt Wilson]

On Sat, Oct 19, 2013 at 12:03:17PM +0100, Ian Campbell wrote:
> On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
> > On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:
> 
> > > makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
> > >
> > Great catch!
> > I also confirm that 3.11.5 kernel boots just fine after reverting of 
> > 'correctly initialize grant table version 1' patch.
> 
> This could just be down to that patch adding some BUG_ONs to catch bad
> things going on, e.g. the one in gnttab_expand which I think is being
> hit here.

Indeed, the BUG_ON was added to ensure that the grant table system is
initialized before we attempt to expand the grant table space.

> I have a feeling that it is still wrong (but just more benign) to be
> hitting that call chain in a configuration where there is no platform
> device driver running. IOW reverting that patch removes the obvious
> symptom (blowing up) but not the root cause, i.e. the patch is doing its
> job.

The initialization of the grant table is deferred when running on a
HVM guest.

drivers/xen/grant-table.c:

static int __gnttab_init(void)
{
        /* Delay grant-table initialization in the PV on HVM case */
        if (xen_hvm_domain())
                return 0;

        if (!xen_pv_domain())
                return -ENODEV;

        return gnttab_init();
}

The Xen platform PCI driver initializes it when it binds to the PCI
device:

drivers/xen/platform-pci.c:

static int platform_pci_init(struct pci_dev *pdev,
                             const struct pci_device_id *ent)
{
...
        max_nr_gframes = gnttab_max_grant_frames();
        xen_hvm_resume_frames = alloc_xen_mmio(PAGE_SIZE *
	max_nr_gframes);
        ret = gnttab_init();
        if (ret)
                goto out;
        xenbus_probe(NULL);
        return 0;
...

Lots of initialization depends on the presence of the Xen platform PCI
device, I don't see how PV enlightenment can be expected to work if
you don't enable the PCI device.

--msw

Re: [BUG] Xen vm kernel crash in get_free_entries.

[David Vrabel]

On 21/10/13 11:29, Matt Wilson wrote:
> On Sat, Oct 19, 2013 at 12:03:17PM +0100, Ian Campbell wrote:
>> On Sat, 2013-10-19 at 14:51 +0400, Astarta wrote:
>>> On 10/19/2013 03:14 AM, Sander Eikelenboom wrote:
>>
>>>> makes a HVM guest (qemu-xen-traditional) with xen_platform_pci=0 boot again using xl, haven't tested it with xend.
>>>>
>>> Great catch!
>>> I also confirm that 3.11.5 kernel boots just fine after reverting of 
>>> 'correctly initialize grant table version 1' patch.
>>
>> This could just be down to that patch adding some BUG_ONs to catch bad
>> things going on, e.g. the one in gnttab_expand which I think is being
>> hit here.
> 
> Indeed, the BUG_ON was added to ensure that the grant table system is
> initialized before we attempt to expand the grant table space.
> 
>> I have a feeling that it is still wrong (but just more benign) to be
>> hitting that call chain in a configuration where there is no platform
>> device driver running. IOW reverting that patch removes the obvious
>> symptom (blowing up) but not the root cause, i.e. the patch is doing its
>> job.
> 
> The initialization of the grant table is deferred when running on a
> HVM guest.
> 
> drivers/xen/grant-table.c:
> 
> static int __gnttab_init(void)
> {
>         /* Delay grant-table initialization in the PV on HVM case */
>         if (xen_hvm_domain())
>                 return 0;
> 
>         if (!xen_pv_domain())
>                 return -ENODEV;
> 
>         return gnttab_init();
> }
> 
> The Xen platform PCI driver initializes it when it binds to the PCI
> device:
> 
> drivers/xen/platform-pci.c:
> 
> static int platform_pci_init(struct pci_dev *pdev,
>                              const struct pci_device_id *ent)
> {
> ...
>         max_nr_gframes = gnttab_max_grant_frames();
>         xen_hvm_resume_frames = alloc_xen_mmio(PAGE_SIZE *
> 	max_nr_gframes);
>         ret = gnttab_init();
>         if (ret)
>                 goto out;
>         xenbus_probe(NULL);
>         return 0;
> ...
> 
> Lots of initialization depends on the presence of the Xen platform PCI
> device, I don't see how PV enlightenment can be expected to work if
> you don't enable the PCI device.

Yes, I think we need to defer the initialization of xenbus to
platform_pci_init() as well (and perhaps some other bits and pieces as
well?).

David