Can't see more than 3.5GB of RAM

Can't see more than 3.5GB of RAM

[Jonathan Tripathy]

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

Re: Can't see more than 3.5GB of RAM

[Jonathan Tripathy]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Pasi Kärkkäinen]

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 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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Pasi Kärkkäinen]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jan Beulich]

>>> 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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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).
>
> Jan

Hi 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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jan Beulich]

>>> 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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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?

Cheers

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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
> 

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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

> Will this be backported to 4.1?
> 
> Cheers
> 

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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

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");
     }

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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");
     }

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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-devel
Anyway, 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.

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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 :)

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Ian Campbell]

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.

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

>
> 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 :(

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Pasi Kärkkäinen]

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

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Jonathan Tripathy]

On 23.08.2012 10:43, Keir Fraser wrote:
> 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

Just for info, is it safe to use no-real-mode on a production system? 
Please keep in mind that our DomUs are untrusted. Or would it be better 
if I created a patch to change the order of the if block to prefer the 
multi-boot memory map?

Thanks

Re: Can't see more than 3.5GB of RAM / UEFI / no e820 memory map detected

[Keir Fraser]

On 23/08/2012 10:50, "Jonathan Tripathy" <jonnyt@abpni.co.uk> wrote:

> On 23.08.2012 10:43, Keir Fraser wrote:
>> 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
> 
> Just for info, is it safe to use no-real-mode on a production system?
> Please keep in mind that our DomUs are untrusted. Or would it be better
> if I created a patch to change the order of the if block to prefer the
> multi-boot memory map?

No-real-mode is perfectly safe to use from that point of view -- it will
have no impact on safe containment of untrusted DomU's.

However, of course it is nice to not have to rely on no-real-mode, so please
try switching the ordring of that if block.

 -- Keir

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