Hi Everyone, I am running Ubuntu 12.04 x86_64. My machine has a supermicro motherboard X9SCI-LN4F with 32GB of RAM installed. To get Xen, I simply did apt-get install xen-hypervisor which gives me Ubuntu''s 4.1 xen version. For some reason, Xen can''t see any more than about 3.5GB of RAM. I can confirm this by xentop as well as xm info. I am definately running a 64-bit Dom0 kernel as when I boot into it without Xen, I can see all 32GB of RAM by running "free -m". Has anybody come across this issue before? For what it''s worth, I''m booting my system using UEFI - could that have something to do with it? Any help is very much appreciated Thanks
Hi Everyone, CC: Xen-users I am running Ubuntu 12.04 x86_64. My machine has a supermicro motherboard X9SCI-LN4F with 32GB of RAM installed. To get Xen, I simply did apt-get install xen-hypervisor which gives me Ubuntu''s 4.1 xen version. For some reason, Xen can''t see any more than about 3.5GB of RAM. I can confirm this by xentop as well as xm info. I am definately running a 64-bit Dom0 kernel as when I boot into it without Xen, I can see all 32GB of RAM by running "free -m". Has anybody come across this issue before? For what it''s worth, I''m booting my system using UEFI - could that have something to do with it? Any help is very much appreciated Thanks Here is the output of xm dmesg: (XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2ubuntu2.2) (stefan.bader@canonical.com) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) Sat Jul 21 09:01:19 UTC 2012 (XEN) Bootloader: GRUB 1.99-21ubuntu3.1 (XEN) Command line: placeholder (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 0 EDD information structures (XEN) Xen-e801 RAM map: (XEN) 0000000000000000 - 0000000000099c00 (usable) (XEN) 0000000000100000 - 00000000ddd00000 (usable) (XEN) System RAM: 3548MB (3633764kB) (XEN) ACPI: RSDP 000FDF00, 0024 (r2 SUPERM) (XEN) ACPI: XSDT DDF9E098, 00AC (r1 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: FACP DDFA90D8, 00F4 (r4 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: DSDT DDF9E1D8, AEFA (r2 SUPERM SMCI--MB 0 INTL 20051117) (XEN) ACPI: FACS DDFBDF80, 0040 (XEN) ACPI: APIC DDFA91D0, 0092 (r3 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: FPDT DDFA9268, 0044 (r1 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: MCFG DDFA92B0, 003C (r1 SUPERM SMCI--MB 1 MSFT 97) (XEN) ACPI: PRAD DDFA92F0, 00BE (r2 PRADID PRADTID 1 MSFT 3000001) (XEN) ACPI: HPET DDFA93B0, 0038 (r1 SUPERM SMCI--MB 1 AMI. 5) (XEN) ACPI: SSDT DDFA93E8, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) ACPI: SPMI DDFA9758, 0040 (r5 A M I OEMSPMI 0 AMI. 0) (XEN) ACPI: SSDT DDFA9798, 09A4 (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) ACPI: SSDT DDFAA140, 0A88 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) ACPI: DMAR DDFAABC8, 0078 (r1 INTEL SNB 1 INTL 1) (XEN) ACPI: BGRT DDFAAC40, 0038 (r0 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: SPCR DDFAAC78, 0050 (r1 A M I APTIO4 1 AMI. 5) (XEN) ACPI: EINJ DDFAACC8, 0130 (r1 AMI AMI EINJ 0 0) (XEN) ACPI: ERST DDFAADF8, 0210 (r1 AMIER AMI ERST 0 0) (XEN) ACPI: HEST DDFAB008, 00A8 (r1 AMI AMI HEST 0 0) (XEN) ACPI: BERT DDFAB0B0, 0030 (r1 AMI AMI BERT 0 0) (XEN) Domain heap initialised (XEN) ACPI: 32/64X FACS address mismatch in FADT - ddfbdf80/0000000000000000, using 32 (XEN) Processor #0 7:10 APIC version 21 (XEN) Processor #2 7:10 APIC version 21 (XEN) Processor #4 7:10 APIC version 21 (XEN) Processor #6 7:10 APIC version 21 (XEN) Processor #1 7:10 APIC version 21 (XEN) Processor #3 7:10 APIC version 21 (XEN) Processor #5 7:10 APIC version 21 (XEN) Processor #7 7:10 APIC version 21 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [VT-D]dmar.c:528: RMRR address range not in reserved memory base = dde16000 end = dde32fff; iommu_inclusive_mapping=1 parameter may be needed. (XEN) ERST table is invalid (XEN) Switched to APIC driver x2apic_cluster. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3292.644 MHz processor. (XEN) Initing memory sharing. (XEN) Intel VT-d Snoop Control enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) EPT supports 2MB super page. (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 8 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x205d000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00000000bc000000->00000000c0000000 (744642 pages to be allocated) (XEN) Init. ramdisk: 00000000c4b6a000->00000000dd7ffe00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff8205d000 (XEN) Init. ramdisk: ffffffff8205d000->ffffffff9acf2e00 (XEN) Phys-Mach map: ffffffff9acf3000->ffffffff9b387ac0 (XEN) Start info: ffffffff9b388000->ffffffff9b3884b4 (XEN) Page tables: ffffffff9b389000->ffffffff9b468000 (XEN) Boot stack: ffffffff9b468000->ffffffff9b469000 (XEN) TOTAL: ffffffff80000000->ffffffff9b800000 (XEN) ENTRY ADDRESS: ffffffff81cfd200 (XEN) Dom0 has maximum 8 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input to Xen) (XEN) Freed 220kB init memory. (XEN) physdev.c:155: dom0: wrong map_pirq type 3
Hello Jonathan, Have you tried xl dmesg? It could just be Dom0 not mapping all the RAM. On Wed, Aug 22, 2012 at 7:41 PM, Jonathan Tripathy <jonnyt@abpni.co.uk>wrote:> Hi Everyone, > > I am running Ubuntu 12.04 x86_64. My machine has a supermicro motherboard > X9SCI-LN4F with 32GB of RAM installed. To get Xen, I simply did apt-get > install xen-hypervisor which gives me Ubuntu''s 4.1 xen version. > > For some reason, Xen can''t see any more than about 3.5GB of RAM. I can > confirm this by xentop as well as xm info. I am definately running a 64-bit > Dom0 kernel as when I boot into it without Xen, I can see all 32GB of RAM > by running "free -m". > > Has anybody come across this issue before? For what it''s worth, I''m > booting my system using UEFI - could that have something to do with it? > > Any help is very much appreciated > > Thanks > > ______________________________**_________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
eLorme wrote:> > Hello Jonathan, > > Have you tried xl dmesg? It could just be Dom0 not mapping all the RAM.Sorry, I posted it to xen-devel: (XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2ubuntu2.2) (stefan.bader@canonical.com) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) Sat Jul 21 09:01:19 UTC 2012 (XEN) Bootloader: GRUB 1.99-21ubuntu3.1 (XEN) Command line: placeholder (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 0 EDD information structures (XEN) Xen-e801 RAM map: (XEN) 0000000000000000 - 0000000000099c00 (usable) (XEN) 0000000000100000 - 00000000ddd00000 (usable) (XEN) System RAM: 3548MB (3633764kB) (XEN) ACPI: RSDP 000FDF00, 0024 (r2 SUPERM) (XEN) ACPI: XSDT DDF9E098, 00AC (r1 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: FACP DDFA90D8, 00F4 (r4 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: DSDT DDF9E1D8, AEFA (r2 SUPERM SMCI--MB 0 INTL 20051117) (XEN) ACPI: FACS DDFBDF80, 0040 (XEN) ACPI: APIC DDFA91D0, 0092 (r3 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: FPDT DDFA9268, 0044 (r1 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: MCFG DDFA92B0, 003C (r1 SUPERM SMCI--MB 1 MSFT 97) (XEN) ACPI: PRAD DDFA92F0, 00BE (r2 PRADID PRADTID 1 MSFT 3000001) (XEN) ACPI: HPET DDFA93B0, 0038 (r1 SUPERM SMCI--MB 1 AMI. 5) (XEN) ACPI: SSDT DDFA93E8, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) ACPI: SPMI DDFA9758, 0040 (r5 A M I OEMSPMI 0 AMI. 0) (XEN) ACPI: SSDT DDFA9798, 09A4 (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) ACPI: SSDT DDFAA140, 0A88 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) ACPI: DMAR DDFAABC8, 0078 (r1 INTEL SNB 1 INTL 1) (XEN) ACPI: BGRT DDFAAC40, 0038 (r0 SUPERM SMCI--MB 1 AMI 10013) (XEN) ACPI: SPCR DDFAAC78, 0050 (r1 A M I APTIO4 1 AMI. 5) (XEN) ACPI: EINJ DDFAACC8, 0130 (r1 AMI AMI EINJ 0 0) (XEN) ACPI: ERST DDFAADF8, 0210 (r1 AMIER AMI ERST 0 0) (XEN) ACPI: HEST DDFAB008, 00A8 (r1 AMI AMI HEST 0 0) (XEN) ACPI: BERT DDFAB0B0, 0030 (r1 AMI AMI BERT 0 0) (XEN) Domain heap initialised (XEN) ACPI: 32/64X FACS address mismatch in FADT - ddfbdf80/0000000000000000, using 32 (XEN) Processor #0 7:10 APIC version 21 (XEN) Processor #2 7:10 APIC version 21 (XEN) Processor #4 7:10 APIC version 21 (XEN) Processor #6 7:10 APIC version 21 (XEN) Processor #1 7:10 APIC version 21 (XEN) Processor #3 7:10 APIC version 21 (XEN) Processor #5 7:10 APIC version 21 (XEN) Processor #7 7:10 APIC version 21 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [VT-D]dmar.c:528: RMRR address range not in reserved memory base = dde16000 end = dde32fff; iommu_inclusive_mapping=1 parameter may be needed. (XEN) ERST table is invalid (XEN) Switched to APIC driver x2apic_cluster. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3292.644 MHz processor. (XEN) Initing memory sharing. (XEN) Intel VT-d Snoop Control enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) EPT supports 2MB super page. (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 8 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x205d000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00000000bc000000->00000000c0000000 (744642 pages to be allocated) (XEN) Init. ramdisk: 00000000c4b6a000->00000000dd7ffe00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff8205d000 (XEN) Init. ramdisk: ffffffff8205d000->ffffffff9acf2e00 (XEN) Phys-Mach map: ffffffff9acf3000->ffffffff9b387ac0 (XEN) Start info: ffffffff9b388000->ffffffff9b3884b4 (XEN) Page tables: ffffffff9b389000->ffffffff9b468000 (XEN) Boot stack: ffffffff9b468000->ffffffff9b469000 (XEN) TOTAL: ffffffff80000000->ffffffff9b800000 (XEN) ENTRY ADDRESS: ffffffff81cfd200 (XEN) Dom0 has maximum 8 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input to Xen) (XEN) Freed 220kB init memory. (XEN) physdev.c:155: dom0: wrong map_pirq type 3
On 23/08/2012 00:48, Jonathan Tripathy wrote:> > Hi Everyone, > > CC: Xen-users > > I am running Ubuntu 12.04 x86_64. My machine has a supermicro > motherboard X9SCI-LN4F with 32GB of RAM installed. To get Xen, I simply > did apt-get install xen-hypervisor which gives me Ubuntu''s 4.1 xen > version. > > For some reason, Xen can''t see any more than about 3.5GB of RAM. I can > confirm this by xentop as well as xm info. I am definately running a > 64-bit Dom0 kernel as when I boot into it without Xen, I can see all > 32GB of RAM by running "free -m". > > Has anybody come across this issue before? For what it''s worth, I''m > booting my system using UEFI - could that have something to do with it? > > Any help is very much appreciated > > Thanks > > Here is the output of xm dmesg: > > (XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2ubuntu2.2) > (stefan.bader@canonical.com) (gcc version 4.6.3 (Ubuntu/Linaro > 4.6.3-1ubuntu5) ) Sat Jul 21 09:01:19 UTC 2012 > (XEN) Bootloader: GRUB 1.99-21ubuntu3.1 > (XEN) Command line: placeholder > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 0 EDD information structures > (XEN) Xen-e801 RAM map: > (XEN) 0000000000000000 - 0000000000099c00 (usable) > (XEN) 0000000000100000 - 00000000ddd00000 (usable) > (XEN) System RAM: 3548MB (3633764kB) > (XEN) ACPI: RSDP 000FDF00, 0024 (r2 SUPERM) > (XEN) ACPI: XSDT DDF9E098, 00AC (r1 SUPERM SMCI--MB 1 AMI > 10013) > (XEN) ACPI: FACP DDFA90D8, 00F4 (r4 SUPERM SMCI--MB 1 AMI > 10013) > (XEN) ACPI: DSDT DDF9E1D8, AEFA (r2 SUPERM SMCI--MB 0 INTL > 20051117) > (XEN) ACPI: FACS DDFBDF80, 0040 > (XEN) ACPI: APIC DDFA91D0, 0092 (r3 SUPERM SMCI--MB 1 AMI > 10013) > (XEN) ACPI: FPDT DDFA9268, 0044 (r1 SUPERM SMCI--MB 1 AMI > 10013) > (XEN) ACPI: MCFG DDFA92B0, 003C (r1 SUPERM SMCI--MB 1 > MSFT 97) > (XEN) ACPI: PRAD DDFA92F0, 00BE (r2 PRADID PRADTID 1 MSFT > 3000001) > (XEN) ACPI: HPET DDFA93B0, 0038 (r1 SUPERM SMCI--MB 1 > AMI. 5) > (XEN) ACPI: SSDT DDFA93E8, 036D (r1 SataRe SataTabl 1000 INTL > 20091112) > (XEN) ACPI: SPMI DDFA9758, 0040 (r5 A M I OEMSPMI 0 > AMI. 0) > (XEN) ACPI: SSDT DDFA9798, 09A4 (r1 PmRef Cpu0Ist 3000 INTL > 20051117) > (XEN) ACPI: SSDT DDFAA140, 0A88 (r1 PmRef CpuPm 3000 INTL > 20051117) > (XEN) ACPI: DMAR DDFAABC8, 0078 (r1 INTEL SNB 1 > INTL 1) > (XEN) ACPI: BGRT DDFAAC40, 0038 (r0 SUPERM SMCI--MB 1 AMI > 10013) > (XEN) ACPI: SPCR DDFAAC78, 0050 (r1 A M I APTIO4 1 > AMI. 5) > (XEN) ACPI: EINJ DDFAACC8, 0130 (r1 AMI AMI EINJ 0 0) > (XEN) ACPI: ERST DDFAADF8, 0210 (r1 AMIER AMI ERST 0 0) > (XEN) ACPI: HEST DDFAB008, 00A8 (r1 AMI AMI HEST 0 0) > (XEN) ACPI: BERT DDFAB0B0, 0030 (r1 AMI AMI BERT 0 0) > (XEN) Domain heap initialised > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > ddfbdf80/0000000000000000, using 32 > (XEN) Processor #0 7:10 APIC version 21 > (XEN) Processor #2 7:10 APIC version 21 > (XEN) Processor #4 7:10 APIC version 21 > (XEN) Processor #6 7:10 APIC version 21 > (XEN) Processor #1 7:10 APIC version 21 > (XEN) Processor #3 7:10 APIC version 21 > (XEN) Processor #5 7:10 APIC version 21 > (XEN) Processor #7 7:10 APIC version 21 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) [VT-D]dmar.c:528: RMRR address range not in reserved memory > base = dde16000 end = dde32fff; iommu_inclusive_mapping=1 parameter > may be needed. > (XEN) ERST table is invalid > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3292.644 MHz processor. > (XEN) Initing memory sharing. > (XEN) Intel VT-d Snoop Control enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) Intel VT-d Shared EPT tables not enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 16 KiB. > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) EPT supports 2MB super page. > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Brought up 8 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x205d000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 00000000bc000000->00000000c0000000 (744642 pages > to be allocated) > (XEN) Init. ramdisk: 00000000c4b6a000->00000000dd7ffe00 > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff8205d000 > (XEN) Init. ramdisk: ffffffff8205d000->ffffffff9acf2e00 > (XEN) Phys-Mach map: ffffffff9acf3000->ffffffff9b387ac0 > (XEN) Start info: ffffffff9b388000->ffffffff9b3884b4 > (XEN) Page tables: ffffffff9b389000->ffffffff9b468000 > (XEN) Boot stack: ffffffff9b468000->ffffffff9b469000 > (XEN) TOTAL: ffffffff80000000->ffffffff9b800000 > (XEN) ENTRY ADDRESS: ffffffff81cfd200 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) Scrubbing Free RAM: .done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch > input to Xen) > (XEN) Freed 220kB init memory. > (XEN) physdev.c:155: dom0: wrong map_pirq type 3 > > >Hi Everyone, You will note that someone has posted a bug report here with the issue I''m facing: https://bugzilla.redhat.com/show_bug.cgi?id=819235 Also, someone has create a patch (for 4.0.1): http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot Could someone here please shed light on this issue? Is there an official patch in the works? Thanks
Well, that''s a shame. Pretty sure the e801 Map is your problem, and the only fix I have found involves compiling from source with modifications: http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot I have had success applying the above fix with plenty of versions of Xen, so I can vouch for the above post being a valid workaround. I still use it with Xen 4.2. Must be a grub efi bug, supposedly 4.2 has a new option to build xen.efi, which would replace the debian.efi boot file, but I haven''t figured anything out for that. On Wed, Aug 22, 2012 at 8:05 PM, Jonathan Tripathy <jonnyt@abpni.co.uk>wrote:> eLorme wrote: > >> >> Hello Jonathan, >> >> Have you tried xl dmesg? It could just be Dom0 not mapping all the RAM. >> > Sorry, I posted it to xen-devel: > > (XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2ubuntu2.2) ( > stefan.bader@canonical.com) (gcc version 4.6.3 (Ubuntu/Linaro > 4.6.3-1ubuntu5) ) Sat Jul 21 09:01:19 UTC 2012 > (XEN) Bootloader: GRUB 1.99-21ubuntu3.1 > (XEN) Command line: placeholder > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 0 EDD information structures > (XEN) Xen-e801 RAM map: > (XEN) 0000000000000000 - 0000000000099c00 (usable) > (XEN) 0000000000100000 - 00000000ddd00000 (usable) > (XEN) System RAM: 3548MB (3633764kB) > (XEN) ACPI: RSDP 000FDF00, 0024 (r2 SUPERM) > (XEN) ACPI: XSDT DDF9E098, 00AC (r1 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: FACP DDFA90D8, 00F4 (r4 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: DSDT DDF9E1D8, AEFA (r2 SUPERM SMCI--MB 0 INTL 20051117) > (XEN) ACPI: FACS DDFBDF80, 0040 > (XEN) ACPI: APIC DDFA91D0, 0092 (r3 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: FPDT DDFA9268, 0044 (r1 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: MCFG DDFA92B0, 003C (r1 SUPERM SMCI--MB 1 MSFT 97) > (XEN) ACPI: PRAD DDFA92F0, 00BE (r2 PRADID PRADTID 1 MSFT 3000001) > (XEN) ACPI: HPET DDFA93B0, 0038 (r1 SUPERM SMCI--MB 1 AMI. 5) > (XEN) ACPI: SSDT DDFA93E8, 036D (r1 SataRe SataTabl 1000 INTL 20091112) > (XEN) ACPI: SPMI DDFA9758, 0040 (r5 A M I OEMSPMI 0 AMI. 0) > (XEN) ACPI: SSDT DDFA9798, 09A4 (r1 PmRef Cpu0Ist 3000 INTL 20051117) > (XEN) ACPI: SSDT DDFAA140, 0A88 (r1 PmRef CpuPm 3000 INTL 20051117) > (XEN) ACPI: DMAR DDFAABC8, 0078 (r1 INTEL SNB 1 INTL 1) > (XEN) ACPI: BGRT DDFAAC40, 0038 (r0 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: SPCR DDFAAC78, 0050 (r1 A M I APTIO4 1 AMI. 5) > (XEN) ACPI: EINJ DDFAACC8, 0130 (r1 AMI AMI EINJ 0 0) > (XEN) ACPI: ERST DDFAADF8, 0210 (r1 AMIER AMI ERST 0 0) > (XEN) ACPI: HEST DDFAB008, 00A8 (r1 AMI AMI HEST 0 0) > (XEN) ACPI: BERT DDFAB0B0, 0030 (r1 AMI AMI BERT 0 0) > (XEN) Domain heap initialised > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > ddfbdf80/0000000000000000, using 32 > (XEN) Processor #0 7:10 APIC version 21 > (XEN) Processor #2 7:10 APIC version 21 > (XEN) Processor #4 7:10 APIC version 21 > (XEN) Processor #6 7:10 APIC version 21 > (XEN) Processor #1 7:10 APIC version 21 > (XEN) Processor #3 7:10 APIC version 21 > (XEN) Processor #5 7:10 APIC version 21 > (XEN) Processor #7 7:10 APIC version 21 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) [VT-D]dmar.c:528: RMRR address range not in reserved memory base > dde16000 end = dde32fff; iommu_inclusive_mapping=1 parameter may be needed. > (XEN) ERST table is invalid > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3292.644 MHz processor. > (XEN) Initing memory sharing. > (XEN) Intel VT-d Snoop Control enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) Intel VT-d Shared EPT tables not enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 16 KiB. > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) EPT supports 2MB super page. > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Brought up 8 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x205d000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 00000000bc000000->**00000000c0000000 (744642 pages > to be allocated) > (XEN) Init. ramdisk: 00000000c4b6a000->**00000000dd7ffe00 > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->**ffffffff8205d000 > (XEN) Init. ramdisk: ffffffff8205d000->**ffffffff9acf2e00 > (XEN) Phys-Mach map: ffffffff9acf3000->**ffffffff9b387ac0 > (XEN) Start info: ffffffff9b388000->**ffffffff9b3884b4 > (XEN) Page tables: ffffffff9b389000->**ffffffff9b468000 > (XEN) Boot stack: ffffffff9b468000->**ffffffff9b469000 > (XEN) TOTAL: ffffffff80000000->**ffffffff9b800000 > (XEN) ENTRY ADDRESS: ffffffff81cfd200 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) Scrubbing Free RAM: .done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input > to Xen) > (XEN) Freed 220kB init memory. > (XEN) physdev.c:155: dom0: wrong map_pirq type 3 >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On 23/08/2012 01:13, Casey DeLorme wrote:> > Well, that''s a shame. Pretty sure the e801 Map is your problem, and > the only fix I have found involves compiling from source with > modifications: > http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot > > I have had success applying the above fix with plenty of versions of > Xen, so I can vouch for the above post being a valid workaround. I > still use it with Xen 4.2. > > Must be a grub efi bug, supposedly 4.2 has a new option to build > xen.efi, which would replace the debian.efi boot file, but I haven''t > figured anything out for that. >I also came across that serverfault posting. Am I correct in saying that the patch will have to be modified a little to work for 4.1.2? Thanks
The code in setup.c has changed very little between versions, but I have
applied this patch successfully to 4.1.2, 4.1.3, and 4.2.
I happened to be testing rc3 right now, and here is what that section of
the file has:
#if 0
else if ( e820_raw_nr != 0 )
{
memmap_type = "Xen-e820";
}
else if ( bootsym(lowmem_kb) )
{
memmap_type = "Xen-e801";
e820_raw[0].addr = 0;
e820_raw[0].size = bootsym(lowmem_kb) << 10;
e820_raw[0].type = E820_RAM;
e820_raw[1].addr = 0x100000;
e820_raw[1].size = bootsym(highmem_kb) << 10;
e820_raw[1].type = E820_RAM;
e820_raw_nr = 2;
}
#endif
else if ( mbi->flags & MBI_MEMMAP )
The condition "( e820_raw_nr != 0 )" has remained the same.
The important change is that it went from "if" to an "else
if", which means
the line after you close your "#endif" has to continue or open the
conditional statement.
So in 4.1.2 you might replace the following "else if" with just
"if".
The goal is to comment out the e801 mapping information. I have no idea
what kind of effects this would have on other systems, but it has worked
fine for me.
On Wed, Aug 22, 2012 at 8:18 PM, Jonathan Tripathy
<jonnyt@abpni.co.uk>wrote:
> On 23/08/2012 01:13, Casey DeLorme wrote:
>
>>
>> Well, that''s a shame. Pretty sure the e801 Map is your
problem, and the
>> only fix I have found involves compiling from source with
modifications:
>> http://serverfault.com/**questions/342109/xen-only-**
>>
sees-512mb-of-system-ram-**should-be-8gb-uefi-boot<http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot>
>>
>> I have had success applying the above fix with plenty of versions of
Xen,
>> so I can vouch for the above post being a valid workaround. I still
use it
>> with Xen 4.2.
>>
>> Must be a grub efi bug, supposedly 4.2 has a new option to build
xen.efi,
>> which would replace the debian.efi boot file, but I haven''t
figured
>> anything out for that.
>>
>> I also came across that serverfault posting. Am I correct in saying
that
> the patch will have to be modified a little to work for 4.1.2?
>
>
> Thanks
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
Pasi Kärkkäinen
2012-Aug-23 06:06 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On Thu, Aug 23, 2012 at 12:48:01AM +0100, Jonathan Tripathy wrote:> > Hi Everyone, > > CC: Xen-users > > I am running Ubuntu 12.04 x86_64. My machine has a supermicro > motherboard X9SCI-LN4F with 32GB of RAM installed. To get Xen, I simply > did apt-get install xen-hypervisor which gives me Ubuntu''s 4.1 xen version. > > For some reason, Xen can''t see any more than about 3.5GB of RAM. I can > confirm this by xentop as well as xm info. I am definately running a > 64-bit Dom0 kernel as when I boot into it without Xen, I can see all > 32GB of RAM by running "free -m". > > Has anybody come across this issue before? For what it''s worth, I''m > booting my system using UEFI - could that have something to do with it? > > Any help is very much appreciated >Yes, this is UEFI related issue. Can you turn UEFI off? It looks like you''re not running UEFI capable Xen hypervisor. (Xen 4.2 has UEFI support, and some vendors have backported UEFI support on older versions, for example Suse SLES11SP2 contains Xen support in Xen 4.1).> Thanks > > Here is the output of xm dmesg: > > (XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2ubuntu2.2) > (stefan.bader@canonical.com) (gcc version 4.6.3 (Ubuntu/Linaro > 4.6.3-1ubuntu5) ) Sat Jul 21 09:01:19 UTC 2012 > (XEN) Bootloader: GRUB 1.99-21ubuntu3.1 > (XEN) Command line: placeholder > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 0 EDD information structureshere:> (XEN) Xen-e801 RAM map: > (XEN) 0000000000000000 - 0000000000099c00 (usable) > (XEN) 0000000000100000 - 00000000ddd00000 (usable)This is the problem - only the legacy e801 memory map is detected here. You need the usual e820 memory map to see all the memory (correct memory layout). You need Xen with UEFI support, or turn off UEFI in BIOS. -- Pasi> (XEN) System RAM: 3548MB (3633764kB) > (XEN) ACPI: RSDP 000FDF00, 0024 (r2 SUPERM) > (XEN) ACPI: XSDT DDF9E098, 00AC (r1 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: FACP DDFA90D8, 00F4 (r4 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: DSDT DDF9E1D8, AEFA (r2 SUPERM SMCI--MB 0 INTL 20051117) > (XEN) ACPI: FACS DDFBDF80, 0040 > (XEN) ACPI: APIC DDFA91D0, 0092 (r3 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: FPDT DDFA9268, 0044 (r1 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: MCFG DDFA92B0, 003C (r1 SUPERM SMCI--MB 1 MSFT 97) > (XEN) ACPI: PRAD DDFA92F0, 00BE (r2 PRADID PRADTID 1 MSFT 3000001) > (XEN) ACPI: HPET DDFA93B0, 0038 (r1 SUPERM SMCI--MB 1 AMI. 5) > (XEN) ACPI: SSDT DDFA93E8, 036D (r1 SataRe SataTabl 1000 INTL 20091112) > (XEN) ACPI: SPMI DDFA9758, 0040 (r5 A M I OEMSPMI 0 AMI. 0) > (XEN) ACPI: SSDT DDFA9798, 09A4 (r1 PmRef Cpu0Ist 3000 INTL 20051117) > (XEN) ACPI: SSDT DDFAA140, 0A88 (r1 PmRef CpuPm 3000 INTL 20051117) > (XEN) ACPI: DMAR DDFAABC8, 0078 (r1 INTEL SNB 1 INTL 1) > (XEN) ACPI: BGRT DDFAAC40, 0038 (r0 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: SPCR DDFAAC78, 0050 (r1 A M I APTIO4 1 AMI. 5) > (XEN) ACPI: EINJ DDFAACC8, 0130 (r1 AMI AMI EINJ 0 0) > (XEN) ACPI: ERST DDFAADF8, 0210 (r1 AMIER AMI ERST 0 0) > (XEN) ACPI: HEST DDFAB008, 00A8 (r1 AMI AMI HEST 0 0) > (XEN) ACPI: BERT DDFAB0B0, 0030 (r1 AMI AMI BERT 0 0) > (XEN) Domain heap initialised > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > ddfbdf80/0000000000000000, using 32 > (XEN) Processor #0 7:10 APIC version 21 > (XEN) Processor #2 7:10 APIC version 21 > (XEN) Processor #4 7:10 APIC version 21 > (XEN) Processor #6 7:10 APIC version 21 > (XEN) Processor #1 7:10 APIC version 21 > (XEN) Processor #3 7:10 APIC version 21 > (XEN) Processor #5 7:10 APIC version 21 > (XEN) Processor #7 7:10 APIC version 21 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) [VT-D]dmar.c:528: RMRR address range not in reserved memory > base = dde16000 end = dde32fff; iommu_inclusive_mapping=1 parameter > may be needed. > (XEN) ERST table is invalid > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3292.644 MHz processor. > (XEN) Initing memory sharing. > (XEN) Intel VT-d Snoop Control enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) Intel VT-d Shared EPT tables not enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 16 KiB. > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) EPT supports 2MB super page. > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Brought up 8 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x205d000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 00000000bc000000->00000000c0000000 (744642 > pages to be allocated) > (XEN) Init. ramdisk: 00000000c4b6a000->00000000dd7ffe00 > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff8205d000 > (XEN) Init. ramdisk: ffffffff8205d000->ffffffff9acf2e00 > (XEN) Phys-Mach map: ffffffff9acf3000->ffffffff9b387ac0 > (XEN) Start info: ffffffff9b388000->ffffffff9b3884b4 > (XEN) Page tables: ffffffff9b389000->ffffffff9b468000 > (XEN) Boot stack: ffffffff9b468000->ffffffff9b469000 > (XEN) TOTAL: ffffffff80000000->ffffffff9b800000 > (XEN) ENTRY ADDRESS: ffffffff81cfd200 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) Scrubbing Free RAM: .done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch > input to Xen) > (XEN) Freed 220kB init memory. > (XEN) physdev.c:155: dom0: wrong map_pirq type 3 > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Pasi Kärkkäinen
2012-Aug-23 07:22 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On Thu, Aug 23, 2012 at 09:06:20AM +0300, Pasi Kärkkäinen wrote:> On Thu, Aug 23, 2012 at 12:48:01AM +0100, Jonathan Tripathy wrote: > > > > Hi Everyone, > > > > CC: Xen-users > > > > I am running Ubuntu 12.04 x86_64. My machine has a supermicro > > motherboard X9SCI-LN4F with 32GB of RAM installed. To get Xen, I simply > > did apt-get install xen-hypervisor which gives me Ubuntu''s 4.1 xen version. > > > > For some reason, Xen can''t see any more than about 3.5GB of RAM. I can > > confirm this by xentop as well as xm info. I am definately running a > > 64-bit Dom0 kernel as when I boot into it without Xen, I can see all > > 32GB of RAM by running "free -m". > > > > Has anybody come across this issue before? For what it''s worth, I''m > > booting my system using UEFI - could that have something to do with it? > > > > Any help is very much appreciated > > > > Yes, this is UEFI related issue. Can you turn UEFI off? > > It looks like you''re not running UEFI capable Xen hypervisor. > (Xen 4.2 has UEFI support, and some vendors have backported UEFI support on older versions, > for example Suse SLES11SP2 contains UEFI support in Xen 4.1). >Fixed the line above :) -- Pasi> > Thanks > > > > Here is the output of xm dmesg: > > > > (XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2ubuntu2.2) > > (stefan.bader@canonical.com) (gcc version 4.6.3 (Ubuntu/Linaro > > 4.6.3-1ubuntu5) ) Sat Jul 21 09:01:19 UTC 2012 > > (XEN) Bootloader: GRUB 1.99-21ubuntu3.1 > > (XEN) Command line: placeholder > > (XEN) Video information: > > (XEN) VGA is text mode 80x25, font 8x16 > > (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds > > (XEN) Disc information: > > (XEN) Found 0 MBR signatures > > (XEN) Found 0 EDD information structures > > here: > > > (XEN) Xen-e801 RAM map: > > (XEN) 0000000000000000 - 0000000000099c00 (usable) > > (XEN) 0000000000100000 - 00000000ddd00000 (usable) > > This is the problem - only the legacy e801 memory map is detected here. > You need the usual e820 memory map to see all the memory (correct memory layout). > > You need Xen with UEFI support, or turn off UEFI in BIOS. > > > -- Pasi > > > > (XEN) System RAM: 3548MB (3633764kB) > > (XEN) ACPI: RSDP 000FDF00, 0024 (r2 SUPERM) > > (XEN) ACPI: XSDT DDF9E098, 00AC (r1 SUPERM SMCI--MB 1 AMI 10013) > > (XEN) ACPI: FACP DDFA90D8, 00F4 (r4 SUPERM SMCI--MB 1 AMI 10013) > > (XEN) ACPI: DSDT DDF9E1D8, AEFA (r2 SUPERM SMCI--MB 0 INTL 20051117) > > (XEN) ACPI: FACS DDFBDF80, 0040 > > (XEN) ACPI: APIC DDFA91D0, 0092 (r3 SUPERM SMCI--MB 1 AMI 10013) > > (XEN) ACPI: FPDT DDFA9268, 0044 (r1 SUPERM SMCI--MB 1 AMI 10013) > > (XEN) ACPI: MCFG DDFA92B0, 003C (r1 SUPERM SMCI--MB 1 MSFT 97) > > (XEN) ACPI: PRAD DDFA92F0, 00BE (r2 PRADID PRADTID 1 MSFT 3000001) > > (XEN) ACPI: HPET DDFA93B0, 0038 (r1 SUPERM SMCI--MB 1 AMI. 5) > > (XEN) ACPI: SSDT DDFA93E8, 036D (r1 SataRe SataTabl 1000 INTL 20091112) > > (XEN) ACPI: SPMI DDFA9758, 0040 (r5 A M I OEMSPMI 0 AMI. 0) > > (XEN) ACPI: SSDT DDFA9798, 09A4 (r1 PmRef Cpu0Ist 3000 INTL 20051117) > > (XEN) ACPI: SSDT DDFAA140, 0A88 (r1 PmRef CpuPm 3000 INTL 20051117) > > (XEN) ACPI: DMAR DDFAABC8, 0078 (r1 INTEL SNB 1 INTL 1) > > (XEN) ACPI: BGRT DDFAAC40, 0038 (r0 SUPERM SMCI--MB 1 AMI 10013) > > (XEN) ACPI: SPCR DDFAAC78, 0050 (r1 A M I APTIO4 1 AMI. 5) > > (XEN) ACPI: EINJ DDFAACC8, 0130 (r1 AMI AMI EINJ 0 0) > > (XEN) ACPI: ERST DDFAADF8, 0210 (r1 AMIER AMI ERST 0 0) > > (XEN) ACPI: HEST DDFAB008, 00A8 (r1 AMI AMI HEST 0 0) > > (XEN) ACPI: BERT DDFAB0B0, 0030 (r1 AMI AMI BERT 0 0) > > (XEN) Domain heap initialised > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > ddfbdf80/0000000000000000, using 32 > > (XEN) Processor #0 7:10 APIC version 21 > > (XEN) Processor #2 7:10 APIC version 21 > > (XEN) Processor #4 7:10 APIC version 21 > > (XEN) Processor #6 7:10 APIC version 21 > > (XEN) Processor #1 7:10 APIC version 21 > > (XEN) Processor #3 7:10 APIC version 21 > > (XEN) Processor #5 7:10 APIC version 21 > > (XEN) Processor #7 7:10 APIC version 21 > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > (XEN) [VT-D]dmar.c:528: RMRR address range not in reserved memory > > base = dde16000 end = dde32fff; iommu_inclusive_mapping=1 parameter > > may be needed. > > (XEN) ERST table is invalid > > (XEN) Switched to APIC driver x2apic_cluster. > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) Detected 3292.644 MHz processor. > > (XEN) Initing memory sharing. > > (XEN) Intel VT-d Snoop Control enabled. > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > (XEN) Intel VT-d Queued Invalidation enabled. > > (XEN) Intel VT-d Interrupt Remapping enabled. > > (XEN) Intel VT-d Shared EPT tables not enabled. > > (XEN) I/O virtualisation enabled > > (XEN) - Dom0 mode: Relaxed > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > (XEN) ENABLING IO-APIC IRQs > > (XEN) -> Using old ACK method > > (XEN) Platform timer is 14.318MHz HPET > > (XEN) Allocated console ring of 16 KiB. > > (XEN) VMX: Supported advanced features: > > (XEN) - APIC MMIO access virtualisation > > (XEN) - APIC TPR shadow > > (XEN) - Extended Page Tables (EPT) > > (XEN) - Virtual-Processor Identifiers (VPID) > > (XEN) - Virtual NMI > > (XEN) - MSR direct-access bitmap > > (XEN) - Unrestricted Guest > > (XEN) EPT supports 2MB super page. > > (XEN) HVM: ASIDs enabled. > > (XEN) HVM: VMX enabled > > (XEN) HVM: Hardware Assisted Paging detected. > > (XEN) Brought up 8 CPUs > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x205d000 > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > (XEN) Dom0 alloc.: 00000000bc000000->00000000c0000000 (744642 > > pages to be allocated) > > (XEN) Init. ramdisk: 00000000c4b6a000->00000000dd7ffe00 > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > (XEN) Loaded kernel: ffffffff81000000->ffffffff8205d000 > > (XEN) Init. ramdisk: ffffffff8205d000->ffffffff9acf2e00 > > (XEN) Phys-Mach map: ffffffff9acf3000->ffffffff9b387ac0 > > (XEN) Start info: ffffffff9b388000->ffffffff9b3884b4 > > (XEN) Page tables: ffffffff9b389000->ffffffff9b468000 > > (XEN) Boot stack: ffffffff9b468000->ffffffff9b469000 > > (XEN) TOTAL: ffffffff80000000->ffffffff9b800000 > > (XEN) ENTRY ADDRESS: ffffffff81cfd200 > > (XEN) Dom0 has maximum 8 VCPUs > > (XEN) Scrubbing Free RAM: .done. > > (XEN) Xen trace buffers: disabled > > (XEN) Std. Loglevel: Errors and warnings > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > > (XEN) Xen is relinquishing VGA console. > > (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch > > input to Xen) > > (XEN) Freed 220kB init memory. > > (XEN) physdev.c:155: dom0: wrong map_pirq type 3 > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Jonathan Tripathy
2012-Aug-23 07:27 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 23/08/2012 08:22, Pasi Kärkkäinen wrote:> On Thu, Aug 23, 2012 at 09:06:20AM +0300, Pasi Kärkkäinen wrote: >> On Thu, Aug 23, 2012 at 12:48:01AM +0100, Jonathan Tripathy wrote: >>> Hi Everyone, >>> >>> CC: Xen-users >>> >>> I am running Ubuntu 12.04 x86_64. My machine has a supermicro >>> motherboard X9SCI-LN4F with 32GB of RAM installed. To get Xen, I simply >>> did apt-get install xen-hypervisor which gives me Ubuntu''s 4.1 xen version. >>> >>> For some reason, Xen can''t see any more than about 3.5GB of RAM. I can >>> confirm this by xentop as well as xm info. I am definately running a >>> 64-bit Dom0 kernel as when I boot into it without Xen, I can see all >>> 32GB of RAM by running "free -m". >>> >>> Has anybody come across this issue before? For what it''s worth, I''m >>> booting my system using UEFI - could that have something to do with it? >>> >>> Any help is very much appreciated >>> >> Yes, this is UEFI related issue. Can you turn UEFI off? >> >> It looks like you''re not running UEFI capable Xen hypervisor. >> (Xen 4.2 has UEFI support, and some vendors have backported UEFI support on older versions, >> for example Suse SLES11SP2 contains UEFI support in Xen 4.1). >> > Fixed the line above :) > > -- Pasi >Thanks, Pasi. A couple of questions: I''m guessing xen.efi (from 4.2) just replaces grub?? Also, if I were to apply that patch from superuser (http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot), would have have any bad consequences? I''m very security conscience as the DomUs are untrusted... Thanks
Jan Beulich
2012-Aug-23 07:39 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
>>> Jonathan Tripathy <jonnyt@abpni.co.uk> 08/23/12 9:29 AM >>> >I''m guessing xen.efi (from 4.2) just replaces grub??"Replaces" is the wrong term. It simply makes the use of grub.efi (or however it''s named) unnecessary.>Also, if I were to apply that patch from superuser >(http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot), >would have have any bad consequences? I''m very security conscience as >the DomUs are untrusted...If you wanted to do that, I''d strongly recommend only removing the E801 code (obviously, from your log, you don''t get E820 entries reported anyway, so this would be to not harm using hypervisors built from the same source on other systems) or simply swapping the E801 and multiboot handling order (which may actually be something to consider even upstream, so you''d be welcome to post such a patch). But in the end, in order to indeed use UEFI as intended, you''ll need to switch to using xen.efi and an EFI-enabled Dom0 kernel (which upstream pv-ops for now isn''t). Jan
Jonathan Tripathy
2012-Aug-23 08:07 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 23.08.2012 08:39, Jan Beulich wrote:>>>> Jonathan Tripathy <jonnyt@abpni.co.uk> 08/23/12 9:29 AM >>> >>I''m guessing xen.efi (from 4.2) just replaces grub?? > > "Replaces" is the wrong term. It simply makes the use of grub.efi (or > however > it''s named) unnecessary. > >>Also, if I were to apply that patch from superuser >>(http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot), >>would have have any bad consequences? I''m very security conscience as >>the DomUs are untrusted... > > If you wanted to do that, I''d strongly recommend only removing the > E801 code > (obviously, from your log, you don''t get E820 entries reported > anyway, so this > would be to not harm using hypervisors built from the same source on > other > systems) or simply swapping the E801 and multiboot handling order > (which may > actually be something to consider even upstream, so you''d be welcome > to post > such a patch). > > But in the end, in order to indeed use UEFI as intended, you''ll need > to switch to > using xen.efi and an EFI-enabled Dom0 kernel (which upstream pv-ops > for now > isn''t). > > JanHi Jan, I''ll submit a patch with the map entries in the if block swapped. I''ll make the patch, then test it for you guys, then post it. Do I just send it to this list (for the benefit of others and for upstream consideration)? When you say "use UEFI as intended", is there something wrong with just flipping the if block on its head? Thanks
Keir Fraser
2012-Aug-23 08:12 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 23/08/2012 08:27, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:> Thanks, Pasi. > > A couple of questions: > > I''m guessing xen.efi (from 4.2) just replaces grub?? > > Also, if I were to apply that patch from superuser > (http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-sho > uld-be-8gb-uefi-boot), > would have have any bad consequences? I''m very security conscience as > the DomUs are untrusted...Firstly, the same effect *should* be had by adding no-real-mode to your Xen command line. So try that first. Secondly, it is arguable that we should patch Xen to prefer "Multiboot-e820" over "Xen-e801". And yes, overall if you have a UEFI BIOS then using UEFI Xen is probably best of all :) -- Keir> Thanks > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Jonathan Tripathy
2012-Aug-23 08:28 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 23.08.2012 09:12, Keir Fraser wrote:> On 23/08/2012 08:27, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: > >> Thanks, Pasi. >> >> A couple of questions: >> >> I''m guessing xen.efi (from 4.2) just replaces grub?? >> >> Also, if I were to apply that patch from superuser >> >> (http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-sho >> uld-be-8gb-uefi-boot), >> would have have any bad consequences? I''m very security conscience >> as >> the DomUs are untrusted... > > Firstly, the same effect *should* be had by adding no-real-mode to > your Xen > command line. So try that first. > > Secondly, it is arguable that we should patch Xen to prefer > "Multiboot-e820" > over "Xen-e801". > > And yes, overall if you have a UEFI BIOS then using UEFI Xen is > probably > best of all :) >Unfortunately, no-real-mode didn''t work :( In xm info, I see xen_commandline : placeholder no-real-mode Not sure where placeholder is coming from... Also, I''m conscience that no-real-mode may cause other problems as it''s designed for debugging? Thanks
Keir Fraser
2012-Aug-23 08:43 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 23/08/2012 09:28, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:> Unfortunately, no-real-mode didn''t work :( > > In xm info, I see > > xen_commandline : placeholder no-real-mode > > Not sure where placeholder is coming from... > > Also, I''m conscience that no-real-mode may cause other problems as it''s > designed for debugging?What does your RAM map look like now from early Xen boot, using no-real-mode? It shouldn''t be "Xen-e801" any more at least, else the no-real-mode parameter isn''t working. The installer probably added ''placeholder'' because older versions of Xen skipped the first argument (because on old GRUB that was the path/to/grub rather than a real argument). -- Keir
Ian Campbell
2012-Aug-23 08:49 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On Thu, 2012-08-23 at 09:43 +0100, Keir Fraser wrote:> > The installer probably added ''placeholder'' because older versions of > Xen skipped the first argument (because on old GRUB that was the > path/to/grub rather than a real argument).grub2''s update-grub adds this. Ian.
Jonathan Tripathy
2012-Aug-23 08:58 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
> > What does your RAM map look like now from early Xen boot, using > no-real-mode? It shouldn''t be "Xen-e801" any more at least, else the > no-real-mode parameter isn''t working. >Still Xen-e801, so it looks like no-real-mode isn''t working :(
Pasi Kärkkäinen
2012-Aug-23 09:13 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On Thu, Aug 23, 2012 at 09:28:31AM +0100, Jonathan Tripathy wrote:> > > On 23.08.2012 09:12, Keir Fraser wrote: > >On 23/08/2012 08:27, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: > > > >>Thanks, Pasi. > >> > >>A couple of questions: > >> > >>I''m guessing xen.efi (from 4.2) just replaces grub?? > >> > >>Also, if I were to apply that patch from superuser > >> > >>(http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-sho > >>uld-be-8gb-uefi-boot), > >>would have have any bad consequences? I''m very security > >>conscience as > >>the DomUs are untrusted... > > > >Firstly, the same effect *should* be had by adding no-real-mode to > >your Xen > >command line. So try that first. > > > >Secondly, it is arguable that we should patch Xen to prefer > >"Multiboot-e820" > >over "Xen-e801". > > > >And yes, overall if you have a UEFI BIOS then using UEFI Xen is > >probably > >best of all :) > > > > Unfortunately, no-real-mode didn''t work :( > > In xm info, I see > > xen_commandline : placeholder no-real-mode > > Not sure where placeholder is coming from... >"placeholder" is usually added by grub in Debian/Ubuntu, to overcome a bug/issue with multiboot and (old versions of) Xen.. (so in some old Xen versions with grub2 multiboot the first cmdline parameter got lost, but that hasn''t really been the case for a long time anymore, so placeholder is not needed these days.) -- Pasi
Keir Fraser
2012-Aug-23 09:43 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 23/08/2012 09:58, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:>> What does your RAM map look like now from early Xen boot, using >> no-real-mode? It shouldn''t be "Xen-e801" any more at least, else the >> no-real-mode parameter isn''t working. >> > > Still Xen-e801, so it looks like no-real-mode isn''t working :(Grrr it''s been broken since tboot support went in, long ago. Going to have to fix that and backport to 4.1 and 4.0 branches... -- Keir
Jan Beulich
2012-Aug-24 15:35 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
>>> On 23.08.12 at 10:07, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:> On 23.08.2012 08:39, Jan Beulich wrote: >>>>> Jonathan Tripathy <jonnyt@abpni.co.uk> 08/23/12 9:29 AM >>> >>>I''m guessing xen.efi (from 4.2) just replaces grub?? >> >> "Replaces" is the wrong term. It simply makes the use of grub.efi (or >> however >> it''s named) unnecessary. >> >>>Also, if I were to apply that patch from superuser >>>(http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-sh > ould-be-8gb-uefi-boot), >>>would have have any bad consequences? I''m very security conscience as >>>the DomUs are untrusted... >> >> If you wanted to do that, I''d strongly recommend only removing the >> E801 code >> (obviously, from your log, you don''t get E820 entries reported >> anyway, so this >> would be to not harm using hypervisors built from the same source on >> other >> systems) or simply swapping the E801 and multiboot handling order >> (which may >> actually be something to consider even upstream, so you''d be welcome >> to post >> such a patch). >> >> But in the end, in order to indeed use UEFI as intended, you''ll need >> to switch to >> using xen.efi and an EFI-enabled Dom0 kernel (which upstream pv-ops >> for now >> isn''t). > > I''ll submit a patch with the map entries in the if block swapped. I''ll > make the patch, then test it for you guys, then post it. Do I just send > it to this list (for the benefit of others and for upstream > consideration)?Yes.> When you say "use UEFI as intended", is there something wrong with just > flipping the if block on its head?That flipping has nothing to do with UEFI, just with the way grub.efi works. Proper UEFI support implies use of EFI''s boot and run time services, which only xen.efi currently does (and which, for those run time services that get made available for use by Dom0, also requires an enabled Dom0 kernel). Jan
Jonathan Tripathy
2012-Aug-24 17:39 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 24/08/2012 16:35, Jan Beulich wrote:>>>> On 23.08.12 at 10:07, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote: >> On 23.08.2012 08:39, Jan Beulich wrote: >>>>>> Jonathan Tripathy <jonnyt@abpni.co.uk> 08/23/12 9:29 AM >>> >>>> I''m guessing xen.efi (from 4.2) just replaces grub?? >>> "Replaces" is the wrong term. It simply makes the use of grub.efi (or >>> however >>> it''s named) unnecessary. >>> >>>> Also, if I were to apply that patch from superuser >>>> (http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-sh >> ould-be-8gb-uefi-boot), >>>> would have have any bad consequences? I''m very security conscience as >>>> the DomUs are untrusted... >>> If you wanted to do that, I''d strongly recommend only removing the >>> E801 code >>> (obviously, from your log, you don''t get E820 entries reported >>> anyway, so this >>> would be to not harm using hypervisors built from the same source on >>> other >>> systems) or simply swapping the E801 and multiboot handling order >>> (which may >>> actually be something to consider even upstream, so you''d be welcome >>> to post >>> such a patch). >>> >>> But in the end, in order to indeed use UEFI as intended, you''ll need >>> to switch to >>> using xen.efi and an EFI-enabled Dom0 kernel (which upstream pv-ops >>> for now >>> isn''t). >> I''ll submit a patch with the map entries in the if block swapped. I''ll >> make the patch, then test it for you guys, then post it. Do I just send >> it to this list (for the benefit of others and for upstream >> consideration)? > Yes. > >> When you say "use UEFI as intended", is there something wrong with just >> flipping the if block on its head? > That flipping has nothing to do with UEFI, just with the way grub.efi > works. > > Proper UEFI support implies use of EFI''s boot and run time services, > which only xen.efi currently does (and which, for those run time > services that get made available for use by Dom0, also requires an > enabled Dom0 kernel). >Thanks for the clarification. So from a security/reliability standpoint, nothing will be affected by flipping the if block? Sorry that I haven''t submitted the patch yet, just been very busy. This is on my to-do list this weekend. Thanks
Keir Fraser
2012-Aug-24 20:05 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 24/08/2012 18:39, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:>> That flipping has nothing to do with UEFI, just with the way grub.efi >> works. >> >> Proper UEFI support implies use of EFI''s boot and run time services, >> which only xen.efi currently does (and which, for those run time >> services that get made available for use by Dom0, also requires an >> enabled Dom0 kernel). >> > Thanks for the clarification. > > So from a security/reliability standpoint, nothing will be affected by > flipping the if block?It should simply make it more likely that Xen sees all your RAM. ;) -- Keir
On Wed, Aug 22, 2012 at 08:34:10PM -0400, Casey DeLorme wrote:> The code in setup.c has changed very little between versions, but I have > applied this patch successfully to 4.1.2, 4.1.3, and 4.2. > I happened to be testing rc3 right now, and here is what that section of > the file has: > #if 0 > else if ( e820_raw_nr != 0 ) > { > memmap_type = "Xen-e820"; > } > else if ( bootsym(lowmem_kb) ) > { > memmap_type = "Xen-e801"; > e820_raw[0].addr = 0; > e820_raw[0].size = bootsym(lowmem_kb) << 10; > e820_raw[0].type = E820_RAM; > e820_raw[1].addr = 0x100000; > e820_raw[1].size = bootsym(highmem_kb) << 10; > e820_raw[1].type = E820_RAM; > e820_raw_nr = 2; > } > #endif > else if ( mbi->flags & MBI_MEMMAP ) > The condition "( e820_raw_nr != 0 )" has remained the same. > The important change is that it went from "if" to an "else if", which > means the line after you close your "#endif" has to continue or open the > conditional statement. > So in 4.1.2 you might replace the following "else if" with just "if". > The goal is to comment out the e801 mapping information. I have no idea > what kind of effects this would have on other systems, but it has worked > fine for me. >Hello, Did you submit patches for this to xen-unstable (and after that, a backport to xen-4.1-testing.hg) ? Thanks, -- Pasi> On Wed, Aug 22, 2012 at 8:18 PM, Jonathan Tripathy <[1]jonnyt@abpni.co.uk> > wrote: > > On 23/08/2012 01:13, Casey DeLorme wrote: > > Well, that''s a shame. Pretty sure the e801 Map is your problem, and > the only fix I have found involves compiling from source with > modifications: > [2]http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot > > I have had success applying the above fix with plenty of versions of > Xen, so I can vouch for the above post being a valid workaround. I > still use it with Xen 4.2. > > Must be a grub efi bug, supposedly 4.2 has a new option to build > xen.efi, which would replace the debian.efi boot file, but I haven''t > figured anything out for that. > > I also came across that serverfault posting. Am I correct in saying that > the patch will have to be modified a little to work for 4.1.2? > > Thanks > > _______________________________________________ > Xen-users mailing list > [3]Xen-users@lists.xen.org > [4]http://lists.xen.org/xen-users > > References > > Visible links > 1. mailto:jonnyt@abpni.co.uk > 2. http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot > 3. mailto:Xen-users@lists.xen.org > 4. http://lists.xen.org/xen-users> _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
Jonathan Tripathy
2012-Aug-28 19:36 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 24/08/2012 21:05, Keir Fraser wrote:> On 24/08/2012 18:39, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: > >>> That flipping has nothing to do with UEFI, just with the way grub.efi >>> works. >>> >>> Proper UEFI support implies use of EFI''s boot and run time services, >>> which only xen.efi currently does (and which, for those run time >>> services that get made available for use by Dom0, also requires an >>> enabled Dom0 kernel). >>> >> Thanks for the clarification. >> >> So from a security/reliability standpoint, nothing will be affected by >> flipping the if block? > It should simply make it more likely that Xen sees all your RAM. ;) > > -- Keir > >Hi Everyone, I reversed the if block in setup.c and now my server can see the full 32GB of RAM. I haven''t submitted a patch yet as we have run into another (possibly unrelated to xen) issue with this server build that we are working on. Once we complete our full testing, a patch will be submitted :) Thanks
Keir Fraser
2012-Aug-28 21:10 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 20:36, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:>>> Thanks for the clarification. >>> >>> So from a security/reliability standpoint, nothing will be affected by >>> flipping the if block? >> It should simply make it more likely that Xen sees all your RAM. ;) >> >> -- Keir >> >> > > Hi Everyone, > > I reversed the if block in setup.c and now my server can see the full > 32GB of RAM. I haven''t submitted a patch yet as we have run into another > (possibly unrelated to xen) issue with this server build that we are > working on. Once we complete our full testing, a patch will be submitted :)In this case, I will re-make the patch myself and check it in. Since it is a trivial one. Thanks, Keir
Jonathan Tripathy
2012-Aug-28 21:13 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
Keir Fraser wrote:> On 28/08/2012 20:36, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: > >>>> Thanks for the clarification. >>>> >>>> So from a security/reliability standpoint, nothing will be affected by >>>> flipping the if block? >>> It should simply make it more likely that Xen sees all your RAM. ;) >>> >>> -- Keir >>> >>> >> Hi Everyone, >> >> I reversed the if block in setup.c and now my server can see the full >> 32GB of RAM. I haven''t submitted a patch yet as we have run into another >> (possibly unrelated to xen) issue with this server build that we are >> working on. Once we complete our full testing, a patch will be submitted :) > In this case, I will re-make the patch myself and check it in. Since it is a > trivial one. > > Thanks, > KeirThanks Keir Will this be backported to 4.1? Cheers
Keir Fraser
2012-Aug-28 21:37 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 22:13, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:> Keir Fraser wrote: >> On 28/08/2012 20:36, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: >> >>>>> Thanks for the clarification. >>>>> >>>>> So from a security/reliability standpoint, nothing will be affected by >>>>> flipping the if block? >>>> It should simply make it more likely that Xen sees all your RAM. ;) >>>> >>>> -- Keir >>>> >>>> >>> Hi Everyone, >>> >>> I reversed the if block in setup.c and now my server can see the full >>> 32GB of RAM. I haven''t submitted a patch yet as we have run into another >>> (possibly unrelated to xen) issue with this server build that we are >>> working on. Once we complete our full testing, a patch will be submitted :) >> In this case, I will re-make the patch myself and check it in. Since it is a >> trivial one. >> >> Thanks, >> Keir > Thanks Keir > > Will this be backported to 4.1?Erm. Yes, I think so. It''s not really sane ever to be using e801-style memory information on modern systems, so preferring Multiboot-e820 over Xen-e801 makes a lot of sense imo. It''ll be Jan who actually does the backports from now on, however. -- Keir> Cheers >
Keir Fraser
2012-Aug-28 21:41 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 22:13, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:> Keir Fraser wrote: >> On 28/08/2012 20:36, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: >> >>>>> Thanks for the clarification. >>>>> >>>>> So from a security/reliability standpoint, nothing will be affected by >>>>> flipping the if block? >>>> It should simply make it more likely that Xen sees all your RAM. ;) >>>> >>>> -- Keir >>>> >>>> >>> Hi Everyone, >>> >>> I reversed the if block in setup.c and now my server can see the full >>> 32GB of RAM. I haven''t submitted a patch yet as we have run into another >>> (possibly unrelated to xen) issue with this server build that we are >>> working on. Once we complete our full testing, a patch will be submitted :) >> In this case, I will re-make the patch myself and check it in. Since it is a >> trivial one. >> >> Thanks, >> Keir > Thanks KeirNow done. xen-unstable:25786 -- Keir> Will this be backported to 4.1? > > Cheers >
Jonathan Tripathy
2012-Aug-28 21:50 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 22:41, Keir Fraser wrote:> On 28/08/2012 22:13, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: > >> Keir Fraser wrote: >>> On 28/08/2012 20:36, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: >>> >>>>>> Thanks for the clarification. >>>>>> >>>>>> So from a security/reliability standpoint, nothing will be affected by >>>>>> flipping the if block? >>>>> It should simply make it more likely that Xen sees all your RAM. ;) >>>>> >>>>> -- Keir >>>>> >>>>> >>>> Hi Everyone, >>>> >>>> I reversed the if block in setup.c and now my server can see the full >>>> 32GB of RAM. I haven''t submitted a patch yet as we have run into another >>>> (possibly unrelated to xen) issue with this server build that we are >>>> working on. Once we complete our full testing, a patch will be submitted :) >>> In this case, I will re-make the patch myself and check it in. Since it is a >>> trivial one. >>> >>> Thanks, >>> Keir >> Thanks Keir > Now done. xen-unstable:25786 > > -- KeirHi Keir, Thanks for doing that. However, the ordering of the if block in my code that I used was slightly different from your commit. Perhaps this doesn''t make too much of a difference? Thanks if ( mbi->flags & MBI_MEMMAP ) { memmap_type = "Multiboot-e820"; while ( (bytes < mbi->mmap_length) && (e820_raw_nr < E820MAX) ) { memory_map_t *map = __va(mbi->mmap_addr + bytes); /* * This is a gross workaround for a BIOS bug. Some bootloaders do * not write e820 map entries into pre-zeroed memory. This is * okay if the BIOS fills in all fields of the map entry, but * some broken BIOSes do not bother to write the high word of * the length field if the length is smaller than 4GB. We * detect and fix this by flagging sections below 4GB that * appear to be larger than 4GB in size. */ if ( (map->base_addr_high == 0) && (map->length_high != 0) ) { if ( !e820_warn ) { printk("WARNING: Buggy e820 map detected and fixed " "(truncated length fields).\n"); e820_warn = 1; } map->length_high = 0; } e820_raw[e820_raw_nr].addr ((u64)map->base_addr_high << 32) | (u64)map->base_addr_low; e820_raw[e820_raw_nr].size ((u64)map->length_high << 32) | (u64)map->length_low; e820_raw[e820_raw_nr].type = map->type; e820_raw_nr++; bytes += map->size + 4; } } else if ( mbi->flags & MBI_MEMLIMITS ) { memmap_type = "Multiboot-e801"; e820_raw[0].addr = 0; e820_raw[0].size = mbi->mem_lower << 10; e820_raw[0].type = E820_RAM; e820_raw[1].addr = 0x100000; e820_raw[1].size = mbi->mem_upper << 10; e820_raw[1].type = E820_RAM; e820_raw_nr = 2; } if ( e820_raw_nr != 0 ) { memmap_type = "Xen-e820"; } else if ( bootsym(lowmem_kb) ) { memmap_type = "Xen-e801"; e820_raw[0].addr = 0; e820_raw[0].size = bootsym(lowmem_kb) << 10; e820_raw[0].type = E820_RAM; e820_raw[1].addr = 0x100000; e820_raw[1].size = bootsym(highmem_kb) << 10; e820_raw[1].type = E820_RAM; e820_raw_nr = 2; } else { EARLY_FAIL("Bootloader provided no memory information.\n"); }
Jonathan Tripathy
2012-Aug-28 21:52 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 22:50, Jonathan Tripathy wrote:> > > On 28/08/2012 22:41, Keir Fraser wrote: >> On 28/08/2012 22:13, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: >> >>> Keir Fraser wrote: >>>> On 28/08/2012 20:36, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: >>>> >>>>>>> Thanks for the clarification. >>>>>>> >>>>>>> So from a security/reliability standpoint, nothing will be >>>>>>> affected by >>>>>>> flipping the if block? >>>>>> It should simply make it more likely that Xen sees all your RAM. ;) >>>>>> >>>>>> -- Keir >>>>>> >>>>>> >>>>> Hi Everyone, >>>>> >>>>> I reversed the if block in setup.c and now my server can see the full >>>>> 32GB of RAM. I haven''t submitted a patch yet as we have run into >>>>> another >>>>> (possibly unrelated to xen) issue with this server build that we are >>>>> working on. Once we complete our full testing, a patch will be >>>>> submitted :) >>>> In this case, I will re-make the patch myself and check it in. >>>> Since it is a >>>> trivial one. >>>> >>>> Thanks, >>>> Keir >>> Thanks Keir >> Now done. xen-unstable:25786 >> >> -- Keir > Hi Keir, > > Thanks for doing that. However, the ordering of the if block in my > code that I used was slightly different from your commit. Perhaps this > doesn''t make too much of a difference? > > Thanks >Ooops, typo''d the code (I had to recreate the changes as I deleted my source tree). Here is the version I used: if ( mbi->flags & MBI_MEMMAP ) { memmap_type = "Multiboot-e820"; while ( (bytes < mbi->mmap_length) && (e820_raw_nr < E820MAX) ) { memory_map_t *map = __va(mbi->mmap_addr + bytes); /* * This is a gross workaround for a BIOS bug. Some bootloaders do * not write e820 map entries into pre-zeroed memory. This is * okay if the BIOS fills in all fields of the map entry, but * some broken BIOSes do not bother to write the high word of * the length field if the length is smaller than 4GB. We * detect and fix this by flagging sections below 4GB that * appear to be larger than 4GB in size. */ if ( (map->base_addr_high == 0) && (map->length_high != 0) ) { if ( !e820_warn ) { printk("WARNING: Buggy e820 map detected and fixed " "(truncated length fields).\n"); e820_warn = 1; } map->length_high = 0; } e820_raw[e820_raw_nr].addr ((u64)map->base_addr_high << 32) | (u64)map->base_addr_low; e820_raw[e820_raw_nr].size ((u64)map->length_high << 32) | (u64)map->length_low; e820_raw[e820_raw_nr].type = map->type; e820_raw_nr++; bytes += map->size + 4; } } else if ( mbi->flags & MBI_MEMLIMITS ) { memmap_type = "Multiboot-e801"; e820_raw[0].addr = 0; e820_raw[0].size = mbi->mem_lower << 10; e820_raw[0].type = E820_RAM; e820_raw[1].addr = 0x100000; e820_raw[1].size = mbi->mem_upper << 10; e820_raw[1].type = E820_RAM; e820_raw_nr = 2; } else if ( e820_raw_nr != 0 ) { memmap_type = "Xen-e820"; } else if ( bootsym(lowmem_kb) ) { memmap_type = "Xen-e801"; e820_raw[0].addr = 0; e820_raw[0].size = bootsym(lowmem_kb) << 10; e820_raw[0].type = E820_RAM; e820_raw[1].addr = 0x100000; e820_raw[1].size = bootsym(highmem_kb) << 10; e820_raw[1].type = E820_RAM; e820_raw_nr = 2; } else { EARLY_FAIL("Bootloader provided no memory information.\n"); }
Jonathan Tripathy
2012-Aug-28 22:05 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 22:52, Jonathan Tripathy wrote:> On 28/08/2012 22:50, Jonathan Tripathy wrote: >> >> >> On 28/08/2012 22:41, Keir Fraser wrote: >>> On 28/08/2012 22:13, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: >>> >>>> Keir Fraser wrote: >>>>> On 28/08/2012 20:36, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: >>>>> >>>>>>>> Thanks for the clarification. >>>>>>>> >>>>>>>> So from a security/reliability standpoint, nothing will be >>>>>>>> affected by >>>>>>>> flipping the if block? >>>>>>> It should simply make it more likely that Xen sees all your RAM. ;) >>>>>>> >>>>>>> -- Keir >>>>>>> >>>>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> I reversed the if block in setup.c and now my server can see the >>>>>> full >>>>>> 32GB of RAM. I haven''t submitted a patch yet as we have run into >>>>>> another >>>>>> (possibly unrelated to xen) issue with this server build that we are >>>>>> working on. Once we complete our full testing, a patch will be >>>>>> submitted :) >>>>> In this case, I will re-make the patch myself and check it in. >>>>> Since it is a >>>>> trivial one. >>>>> >>>>> Thanks, >>>>> Keir >>>> Thanks Keir >>> Now done. xen-unstable:25786 >>> >>> -- Keir >> Hi Keir, >> >> Thanks for doing that. However, the ordering of the if block in my >> code that I used was slightly different from your commit. Perhaps >> this doesn''t make too much of a difference? >> >> Thanks >> > Ooops, typo''d the code (I had to recreate the changes as I deleted my > source tree). Here is the version I used: > > if ( mbi->flags & MBI_MEMMAP ) > { > memmap_type = "Multiboot-e820"; > while ( (bytes < mbi->mmap_length) && (e820_raw_nr < E820MAX) ) > { > memory_map_t *map = __va(mbi->mmap_addr + bytes); > > /* > * This is a gross workaround for a BIOS bug. Some > bootloaders do > * not write e820 map entries into pre-zeroed memory. This is > * okay if the BIOS fills in all fields of the map entry, but > * some broken BIOSes do not bother to write the high word of > * the length field if the length is smaller than 4GB. We > * detect and fix this by flagging sections below 4GB that > * appear to be larger than 4GB in size. > */ > if ( (map->base_addr_high == 0) && (map->length_high != 0) ) > { > if ( !e820_warn ) > { > printk("WARNING: Buggy e820 map detected and fixed " > "(truncated length fields).\n"); > e820_warn = 1; > } > map->length_high = 0; > } > > e820_raw[e820_raw_nr].addr > ((u64)map->base_addr_high << 32) | > (u64)map->base_addr_low; > e820_raw[e820_raw_nr].size > ((u64)map->length_high << 32) | (u64)map->length_low; > e820_raw[e820_raw_nr].type = map->type; > e820_raw_nr++; > > bytes += map->size + 4; > } > } > else if ( mbi->flags & MBI_MEMLIMITS ) > { > memmap_type = "Multiboot-e801"; > e820_raw[0].addr = 0; > e820_raw[0].size = mbi->mem_lower << 10; > e820_raw[0].type = E820_RAM; > e820_raw[1].addr = 0x100000; > e820_raw[1].size = mbi->mem_upper << 10; > e820_raw[1].type = E820_RAM; > e820_raw_nr = 2; > } > else if ( e820_raw_nr != 0 ) > { > memmap_type = "Xen-e820"; > } > else if ( bootsym(lowmem_kb) ) > { > memmap_type = "Xen-e801"; > e820_raw[0].addr = 0; > e820_raw[0].size = bootsym(lowmem_kb) << 10; > e820_raw[0].type = E820_RAM; > e820_raw[1].addr = 0x100000; > e820_raw[1].size = bootsym(highmem_kb) << 10; > e820_raw[1].type = E820_RAM; > e820_raw_nr = 2; > } > else > { > EARLY_FAIL("Bootloader provided no memory information.\n"); > } > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-develAnyway, question is moot. I rebuilt my code using your ordering of the if block and it works just fine. All 32GB is detected. I actually agree with your order because as you as, 801 is outdated.
Keir Fraser
2012-Aug-28 22:31 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 22:50, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:>>>>> I reversed the if block in setup.c and now my server can see the full >>>>> 32GB of RAM. I haven''t submitted a patch yet as we have run into another >>>>> (possibly unrelated to xen) issue with this server build that we are >>>>> working on. Once we complete our full testing, a patch will be submitted >>>>> :) >>>> In this case, I will re-make the patch myself and check it in. Since it is >>>> a >>>> trivial one. >>>> >>>> Thanks, >>>> Keir >>> Thanks Keir >> Now done. xen-unstable:25786 >> >> -- Keir > Hi Keir, > > Thanks for doing that. However, the ordering of the if block in my code > that I used was slightly different from your commit. Perhaps this > doesn''t make too much of a difference?Your ordering favours Multiboot-e820 over Xen-e820, which we do not want to do, and Multiboot-e801 over Xen-e820 which is definitely not sane. I see you tested the checked-in version and it worked okay for you, which is expected, and is a more sensible re-ordering. :) -- Keir
Jonathan Tripathy
2012-Aug-28 22:33 UTC
Re: Can''t see more than 3.5GB of RAM / UEFI / no e820 memory map detected
On 28/08/2012 23:31, Keir Fraser wrote:> On 28/08/2012 22:50, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote: > >>>>>> I reversed the if block in setup.c and now my server can see the full >>>>>> 32GB of RAM. I haven''t submitted a patch yet as we have run into another >>>>>> (possibly unrelated to xen) issue with this server build that we are >>>>>> working on. Once we complete our full testing, a patch will be submitted >>>>>> :) >>>>> In this case, I will re-make the patch myself and check it in. Since it is >>>>> a >>>>> trivial one. >>>>> >>>>> Thanks, >>>>> Keir >>>> Thanks Keir >>> Now done. xen-unstable:25786 >>> >>> -- Keir >> Hi Keir, >> >> Thanks for doing that. However, the ordering of the if block in my code >> that I used was slightly different from your commit. Perhaps this >> doesn''t make too much of a difference? > Your ordering favours Multiboot-e820 over Xen-e820, which we do not want to > do, and Multiboot-e801 over Xen-e820 which is definitely not sane. > > I see you tested the checked-in version and it worked okay for you, which is > expected, and is a more sensible re-ordering. :) >Yup, I completely agree with you :)
This "patch" is only for EFI users, and doesn''t appear to apply to all cases. It wouldn''t make sense to submit it. On Tue, Aug 28, 2012 at 2:22 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:> On Wed, Aug 22, 2012 at 08:34:10PM -0400, Casey DeLorme wrote: > > The code in setup.c has changed very little between versions, but I > have > > applied this patch successfully to 4.1.2, 4.1.3, and 4.2. > > I happened to be testing rc3 right now, and here is what that section > of > > the file has: > > #if 0 > > else if ( e820_raw_nr != 0 ) > > { > > memmap_type = "Xen-e820"; > > } > > else if ( bootsym(lowmem_kb) ) > > { > > memmap_type = "Xen-e801"; > > e820_raw[0].addr = 0; > > e820_raw[0].size = bootsym(lowmem_kb) << 10; > > e820_raw[0].type = E820_RAM; > > e820_raw[1].addr = 0x100000; > > e820_raw[1].size = bootsym(highmem_kb) << 10; > > e820_raw[1].type = E820_RAM; > > e820_raw_nr = 2; > > } > > #endif > > else if ( mbi->flags & MBI_MEMMAP ) > > The condition "( e820_raw_nr != 0 )" has remained the same. > > The important change is that it went from "if" to an "else if", which > > means the line after you close your "#endif" has to continue or open > the > > conditional statement. > > So in 4.1.2 you might replace the following "else if" with just "if". > > The goal is to comment out the e801 mapping information. I have no > idea > > what kind of effects this would have on other systems, but it has > worked > > fine for me. > > > > Hello, > > Did you submit patches for this to xen-unstable (and after that, a > backport to xen-4.1-testing.hg) ? > > Thanks, > > -- Pasi > > > On Wed, Aug 22, 2012 at 8:18 PM, Jonathan Tripathy <[1] > jonnyt@abpni.co.uk> > > wrote: > > > > On 23/08/2012 01:13, Casey DeLorme wrote: > > > > Well, that''s a shame. Pretty sure the e801 Map is your problem, > and > > the only fix I have found involves compiling from source with > > modifications: > > [2] > http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot > > > > I have had success applying the above fix with plenty of versions > of > > Xen, so I can vouch for the above post being a valid workaround. > I > > still use it with Xen 4.2. > > > > Must be a grub efi bug, supposedly 4.2 has a new option to build > > xen.efi, which would replace the debian.efi boot file, but I > haven''t > > figured anything out for that. > > > > I also came across that serverfault posting. Am I correct in saying > that > > the patch will have to be modified a little to work for 4.1.2? > > > > Thanks > > > > _______________________________________________ > > Xen-users mailing list > > [3]Xen-users@lists.xen.org > > [4]http://lists.xen.org/xen-users > > > > References > > > > Visible links > > 1. mailto:jonnyt@abpni.co.uk > > 2. > http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot > > 3. mailto:Xen-users@lists.xen.org > > 4. http://lists.xen.org/xen-users > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On 28/08/2012 23:44, Casey DeLorme wrote:> This "patch" is only for EFI users, and doesn''t appear to apply to all > cases. It wouldn''t make sense to submit it. >Hi Casey, I changed the order of the if block (without commenting out anything) and managed to get Xen to recognise all the RAM in the system. Keir has made a commit to xen-unstable. http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a0b5f8102a00 Thanks