OVMF (open virtual machine firmware) is used to provide UEFI support for virtual machines. It was first introduced about a year ago but was disabled due to compilation problem. Now that the compilation problem is resolved we can reintorduce it. OVMF tree can be pulled from git://xenbits.xen.org/people/liuw/ovmf.git for-xenbits Wei. Change from V2: * update Config.mk before enabling OVMF build Ian Campbell (3): tools: clone ovmf to ovmf-dir directory tools: support system supplied ovmf binary tools: Enable OVMF build by default Wei Liu (2): libxl: bump LIBXL_MAXMEM_CONSTANT to 2048 Config.mk: update OVMF changeset Config.mk | 2 +- Makefile | 4 ++++ config/Tools.mk.in | 1 + tools/configure | 20 +++++++++++++++----- tools/configure.ac | 13 ++++++++++++- tools/firmware/Makefile | 31 ++++++++++++------------------- tools/firmware/hvmloader/Makefile | 8 ++++++-- tools/libxl/libxl_internal.h | 2 +- 8 files changed, 52 insertions(+), 29 deletions(-) -- 1.7.10.4
When using OVMF we need to have 1MiB of memory in place for firmware. Without this change we have: (XEN) HVM128: Loading OVMF ... (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) This is not a fatal error as hvmloader will instead use low memory to load OVMF, but it''s better to eliminate such error. Changing this constant doesn''t necessary increase the total amount of memory a guest uses because it''s just a limit. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Ian Jackson <ian.jackson@eu.citrix.com> --- tools/libxl/libxl_internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 165dc00..908af20 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -87,7 +87,7 @@ #define LIBXL_QEMU_BODGE_TIMEOUT 2 #define LIBXL_XENCONSOLE_LIMIT 1048576 #define LIBXL_XENCONSOLE_PROTOCOL "vt100" -#define LIBXL_MAXMEM_CONSTANT 1024 +#define LIBXL_MAXMEM_CONSTANT 2048 #define LIBXL_PV_EXTRA_MEMORY 1024 #define LIBXL_HVM_EXTRA_MEMORY 2048 #define LIBXL_MIN_DOM0_MEM (128*1024) -- 1.7.10.4
Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- Config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Config.mk b/Config.mk index 1879454..dad2dc4 100644 --- a/Config.mk +++ b/Config.mk @@ -232,7 +232,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git endif -OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 +OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807 QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1 # Fri Aug 2 14:12:09 2013 -0400 -- 1.7.10.4
From: Ian Campbell <ian.campbell@citrix.com> for consistency with other foo-dir e.g. qemu, seabios. Remove obsolete ovmf-find target. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- Makefile | 4 ++++ tools/firmware/Makefile | 29 ++++++++++------------------- tools/firmware/hvmloader/Makefile | 2 +- 3 files changed, 15 insertions(+), 20 deletions(-) diff --git a/Makefile b/Makefile index d915660..4e48457 100644 --- a/Makefile +++ b/Makefile @@ -110,6 +110,10 @@ endif tools/firmware/seabios-dir-force-update: $(MAKE) -C tools/firmware seabios-dir-force-update +.PHONY: tools/firmware/ovmf-dir-force-update +tools/firmware/ovmf-dir-force-update: + $(MAKE) -C tools/firmware ovmf-dir-force-update + .PHONY: install-docs install-docs: $(MAKE) -C docs install diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile index f064765..8633748 100644 --- a/tools/firmware/Makefile +++ b/tools/firmware/Makefile @@ -6,7 +6,7 @@ TARGET := hvmloader/hvmloader INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR) SUBDIRS-y :-SUBDIRS-$(CONFIG_OVMF) += ovmf +SUBDIRS-$(CONFIG_OVMF) += ovmf-dir ifeq ($(SEABIOS_PATH),) SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir endif @@ -15,9 +15,9 @@ SUBDIRS-$(CONFIG_ROMBIOS) += vgabios SUBDIRS-$(CONFIG_ROMBIOS) += etherboot SUBDIRS-y += hvmloader -ovmf: - GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) ovmf - cp ovmf-makefile ovmf/Makefile; +ovmf-dir: + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) ovmf-dir + cp ovmf-makefile ovmf-dir/Makefile; seabios-dir: GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir @@ -52,32 +52,23 @@ subdir-distclean-etherboot: .phony $(MAKE) -C etherboot distclean subdir-distclean-ovmf: .phony - rm -rf ovmf ovmf-remote + rm -rf ovmf-dir ovmf-dir-remote subdir-distclean-seabios-dir: .phony rm -rf seabios-dir seabios-dir-remote -.PHONY: ovmf-find -ovmf-find: - if test -d $(OVMF_UPSTREAM_URL) ; then \ - mkdir -p ovmf; \ - else \ - export GIT=$(GIT); \ - $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) ovmf ; \ - fi - -.PHONY: ovmf-force-update -ovmf-force-update: +.PHONY: ovmf-dir-force-update +ovmf-dir-force-update: set -ex; \ if [ "$(OVMF_UPSTREAM_REVISION)" ]; then \ - cd ovmf-remote; \ + cd ovmf-dir-remote; \ $(GIT) fetch origin; \ $(GIT) reset --hard $(OVMF_UPSTREAM_REVISION); \ fi subdir-clean-ovmf: - set -e; if test -d ovmf/.; then \ - $(MAKE) -C ovmf clean; \ + set -e; if test -d ovmf-dir/.; then \ + $(MAKE) -C ovmf-dir clean; \ fi .PHONY: seabios-dir-force-update diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile index 8ab1429..e27e457 100644 --- a/tools/firmware/hvmloader/Makefile +++ b/tools/firmware/hvmloader/Makefile @@ -37,7 +37,7 @@ endif CIRRUSVGA_DEBUG ?= n -OVMF_DIR := ../ovmf +OVMF_DIR := ../ovmf-dir ROMBIOS_DIR := ../rombios SEABIOS_DIR := ../seabios-dir -- 1.7.10.4
From: Ian Campbell <ian.campbell@citrix.com>
Debian Jessie at least contains an ovmf package that includes
/usr/share/ovmf/OVMF.fd. It''s also possible that user may want to
supply
his/her own ovmf binary.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
config/Tools.mk.in | 1 +
tools/configure | 16 +++++++++++++---
tools/configure.ac | 11 +++++++++++
tools/firmware/Makefile | 2 ++
tools/firmware/hvmloader/Makefile | 6 +++++-
5 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 67f5782..d9d3239 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -24,6 +24,7 @@ BCC := @BCC@
IASL := @IASL@
FETCHER := @FETCHER@
SEABIOS_PATH := @seabios_path@
+OVMF_PATH := @ovmf_path@
# Extra folder for libs/includes
PREPEND_INCLUDES := @PREPEND_INCLUDES@
diff --git a/tools/configure b/tools/configure
index 1da8652..22e74a7 100755
--- a/tools/configure
+++ b/tools/configure
@@ -682,6 +682,7 @@ APPEND_LIB
APPEND_INCLUDES
PREPEND_LIB
PREPEND_INCLUDES
+ovmf_path
seabios_path
qemu_xen
qemu_traditional
@@ -768,6 +769,7 @@ enable_blktap1
enable_qemu_traditional
with_system_qemu
with_system_seabios
+with_system_ovmf
''
ac_precious_vars=''build_alias
host_alias
@@ -1440,6 +1442,9 @@ Optional Packages:
--with-system-seabios[=PATH]
Use system supplied seabios PATH instead of building
and installing our own version
+ --with-system-ovmf[=PATH]
+ Use system supplied OVMF PATH instead of building
+ and installing our own version
Some influential environment variables:
CC C compiler command
@@ -3771,9 +3776,14 @@ fi
-
-
-
+# Check whether --with-system-ovmf was given.
+if test "${with_system_ovmf+set}" = set; then :
+ withval=$with_system_ovmf;
+ case $withval in
+ no) ovmf_path= ;;
+ *) ovmf_path=$withval ;;
+ esac
+fi
for cppflag in $PREPEND_INCLUDES
diff --git a/tools/configure.ac b/tools/configure.ac
index 4f3c33a..b2941a4 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -108,6 +108,17 @@ AC_ARG_WITH([system-seabios],
],[])
AC_SUBST(seabios_path)
+AC_ARG_WITH([system-ovmf],
+ AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
+ [Use system supplied OVMF PATH instead of building and installing
+ our own version]),[
+ case $withval in
+ no) ovmf_path= ;;
+ *) ovmf_path=$withval ;;
+ esac
+],[])
+AC_SUBST(ovmf_path)
+
AC_ARG_VAR([PREPEND_INCLUDES],
[List of include folders to prepend to CFLAGS (without -I)])
AC_ARG_VAR([PREPEND_LIB],
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 8633748..cb13212 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,7 +6,9 @@ TARGET := hvmloader/hvmloader
INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
SUBDIRS-y :+ifeq ($(OVMF_PATH),)
SUBDIRS-$(CONFIG_OVMF) += ovmf-dir
+endif
ifeq ($(SEABIOS_PATH),)
SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
endif
diff --git a/tools/firmware/hvmloader/Makefile
b/tools/firmware/hvmloader/Makefile
index e27e457..00ee952 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -56,7 +56,11 @@ ROMS : ifeq ($(CONFIG_OVMF),y)
OBJS += ovmf.o
CFLAGS += -DENABLE_OVMF
-OVMF_ROM := $(OVMF_DIR)/ovmf.bin
+ifeq ($(OVMF_PATH),)
+ OVMF_ROM := $(OVMF_DIR)/ovmf.bin
+else
+ OVMF_ROM := $(OVMF_PATH)
+endif
ROMS += $(OVMF_ROM)
endif
--
1.7.10.4
From: Ian Campbell <ian.campbell@citrix.com> The issues with non-GCC4.4 builds seem to have been resolved. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- tools/configure | 4 ++-- tools/configure.ac | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/configure b/tools/configure index 22e74a7..eb58bcd 100755 --- a/tools/configure +++ b/tools/configure @@ -1422,7 +1422,7 @@ Optional Features: --enable-xenapi Enable Xen API Bindings (default is DISABLED) --disable-ocamltools Disable Ocaml tools (default is ENABLED) --disable-xsmpolicy Disable XSM policy compilation (default is ENABLED) - --enable-ovmf Enable OVMF (default is DISABLED) + --disable-ovmf Enable OVMF (default is ENABLED) --disable-rombios Disable ROM BIOS (default is ENABLED) --disable-seabios Disable SeaBIOS (default is ENABLED) --disable-debug Disable debug build of tools (default is ENABLED) @@ -3584,7 +3584,7 @@ elif test "x$enable_ovmf" = "xyes"; then : elif test -z $ax_cv_ovmf; then : - ax_cv_ovmf="n" + ax_cv_ovmf="y" fi ovmf=$ax_cv_ovmf diff --git a/tools/configure.ac b/tools/configure.ac index b2941a4..86fcb28 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -53,7 +53,7 @@ AX_ARG_DEFAULT_ENABLE([monitors], [Disable xenstat and xentop monitoring tools]) AX_ARG_DEFAULT_DISABLE([xenapi], [Enable Xen API Bindings]) AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools]) AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation]) -AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF]) +AX_ARG_DEFAULT_ENABLE([ovmf], [Enable OVMF]) AX_ARG_DEFAULT_ENABLE([rombios], [Disable ROM BIOS]) AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS]) AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of tools]) -- 1.7.10.4
Il 29/10/2013 12:39, Wei Liu ha scritto:> Signed-off-by: Wei Liu <wei.liu2@citrix.com> > --- > Config.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Config.mk b/Config.mk > index 1879454..dad2dc4 100644 > --- a/Config.mk > +++ b/Config.mk > @@ -232,7 +232,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git > SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git > endif > -OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 > +OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807 > QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c > SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1 > # Fri Aug 2 14:12:09 2013 -0400This patch update only the ovmf changeset but not the repository, now git://xenbits.xen.org/ovmf.git is not updated, so you have to update it or change also repository to git://xenbits.xen.org/people/liuw/ovmf.git. All other things look good to me, now I test this series of patches.
On Tue, Oct 29, 2013 at 03:16:17PM +0100, Fabio Fantoni wrote:> Il 29/10/2013 12:39, Wei Liu ha scritto: > >Signed-off-by: Wei Liu <wei.liu2@citrix.com> > >--- > > Config.mk | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/Config.mk b/Config.mk > >index 1879454..dad2dc4 100644 > >--- a/Config.mk > >+++ b/Config.mk > >@@ -232,7 +232,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git > > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git > > SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git > > endif > >-OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 > >+OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807 > > QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c > > SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1 > > # Fri Aug 2 14:12:09 2013 -0400 > > This patch update only the ovmf changeset but not the repository, > now git://xenbits.xen.org/ovmf.git is not updated, so you have to > update it or change also repository to > git://xenbits.xen.org/people/liuw/ovmf.git. > All other things look good to me, now I test this series of patches.I don''t have the permission to push to that repository so I need to defer this to maintainers. Again, you can probably wait until this series go through push gate before conducting any test. Wei.
Il 29/10/2013 15:21, Wei Liu ha scritto:> On Tue, Oct 29, 2013 at 03:16:17PM +0100, Fabio Fantoni wrote: >> Il 29/10/2013 12:39, Wei Liu ha scritto: >>> Signed-off-by: Wei Liu <wei.liu2@citrix.com> >>> --- >>> Config.mk | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/Config.mk b/Config.mk >>> index 1879454..dad2dc4 100644 >>> --- a/Config.mk >>> +++ b/Config.mk >>> @@ -232,7 +232,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git >>> QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git >>> SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git >>> endif >>> -OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 >>> +OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807 >>> QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c >>> SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1 >>> # Fri Aug 2 14:12:09 2013 -0400 >> This patch update only the ovmf changeset but not the repository, >> now git://xenbits.xen.org/ovmf.git is not updated, so you have to >> update it or change also repository to >> git://xenbits.xen.org/people/liuw/ovmf.git. >> All other things look good to me, now I test this series of patches. > I don''t have the permission to push to that repository so I need to > defer this to maintainers. > > Again, you can probably wait until this series go through push gate > before conducting any test. > > Wei.For this patches serie: Tested-by: Fabio Fantoni <fabio.fantoni@m2r.biz> About ovmf: I don''t have uefi domUs ready, so I did a fast test with windows 7 pro 64 bit dvd and starts, spice it works. The problem found for now is very bad general performance and at the end of windows installer loading the domU reboots.
On Tue, Oct 29, 2013 at 05:15:49PM +0100, Fabio Fantoni wrote:> Il 29/10/2013 15:21, Wei Liu ha scritto: > >On Tue, Oct 29, 2013 at 03:16:17PM +0100, Fabio Fantoni wrote: > >>Il 29/10/2013 12:39, Wei Liu ha scritto: > >>>Signed-off-by: Wei Liu <wei.liu2@citrix.com> > >>>--- > >>> Config.mk | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>>diff --git a/Config.mk b/Config.mk > >>>index 1879454..dad2dc4 100644 > >>>--- a/Config.mk > >>>+++ b/Config.mk > >>>@@ -232,7 +232,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git > >>> QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git > >>> SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git > >>> endif > >>>-OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 > >>>+OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807 > >>> QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c > >>> SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1 > >>> # Fri Aug 2 14:12:09 2013 -0400 > >>This patch update only the ovmf changeset but not the repository, > >>now git://xenbits.xen.org/ovmf.git is not updated, so you have to > >>update it or change also repository to > >>git://xenbits.xen.org/people/liuw/ovmf.git. > >>All other things look good to me, now I test this series of patches. > >I don''t have the permission to push to that repository so I need to > >defer this to maintainers. > > > >Again, you can probably wait until this series go through push gate > >before conducting any test. > > > >Wei. > > > For this patches serie: > Tested-by: Fabio Fantoni <fabio.fantoni@m2r.biz> > > About ovmf: > I don''t have uefi domUs ready, so I did a fast test with windows 7 > pro 64 bit dvd and starts, spice it works. > The problem found for now is very bad general performance and at the > end of windows installer loading the domU reboots.Oh Windows... :-P It would be useful to have at least some hypervisor / QEMU logs.
Il 29/10/2013 17:34, Wei Liu ha scritto:> On Tue, Oct 29, 2013 at 05:15:49PM +0100, Fabio Fantoni wrote: >> Il 29/10/2013 15:21, Wei Liu ha scritto: >>> On Tue, Oct 29, 2013 at 03:16:17PM +0100, Fabio Fantoni wrote: >>>> Il 29/10/2013 12:39, Wei Liu ha scritto: >>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com> >>>>> --- >>>>> Config.mk | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/Config.mk b/Config.mk >>>>> index 1879454..dad2dc4 100644 >>>>> --- a/Config.mk >>>>> +++ b/Config.mk >>>>> @@ -232,7 +232,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git >>>>> QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git >>>>> SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git >>>>> endif >>>>> -OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 >>>>> +OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807 >>>>> QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c >>>>> SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1 >>>>> # Fri Aug 2 14:12:09 2013 -0400 >>>> This patch update only the ovmf changeset but not the repository, >>>> now git://xenbits.xen.org/ovmf.git is not updated, so you have to >>>> update it or change also repository to >>>> git://xenbits.xen.org/people/liuw/ovmf.git. >>>> All other things look good to me, now I test this series of patches. >>> I don''t have the permission to push to that repository so I need to >>> defer this to maintainers. >>> >>> Again, you can probably wait until this series go through push gate >>> before conducting any test. >>> >>> Wei. >> >> For this patches serie: >> Tested-by: Fabio Fantoni <fabio.fantoni@m2r.biz> >> >> About ovmf: >> I don''t have uefi domUs ready, so I did a fast test with windows 7 >> pro 64 bit dvd and starts, spice it works. >> The problem found for now is very bad general performance and at the >> end of windows installer loading the domU reboots. > Oh Windows... :-PI know that quality, efficiency, stability and security do not exist in the Microsoft vocabulary... Unfortunately almost all users for desktop/workstation use windows (for now) and even at the time I still use it for work due to some programs that only run on windows (and often are made very badly) :(> > It would be useful to have at least some hypervisor / QEMU logs.I found this error on xl dmesg:> (XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffffI see a recently posted patch about pfn: http://lists.xen.org/archives/html/xen-devel/2013-10/msg02028.html Can this serie solve the problem and I have to try it or has nothing to do with this? And this is the error that cause reboot of domU:> (XEN) hvm.c:1274:d4 Triple fault on VCPU0 - invoking HVM shutdown > action 1.I not found any other error or relevant information on logs but I attach them if you want see. I also tried with Ubuntu 12.04.3, same pfn error on xl dmesg, same performance problem (some minutes only for arrive to grub-efi of dvd) and after other 10-15 minutes without complete the boot I did a destroy. Also for that logs on attachments. Despite windows is bad, it seems that problems persist even in the test linux except the shutdown with vcpu issue. The dom0 used have the installation of this: http://lists.xen.org/archives/html/xen-devel/2013-10/msg01111.html Except the git branch used (here the hvm-improve.t6) and the qemu: QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/staging/qemu-upstream-unstable.git QEMU_UPSTREAM_REVISION ?= master If you need more informations and/or tests tell me and I''ll do/post them. About legacy bios support that I mentioned days ago I found this document about: http://code.coreboot.org/p/seabios/source/tree/master/README.CSM Seem that need ovmf change (and probably also on hvmloader) that are not able to do. Thank for any reply and sorry for my bad english. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, Oct 30, 2013 at 12:33:50PM +0100, Fabio Fantoni wrote: [...]> >>For this patches serie: > >>Tested-by: Fabio Fantoni <fabio.fantoni@m2r.biz> > >> > >>About ovmf: > >>I don''t have uefi domUs ready, so I did a fast test with windows 7 > >>pro 64 bit dvd and starts, spice it works. > >>The problem found for now is very bad general performance and at the > >>end of windows installer loading the domU reboots. > >Oh Windows... :-P > > I know that quality, efficiency, stability and security do not exist > in the Microsoft vocabulary... > Unfortunately almost all users for desktop/workstation use windows > (for now) and even at the time I still use it for work due to some > programs that only run on windows (and often are made very badly) :( >Don''t get me wrong. I''m just saying debugging Windows with no source code available is beyond my ability. :-)> > > >It would be useful to have at least some hypervisor / QEMU logs. > > I found this error on xl dmesg: > >(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff > I see a recently posted patch about pfn: > http://lists.xen.org/archives/html/xen-devel/2013-10/msg02028.html > Can this serie solve the problem and I have to try it or has nothing > to do with this?I don''t think that patch is useful to fix this at first glance. AFAICT this is a limitation of Xen''s physmap implementation. I''m still investigating a proper fix for this -- unfortunately that might involving modifying Xen''s most complicated part so don''t hold your breath.> > And this is the error that cause reboot of domU: > >(XEN) hvm.c:1274:d4 Triple fault on VCPU0 - invoking HVM shutdown > >action 1. >Windows, right? Could you try Linux?> I not found any other error or relevant information on logs but I > attach them if you want see. > > I also tried with Ubuntu 12.04.3, same pfn error on xl dmesg, same > performance problem (some minutes only for arrive to grub-efi of > dvd) and after other 10-15 minutes without complete the boot I did a > destroy. > Also for that logs on attachments. >Is QMEU busy-looping?> Despite windows is bad, it seems that problems persist even in the > test linux except the shutdown with vcpu issue. > > The dom0 used have the installation of this: > http://lists.xen.org/archives/html/xen-devel/2013-10/msg01111.html > Except the git branch used (here the hvm-improve.t6) and the qemu: > QEMU_UPSTREAM_URL ?> git://xenbits.xen.org/staging/qemu-upstream-unstable.git > QEMU_UPSTREAM_REVISION ?= master >Oh please don''t use staging QEMU. That introduces a new variable which makes it very hard to identify the genuine problem. Wei.> If you need more informations and/or tests tell me and I''ll do/post them. > > About legacy bios support that I mentioned days ago I found this > document about: > http://code.coreboot.org/p/seabios/source/tree/master/README.CSM > Seem that need ovmf change (and probably also on hvmloader) that are > not able to do. > > Thank for any reply and sorry for my bad english.
Just notice you also attached log files... You can just inline them in mail or attach them one by one instead of making zip / tarball -- this will be much easier for people to look at them. Wei.
Il 30/10/2013 13:09, Wei Liu ha scritto:> Just notice you also attached log files... > > You can just inline them in mail or attach them one by one instead of > making zip / tarball -- this will be much easier for people to look at > them. > > Wei.Done and also reported below some part about of previous mail... I found this error on xl dmesg:> (XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffffI see a recently posted patch about pfn: http://lists.xen.org/archives/html/xen-devel/2013-10/msg02028.html Can this serie solve the problem and I have to try it or has nothing to do with this? And this is the error that cause reboot of domU:> (XEN) hvm.c:1274:d4 Triple fault on VCPU0 - invoking HVM shutdown > action 1.I not found any other error or relevant information on logs but I attach them if you want see. I also tried with Ubuntu 12.04.3, same pfn error on xl dmesg, same performance problem (some minutes only for arrive to grub-efi of dvd) and after other 10-15 minutes without complete the boot I did a destroy. Also for that logs on attachments. Despite windows is bad, it seems that problems persist even in the test linux except the shutdown with vcpu issue. The dom0 used have the installation of this: http://lists.xen.org/archives/html/xen-devel/2013-10/msg01111.html Except the git branch used (here the hvm-improve.t6) and the qemu: QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/staging/qemu-upstream-unstable.git QEMU_UPSTREAM_REVISION ?= master _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Il 30/10/2013 12:50, Wei Liu ha scritto:> On Wed, Oct 30, 2013 at 12:33:50PM +0100, Fabio Fantoni wrote: > [...] >>>> For this patches serie: >>>> Tested-by: Fabio Fantoni <fabio.fantoni@m2r.biz> >>>> >>>> About ovmf: >>>> I don''t have uefi domUs ready, so I did a fast test with windows 7 >>>> pro 64 bit dvd and starts, spice it works. >>>> The problem found for now is very bad general performance and at the >>>> end of windows installer loading the domU reboots. >>> Oh Windows... :-P >> I know that quality, efficiency, stability and security do not exist >> in the Microsoft vocabulary... >> Unfortunately almost all users for desktop/workstation use windows >> (for now) and even at the time I still use it for work due to some >> programs that only run on windows (and often are made very badly) :( >> > Don''t get me wrong. I''m just saying debugging Windows with no source > code available is beyond my ability. :-) > >>> It would be useful to have at least some hypervisor / QEMU logs. >> I found this error on xl dmesg: >>> (XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff >> I see a recently posted patch about pfn: >> http://lists.xen.org/archives/html/xen-devel/2013-10/msg02028.html >> Can this serie solve the problem and I have to try it or has nothing >> to do with this? > I don''t think that patch is useful to fix this at first glance. > > AFAICT this is a limitation of Xen''s physmap implementation. I''m still > investigating a proper fix for this -- unfortunately that might > involving modifying Xen''s most complicated part so don''t hold your > breath. > >> And this is the error that cause reboot of domU: >>> (XEN) hvm.c:1274:d4 Triple fault on VCPU0 - invoking HVM shutdown >>> action 1. > Windows, right? Could you try Linux? > >> I not found any other error or relevant information on logs but I >> attach them if you want see. >> >> I also tried with Ubuntu 12.04.3, same pfn error on xl dmesg, same >> performance problem (some minutes only for arrive to grub-efi of >> dvd) and after other 10-15 minutes without complete the boot I did a >> destroy. >> Also for that logs on attachments. >> > Is QMEU busy-looping?I probably not understand exactly what you mean, the domU seems continue to boot apparently but in very slow motion. Qemu is always active and with low load (on average 5% cpu).> >> Despite windows is bad, it seems that problems persist even in the >> test linux except the shutdown with vcpu issue. >> >> The dom0 used have the installation of this: >> http://lists.xen.org/archives/html/xen-devel/2013-10/msg01111.html >> Except the git branch used (here the hvm-improve.t6) and the qemu: >> QEMU_UPSTREAM_URL ?>> git://xenbits.xen.org/staging/qemu-upstream-unstable.git >> QEMU_UPSTREAM_REVISION ?= master >> > Oh please don''t use staging QEMU. That introduces a new variable which > makes it very hard to identify the genuine problem. > > Wei.Is based on latest qemu stable (1.6.1). I tested 1.6 fora long time without see regression and seems more good than 1.3 on something. Are there specific reasons to use an older version instead? If there were it would not be a problem for me to recompile/re-test with a qemu previous.> >> If you need more informations and/or tests tell me and I''ll do/post them. >> >> About legacy bios support that I mentioned days ago I found this >> document about: >> http://code.coreboot.org/p/seabios/source/tree/master/README.CSM >> Seem that need ovmf change (and probably also on hvmloader) that are >> not able to do. >> >> Thank for any reply and sorry for my bad english. > >
On Wed, Oct 30, 2013 at 01:57:40PM +0100, Fabio Fantoni wrote: [...]> >>I also tried with Ubuntu 12.04.3, same pfn error on xl dmesg, same > >>performance problem (some minutes only for arrive to grub-efi of > >>dvd) and after other 10-15 minutes without complete the boot I did a > >>destroy. > >>Also for that logs on attachments. > >> > >Is QMEU busy-looping? > > I probably not understand exactly what you mean, the domU seems > continue to boot apparently but in very slow motion. > Qemu is always active and with low load (on average 5% cpu). >OK. I get it. 5% CPU is OK and expected at this stage. To get an idea what your guest is doing you probably need to setup serial console.> > > >>Despite windows is bad, it seems that problems persist even in the > >>test linux except the shutdown with vcpu issue. > >> > >>The dom0 used have the installation of this: > >>http://lists.xen.org/archives/html/xen-devel/2013-10/msg01111.html > >>Except the git branch used (here the hvm-improve.t6) and the qemu: > >>QEMU_UPSTREAM_URL ?> >>git://xenbits.xen.org/staging/qemu-upstream-unstable.git > >>QEMU_UPSTREAM_REVISION ?= master > >> > >Oh please don''t use staging QEMU. That introduces a new variable which > >makes it very hard to identify the genuine problem. > > > >Wei. > > Is based on latest qemu stable (1.6.1). > I tested 1.6 fora long time without see regression and seems more > good than 1.3 on something. > Are there specific reasons to use an older version instead? > If there were it would not be a problem for me to recompile/re-test > with a qemu previous. >If it is working fine for you then it is OK. But IMHO it is generally better to wait for specific changeset to go through push gate before conducting your test because that reduces the variables which might cause regressions. Wei.> > > >>If you need more informations and/or tests tell me and I''ll do/post them. > >> > >>About legacy bios support that I mentioned days ago I found this > >>document about: > >>http://code.coreboot.org/p/seabios/source/tree/master/README.CSM > >>Seem that need ovmf change (and probably also on hvmloader) that are > >>not able to do. > >> > >>Thank for any reply and sorry for my bad english. > > > >
Il 30/10/2013 15:05, Wei Liu ha scritto:> On Wed, Oct 30, 2013 at 01:57:40PM +0100, Fabio Fantoni wrote: > [...] >>>> I also tried with Ubuntu 12.04.3, same pfn error on xl dmesg, same >>>> performance problem (some minutes only for arrive to grub-efi of >>>> dvd) and after other 10-15 minutes without complete the boot I did a >>>> destroy. >>>> Also for that logs on attachments. >>>> >>> Is QMEU busy-looping? >> I probably not understand exactly what you mean, the domU seems >> continue to boot apparently but in very slow motion. >> Qemu is always active and with low load (on average 5% cpu). >> > OK. I get it. 5% CPU is OK and expected at this stage. > > To get an idea what your guest is doing you probably need to setup > serial console. > >>>> Despite windows is bad, it seems that problems persist even in the >>>> test linux except the shutdown with vcpu issue. >>>> >>>> The dom0 used have the installation of this: >>>> http://lists.xen.org/archives/html/xen-devel/2013-10/msg01111.html >>>> Except the git branch used (here the hvm-improve.t6) and the qemu: >>>> QEMU_UPSTREAM_URL ?>>>> git://xenbits.xen.org/staging/qemu-upstream-unstable.git >>>> QEMU_UPSTREAM_REVISION ?= master >>>> >>> Oh please don''t use staging QEMU. That introduces a new variable which >>> makes it very hard to identify the genuine problem. >>> >>> Wei. >> Is based on latest qemu stable (1.6.1). >> I tested 1.6 fora long time without see regression and seems more >> good than 1.3 on something. >> Are there specific reasons to use an older version instead? >> If there were it would not be a problem for me to recompile/re-test >> with a qemu previous. >> > If it is working fine for you then it is OK. > > But IMHO it is generally better to wait for specific changeset to go > through push gate before conducting your test because that reduces the > variables which might cause regressions. > > Wei.I also tried another build without change qemu repo and changet but same result. Do you have domUs working on ovmf? If yes what are differences from my test system? I tried to change also domU parameters: - removing audio, vdagent and usb redirection it changes nothing. - switch from stdvga to cirrus vga solves the performance problem, but with Precise it shows always a black screen after start of grub-efi entry, and black screen also with windows 7 installer. What domU vga you used on your tests? I''m trying to setup ovmf serial console, but I have no idea on where to start from. Do you have some suggestions? Thanks for any reply.> >>>> If you need more informations and/or tests tell me and I''ll do/post them. >>>> >>>> About legacy bios support that I mentioned days ago I found this >>>> document about: >>>> http://code.coreboot.org/p/seabios/source/tree/master/README.CSM >>>> Seem that need ovmf change (and probably also on hvmloader) that are >>>> not able to do. >>>> >>>> Thank for any reply and sorry for my bad english. >>>
On Wed, Oct 30, 2013 at 04:52:52PM +0100, Fabio Fantoni wrote: [...]> > I also tried another build without change qemu repo and changet but > same result. > Do you have domUs working on ovmf? If yes what are differences from > my test system? > > I tried to change also domU parameters: > - removing audio, vdagent and usb redirection it changes nothing. > - switch from stdvga to cirrus vga solves the performance problem, > but with Precise it shows always a black screen after start of > grub-efi entry, and black screen also with windows 7 installer. > > What domU vga you used on your tests? >Cirrus, because there''s cirrus driver in OVMF. I don''t know whether there is driver for stdvga. Black screen is expected because there''s probably something wrong with OVMF / Xen. I need to check real hardware behavior to identify the problem.> I''m trying to setup ovmf serial console, but I have no idea on where > to start from. Do you have some suggestions? >Add serial=''pty'' in you HVM guest config file. I believe you can get a tutorial on wiki.xen.org Wei.> Thanks for any reply. > > > > >>>>If you need more informations and/or tests tell me and I''ll do/post them. > >>>> > >>>>About legacy bios support that I mentioned days ago I found this > >>>>document about: > >>>>http://code.coreboot.org/p/seabios/source/tree/master/README.CSM > >>>>Seem that need ovmf change (and probably also on hvmloader) that are > >>>>not able to do. > >>>> > >>>>Thank for any reply and sorry for my bad english. > >>>
Il 30/10/2013 16:58, Wei Liu ha scritto:> On Wed, Oct 30, 2013 at 04:52:52PM +0100, Fabio Fantoni wrote: > [...] >> I also tried another build without change qemu repo and changet but >> same result. >> Do you have domUs working on ovmf? If yes what are differences from >> my test system? >> >> I tried to change also domU parameters: >> - removing audio, vdagent and usb redirection it changes nothing. >> - switch from stdvga to cirrus vga solves the performance problem, >> but with Precise it shows always a black screen after start of >> grub-efi entry, and black screen also with windows 7 installer. >> >> What domU vga you used on your tests? >> > Cirrus, because there''s cirrus driver in OVMF. I don''t know whether > there is driver for stdvga. > > Black screen is expected because there''s probably something wrong with > OVMF / Xen. I need to check real hardware behavior to identify the > problem. > >> I''m trying to setup ovmf serial console, but I have no idea on where >> to start from. Do you have some suggestions? >> > Add serial=''pty'' in you HVM guest config file. I believe you can get a > tutorial on wiki.xen.org > > Wei.Thanks and sorry for the stupid question. Precise''s boot stops with calltrace, log on attachment. I''ll try also with latest ubuntu version (Saucy) with newer kernel (3.11) and with latest stable qemu version (1.6.1).>> Thanks for any reply. >> >>>>>> If you need more informations and/or tests tell me and I''ll do/post them. >>>>>> >>>>>> About legacy bios support that I mentioned days ago I found this >>>>>> document about: >>>>>> http://code.coreboot.org/p/seabios/source/tree/master/README.CSM >>>>>> Seem that need ovmf change (and probably also on hvmloader) that are >>>>>> not able to do. >>>>>> >>>>>> Thank for any reply and sorry for my bad english.This idea could be enable legacy bios and vgabioses support on ovmf... Is that really stupid question to not deserve an aswer? Thanks for any reply. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, Oct 31, 2013 at 10:47:24AM +0100, Fabio Fantoni wrote:> Il 30/10/2013 16:58, Wei Liu ha scritto: > >On Wed, Oct 30, 2013 at 04:52:52PM +0100, Fabio Fantoni wrote: > >[...] > >>I also tried another build without change qemu repo and changet but > >>same result. > >>Do you have domUs working on ovmf? If yes what are differences from > >>my test system? > >> > >>I tried to change also domU parameters: > >>- removing audio, vdagent and usb redirection it changes nothing. > >>- switch from stdvga to cirrus vga solves the performance problem, > >>but with Precise it shows always a black screen after start of > >>grub-efi entry, and black screen also with windows 7 installer. > >> > >>What domU vga you used on your tests? > >> > >Cirrus, because there''s cirrus driver in OVMF. I don''t know whether > >there is driver for stdvga. > > > >Black screen is expected because there''s probably something wrong with > >OVMF / Xen. I need to check real hardware behavior to identify the > >problem. > > > >>I''m trying to setup ovmf serial console, but I have no idea on where > >>to start from. Do you have some suggestions? > >> > >Add serial=''pty'' in you HVM guest config file. I believe you can get a > >tutorial on wiki.xen.org > > > >Wei. > > Thanks and sorry for the stupid question. > Precise''s boot stops with calltrace, log on attachment. > I''ll try also with latest ubuntu version (Saucy) with newer kernel > (3.11) and with latest stable qemu version (1.6.1). > > >>Thanks for any reply. > >> > >>>>>>If you need more informations and/or tests tell me and I''ll do/post them. > >>>>>> > >>>>>>About legacy bios support that I mentioned days ago I found this > >>>>>>document about: > >>>>>>http://code.coreboot.org/p/seabios/source/tree/master/README.CSM > >>>>>>Seem that need ovmf change (and probably also on hvmloader) that are > >>>>>>not able to do. > >>>>>> > >>>>>>Thank for any reply and sorry for my bad english. > > This idea could be enable legacy bios and vgabioses support on > ovmf... Is that really stupid question to not deserve an aswer? > Thanks for any reply.I think we need to wait until this happens in upstream. As for the guest log, I don''t have a clear idea whether it is caused by OVMF at this stage. Null pointer deference looks just like a normal bug but I''m not sure whether it is caused by OVMF setting up the wrong thing very far ahead... Wei.
Il 31/10/2013 11:03, Wei Liu ha scritto:> On Thu, Oct 31, 2013 at 10:47:24AM +0100, Fabio Fantoni wrote: >> Il 30/10/2013 16:58, Wei Liu ha scritto: >>> On Wed, Oct 30, 2013 at 04:52:52PM +0100, Fabio Fantoni wrote: >>> [...] >>>> I also tried another build without change qemu repo and changet but >>>> same result. >>>> Do you have domUs working on ovmf? If yes what are differences from >>>> my test system? >>>> >>>> I tried to change also domU parameters: >>>> - removing audio, vdagent and usb redirection it changes nothing. >>>> - switch from stdvga to cirrus vga solves the performance problem, >>>> but with Precise it shows always a black screen after start of >>>> grub-efi entry, and black screen also with windows 7 installer. >>>> >>>> What domU vga you used on your tests? >>>> >>> Cirrus, because there''s cirrus driver in OVMF. I don''t know whether >>> there is driver for stdvga. >>> >>> Black screen is expected because there''s probably something wrong with >>> OVMF / Xen. I need to check real hardware behavior to identify the >>> problem. >>> >>>> I''m trying to setup ovmf serial console, but I have no idea on where >>>> to start from. Do you have some suggestions? >>>> >>> Add serial=''pty'' in you HVM guest config file. I believe you can get a >>> tutorial on wiki.xen.org >>> >>> Wei. >> Thanks and sorry for the stupid question. >> Precise''s boot stops with calltrace, log on attachment. >> I''ll try also with latest ubuntu version (Saucy) with newer kernel >> (3.11) and with latest stable qemu version (1.6.1). >> >>>> Thanks for any reply. >>>> >>>>>>>> If you need more informations and/or tests tell me and I''ll do/post them. >>>>>>>> >>>>>>>> About legacy bios support that I mentioned days ago I found this >>>>>>>> document about: >>>>>>>> http://code.coreboot.org/p/seabios/source/tree/master/README.CSM >>>>>>>> Seem that need ovmf change (and probably also on hvmloader) that are >>>>>>>> not able to do. >>>>>>>> >>>>>>>> Thank for any reply and sorry for my bad english. >> This idea could be enable legacy bios and vgabioses support on >> ovmf... Is that really stupid question to not deserve an aswer? >> Thanks for any reply. > I think we need to wait until this happens in upstream. > > As for the guest log, I don''t have a clear idea whether it is caused by > OVMF at this stage. Null pointer deference looks just like a normal bug > but I''m not sure whether it is caused by OVMF setting up the wrong thing > very far ahead... > > Wei.I tried with saucy and it boot but has graphic performance issue and no mouse. About windows problem it is probably due to a missed cirrus driver on windows 7. The only other option that I found should be try with stdvga but seem it needs legacy vgabios from csm. What if I try to add ovmf patches for legacybios (that seems to have also memory patch) from this git? http://git.infradead.org/users/dwmw2/edk2.git Does it make sense without modification to hvmloader? Thanks for any reply.
On Thu, Oct 31, 2013 at 12:22:32PM +0100, Fabio Fantoni wrote: [...]> > I tried with saucy and it boot but has graphic performance issue and > no mouse. > About windows problem it is probably due to a missed cirrus driver > on windows 7. > The only other option that I found should be try with stdvga but > seem it needs legacy vgabios from csm. > What if I try to add ovmf patches for legacybios (that seems to have > also memory patch) from this git? > http://git.infradead.org/users/dwmw2/edk2.git > Does it make sense without modification to hvmloader? > Thanks for any reply.It''s really hard to tell whether these out-of-tree patches will be of any help for the cuurent situation. Wei.
Il 31/10/2013 15:40, Wei Liu ha scritto:> On Thu, Oct 31, 2013 at 12:22:32PM +0100, Fabio Fantoni wrote: > [...] >> I tried with saucy and it boot but has graphic performance issue and >> no mouse. >> About windows problem it is probably due to a missed cirrus driver >> on windows 7. >> The only other option that I found should be try with stdvga but >> seem it needs legacy vgabios from csm. >> What if I try to add ovmf patches for legacybios (that seems to have >> also memory patch) from this git? >> http://git.infradead.org/users/dwmw2/edk2.git >> Does it make sense without modification to hvmloader? >> Thanks for any reply. > It''s really hard to tell whether these out-of-tree patches will be of > any help for the cuurent situation. > > Wei.Sorry, I try to better explain what i meant: In my earlier mail, what I was asking is: since the patch to OVMF to prevent it from marking the region from 0xC0000-0xFFFFF as read-only before invoking Legacy16Boot method is already present on the git I''ve linked, I was asking if such a patch should works without any further modification xen-side. On the other hand, if you think the patch will never work without xen modifications, I''ll not test csm now but I''ll wait xen change.
George Dunlap
2013-Nov-01 11:14 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Tue, Oct 29, 2013 at 11:39 AM, Wei Liu <wei.liu2@citrix.com> wrote:> When using OVMF we need to have 1MiB of memory in place for firmware. > Without this change we have: > > (XEN) HVM128: Loading OVMF ... > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > This is not a fatal error as hvmloader will instead use low memory to > load OVMF, but it''s better to eliminate such error. > > Changing this constant doesn''t necessary increase the total amount of > memory a guest uses because it''s just a limit. > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > Cc: Ian Campbell <ian.campbell@citrix.com> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Ian Campbell
2013-Nov-01 16:02 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote:> When using OVMF we need to have 1MiB of memory in place for firmware. > Without this change we have: > > (XEN) HVM128: Loading OVMF ... > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > This is not a fatal error as hvmloader will instead use low memory to > load OVMF, but it''s better to eliminate such error. > > Changing this constant doesn''t necessary increase the total amount of > memory a guest uses because it''s just a limit.It will allow a guest to try and use up to 1MB more though, and it allows this for PV guests as well as HVM guests not using OVMF. There''s only a small number of place which use this constant, can we refactor them into a helper function, which can then be expanded to include a per-BIOS overhead in addition to this one? The BIOS selection is stored in xenstore, so that work even for calls which don''t have the domain configuration to hand. (does anyone remember what the existing 1MB is actually for?)
On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote:> Signed-off-by: Wei Liu <wei.liu2@citrix.com>Acked-by: Ian Campbell <ian.campbell@citrix.com> Along with a reminder to self to pull git://xenbits.xen.org/people/liuw/ovmf.git for-xenbits and push ssh://xenbits.xen.org/home/xen/git/ovmf.git FETCH_HEAD:master while committing...> --- > Config.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Config.mk b/Config.mk > index 1879454..dad2dc4 100644 > --- a/Config.mk > +++ b/Config.mk > @@ -232,7 +232,7 @@ OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git > SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git > endif > -OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 > +OVMF_UPSTREAM_REVISION ?= a93b0e3f6895a074b99c8817181dfa6dbc7a4807 > QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c > SEABIOS_UPSTREAM_TAG ?= rel-1.7.3.1 > # Fri Aug 2 14:12:09 2013 -0400
Wei Liu
2013-Nov-01 16:10 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Fri, Nov 01, 2013 at 04:02:17PM +0000, Ian Campbell wrote:> On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote: > > When using OVMF we need to have 1MiB of memory in place for firmware. > > Without this change we have: > > > > (XEN) HVM128: Loading OVMF ... > > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > > > This is not a fatal error as hvmloader will instead use low memory to > > load OVMF, but it''s better to eliminate such error. > > > > Changing this constant doesn''t necessary increase the total amount of > > memory a guest uses because it''s just a limit. > > It will allow a guest to try and use up to 1MB more though, and it > allows this for PV guests as well as HVM guests not using OVMF. > > There''s only a small number of place which use this constant, can we > refactor them into a helper function, which can then be expanded to > include a per-BIOS overhead in addition to this one? The BIOS selection > is stored in xenstore, so that work even for calls which don''t have the > domain configuration to hand. > > (does anyone remember what the existing 1MB is actually for?) >Happened to come across this when I was looking at other problem. http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html It looks like that constant was never intended to use in the way it is now. Hah. Wei.
Ian Campbell
2013-Nov-01 16:23 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Fri, 2013-11-01 at 16:10 +0000, Wei Liu wrote:> On Fri, Nov 01, 2013 at 04:02:17PM +0000, Ian Campbell wrote: > > On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote: > > > When using OVMF we need to have 1MiB of memory in place for firmware. > > > Without this change we have: > > > > > > (XEN) HVM128: Loading OVMF ... > > > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > > > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > > > > > This is not a fatal error as hvmloader will instead use low memory to > > > load OVMF, but it''s better to eliminate such error. > > > > > > Changing this constant doesn''t necessary increase the total amount of > > > memory a guest uses because it''s just a limit. > > > > It will allow a guest to try and use up to 1MB more though, and it > > allows this for PV guests as well as HVM guests not using OVMF. > > > > There''s only a small number of place which use this constant, can we > > refactor them into a helper function, which can then be expanded to > > include a per-BIOS overhead in addition to this one? The BIOS selection > > is stored in xenstore, so that work even for calls which don''t have the > > domain configuration to hand. > > > > (does anyone remember what the existing 1MB is actually for?) > > > > Happened to come across this when I was looking at other problem. > > http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html > > It looks like that constant was never intended to use in the way it is > now. Hah.Indeed not. I vaguely recall that the xapi folks add a bit of slack to the domain size while they are doing the calculation to see if it fit will on the host, but not actually when they build the domain. (note that this therefore only matters for the domain being built, and not cumulatively for all domains, which makes a difference to the overall overheads on the system). We could try switching to a model like that and see what breaks I guess? I''ve CC''d a couple of xapi folks so they can correct my no doubt faulty memory ;-) Ian.
Wei Liu
2013-Nov-06 10:32 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Fri, Nov 01, 2013 at 04:23:04PM +0000, Ian Campbell wrote:> On Fri, 2013-11-01 at 16:10 +0000, Wei Liu wrote: > > On Fri, Nov 01, 2013 at 04:02:17PM +0000, Ian Campbell wrote: > > > On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote: > > > > When using OVMF we need to have 1MiB of memory in place for firmware. > > > > Without this change we have: > > > > > > > > (XEN) HVM128: Loading OVMF ... > > > > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > > > > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > > > > > > > This is not a fatal error as hvmloader will instead use low memory to > > > > load OVMF, but it''s better to eliminate such error. > > > > > > > > Changing this constant doesn''t necessary increase the total amount of > > > > memory a guest uses because it''s just a limit. > > > > > > It will allow a guest to try and use up to 1MB more though, and it > > > allows this for PV guests as well as HVM guests not using OVMF. > > > > > > There''s only a small number of place which use this constant, can we > > > refactor them into a helper function, which can then be expanded to > > > include a per-BIOS overhead in addition to this one? The BIOS selection > > > is stored in xenstore, so that work even for calls which don''t have the > > > domain configuration to hand. > > > > > > (does anyone remember what the existing 1MB is actually for?) > > > > > > > Happened to come across this when I was looking at other problem. > > > > http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html > > > > It looks like that constant was never intended to use in the way it is > > now. Hah. > > Indeed not. > > I vaguely recall that the xapi folks add a bit of slack to the domain > size while they are doing the calculation to see if it fit will on the > host, but not actually when they build the domain. (note that this > therefore only matters for the domain being built, and not cumulatively > for all domains, which makes a difference to the overall overheads on > the system). We could try switching to a model like that and see what > breaks I guess? > > I''ve CC''d a couple of xapi folks so they can correct my no doubt faulty > memory ;-) > Ian.Xapi experts, any thought? Wei.
Ian Campbell
2013-Nov-06 10:41 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Wed, 2013-11-06 at 10:32 +0000, Wei Liu wrote:> On Fri, Nov 01, 2013 at 04:23:04PM +0000, Ian Campbell wrote: > > On Fri, 2013-11-01 at 16:10 +0000, Wei Liu wrote: > > > On Fri, Nov 01, 2013 at 04:02:17PM +0000, Ian Campbell wrote: > > > > On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote: > > > > > When using OVMF we need to have 1MiB of memory in place for firmware. > > > > > Without this change we have: > > > > > > > > > > (XEN) HVM128: Loading OVMF ... > > > > > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > > > > > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > > > > > > > > > This is not a fatal error as hvmloader will instead use low memory to > > > > > load OVMF, but it''s better to eliminate such error. > > > > > > > > > > Changing this constant doesn''t necessary increase the total amount of > > > > > memory a guest uses because it''s just a limit. > > > > > > > > It will allow a guest to try and use up to 1MB more though, and it > > > > allows this for PV guests as well as HVM guests not using OVMF. > > > > > > > > There''s only a small number of place which use this constant, can we > > > > refactor them into a helper function, which can then be expanded to > > > > include a per-BIOS overhead in addition to this one? The BIOS selection > > > > is stored in xenstore, so that work even for calls which don''t have the > > > > domain configuration to hand. > > > > > > > > (does anyone remember what the existing 1MB is actually for?) > > > > > > > > > > Happened to come across this when I was looking at other problem. > > > > > > http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html > > > > > > It looks like that constant was never intended to use in the way it is > > > now. Hah. > > > > Indeed not. > > > > I vaguely recall that the xapi folks add a bit of slack to the domain > > size while they are doing the calculation to see if it fit will on the > > host, but not actually when they build the domain. (note that this > > therefore only matters for the domain being built, and not cumulatively > > for all domains, which makes a difference to the overall overheads on > > the system). We could try switching to a model like that and see what > > breaks I guess? > > > > I''ve CC''d a couple of xapi folks so they can correct my no doubt faulty > > memory ;-) > > Ian. > > Xapi experts, any thought?Andy Cooper told me on IRC Xapi adds the slack when building the domain. Apparently not doing so cause unspecified fallout. Which isn''t to say that''s xapi specific and xl would be fine. Ian.
Wei Liu
2013-Nov-06 12:04 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Tue, Oct 29, 2013 at 11:39:47AM +0000, Wei Liu wrote:> When using OVMF we need to have 1MiB of memory in place for firmware. > Without this change we have: > > (XEN) HVM128: Loading OVMF ... > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > This is not a fatal error as hvmloader will instead use low memory to > load OVMF, but it''s better to eliminate such error. > > Changing this constant doesn''t necessary increase the total amount of > memory a guest uses because it''s just a limit. > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > Cc: Ian Campbell <ian.campbell@citrix.com> > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > --- > tools/libxl/libxl_internal.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 165dc00..908af20 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -87,7 +87,7 @@ > #define LIBXL_QEMU_BODGE_TIMEOUT 2 > #define LIBXL_XENCONSOLE_LIMIT 1048576 > #define LIBXL_XENCONSOLE_PROTOCOL "vt100" > -#define LIBXL_MAXMEM_CONSTANT 1024 > +#define LIBXL_MAXMEM_CONSTANT 2048 > #define LIBXL_PV_EXTRA_MEMORY 1024 > #define LIBXL_HVM_EXTRA_MEMORY 2048 > #define LIBXL_MIN_DOM0_MEM (128*1024) > --Actually those messages are debug only, so this patch is not necessary. Please drop this one. Wei.> 1.7.10.4
Stefano Stabellini
2013-Nov-06 18:04 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
On Wed, 6 Nov 2013, Ian Campbell wrote:> On Wed, 2013-11-06 at 10:32 +0000, Wei Liu wrote: > > On Fri, Nov 01, 2013 at 04:23:04PM +0000, Ian Campbell wrote: > > > On Fri, 2013-11-01 at 16:10 +0000, Wei Liu wrote: > > > > On Fri, Nov 01, 2013 at 04:02:17PM +0000, Ian Campbell wrote: > > > > > On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote: > > > > > > When using OVMF we need to have 1MiB of memory in place for firmware. > > > > > > Without this change we have: > > > > > > > > > > > > (XEN) HVM128: Loading OVMF ... > > > > > > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024 > > > > > > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1) > > > > > > > > > > > > This is not a fatal error as hvmloader will instead use low memory to > > > > > > load OVMF, but it''s better to eliminate such error. > > > > > > > > > > > > Changing this constant doesn''t necessary increase the total amount of > > > > > > memory a guest uses because it''s just a limit. > > > > > > > > > > It will allow a guest to try and use up to 1MB more though, and it > > > > > allows this for PV guests as well as HVM guests not using OVMF. > > > > > > > > > > There''s only a small number of place which use this constant, can we > > > > > refactor them into a helper function, which can then be expanded to > > > > > include a per-BIOS overhead in addition to this one? The BIOS selection > > > > > is stored in xenstore, so that work even for calls which don''t have the > > > > > domain configuration to hand. > > > > > > > > > > (does anyone remember what the existing 1MB is actually for?) > > > > > > > > > > > > > Happened to come across this when I was looking at other problem. > > > > > > > > http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html > > > > > > > > It looks like that constant was never intended to use in the way it is > > > > now. Hah. > > > > > > Indeed not. > > > > > > I vaguely recall that the xapi folks add a bit of slack to the domain > > > size while they are doing the calculation to see if it fit will on the > > > host, but not actually when they build the domain. (note that this > > > therefore only matters for the domain being built, and not cumulatively > > > for all domains, which makes a difference to the overall overheads on > > > the system). We could try switching to a model like that and see what > > > breaks I guess? > > > > > > I''ve CC''d a couple of xapi folks so they can correct my no doubt faulty > > > memory ;-) > > > Ian. > > > > Xapi experts, any thought? > > Andy Cooper told me on IRC > Xapi adds the slack when building the domain. > > Apparently not doing so cause unspecified fallout. Which isn''t to say > that''s xapi specific and xl would be fine.Yeah.. theoretically I think that we shouldn''t have that constat at all. In practice it could cause stability issues, maybe difficult to narrow down. Maybe we should remember to remove it at the beginning of the next development cycle and see what breaks? Keeping in mind that OSSTests is really unlikely to find any of these issues, we should probably try to get the community more involved with the testing.
Ian Campbell
2013-Nov-07 11:03 UTC
Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
create ! title it Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks thanks On Wed, 2013-11-06 at 18:04 +0000, Stefano Stabellini wrote:> > > > > Happened to come across this when I was looking at other problem. > > > > > > > > > > http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html > > > > > > > > > > It looks like that constant was never intended to use in the way it is > > > > > now. Hah. > > > > > > > > Indeed not. > > > > > > > > I vaguely recall that the xapi folks add a bit of slack to the domain > > > > size while they are doing the calculation to see if it fit will on the > > > > host, but not actually when they build the domain. (note that this > > > > therefore only matters for the domain being built, and not cumulatively > > > > for all domains, which makes a difference to the overall overheads on > > > > the system). We could try switching to a model like that and see what > > > > breaks I guess? > > > > > > > > I''ve CC''d a couple of xapi folks so they can correct my no doubt faulty > > > > memory ;-) > > > > Ian. > > > > > > Xapi experts, any thought? > > > > Andy Cooper told me on IRC > > Xapi adds the slack when building the domain. > > > > Apparently not doing so cause unspecified fallout. Which isn''t to say > > that''s xapi specific and xl would be fine. > > Yeah.. theoretically I think that we shouldn''t have that constat at all. > In practice it could cause stability issues, maybe difficult to narrow > down. Maybe we should remember to remove it at the beginning of the next > development cycle and see what breaks? Keeping in mind that OSSTests is > really unlikely to find any of these issues, we should probably try to > get the community more involved with the testing.The reasons for keeping it are based mostly on folklore rather than an actual understanding of the issues, which may not even be real, and it''s wasting (cumulatively) a fair bit of RAM. But waiting until early in the 4.5 cycle is probably a good idea. I''ve created a bug (with this mail) to remind us to do this. Ian.
xen@bugs.xenproject.org
2013-Nov-07 11:15 UTC
Processed: Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
Processing commands for xen@bugs.xenproject.org:> create !Created new bug #23 rooted at `<1383822208.26213.173.camel@kazak.uk.xensource.com>'' Title: `Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048''> title it Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaksSet title for #23 to `Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks''> thanksFinished processing. Modified/created Bugs: - 23: http://bugs.xenproject.org/xen/bug/23 (new) --- Xen Hypervisor Bug Tracker See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues
On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote:> OVMF (open virtual machine firmware) is used to provide UEFI support for > virtual machines. It was first introduced about a year ago but was disabled due > to compilation problem. Now that the compilation problem is resolved we can > reintorduce it. > > OVMF tree can be pulled from > git://xenbits.xen.org/people/liuw/ovmf.git for-xenbits > > Wei. > > Change from V2: > * update Config.mk before enabling OVMF build > > Ian Campbell (3): > tools: clone ovmf to ovmf-dir directory > tools: support system supplied ovmf binaryI have pushed these.> tools: Enable OVMF build by defaultWei told me that more work was needed to make OVMF usable, so on his recommendation I have held off on this one.> Wei Liu (2): > libxl: bump LIBXL_MAXMEM_CONSTANT to 2048This one was previously ruled out.> Config.mk: update OVMF changesetI have applied this one. Thanks Wei. Ian