* Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-15 22:27 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-15 22:27 UTC (permalink / raw)
To: xen-devel; +Cc: royger
ref: from chat in #xen
[08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
I've got Xen PV Dom0 booted on a Linux UEFI box
dmesg | grep -i "xen version"
[ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
uname -rm
5.0.7-lp150.5.g012b5f1-default x86_64
lsb_release -rd
Description: openSUSE Leap 15.0
Release: 15.0
rpm -qa | grep -i qemu | egrep "seabios|u-3"
qemu-seabios-1.12.0-lp150.513.13.noarch
qemu-3.1.0-lp150.513.13.x86_64
rpm -qa | grep -i ovmf
ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
rpm -qa | grep grub2 |egrep "xen|efi"
grub2-x86_64-efi-2.02-lp150.64.10.noarch
grub2-x86_64-xen-2.02-lp150.64.10.noarch
&
rpm -qa | grep -i efi | grep git | sort
efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
note these^^ EFI* tools -- src from efi master branch, pkgs available here,
https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
-- were needed, as distro packaged versions' were old/problematic ...
With this^^ config, all's well
serial boot log
...
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] Hypervisor detected: Xen PV
[ 0.000000] Xen version 4.12.
...
at shell prompt,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4016 4 r----- 5949.6
Xenstore 1 31 1 -b---- 0.2
efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
dp: 04 01 2a ... 04 00
enabling PVH Dom0, adding to grub configs,
GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
then mkinitrd & grub reconfig,
serial boot log
Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
...
(XEN) [00000027dcded44e] Bootloader: EFI
...
Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
...
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] Hypervisor detected: Xen HVM
[ 0.000000] Xen version 4.12.
...
Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
at shell prompt,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 563.0
Xenstore 1 31 1 -b---- 0.0
but, in this Dom0=pvh mode,
efibootmgr -v
EFI variables are not supported on this system.
checking
mount | grep -i efi
systemd-1 on /boot/efi type autofs (rw,relatime,fd=54,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21340)
/dev/sde2 on /boot/efi type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,x-systemd.automount)
tree /boot/efi/
/boot/efi/
├── [root 4096] EFI
│ ├── [root 4096] BOOT
│ │ └── [root 142848] BOOTX64.EFI
│ └── [root 4096] opensuse
│ ├── [root 142848] grubx64.efi
│ ├── [root 532] grub.xen-files
│ ├── [root 18318448] initrd-5.0.7-lp150.5.g012b5f1-default
│ ├── [root 8199608] vmlinuz-5.0.7-lp150.5.g012b5f1-default
│ ├── [root 4924] xen-4.12.0_09-lp150.640.cfg
│ └── [root 2735560] xen-4.12.0_09-lp150.640.efi
└── [root 30] startup.nsh
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-15 22:27 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-15 22:27 UTC (permalink / raw)
To: xen-devel; +Cc: royger
ref: from chat in #xen
[08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
I've got Xen PV Dom0 booted on a Linux UEFI box
dmesg | grep -i "xen version"
[ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
uname -rm
5.0.7-lp150.5.g012b5f1-default x86_64
lsb_release -rd
Description: openSUSE Leap 15.0
Release: 15.0
rpm -qa | grep -i qemu | egrep "seabios|u-3"
qemu-seabios-1.12.0-lp150.513.13.noarch
qemu-3.1.0-lp150.513.13.x86_64
rpm -qa | grep -i ovmf
ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
rpm -qa | grep grub2 |egrep "xen|efi"
grub2-x86_64-efi-2.02-lp150.64.10.noarch
grub2-x86_64-xen-2.02-lp150.64.10.noarch
&
rpm -qa | grep -i efi | grep git | sort
efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
note these^^ EFI* tools -- src from efi master branch, pkgs available here,
https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
-- were needed, as distro packaged versions' were old/problematic ...
With this^^ config, all's well
serial boot log
...
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] Hypervisor detected: Xen PV
[ 0.000000] Xen version 4.12.
...
at shell prompt,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4016 4 r----- 5949.6
Xenstore 1 31 1 -b---- 0.2
efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
dp: 04 01 2a ... 04 00
enabling PVH Dom0, adding to grub configs,
GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
then mkinitrd & grub reconfig,
serial boot log
Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
...
(XEN) [00000027dcded44e] Bootloader: EFI
...
Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
...
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] Hypervisor detected: Xen HVM
[ 0.000000] Xen version 4.12.
...
Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
at shell prompt,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 563.0
Xenstore 1 31 1 -b---- 0.0
but, in this Dom0=pvh mode,
efibootmgr -v
EFI variables are not supported on this system.
checking
mount | grep -i efi
systemd-1 on /boot/efi type autofs (rw,relatime,fd=54,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21340)
/dev/sde2 on /boot/efi type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,x-systemd.automount)
tree /boot/efi/
/boot/efi/
├── [root 4096] EFI
│ ├── [root 4096] BOOT
│ │ └── [root 142848] BOOTX64.EFI
│ └── [root 4096] opensuse
│ ├── [root 142848] grubx64.efi
│ ├── [root 532] grub.xen-files
│ ├── [root 18318448] initrd-5.0.7-lp150.5.g012b5f1-default
│ ├── [root 8199608] vmlinuz-5.0.7-lp150.5.g012b5f1-default
│ ├── [root 4924] xen-4.12.0_09-lp150.640.cfg
│ └── [root 2735560] xen-4.12.0_09-lp150.640.efi
└── [root 30] startup.nsh
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-16 10:50 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-04-16 10:50 UTC (permalink / raw)
To: PGNet Dev; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
Adding the Linux Xen maintainers, in case they can provide some insight.
On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
> ref: from chat in #xen
>
> [08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
>
> I've got Xen PV Dom0 booted on a Linux UEFI box
>
> dmesg | grep -i "xen version"
> [ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
>
> uname -rm
> 5.0.7-lp150.5.g012b5f1-default x86_64
>
> lsb_release -rd
> Description: openSUSE Leap 15.0
> Release: 15.0
>
> rpm -qa | grep -i qemu | egrep "seabios|u-3"
> qemu-seabios-1.12.0-lp150.513.13.noarch
> qemu-3.1.0-lp150.513.13.x86_64
>
> rpm -qa | grep -i ovmf
> ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
> qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
> ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
>
> rpm -qa | grep grub2 |egrep "xen|efi"
> grub2-x86_64-efi-2.02-lp150.64.10.noarch
> grub2-x86_64-xen-2.02-lp150.64.10.noarch
> &
>
> rpm -qa | grep -i efi | grep git | sort
> efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
> efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
> libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
>
> note these^^ EFI* tools -- src from efi master branch, pkgs available here,
>
> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
>
> -- were needed, as distro packaged versions' were old/problematic ...
>
> With this^^ config, all's well
>
> serial boot log
> ...
> [ 0.000000] efi: EFI v2.31 by American Megatrends
> [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
> [ 0.000000] SMBIOS 2.7 present.
> [ 0.000000] Hypervisor detected: Xen PV
> [ 0.000000] Xen version 4.12.
> ...
>
> at shell prompt,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4016 4 r----- 5949.6
> Xenstore 1 31 1 -b---- 0.2
>
> efibootmgr -v
> BootCurrent: 0000
> Timeout: 1 seconds
> BootOrder: 0000
> Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
> dp: 04 01 2a ... 04 00
>
> enabling PVH Dom0, adding to grub configs,
>
> GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
> GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
>
> then mkinitrd & grub reconfig,
>
> serial boot log
> Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
> ...
> (XEN) [00000027dcded44e] Bootloader: EFI
> ...
> Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
> ...
> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] SMBIOS 2.7 present.
> [ 0.000000] Hypervisor detected: Xen HVM
> [ 0.000000] Xen version 4.12.
> ...
>
> Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
>
> at shell prompt,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4015 4 r----- 563.0
> Xenstore 1 31 1 -b---- 0.0
>
> but, in this Dom0=pvh mode,
>
> efibootmgr -v
> EFI variables are not supported on this system.
So boot works as expected, it's just interaction with the EFI firmware
by dom0 that seems to be broken. I'm currently setting up a Linux EFI
box to test this, thanks for the report.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-16 10:50 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-04-16 10:50 UTC (permalink / raw)
To: PGNet Dev; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
Adding the Linux Xen maintainers, in case they can provide some insight.
On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
> ref: from chat in #xen
>
> [08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
>
> I've got Xen PV Dom0 booted on a Linux UEFI box
>
> dmesg | grep -i "xen version"
> [ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
>
> uname -rm
> 5.0.7-lp150.5.g012b5f1-default x86_64
>
> lsb_release -rd
> Description: openSUSE Leap 15.0
> Release: 15.0
>
> rpm -qa | grep -i qemu | egrep "seabios|u-3"
> qemu-seabios-1.12.0-lp150.513.13.noarch
> qemu-3.1.0-lp150.513.13.x86_64
>
> rpm -qa | grep -i ovmf
> ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
> qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
> ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
>
> rpm -qa | grep grub2 |egrep "xen|efi"
> grub2-x86_64-efi-2.02-lp150.64.10.noarch
> grub2-x86_64-xen-2.02-lp150.64.10.noarch
> &
>
> rpm -qa | grep -i efi | grep git | sort
> efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
> efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
> libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
>
> note these^^ EFI* tools -- src from efi master branch, pkgs available here,
>
> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
>
> -- were needed, as distro packaged versions' were old/problematic ...
>
> With this^^ config, all's well
>
> serial boot log
> ...
> [ 0.000000] efi: EFI v2.31 by American Megatrends
> [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
> [ 0.000000] SMBIOS 2.7 present.
> [ 0.000000] Hypervisor detected: Xen PV
> [ 0.000000] Xen version 4.12.
> ...
>
> at shell prompt,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4016 4 r----- 5949.6
> Xenstore 1 31 1 -b---- 0.2
>
> efibootmgr -v
> BootCurrent: 0000
> Timeout: 1 seconds
> BootOrder: 0000
> Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
> dp: 04 01 2a ... 04 00
>
> enabling PVH Dom0, adding to grub configs,
>
> GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
> GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
>
> then mkinitrd & grub reconfig,
>
> serial boot log
> Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
> ...
> (XEN) [00000027dcded44e] Bootloader: EFI
> ...
> Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
> ...
> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] SMBIOS 2.7 present.
> [ 0.000000] Hypervisor detected: Xen HVM
> [ 0.000000] Xen version 4.12.
> ...
>
> Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
>
> at shell prompt,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4015 4 r----- 563.0
> Xenstore 1 31 1 -b---- 0.0
>
> but, in this Dom0=pvh mode,
>
> efibootmgr -v
> EFI variables are not supported on this system.
So boot works as expected, it's just interaction with the EFI firmware
by dom0 that seems to be broken. I'm currently setting up a Linux EFI
box to test this, thanks for the report.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-17 12:05 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-04-17 12:05 UTC (permalink / raw)
To: PGNet Dev; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On Tue, Apr 16, 2019 at 12:50:43PM +0200, Roger Pau Monné wrote:
> Adding the Linux Xen maintainers, in case they can provide some insight.
>
> On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
> > ref: from chat in #xen
> >
> > [08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
> >
> > I've got Xen PV Dom0 booted on a Linux UEFI box
> >
> > dmesg | grep -i "xen version"
> > [ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
> >
> > uname -rm
> > 5.0.7-lp150.5.g012b5f1-default x86_64
> >
> > lsb_release -rd
> > Description: openSUSE Leap 15.0
> > Release: 15.0
> >
> > rpm -qa | grep -i qemu | egrep "seabios|u-3"
> > qemu-seabios-1.12.0-lp150.513.13.noarch
> > qemu-3.1.0-lp150.513.13.x86_64
> >
> > rpm -qa | grep -i ovmf
> > ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
> > qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
> > ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
> >
> > rpm -qa | grep grub2 |egrep "xen|efi"
> > grub2-x86_64-efi-2.02-lp150.64.10.noarch
> > grub2-x86_64-xen-2.02-lp150.64.10.noarch
> > &
> >
> > rpm -qa | grep -i efi | grep git | sort
> > efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
> > efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
> > libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
> >
> > note these^^ EFI* tools -- src from efi master branch, pkgs available here,
> >
> > https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
> > https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
> >
> > -- were needed, as distro packaged versions' were old/problematic ...
> >
> > With this^^ config, all's well
> >
> > serial boot log
> > ...
> > [ 0.000000] efi: EFI v2.31 by American Megatrends
> > [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
> > [ 0.000000] SMBIOS 2.7 present.
> > [ 0.000000] Hypervisor detected: Xen PV
> > [ 0.000000] Xen version 4.12.
> > ...
> >
> > at shell prompt,
> >
> > xl list
> > Name ID Mem VCPUs State Time(s)
> > Domain-0 0 4016 4 r----- 5949.6
> > Xenstore 1 31 1 -b---- 0.2
> >
> > efibootmgr -v
> > BootCurrent: 0000
> > Timeout: 1 seconds
> > BootOrder: 0000
> > Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
> > dp: 04 01 2a ... 04 00
> >
> > enabling PVH Dom0, adding to grub configs,
> >
> > GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
> > GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
> >
> > then mkinitrd & grub reconfig,
> >
> > serial boot log
> > Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
> > ...
> > (XEN) [00000027dcded44e] Bootloader: EFI
> > ...
> > Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
> > ...
> > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
> > [ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
> > [ 0.000000] NX (Execute Disable) protection: active
> > [ 0.000000] SMBIOS 2.7 present.
> > [ 0.000000] Hypervisor detected: Xen HVM
> > [ 0.000000] Xen version 4.12.
> > ...
> >
> > Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
> >
> > at shell prompt,
> >
> > xl list
> > Name ID Mem VCPUs State Time(s)
> > Domain-0 0 4015 4 r----- 563.0
> > Xenstore 1 31 1 -b---- 0.0
> >
> > but, in this Dom0=pvh mode,
> >
> > efibootmgr -v
> > EFI variables are not supported on this system.
>
> So boot works as expected, it's just interaction with the EFI firmware
> by dom0 that seems to be broken. I'm currently setting up a Linux EFI
> box to test this, thanks for the report.
I've managed to reproduce this, and have a patch for the Linux kernel
for you to try. If you can give it a try and report back whether if
fixes the issue that would be appreciated.
Thanks, Roger.
---8<---
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 62f5c7045944..a748d2ea2d90 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -11,6 +11,7 @@
#include <asm/xen/interface.h>
#include <xen/xen.h>
+#include <xen/xen-ops.h>
#include <xen/interface/hvm/start_info.h>
/*
@@ -44,8 +45,6 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
static void __init init_pvh_bootparams(bool xen_guest)
{
- memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
-
if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
struct hvm_memmap_table_entry *ep;
int i;
@@ -111,8 +110,10 @@ void __init __weak xen_pvh_init(void)
static void hypervisor_specific_init(bool xen_guest)
{
- if (xen_guest)
+ if (xen_guest) {
xen_pvh_init();
+ xen_efi_init(&pvh_bootparams);
+ }
}
/*
@@ -131,6 +132,8 @@ void __init xen_prepare_pvh(void)
BUG();
}
+ memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
+
hypervisor_specific_init(xen_guest);
init_pvh_bootparams(xen_guest);
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 1fbb629a9d78..0d3365cb64de 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -158,7 +158,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
return efi_secureboot_mode_unknown;
}
-void __init xen_efi_init(void)
+void __init xen_efi_init(struct boot_params *boot_params)
{
efi_system_table_t *efi_systab_xen;
@@ -167,12 +167,12 @@ void __init xen_efi_init(void)
if (efi_systab_xen == NULL)
return;
- strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
- sizeof(boot_params.efi_info.efi_loader_signature));
- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
- boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
+ strncpy((char *)&boot_params->efi_info.efi_loader_signature, "Xen",
+ sizeof(boot_params->efi_info.efi_loader_signature));
+ boot_params->efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
+ boot_params->efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
- boot_params.secure_boot = xen_efi_get_secureboot();
+ boot_params->secure_boot = xen_efi_get_secureboot();
set_bit(EFI_BOOT, &efi.flags);
set_bit(EFI_PARAVIRT, &efi.flags);
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c54a493e139a..4722ba2966ac 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1403,7 +1403,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
/* We need this for printk timestamps */
xen_setup_runstate_info(0);
- xen_efi_init();
+ xen_efi_init(&boot_params);
/* Start the world */
#ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 35b7599d2d0b..69438fc32df5 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -27,6 +27,11 @@ void __init xen_pvh_init(void)
u64 pfn;
xen_pvh = 1;
+ /*
+ * NB: xen_domain_type must be set to HVM or else xen_domain()
+ * returns false.
+ */
+ xen_domain_type = XEN_HVM_DOMAIN;
xen_start_flags = pvh_start_info.flags;
msr = cpuid_ebx(xen_cpuid_base() + 2);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 0e60bd918695..357eb3fa2144 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -121,14 +121,6 @@ static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
void __init xen_init_apic(void);
-#ifdef CONFIG_XEN_EFI
-extern void xen_efi_init(void);
-#else
-static inline void __init xen_efi_init(void)
-{
-}
-#endif
-
__visible void xen_irq_enable_direct(void);
__visible void xen_irq_disable_direct(void);
__visible unsigned long xen_save_fl_direct(void);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 4969817124a8..51ef98e96d88 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -209,6 +209,7 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
+#ifdef CONFIG_XEN_EFI
efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
efi_status_t xen_efi_set_time(efi_time_t *tm);
efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
@@ -233,7 +234,12 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
int *reset_type);
void xen_efi_reset_system(int reset_type, efi_status_t status,
unsigned long data_size, efi_char16_t *data);
-
+extern void xen_efi_init(struct boot_params *boot_params);
+#else
+static inline void __init xen_efi_init(struct boot_params *boot_params)
+{
+}
+#endif
#ifdef CONFIG_PREEMPT
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-17 12:05 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-04-17 12:05 UTC (permalink / raw)
To: PGNet Dev; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On Tue, Apr 16, 2019 at 12:50:43PM +0200, Roger Pau Monné wrote:
> Adding the Linux Xen maintainers, in case they can provide some insight.
>
> On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
> > ref: from chat in #xen
> >
> > [08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
> >
> > I've got Xen PV Dom0 booted on a Linux UEFI box
> >
> > dmesg | grep -i "xen version"
> > [ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
> >
> > uname -rm
> > 5.0.7-lp150.5.g012b5f1-default x86_64
> >
> > lsb_release -rd
> > Description: openSUSE Leap 15.0
> > Release: 15.0
> >
> > rpm -qa | grep -i qemu | egrep "seabios|u-3"
> > qemu-seabios-1.12.0-lp150.513.13.noarch
> > qemu-3.1.0-lp150.513.13.x86_64
> >
> > rpm -qa | grep -i ovmf
> > ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
> > qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
> > ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
> >
> > rpm -qa | grep grub2 |egrep "xen|efi"
> > grub2-x86_64-efi-2.02-lp150.64.10.noarch
> > grub2-x86_64-xen-2.02-lp150.64.10.noarch
> > &
> >
> > rpm -qa | grep -i efi | grep git | sort
> > efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
> > efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
> > libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
> >
> > note these^^ EFI* tools -- src from efi master branch, pkgs available here,
> >
> > https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
> > https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
> >
> > -- were needed, as distro packaged versions' were old/problematic ...
> >
> > With this^^ config, all's well
> >
> > serial boot log
> > ...
> > [ 0.000000] efi: EFI v2.31 by American Megatrends
> > [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
> > [ 0.000000] SMBIOS 2.7 present.
> > [ 0.000000] Hypervisor detected: Xen PV
> > [ 0.000000] Xen version 4.12.
> > ...
> >
> > at shell prompt,
> >
> > xl list
> > Name ID Mem VCPUs State Time(s)
> > Domain-0 0 4016 4 r----- 5949.6
> > Xenstore 1 31 1 -b---- 0.2
> >
> > efibootmgr -v
> > BootCurrent: 0000
> > Timeout: 1 seconds
> > BootOrder: 0000
> > Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
> > dp: 04 01 2a ... 04 00
> >
> > enabling PVH Dom0, adding to grub configs,
> >
> > GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
> > GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
> >
> > then mkinitrd & grub reconfig,
> >
> > serial boot log
> > Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
> > ...
> > (XEN) [00000027dcded44e] Bootloader: EFI
> > ...
> > Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
> > ...
> > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
> > [ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
> > [ 0.000000] NX (Execute Disable) protection: active
> > [ 0.000000] SMBIOS 2.7 present.
> > [ 0.000000] Hypervisor detected: Xen HVM
> > [ 0.000000] Xen version 4.12.
> > ...
> >
> > Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
> >
> > at shell prompt,
> >
> > xl list
> > Name ID Mem VCPUs State Time(s)
> > Domain-0 0 4015 4 r----- 563.0
> > Xenstore 1 31 1 -b---- 0.0
> >
> > but, in this Dom0=pvh mode,
> >
> > efibootmgr -v
> > EFI variables are not supported on this system.
>
> So boot works as expected, it's just interaction with the EFI firmware
> by dom0 that seems to be broken. I'm currently setting up a Linux EFI
> box to test this, thanks for the report.
I've managed to reproduce this, and have a patch for the Linux kernel
for you to try. If you can give it a try and report back whether if
fixes the issue that would be appreciated.
Thanks, Roger.
---8<---
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 62f5c7045944..a748d2ea2d90 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -11,6 +11,7 @@
#include <asm/xen/interface.h>
#include <xen/xen.h>
+#include <xen/xen-ops.h>
#include <xen/interface/hvm/start_info.h>
/*
@@ -44,8 +45,6 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
static void __init init_pvh_bootparams(bool xen_guest)
{
- memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
-
if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
struct hvm_memmap_table_entry *ep;
int i;
@@ -111,8 +110,10 @@ void __init __weak xen_pvh_init(void)
static void hypervisor_specific_init(bool xen_guest)
{
- if (xen_guest)
+ if (xen_guest) {
xen_pvh_init();
+ xen_efi_init(&pvh_bootparams);
+ }
}
/*
@@ -131,6 +132,8 @@ void __init xen_prepare_pvh(void)
BUG();
}
+ memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
+
hypervisor_specific_init(xen_guest);
init_pvh_bootparams(xen_guest);
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 1fbb629a9d78..0d3365cb64de 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -158,7 +158,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
return efi_secureboot_mode_unknown;
}
-void __init xen_efi_init(void)
+void __init xen_efi_init(struct boot_params *boot_params)
{
efi_system_table_t *efi_systab_xen;
@@ -167,12 +167,12 @@ void __init xen_efi_init(void)
if (efi_systab_xen == NULL)
return;
- strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
- sizeof(boot_params.efi_info.efi_loader_signature));
- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
- boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
+ strncpy((char *)&boot_params->efi_info.efi_loader_signature, "Xen",
+ sizeof(boot_params->efi_info.efi_loader_signature));
+ boot_params->efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
+ boot_params->efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
- boot_params.secure_boot = xen_efi_get_secureboot();
+ boot_params->secure_boot = xen_efi_get_secureboot();
set_bit(EFI_BOOT, &efi.flags);
set_bit(EFI_PARAVIRT, &efi.flags);
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c54a493e139a..4722ba2966ac 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1403,7 +1403,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
/* We need this for printk timestamps */
xen_setup_runstate_info(0);
- xen_efi_init();
+ xen_efi_init(&boot_params);
/* Start the world */
#ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 35b7599d2d0b..69438fc32df5 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -27,6 +27,11 @@ void __init xen_pvh_init(void)
u64 pfn;
xen_pvh = 1;
+ /*
+ * NB: xen_domain_type must be set to HVM or else xen_domain()
+ * returns false.
+ */
+ xen_domain_type = XEN_HVM_DOMAIN;
xen_start_flags = pvh_start_info.flags;
msr = cpuid_ebx(xen_cpuid_base() + 2);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 0e60bd918695..357eb3fa2144 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -121,14 +121,6 @@ static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
void __init xen_init_apic(void);
-#ifdef CONFIG_XEN_EFI
-extern void xen_efi_init(void);
-#else
-static inline void __init xen_efi_init(void)
-{
-}
-#endif
-
__visible void xen_irq_enable_direct(void);
__visible void xen_irq_disable_direct(void);
__visible unsigned long xen_save_fl_direct(void);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 4969817124a8..51ef98e96d88 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -209,6 +209,7 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
+#ifdef CONFIG_XEN_EFI
efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
efi_status_t xen_efi_set_time(efi_time_t *tm);
efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
@@ -233,7 +234,12 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
int *reset_type);
void xen_efi_reset_system(int reset_type, efi_status_t status,
unsigned long data_size, efi_char16_t *data);
-
+extern void xen_efi_init(struct boot_params *boot_params);
+#else
+static inline void __init xen_efi_init(struct boot_params *boot_params)
+{
+}
+#endif
#ifdef CONFIG_PREEMPT
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-18 3:30 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-18 3:30 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
Thx.
not ignoring you -- opensuse kernel build system is having a hissy-fit
atm; builds are failing. :-/
if I can't get it to behave a build a nice pkg for me, I'll work on a
manual spin.
On 4/17/19 5:05 AM, Roger Pau Monné wrote:
> On Tue, Apr 16, 2019 at 12:50:43PM +0200, Roger Pau Monné wrote:
>> Adding the Linux Xen maintainers, in case they can provide some insight.
>>
>> On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
>>> ref: from chat in #xen
>>>
>>> [08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
>>>
>>> I've got Xen PV Dom0 booted on a Linux UEFI box
>>>
>>> dmesg | grep -i "xen version"
>>> [ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
>>>
>>> uname -rm
>>> 5.0.7-lp150.5.g012b5f1-default x86_64
>>>
>>> lsb_release -rd
>>> Description: openSUSE Leap 15.0
>>> Release: 15.0
>>>
>>> rpm -qa | grep -i qemu | egrep "seabios|u-3"
>>> qemu-seabios-1.12.0-lp150.513.13.noarch
>>> qemu-3.1.0-lp150.513.13.x86_64
>>>
>>> rpm -qa | grep -i ovmf
>>> ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
>>> qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
>>> ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
>>>
>>> rpm -qa | grep grub2 |egrep "xen|efi"
>>> grub2-x86_64-efi-2.02-lp150.64.10.noarch
>>> grub2-x86_64-xen-2.02-lp150.64.10.noarch
>>> &
>>>
>>> rpm -qa | grep -i efi | grep git | sort
>>> efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
>>> efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
>>> libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
>>>
>>> note these^^ EFI* tools -- src from efi master branch, pkgs available here,
>>>
>>> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
>>> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
>>>
>>> -- were needed, as distro packaged versions' were old/problematic ...
>>>
>>> With this^^ config, all's well
>>>
>>> serial boot log
>>> ...
>>> [ 0.000000] efi: EFI v2.31 by American Megatrends
>>> [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
>>> [ 0.000000] SMBIOS 2.7 present.
>>> [ 0.000000] Hypervisor detected: Xen PV
>>> [ 0.000000] Xen version 4.12.
>>> ...
>>>
>>> at shell prompt,
>>>
>>> xl list
>>> Name ID Mem VCPUs State Time(s)
>>> Domain-0 0 4016 4 r----- 5949.6
>>> Xenstore 1 31 1 -b---- 0.2
>>>
>>> efibootmgr -v
>>> BootCurrent: 0000
>>> Timeout: 1 seconds
>>> BootOrder: 0000
>>> Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
>>> dp: 04 01 2a ... 04 00
>>>
>>> enabling PVH Dom0, adding to grub configs,
>>>
>>> GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
>>> GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
>>>
>>> then mkinitrd & grub reconfig,
>>>
>>> serial boot log
>>> Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
>>> ...
>>> (XEN) [00000027dcded44e] Bootloader: EFI
>>> ...
>>> Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
>>> ...
>>> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
>>> [ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
>>> [ 0.000000] NX (Execute Disable) protection: active
>>> [ 0.000000] SMBIOS 2.7 present.
>>> [ 0.000000] Hypervisor detected: Xen HVM
>>> [ 0.000000] Xen version 4.12.
>>> ...
>>>
>>> Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
>>>
>>> at shell prompt,
>>>
>>> xl list
>>> Name ID Mem VCPUs State Time(s)
>>> Domain-0 0 4015 4 r----- 563.0
>>> Xenstore 1 31 1 -b---- 0.0
>>>
>>> but, in this Dom0=pvh mode,
>>>
>>> efibootmgr -v
>>> EFI variables are not supported on this system.
>>
>> So boot works as expected, it's just interaction with the EFI firmware
>> by dom0 that seems to be broken. I'm currently setting up a Linux EFI
>> box to test this, thanks for the report.
>
> I've managed to reproduce this, and have a patch for the Linux kernel
> for you to try. If you can give it a try and report back whether if
> fixes the issue that would be appreciated.
>
> Thanks, Roger.
>
> ---8<---
> diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
> index 62f5c7045944..a748d2ea2d90 100644
> --- a/arch/x86/platform/pvh/enlighten.c
> +++ b/arch/x86/platform/pvh/enlighten.c
> @@ -11,6 +11,7 @@
> #include <asm/xen/interface.h>
>
> #include <xen/xen.h>
> +#include <xen/xen-ops.h>
> #include <xen/interface/hvm/start_info.h>
>
> /*
> @@ -44,8 +45,6 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
>
> static void __init init_pvh_bootparams(bool xen_guest)
> {
> - memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
> -
> if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
> struct hvm_memmap_table_entry *ep;
> int i;
> @@ -111,8 +110,10 @@ void __init __weak xen_pvh_init(void)
>
> static void hypervisor_specific_init(bool xen_guest)
> {
> - if (xen_guest)
> + if (xen_guest) {
> xen_pvh_init();
> + xen_efi_init(&pvh_bootparams);
> + }
> }
>
> /*
> @@ -131,6 +132,8 @@ void __init xen_prepare_pvh(void)
> BUG();
> }
>
> + memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
> +
> hypervisor_specific_init(xen_guest);
>
> init_pvh_bootparams(xen_guest);
> diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
> index 1fbb629a9d78..0d3365cb64de 100644
> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -158,7 +158,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
> return efi_secureboot_mode_unknown;
> }
>
> -void __init xen_efi_init(void)
> +void __init xen_efi_init(struct boot_params *boot_params)
> {
> efi_system_table_t *efi_systab_xen;
>
> @@ -167,12 +167,12 @@ void __init xen_efi_init(void)
> if (efi_systab_xen == NULL)
> return;
>
> - strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
> - sizeof(boot_params.efi_info.efi_loader_signature));
> - boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> - boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
> + strncpy((char *)&boot_params->efi_info.efi_loader_signature, "Xen",
> + sizeof(boot_params->efi_info.efi_loader_signature));
> + boot_params->efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> + boot_params->efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
>
> - boot_params.secure_boot = xen_efi_get_secureboot();
> + boot_params->secure_boot = xen_efi_get_secureboot();
>
> set_bit(EFI_BOOT, &efi.flags);
> set_bit(EFI_PARAVIRT, &efi.flags);
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index c54a493e139a..4722ba2966ac 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1403,7 +1403,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
> /* We need this for printk timestamps */
> xen_setup_runstate_info(0);
>
> - xen_efi_init();
> + xen_efi_init(&boot_params);
>
> /* Start the world */
> #ifdef CONFIG_X86_32
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> index 35b7599d2d0b..69438fc32df5 100644
> --- a/arch/x86/xen/enlighten_pvh.c
> +++ b/arch/x86/xen/enlighten_pvh.c
> @@ -27,6 +27,11 @@ void __init xen_pvh_init(void)
> u64 pfn;
>
> xen_pvh = 1;
> + /*
> + * NB: xen_domain_type must be set to HVM or else xen_domain()
> + * returns false.
> + */
> + xen_domain_type = XEN_HVM_DOMAIN;
> xen_start_flags = pvh_start_info.flags;
>
> msr = cpuid_ebx(xen_cpuid_base() + 2);
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 0e60bd918695..357eb3fa2144 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -121,14 +121,6 @@ static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
>
> void __init xen_init_apic(void);
>
> -#ifdef CONFIG_XEN_EFI
> -extern void xen_efi_init(void);
> -#else
> -static inline void __init xen_efi_init(void)
> -{
> -}
> -#endif
> -
> __visible void xen_irq_enable_direct(void);
> __visible void xen_irq_disable_direct(void);
> __visible unsigned long xen_save_fl_direct(void);
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 4969817124a8..51ef98e96d88 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -209,6 +209,7 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
>
> bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
>
> +#ifdef CONFIG_XEN_EFI
> efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
> efi_status_t xen_efi_set_time(efi_time_t *tm);
> efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
> @@ -233,7 +234,12 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
> int *reset_type);
> void xen_efi_reset_system(int reset_type, efi_status_t status,
> unsigned long data_size, efi_char16_t *data);
> -
> +extern void xen_efi_init(struct boot_params *boot_params);
> +#else
> +static inline void __init xen_efi_init(struct boot_params *boot_params)
> +{
> +}
> +#endif
>
> #ifdef CONFIG_PREEMPT
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-18 3:30 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-18 3:30 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
Thx.
not ignoring you -- opensuse kernel build system is having a hissy-fit
atm; builds are failing. :-/
if I can't get it to behave a build a nice pkg for me, I'll work on a
manual spin.
On 4/17/19 5:05 AM, Roger Pau Monné wrote:
> On Tue, Apr 16, 2019 at 12:50:43PM +0200, Roger Pau Monné wrote:
>> Adding the Linux Xen maintainers, in case they can provide some insight.
>>
>> On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
>>> ref: from chat in #xen
>>>
>>> [08:53] <royger> pgnd: would be good to send an email so we can keep track of this in a more formal way.
>>>
>>> I've got Xen PV Dom0 booted on a Linux UEFI box
>>>
>>> dmesg | grep -i "xen version"
>>> [ 1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
>>>
>>> uname -rm
>>> 5.0.7-lp150.5.g012b5f1-default x86_64
>>>
>>> lsb_release -rd
>>> Description: openSUSE Leap 15.0
>>> Release: 15.0
>>>
>>> rpm -qa | grep -i qemu | egrep "seabios|u-3"
>>> qemu-seabios-1.12.0-lp150.513.13.noarch
>>> qemu-3.1.0-lp150.513.13.x86_64
>>>
>>> rpm -qa | grep -i ovmf
>>> ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
>>> qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
>>> ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
>>>
>>> rpm -qa | grep grub2 |egrep "xen|efi"
>>> grub2-x86_64-efi-2.02-lp150.64.10.noarch
>>> grub2-x86_64-xen-2.02-lp150.64.10.noarch
>>> &
>>>
>>> rpm -qa | grep -i efi | grep git | sort
>>> efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
>>> efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
>>> libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
>>>
>>> note these^^ EFI* tools -- src from efi master branch, pkgs available here,
>>>
>>> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
>>> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
>>>
>>> -- were needed, as distro packaged versions' were old/problematic ...
>>>
>>> With this^^ config, all's well
>>>
>>> serial boot log
>>> ...
>>> [ 0.000000] efi: EFI v2.31 by American Megatrends
>>> [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
>>> [ 0.000000] SMBIOS 2.7 present.
>>> [ 0.000000] Hypervisor detected: Xen PV
>>> [ 0.000000] Xen version 4.12.
>>> ...
>>>
>>> at shell prompt,
>>>
>>> xl list
>>> Name ID Mem VCPUs State Time(s)
>>> Domain-0 0 4016 4 r----- 5949.6
>>> Xenstore 1 31 1 -b---- 0.2
>>>
>>> efibootmgr -v
>>> BootCurrent: 0000
>>> Timeout: 1 seconds
>>> BootOrder: 0000
>>> Boot0000* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
>>> dp: 04 01 2a ... 04 00
>>>
>>> enabling PVH Dom0, adding to grub configs,
>>>
>>> GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
>>> GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
>>>
>>> then mkinitrd & grub reconfig,
>>>
>>> serial boot log
>>> Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
>>> ...
>>> (XEN) [00000027dcded44e] Bootloader: EFI
>>> ...
>>> Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
>>> ...
>>> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000016a2acfff] usable
>>> [ 0.000000] BIOS-e820: [mem 0x000000016a2ad000-0x000000085dffffff] unusable
>>> [ 0.000000] NX (Execute Disable) protection: active
>>> [ 0.000000] SMBIOS 2.7 present.
>>> [ 0.000000] Hypervisor detected: Xen HVM
>>> [ 0.000000] Xen version 4.12.
>>> ...
>>>
>>> Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
>>>
>>> at shell prompt,
>>>
>>> xl list
>>> Name ID Mem VCPUs State Time(s)
>>> Domain-0 0 4015 4 r----- 563.0
>>> Xenstore 1 31 1 -b---- 0.0
>>>
>>> but, in this Dom0=pvh mode,
>>>
>>> efibootmgr -v
>>> EFI variables are not supported on this system.
>>
>> So boot works as expected, it's just interaction with the EFI firmware
>> by dom0 that seems to be broken. I'm currently setting up a Linux EFI
>> box to test this, thanks for the report.
>
> I've managed to reproduce this, and have a patch for the Linux kernel
> for you to try. If you can give it a try and report back whether if
> fixes the issue that would be appreciated.
>
> Thanks, Roger.
>
> ---8<---
> diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
> index 62f5c7045944..a748d2ea2d90 100644
> --- a/arch/x86/platform/pvh/enlighten.c
> +++ b/arch/x86/platform/pvh/enlighten.c
> @@ -11,6 +11,7 @@
> #include <asm/xen/interface.h>
>
> #include <xen/xen.h>
> +#include <xen/xen-ops.h>
> #include <xen/interface/hvm/start_info.h>
>
> /*
> @@ -44,8 +45,6 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
>
> static void __init init_pvh_bootparams(bool xen_guest)
> {
> - memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
> -
> if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
> struct hvm_memmap_table_entry *ep;
> int i;
> @@ -111,8 +110,10 @@ void __init __weak xen_pvh_init(void)
>
> static void hypervisor_specific_init(bool xen_guest)
> {
> - if (xen_guest)
> + if (xen_guest) {
> xen_pvh_init();
> + xen_efi_init(&pvh_bootparams);
> + }
> }
>
> /*
> @@ -131,6 +132,8 @@ void __init xen_prepare_pvh(void)
> BUG();
> }
>
> + memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
> +
> hypervisor_specific_init(xen_guest);
>
> init_pvh_bootparams(xen_guest);
> diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
> index 1fbb629a9d78..0d3365cb64de 100644
> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -158,7 +158,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
> return efi_secureboot_mode_unknown;
> }
>
> -void __init xen_efi_init(void)
> +void __init xen_efi_init(struct boot_params *boot_params)
> {
> efi_system_table_t *efi_systab_xen;
>
> @@ -167,12 +167,12 @@ void __init xen_efi_init(void)
> if (efi_systab_xen == NULL)
> return;
>
> - strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
> - sizeof(boot_params.efi_info.efi_loader_signature));
> - boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> - boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
> + strncpy((char *)&boot_params->efi_info.efi_loader_signature, "Xen",
> + sizeof(boot_params->efi_info.efi_loader_signature));
> + boot_params->efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> + boot_params->efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
>
> - boot_params.secure_boot = xen_efi_get_secureboot();
> + boot_params->secure_boot = xen_efi_get_secureboot();
>
> set_bit(EFI_BOOT, &efi.flags);
> set_bit(EFI_PARAVIRT, &efi.flags);
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index c54a493e139a..4722ba2966ac 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1403,7 +1403,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
> /* We need this for printk timestamps */
> xen_setup_runstate_info(0);
>
> - xen_efi_init();
> + xen_efi_init(&boot_params);
>
> /* Start the world */
> #ifdef CONFIG_X86_32
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> index 35b7599d2d0b..69438fc32df5 100644
> --- a/arch/x86/xen/enlighten_pvh.c
> +++ b/arch/x86/xen/enlighten_pvh.c
> @@ -27,6 +27,11 @@ void __init xen_pvh_init(void)
> u64 pfn;
>
> xen_pvh = 1;
> + /*
> + * NB: xen_domain_type must be set to HVM or else xen_domain()
> + * returns false.
> + */
> + xen_domain_type = XEN_HVM_DOMAIN;
> xen_start_flags = pvh_start_info.flags;
>
> msr = cpuid_ebx(xen_cpuid_base() + 2);
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 0e60bd918695..357eb3fa2144 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -121,14 +121,6 @@ static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
>
> void __init xen_init_apic(void);
>
> -#ifdef CONFIG_XEN_EFI
> -extern void xen_efi_init(void);
> -#else
> -static inline void __init xen_efi_init(void)
> -{
> -}
> -#endif
> -
> __visible void xen_irq_enable_direct(void);
> __visible void xen_irq_disable_direct(void);
> __visible unsigned long xen_save_fl_direct(void);
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 4969817124a8..51ef98e96d88 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -209,6 +209,7 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
>
> bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
>
> +#ifdef CONFIG_XEN_EFI
> efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
> efi_status_t xen_efi_set_time(efi_time_t *tm);
> efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
> @@ -233,7 +234,12 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
> int *reset_type);
> void xen_efi_reset_system(int reset_type, efi_status_t status,
> unsigned long data_size, efi_char16_t *data);
> -
> +extern void xen_efi_init(struct boot_params *boot_params);
> +#else
> +static inline void __init xen_efi_init(struct boot_params *boot_params)
> +{
> +}
> +#endif
>
> #ifdef CONFIG_PREEMPT
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-18 4:51 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-18 4:51 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On 4/17/19 8:30 PM, PGNet Dev wrote:
> Thx.
>
> not ignoring you -- opensuse kernel build system is having a hissy-fit
> atm; builds are failing. :-/
>
> if I can't get it to behave a build a nice pkg for me, I'll work on a
> manual spin.
With a pkg instance of your-patched kernel 5.0.8,
https://build.opensuse.org/build/home:pgnd:Kernel:stable/openSUSE_Leap_15.0/x86_64/kernel-source/_log
...
[ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.suse/vfio-type1-limit-dma-mappings-per-container
>>> [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.addon/xen-pvh-uefi.patch
[ 79s] ++ find . -name .gitignore
...
and Dom=pvh enabled,
...
Xen 4.12.0_10-lp150.647 (c/s ) EFI loader
Using configuration file 'xen-4.12.0_10-lp150.647.cfg'
vmlinuz-5.0.8-lp150.2.g8b88553-default: 0x000000008b899000-0x000000008c068db8
initrd-5.0.8-lp150.2.g8b88553-default: 0x000000008a720000-0x000000008b898618
...
(XEN) [00000027c63c1674] Xen version 4.12.0_10-lp150.647
...
(XEN) [00000027caa3ad80] Command line: dom0=pvh dom0-iommu=map-reserved ...
...
it boots OK,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 62.1
Xenstore 1 31 1 -b---- 0.0
but still
efibootmgr -v
EFI variables are not supported on this system.
error trace:
Given some of the build 'fun' I've been having today, I'll take a closer look at the patched kernel build in the morning -- to make doubly sure I actually built correctly.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-18 4:51 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-18 4:51 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On 4/17/19 8:30 PM, PGNet Dev wrote:
> Thx.
>
> not ignoring you -- opensuse kernel build system is having a hissy-fit
> atm; builds are failing. :-/
>
> if I can't get it to behave a build a nice pkg for me, I'll work on a
> manual spin.
With a pkg instance of your-patched kernel 5.0.8,
https://build.opensuse.org/build/home:pgnd:Kernel:stable/openSUSE_Leap_15.0/x86_64/kernel-source/_log
...
[ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.suse/vfio-type1-limit-dma-mappings-per-container
>>> [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.addon/xen-pvh-uefi.patch
[ 79s] ++ find . -name .gitignore
...
and Dom=pvh enabled,
...
Xen 4.12.0_10-lp150.647 (c/s ) EFI loader
Using configuration file 'xen-4.12.0_10-lp150.647.cfg'
vmlinuz-5.0.8-lp150.2.g8b88553-default: 0x000000008b899000-0x000000008c068db8
initrd-5.0.8-lp150.2.g8b88553-default: 0x000000008a720000-0x000000008b898618
...
(XEN) [00000027c63c1674] Xen version 4.12.0_10-lp150.647
...
(XEN) [00000027caa3ad80] Command line: dom0=pvh dom0-iommu=map-reserved ...
...
it boots OK,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 62.1
Xenstore 1 31 1 -b---- 0.0
but still
efibootmgr -v
EFI variables are not supported on this system.
error trace:
Given some of the build 'fun' I've been having today, I'll take a closer look at the patched kernel build in the morning -- to make doubly sure I actually built correctly.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-18 12:52 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-04-18 12:52 UTC (permalink / raw)
To: PGNet Dev; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On Wed, Apr 17, 2019 at 09:51:47PM -0700, PGNet Dev wrote:
> On 4/17/19 8:30 PM, PGNet Dev wrote:
> > Thx.
> >
> > not ignoring you -- opensuse kernel build system is having a hissy-fit
> > atm; builds are failing. :-/
> >
> > if I can't get it to behave a build a nice pkg for me, I'll work on a
> > manual spin.
>
> With a pkg instance of your-patched kernel 5.0.8,
>
> https://build.opensuse.org/build/home:pgnd:Kernel:stable/openSUSE_Leap_15.0/x86_64/kernel-source/_log
> ...
> [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.suse/vfio-type1-limit-dma-mappings-per-container
> >>> [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.addon/xen-pvh-uefi.patch
> [ 79s] ++ find . -name .gitignore
> ...
>
> and Dom=pvh enabled,
>
> ...
> Xen 4.12.0_10-lp150.647 (c/s ) EFI loader
> Using configuration file 'xen-4.12.0_10-lp150.647.cfg'
> vmlinuz-5.0.8-lp150.2.g8b88553-default: 0x000000008b899000-0x000000008c068db8
> initrd-5.0.8-lp150.2.g8b88553-default: 0x000000008a720000-0x000000008b898618
> ...
> (XEN) [00000027c63c1674] Xen version 4.12.0_10-lp150.647
> ...
> (XEN) [00000027caa3ad80] Command line: dom0=pvh dom0-iommu=map-reserved ...
> ...
>
> it boots OK,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4015 4 r----- 62.1
> Xenstore 1 31 1 -b---- 0.0
>
> but still
>
> efibootmgr -v
> EFI variables are not supported on this system.
> error trace:
>
> Given some of the build 'fun' I've been having today, I'll take a closer look at the patched kernel build in the morning -- to make doubly sure I actually built correctly.
OK, that patch seemed to fix the issue for me, and I managed to get
efibootmgr to display the firmware data from a PVH dom0.
Can you provide the full serial output of Xen plus Linux booting with
dom0=pvh and the patch below applied?
Note that this is the previously provided patch with added debug
messages.
Thanks, Roger.
---8<---
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 62f5c7045944..a748d2ea2d90 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -11,6 +11,7 @@
#include <asm/xen/interface.h>
#include <xen/xen.h>
+#include <xen/xen-ops.h>
#include <xen/interface/hvm/start_info.h>
/*
@@ -44,8 +45,6 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
static void __init init_pvh_bootparams(bool xen_guest)
{
- memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
-
if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
struct hvm_memmap_table_entry *ep;
int i;
@@ -111,8 +110,10 @@ void __init __weak xen_pvh_init(void)
static void hypervisor_specific_init(bool xen_guest)
{
- if (xen_guest)
+ if (xen_guest) {
xen_pvh_init();
+ xen_efi_init(&pvh_bootparams);
+ }
}
/*
@@ -131,6 +132,8 @@ void __init xen_prepare_pvh(void)
BUG();
}
+ memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
+
hypervisor_specific_init(xen_guest);
init_pvh_bootparams(xen_guest);
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 1fbb629a9d78..cdefa2a6b15d 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -16,6 +16,8 @@
#include <asm/setup.h>
#include <asm/xen/hypercall.h>
+#include <xen/hvc-console.h>
+
static efi_char16_t vendor[100] __initdata;
static efi_system_table_t efi_systab_xen __initdata = {
@@ -53,8 +55,10 @@ static efi_system_table_t __init *xen_efi_probe(void)
};
union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
- if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
+ if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0) {
+xen_raw_printk("Not initial domain or no EFI_INFO\n");
return NULL;
+ }
/* Here we know that Xen runs on EFI platform. */
@@ -158,23 +162,28 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
return efi_secureboot_mode_unknown;
}
-void __init xen_efi_init(void)
+void __init xen_efi_init(struct boot_params *boot_params)
{
efi_system_table_t *efi_systab_xen;
+xen_raw_printk("Proving for XEN-EFI presence\n");
+
efi_systab_xen = xen_efi_probe();
- if (efi_systab_xen == NULL)
+ if (efi_systab_xen == NULL) {
+xen_raw_printk("No XEN-EFI detected\n");
return;
+ }
- strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
- sizeof(boot_params.efi_info.efi_loader_signature));
- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
- boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
+ strncpy((char *)&boot_params->efi_info.efi_loader_signature, "Xen",
+ sizeof(boot_params->efi_info.efi_loader_signature));
+ boot_params->efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
+ boot_params->efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
- boot_params.secure_boot = xen_efi_get_secureboot();
+ boot_params->secure_boot = xen_efi_get_secureboot();
set_bit(EFI_BOOT, &efi.flags);
set_bit(EFI_PARAVIRT, &efi.flags);
set_bit(EFI_64BIT, &efi.flags);
+xen_raw_printk("XEN-EFI correctly initialized\n");
}
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c54a493e139a..4722ba2966ac 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1403,7 +1403,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
/* We need this for printk timestamps */
xen_setup_runstate_info(0);
- xen_efi_init();
+ xen_efi_init(&boot_params);
/* Start the world */
#ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 35b7599d2d0b..bbffa409e0e8 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -27,6 +27,7 @@ void __init xen_pvh_init(void)
u64 pfn;
xen_pvh = 1;
+ xen_domain_type = XEN_HVM_DOMAIN;
xen_start_flags = pvh_start_info.flags;
msr = cpuid_ebx(xen_cpuid_base() + 2);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 0e60bd918695..357eb3fa2144 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -121,14 +121,6 @@ static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
void __init xen_init_apic(void);
-#ifdef CONFIG_XEN_EFI
-extern void xen_efi_init(void);
-#else
-static inline void __init xen_efi_init(void)
-{
-}
-#endif
-
__visible void xen_irq_enable_direct(void);
__visible void xen_irq_disable_direct(void);
__visible unsigned long xen_save_fl_direct(void);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 4969817124a8..51ef98e96d88 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -209,6 +209,7 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
+#ifdef CONFIG_XEN_EFI
efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
efi_status_t xen_efi_set_time(efi_time_t *tm);
efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
@@ -233,7 +234,12 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
int *reset_type);
void xen_efi_reset_system(int reset_type, efi_status_t status,
unsigned long data_size, efi_char16_t *data);
-
+extern void xen_efi_init(struct boot_params *boot_params);
+#else
+static inline void __init xen_efi_init(struct boot_params *boot_params)
+{
+}
+#endif
#ifdef CONFIG_PREEMPT
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-18 12:52 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-04-18 12:52 UTC (permalink / raw)
To: PGNet Dev; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On Wed, Apr 17, 2019 at 09:51:47PM -0700, PGNet Dev wrote:
> On 4/17/19 8:30 PM, PGNet Dev wrote:
> > Thx.
> >
> > not ignoring you -- opensuse kernel build system is having a hissy-fit
> > atm; builds are failing. :-/
> >
> > if I can't get it to behave a build a nice pkg for me, I'll work on a
> > manual spin.
>
> With a pkg instance of your-patched kernel 5.0.8,
>
> https://build.opensuse.org/build/home:pgnd:Kernel:stable/openSUSE_Leap_15.0/x86_64/kernel-source/_log
> ...
> [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.suse/vfio-type1-limit-dma-mappings-per-container
> >>> [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.addon/xen-pvh-uefi.patch
> [ 79s] ++ find . -name .gitignore
> ...
>
> and Dom=pvh enabled,
>
> ...
> Xen 4.12.0_10-lp150.647 (c/s ) EFI loader
> Using configuration file 'xen-4.12.0_10-lp150.647.cfg'
> vmlinuz-5.0.8-lp150.2.g8b88553-default: 0x000000008b899000-0x000000008c068db8
> initrd-5.0.8-lp150.2.g8b88553-default: 0x000000008a720000-0x000000008b898618
> ...
> (XEN) [00000027c63c1674] Xen version 4.12.0_10-lp150.647
> ...
> (XEN) [00000027caa3ad80] Command line: dom0=pvh dom0-iommu=map-reserved ...
> ...
>
> it boots OK,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4015 4 r----- 62.1
> Xenstore 1 31 1 -b---- 0.0
>
> but still
>
> efibootmgr -v
> EFI variables are not supported on this system.
> error trace:
>
> Given some of the build 'fun' I've been having today, I'll take a closer look at the patched kernel build in the morning -- to make doubly sure I actually built correctly.
OK, that patch seemed to fix the issue for me, and I managed to get
efibootmgr to display the firmware data from a PVH dom0.
Can you provide the full serial output of Xen plus Linux booting with
dom0=pvh and the patch below applied?
Note that this is the previously provided patch with added debug
messages.
Thanks, Roger.
---8<---
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 62f5c7045944..a748d2ea2d90 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -11,6 +11,7 @@
#include <asm/xen/interface.h>
#include <xen/xen.h>
+#include <xen/xen-ops.h>
#include <xen/interface/hvm/start_info.h>
/*
@@ -44,8 +45,6 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
static void __init init_pvh_bootparams(bool xen_guest)
{
- memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
-
if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
struct hvm_memmap_table_entry *ep;
int i;
@@ -111,8 +110,10 @@ void __init __weak xen_pvh_init(void)
static void hypervisor_specific_init(bool xen_guest)
{
- if (xen_guest)
+ if (xen_guest) {
xen_pvh_init();
+ xen_efi_init(&pvh_bootparams);
+ }
}
/*
@@ -131,6 +132,8 @@ void __init xen_prepare_pvh(void)
BUG();
}
+ memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
+
hypervisor_specific_init(xen_guest);
init_pvh_bootparams(xen_guest);
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 1fbb629a9d78..cdefa2a6b15d 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -16,6 +16,8 @@
#include <asm/setup.h>
#include <asm/xen/hypercall.h>
+#include <xen/hvc-console.h>
+
static efi_char16_t vendor[100] __initdata;
static efi_system_table_t efi_systab_xen __initdata = {
@@ -53,8 +55,10 @@ static efi_system_table_t __init *xen_efi_probe(void)
};
union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
- if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
+ if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0) {
+xen_raw_printk("Not initial domain or no EFI_INFO\n");
return NULL;
+ }
/* Here we know that Xen runs on EFI platform. */
@@ -158,23 +162,28 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
return efi_secureboot_mode_unknown;
}
-void __init xen_efi_init(void)
+void __init xen_efi_init(struct boot_params *boot_params)
{
efi_system_table_t *efi_systab_xen;
+xen_raw_printk("Proving for XEN-EFI presence\n");
+
efi_systab_xen = xen_efi_probe();
- if (efi_systab_xen == NULL)
+ if (efi_systab_xen == NULL) {
+xen_raw_printk("No XEN-EFI detected\n");
return;
+ }
- strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
- sizeof(boot_params.efi_info.efi_loader_signature));
- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
- boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
+ strncpy((char *)&boot_params->efi_info.efi_loader_signature, "Xen",
+ sizeof(boot_params->efi_info.efi_loader_signature));
+ boot_params->efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
+ boot_params->efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
- boot_params.secure_boot = xen_efi_get_secureboot();
+ boot_params->secure_boot = xen_efi_get_secureboot();
set_bit(EFI_BOOT, &efi.flags);
set_bit(EFI_PARAVIRT, &efi.flags);
set_bit(EFI_64BIT, &efi.flags);
+xen_raw_printk("XEN-EFI correctly initialized\n");
}
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c54a493e139a..4722ba2966ac 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1403,7 +1403,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
/* We need this for printk timestamps */
xen_setup_runstate_info(0);
- xen_efi_init();
+ xen_efi_init(&boot_params);
/* Start the world */
#ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 35b7599d2d0b..bbffa409e0e8 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -27,6 +27,7 @@ void __init xen_pvh_init(void)
u64 pfn;
xen_pvh = 1;
+ xen_domain_type = XEN_HVM_DOMAIN;
xen_start_flags = pvh_start_info.flags;
msr = cpuid_ebx(xen_cpuid_base() + 2);
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 0e60bd918695..357eb3fa2144 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -121,14 +121,6 @@ static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
void __init xen_init_apic(void);
-#ifdef CONFIG_XEN_EFI
-extern void xen_efi_init(void);
-#else
-static inline void __init xen_efi_init(void)
-{
-}
-#endif
-
__visible void xen_irq_enable_direct(void);
__visible void xen_irq_disable_direct(void);
__visible unsigned long xen_save_fl_direct(void);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 4969817124a8..51ef98e96d88 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -209,6 +209,7 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
+#ifdef CONFIG_XEN_EFI
efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
efi_status_t xen_efi_set_time(efi_time_t *tm);
efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
@@ -233,7 +234,12 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
int *reset_type);
void xen_efi_reset_system(int reset_type, efi_status_t status,
unsigned long data_size, efi_char16_t *data);
-
+extern void xen_efi_init(struct boot_params *boot_params);
+#else
+static inline void __init xen_efi_init(struct boot_params *boot_params)
+{
+}
+#endif
#ifdef CONFIG_PREEMPT
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-20 14:56 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-20 14:56 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On 4/18/19 5:52 AM, Roger Pau Monné wrote:
>> Given some of the build 'fun' I've been having today, I'll take a closer look at the patched kernel build in the morning -- to make doubly sure I actually built correctly.
finally! got that cleaned up.
> OK, that patch seemed to fix the issue for me, and I managed to get
> efibootmgr to display the firmware data from a PVH dom0.
>
> Can you provide the full serial output of Xen plus Linux booting with
> dom0=pvh and the patch below applied?
>
> Note that this is the previously provided patch with added debug
> messages.
with your latest patch applied, packages available from
https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/kernel-source?expand=0
it appears to boot OK -- with EFI tools correctly functioning.
serial output includes,
...
(XEN) [00000027b5faa36d] Bootloader: EFI
(XEN) [00000027b6afda74] Command line: dom0=pvh dom0-iommu=map-reserved dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcp
...
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
...
[ 3.780634] Registered efivars operations
...
[ 6.903746] EFI Variables Facility v0.08 2004-May-17
...
[ 6.992034] Couldn't get size: 0x800000000000000e
[ 6.997132] MODSIGN: Couldn't get UEFI db list
[ 7.002052] Couldn't get size: 0x800000000000000e
[ 7.007148] Couldn't get UEFI MokListRT
[ 7.011379] Couldn't get size: 0x800000000000000e
[ 7.016438] Couldn't get UEFI dbx list
...
xen's up,
uname -rm
5.0.8-21.g4835ec0-default x86_64
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 117.1
Xenstore 1 31 1 -b---- 0.0
as are efi tools
efibootmgr -V
version 17
efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003
Boot0000* openSUSE-XSVR HD(2,GPT,981...)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0002* UEFI OS HD(2,GPT,981...)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003* UEFI: Built-in EFI Shell VenMedia(502...)..BO
assuming nothing's changed, other than logging, in your recent patch, the problem in my last attempt was due to the kernel build mess on my end; likely equal portions of buildsystem challenges and pebkac.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-04-20 14:56 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-04-20 14:56 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky
On 4/18/19 5:52 AM, Roger Pau Monné wrote:
>> Given some of the build 'fun' I've been having today, I'll take a closer look at the patched kernel build in the morning -- to make doubly sure I actually built correctly.
finally! got that cleaned up.
> OK, that patch seemed to fix the issue for me, and I managed to get
> efibootmgr to display the firmware data from a PVH dom0.
>
> Can you provide the full serial output of Xen plus Linux booting with
> dom0=pvh and the patch below applied?
>
> Note that this is the previously provided patch with added debug
> messages.
with your latest patch applied, packages available from
https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/kernel-source?expand=0
it appears to boot OK -- with EFI tools correctly functioning.
serial output includes,
...
(XEN) [00000027b5faa36d] Bootloader: EFI
(XEN) [00000027b6afda74] Command line: dom0=pvh dom0-iommu=map-reserved dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcp
...
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490
...
[ 3.780634] Registered efivars operations
...
[ 6.903746] EFI Variables Facility v0.08 2004-May-17
...
[ 6.992034] Couldn't get size: 0x800000000000000e
[ 6.997132] MODSIGN: Couldn't get UEFI db list
[ 7.002052] Couldn't get size: 0x800000000000000e
[ 7.007148] Couldn't get UEFI MokListRT
[ 7.011379] Couldn't get size: 0x800000000000000e
[ 7.016438] Couldn't get UEFI dbx list
...
xen's up,
uname -rm
5.0.8-21.g4835ec0-default x86_64
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 117.1
Xenstore 1 31 1 -b---- 0.0
as are efi tools
efibootmgr -V
version 17
efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003
Boot0000* openSUSE-XSVR HD(2,GPT,981...)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0002* UEFI OS HD(2,GPT,981...)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003* UEFI: Built-in EFI Shell VenMedia(502...)..BO
assuming nothing's changed, other than logging, in your recent patch, the problem in my last attempt was due to the kernel build mess on my end; likely equal portions of buildsystem challenges and pebkac.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-05-24 15:33 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-05-24 15:33 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, boris.ostrovsky
After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0 successfully boots in PVH mode (dom0=pvh ...), with efi vars available so that efibootmgr functions,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 847.6
Xenstore 1 31 1 -b---- 0.0
dmesg | grep -i pvh
[ 0.181973] Booting paravirtualized kernel on Xen PVH
efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003
Boot0000* xensvr HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0002* UEFI OS HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003* UEFI: Built-in EFI Shell VenMedia(5126c8dc-e6a4-b3e9-a119-cf41345c9754)..BO
From
https://xenproject.org/2018/07/10/xen-project-hypervisor-4-11-brings-cleaner-architecture-to-hypervisor-core-technologies/
I understand that PVH Dom0 *removes* qemu dependency,
"PVH Dom0 Reduces the Attack Surface of Xen Project Based Systems
PVH combines the best of PV and HVM mode to simplify the interface between operating systems with Xen Project Support and the Xen Project Hypervisor and to reduce the attack surface of Xen Project Software. PVH guests are lightweight HVM guests that use hardware virtualization support for memory and privileged instructions. PVH does not require QEMU.
Xen Project 4.11 adds experimental PVH Dom0 support by calling Xen via dom0=pvh on the command line. Running a PVH Dom0 removes approximately 1 million lines of QEMU code from Xen Project’s computing base shrinking the attack surface of Xen Project based systems."
Checking, qemu is still resident,
ps ax | grep qemu
1895 ? Sl 0:00 /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile /var/run/xen/qemu-dom0.pid
Is this still expected?
If so, why the *i386* variant, not /usr/bin/qemu-system-x86_64?
If not, is there some additional config required to disable its use here?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-05-24 15:33 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-05-24 15:33 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, boris.ostrovsky
After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0 successfully boots in PVH mode (dom0=pvh ...), with efi vars available so that efibootmgr functions,
xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4015 4 r----- 847.6
Xenstore 1 31 1 -b---- 0.0
dmesg | grep -i pvh
[ 0.181973] Booting paravirtualized kernel on Xen PVH
efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003
Boot0000* xensvr HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0002* UEFI OS HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003* UEFI: Built-in EFI Shell VenMedia(5126c8dc-e6a4-b3e9-a119-cf41345c9754)..BO
From
https://xenproject.org/2018/07/10/xen-project-hypervisor-4-11-brings-cleaner-architecture-to-hypervisor-core-technologies/
I understand that PVH Dom0 *removes* qemu dependency,
"PVH Dom0 Reduces the Attack Surface of Xen Project Based Systems
PVH combines the best of PV and HVM mode to simplify the interface between operating systems with Xen Project Support and the Xen Project Hypervisor and to reduce the attack surface of Xen Project Software. PVH guests are lightweight HVM guests that use hardware virtualization support for memory and privileged instructions. PVH does not require QEMU.
Xen Project 4.11 adds experimental PVH Dom0 support by calling Xen via dom0=pvh on the command line. Running a PVH Dom0 removes approximately 1 million lines of QEMU code from Xen Project’s computing base shrinking the attack surface of Xen Project based systems."
Checking, qemu is still resident,
ps ax | grep qemu
1895 ? Sl 0:00 /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile /var/run/xen/qemu-dom0.pid
Is this still expected?
If so, why the *i386* variant, not /usr/bin/qemu-system-x86_64?
If not, is there some additional config required to disable its use here?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-05-27 11:41 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-05-27 11:41 UTC (permalink / raw)
To: PGNet Dev; +Cc: xen-devel, boris.ostrovsky
On Fri, May 24, 2019 at 08:33:51AM -0700, PGNet Dev wrote:
> After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0 successfully boots in PVH mode (dom0=pvh ...), with efi vars available so that efibootmgr functions,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4015 4 r----- 847.6
> Xenstore 1 31 1 -b---- 0.0
>
> dmesg | grep -i pvh
> [ 0.181973] Booting paravirtualized kernel on Xen PVH
>
> efibootmgr
> BootCurrent: 0000
> Timeout: 1 seconds
> BootOrder: 0000,0002,0003
> Boot0000* xensvr HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
> Boot0002* UEFI OS HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
> Boot0003* UEFI: Built-in EFI Shell VenMedia(5126c8dc-e6a4-b3e9-a119-cf41345c9754)..BO
>
> From
>
> https://xenproject.org/2018/07/10/xen-project-hypervisor-4-11-brings-cleaner-architecture-to-hypervisor-core-technologies/
>
> I understand that PVH Dom0 *removes* qemu dependency,
Let's clarify this a bit:
* PVH domU doesn't require a QEMU to run (as opposed to a HVM domU).
* PVH dom0 also doesn't require a QEMU, the more that running a QEMU for
dom0 is very, very complex if possible (you would have to boot
something like a stubdom before booting dom0).
Classic PV dom0 also doesn't have a QEMU dependency, and the QEMU
process that you see running in dom0 when using either a PV or PVH
dom0 is not used for emulation (see below).
> "PVH Dom0 Reduces the Attack Surface of Xen Project Based Systems
>
> PVH combines the best of PV and HVM mode to simplify the interface between operating systems with Xen Project Support and the Xen Project Hypervisor and to reduce the attack surface of Xen Project Software. PVH guests are lightweight HVM guests that use hardware virtualization support for memory and privileged instructions. PVH does not require QEMU.
>
> Xen Project 4.11 adds experimental PVH Dom0 support by calling Xen via dom0=pvh on the command line. Running a PVH Dom0 removes approximately 1 million lines of QEMU code from Xen Project’s computing base shrinking the attack surface of Xen Project based systems."
>
> Checking, qemu is still resident,
>
> ps ax | grep qemu
> 1895 ? Sl 0:00 /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile /var/run/xen/qemu-dom0.pid
>
> Is this still expected?
Yes, this QEMU is not emulating any devices for dom0, it is just used
to locally attach disks to dom0 in order to run pygrub (or any
dom0-based bootloader).
> If so, why the *i386* variant, not /usr/bin/qemu-system-x86_64?
It makes no difference: when using QEMU together with Xen the CPU
emulation parts of QEMU are not used, hence it doesn't matter if the
i386 or the x86_64 variants are used, both provide the same set of
emulated devices, which is what Xen guests use from QEMU.
> If not, is there some additional config required to disable its use here?
You can modify the init script (xencommons) or disable
xen-qemu-dom0-disk-backend if using systemd to prevent launching a
QEMU for dom0, but then certain toolstack operations would fail (ie:
trying to boot a domU with a qcow disk using pygrub).
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-05-27 11:41 ` Roger Pau Monné
0 siblings, 0 replies; 20+ messages in thread
From: Roger Pau Monné @ 2019-05-27 11:41 UTC (permalink / raw)
To: PGNet Dev; +Cc: xen-devel, boris.ostrovsky
On Fri, May 24, 2019 at 08:33:51AM -0700, PGNet Dev wrote:
> After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0 successfully boots in PVH mode (dom0=pvh ...), with efi vars available so that efibootmgr functions,
>
> xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 4015 4 r----- 847.6
> Xenstore 1 31 1 -b---- 0.0
>
> dmesg | grep -i pvh
> [ 0.181973] Booting paravirtualized kernel on Xen PVH
>
> efibootmgr
> BootCurrent: 0000
> Timeout: 1 seconds
> BootOrder: 0000,0002,0003
> Boot0000* xensvr HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
> Boot0002* UEFI OS HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
> Boot0003* UEFI: Built-in EFI Shell VenMedia(5126c8dc-e6a4-b3e9-a119-cf41345c9754)..BO
>
> From
>
> https://xenproject.org/2018/07/10/xen-project-hypervisor-4-11-brings-cleaner-architecture-to-hypervisor-core-technologies/
>
> I understand that PVH Dom0 *removes* qemu dependency,
Let's clarify this a bit:
* PVH domU doesn't require a QEMU to run (as opposed to a HVM domU).
* PVH dom0 also doesn't require a QEMU, the more that running a QEMU for
dom0 is very, very complex if possible (you would have to boot
something like a stubdom before booting dom0).
Classic PV dom0 also doesn't have a QEMU dependency, and the QEMU
process that you see running in dom0 when using either a PV or PVH
dom0 is not used for emulation (see below).
> "PVH Dom0 Reduces the Attack Surface of Xen Project Based Systems
>
> PVH combines the best of PV and HVM mode to simplify the interface between operating systems with Xen Project Support and the Xen Project Hypervisor and to reduce the attack surface of Xen Project Software. PVH guests are lightweight HVM guests that use hardware virtualization support for memory and privileged instructions. PVH does not require QEMU.
>
> Xen Project 4.11 adds experimental PVH Dom0 support by calling Xen via dom0=pvh on the command line. Running a PVH Dom0 removes approximately 1 million lines of QEMU code from Xen Project’s computing base shrinking the attack surface of Xen Project based systems."
>
> Checking, qemu is still resident,
>
> ps ax | grep qemu
> 1895 ? Sl 0:00 /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile /var/run/xen/qemu-dom0.pid
>
> Is this still expected?
Yes, this QEMU is not emulating any devices for dom0, it is just used
to locally attach disks to dom0 in order to run pygrub (or any
dom0-based bootloader).
> If so, why the *i386* variant, not /usr/bin/qemu-system-x86_64?
It makes no difference: when using QEMU together with Xen the CPU
emulation parts of QEMU are not used, hence it doesn't matter if the
i386 or the x86_64 variants are used, both provide the same set of
emulated devices, which is what Xen guests use from QEMU.
> If not, is there some additional config required to disable its use here?
You can modify the init script (xencommons) or disable
xen-qemu-dom0-disk-backend if using systemd to prevent launching a
QEMU for dom0, but then certain toolstack operations would fail (ie:
trying to boot a domU with a qcow disk using pygrub).
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-05-27 14:37 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-05-27 14:37 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, boris.ostrovsky
> Let's clarify this a bit:
a very useful & clear reply -- if that's all in the docs/wiki already, I
managed to miss it!
thx!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
@ 2019-05-27 14:37 ` PGNet Dev
0 siblings, 0 replies; 20+ messages in thread
From: PGNet Dev @ 2019-05-27 14:37 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, boris.ostrovsky
> Let's clarify this a bit:
a very useful & clear reply -- if that's all in the docs/wiki already, I
managed to miss it!
thx!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-05-27 14:37 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-15 22:27 Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot PGNet Dev
2019-04-15 22:27 ` [Xen-devel] " PGNet Dev
2019-04-16 10:50 ` Roger Pau Monné
2019-04-16 10:50 ` [Xen-devel] " Roger Pau Monné
2019-04-17 12:05 ` Roger Pau Monné
2019-04-17 12:05 ` [Xen-devel] " Roger Pau Monné
2019-04-18 3:30 ` PGNet Dev
2019-04-18 3:30 ` [Xen-devel] " PGNet Dev
2019-04-18 4:51 ` PGNet Dev
2019-04-18 4:51 ` [Xen-devel] " PGNet Dev
2019-04-18 12:52 ` Roger Pau Monné
2019-04-18 12:52 ` [Xen-devel] " Roger Pau Monné
2019-04-20 14:56 ` PGNet Dev
2019-04-20 14:56 ` [Xen-devel] " PGNet Dev
2019-05-24 15:33 ` PGNet Dev
2019-05-24 15:33 ` [Xen-devel] " PGNet Dev
2019-05-27 11:41 ` Roger Pau Monné
2019-05-27 11:41 ` [Xen-devel] " Roger Pau Monné
2019-05-27 14:37 ` PGNet Dev
2019-05-27 14:37 ` [Xen-devel] " PGNet Dev
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.