Re: [Xen-devel] [PATCH v1 0/7] tools: add linker table userspace sandbox

On 08/19/2016 04:41 PM, mcg...@kernel.org wrote: > Please let me know if there are any issue or questions. Only that this has been the majority of the traffic on the linux-sh mailing list for over a month and I'm still not sure why anyone should care. I have no idea what problem it solves,

[Xen-devel] [xen-unstable test] 100565: regressions - FAIL

flight 100565 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100565/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 4 host-ping-check-native fail REGR. vs. 100557 Regressions which

[Xen-devel] [qemu-mainline test] 100562: tolerable FAIL - PUSHED

flight 100562 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100562/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100546

[Xen-devel] [ovmf baseline-only test] 67564: regressions - FAIL

This run is configured for baseline tests only. flight 67564 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67564/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 5 kernel-build

[Xen-devel] [xen-unstable-smoke test] 100568: tolerable all pass - PUSHED

flight 100568 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100568/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [PATCH v5 15/16] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 1

[Xen-devel] [PATCH v5 16/16] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v5 13/16] x86: add multiboot2 protocol support for EFI platforms

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v4 - suggestions/fixes: - remove redundant BSS alignment, - update BSS alignment check, - use __set_bit() instead of

[Xen-devel] [PATCH v5 14/16] x86/boot: implement early command line parser in C

Current early command line parser implementation in assembler is very difficult to change to relocatable stuff using segment registers. This requires a lot of changes in very weird and fragile code. So, reimplement this functionality in C. This way code will be relocatable out of the box (without

[Xen-devel] [PATCH v5 12/16] x86/efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory

[Xen-devel] [PATCH v5 08/16] x86/boot/reloc: rename some variables and rearrange code a bit

Replace mbi with mbi_out and mbi_old with mbi_in and rearrange code a bit to make it more readable. Additionally, this way multiboot (v1) protocol implementation and future multiboot2 protocol implementation will use the same variable naming convention. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v5 09/16] x86: add multiboot2 protocol support

Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper --- v5 - suggestions/fixes: -

Re: [Xen-devel] unable start xen in hikey

Hi Julien/Chen, Thanks, it is working for me after setting CONFIG_ARCH_HISI = y in config file. So, when i tried to boot linux thru startup.sh, it seems to hangs and below are the traces of log: Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> FS0: FS0:\> Image

[Xen-devel] [PATCH v5 10/16] efi: create efi_enabled()

First of all we need to differentiate between legacy BIOS and EFI platforms during runtime, not during build, because one image will have legacy and EFI code and can be executed on both platforms. Additionally, we need more fine grained knowledge about EFI environment and check for EFI platform

[Xen-devel] [PATCH v5 11/16] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

[Xen-devel] [PATCH v5 07/16] x86/boot: use %ecx instead of %eax

Use %ecx instead of %eax to store low memory upper limit from EBDA. This way we do not wipe multiboot protocol identifier. It is needed in reloc() to differentiate between multiboot (v1) and multiboot2 protocol. Signed-off-by: Daniel Kiper Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH v5 06/16] x86/boot/reloc: create generic alloc and copy functions

Create generic alloc and copy functions. We need separate tools for memory allocation and copy to provide multiboot2 protocol support. Signed-off-by: Daniel Kiper --- v4 - suggestions/fixes: - avoid assembly usage. v3 - suggestions/fixes: - use "g" constraint

[Xen-devel] [PATCH v5 05/16] x86/boot: call reloc() using stdcall calling convention

Current reloc() call method makes confusion and does not scale well for more arguments. And subsequent patch adding multiboot2 protocol support have to pass 3 arguments instead of 2. Hence, move reloc() call to stdcall calling convention. One may argue that we should use standard cdecl calling

[Xen-devel] [PATCH v5 04/16] x86/boot/reloc: reduce assembly usage as much as possible

..to increase code readability and ease its maintenance. Signed-off-by: Daniel Kiper --- v5 - suggestions/fixes: - improve commit message (suggested by Jan Beulich). --- xen/arch/x86/boot/reloc.c | 52 ++--- 1 file

[Xen-devel] [PATCH v5 02/16] x86/boot: remove multiboot1_header_end from symbol table

Its visibility is not needed and just pollute symbol table. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper --- xen/arch/x86/boot/head.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/boot/head.S

[Xen-devel] [PATCH v5 01/16] x86: allow EFI reboot method neither on EFI platforms...

..nor EFI platforms with runtime services enabled. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper --- v5 - suggestions/fixes: - fix build error (suggested by Jan Beulich), - improve commit message. --- xen/arch/x86/shutdown.c |3

[Xen-devel] [PATCH v5 00/16] x86: multiboot2 protocol support

Hi, I am sending fifth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known issues (many of them were found by Jan Beulich; thanks a lot!). The final goal is xen.efi binary file which could be loaded by EFI loader,

[Xen-devel] [PATCH v5 03/16] x86/boot: create *.lnk files with linker script

Newer GCC (e.g. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) does some code optimizations by creating data sections (e.g. jump addresses for C switch/case are calculated using data in .rodata section). This thing is not accepted by *.lnk build recipe which requires that only .text section

Re: [Xen-devel] [PATCH v1 7/7] tools: add userspace linker table sandbox

On Fri, Aug 19, 2016 at 2:41 PM, wrote: > From: "Luis R. Rodriguez" > > Add a userspace sandbox to allow easy experimentation and > test extensions with linker tables, section ranges and the > new section core definitions. > > The userspace sandbox tries to

Re: [Xen-devel] [PATCH v4 00/16] linux: generalize sections, ranges and linker tables

the kernel under tools/ to make it easier to keep > things in sync, however since this requires a bit of changes to some headers > in tools/ I'll submit that separately. > > [0] > https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcg...@kernel.org > > If you'd like this in git-form,

Re: [Xen-devel] [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y

On Fri, Aug 19, 2016 at 2:32 PM, wrote: > From: "Luis R. Rodriguez" > > Linux provides a rich array of features, enabling each feature > however increases the size of the kernel and there are many > features which users often want disabled. The traditional

Re: [Xen-devel] [PATCH v4 07/16] tables.h: add linker table support

On Fri, Aug 19, 2016 at 2:32 PM, wrote: > From: "Luis R. Rodriguez" > > A linker table is a data structure that is stitched together from items > in multiple object files. Linux has historically implicitly used linker > tables for ages, however they were

Re: [Xen-devel] [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges

On Fri, Aug 19, 2016 at 2:32 PM, wrote: > From: "Luis R. Rodriguez" > > Section ranges are on one of the types of custom sections > types used in Linux. This provides a series of helpers for > defining them and using them. Most importantly this also >

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

On Fri, Aug 19, 2016 at 2:32 PM, wrote: > From: "Luis R. Rodriguez" > > Linux makes extensive use of custom ELF header sections, > documentation for these are well scatterred. Unify this > documentation in a central place and provide helpers to > build

[Xen-devel] [PATCH v1 6/7] tools: add __section() to compiler.h

From: "Luis R. Rodriguez" This will be used later by the userspace linker table. Signed-off-by: Luis R. Rodriguez --- tools/include/linux/compiler.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/include/linux/compiler.h

[Xen-devel] [PATCH v1 5/7] tools: expand export.h with VMLINUX_SYMBOL()

From: "Luis R. Rodriguez" This will be used later by the linker-table userspace sandbox. Signed-off-by: Luis R. Rodriguez --- tools/include/linux/export.h | 22 ++ 1 file changed, 22 insertions(+) diff --git

[Xen-devel] [PATCH v1 3/7] tools: add init.h for tools

From: "Luis R. Rodriguez" Start off with just __ref -- we enalbe you to override, if you do that then you can define your own. The way you'd use this, if you do override, is define your own __ref and then use include_next. Signed-off-by: Luis R. Rodriguez

[Xen-devel] [PATCH v1 0/7] tools: add linker table userspace sandbox

tches which adds linker table support into the kernel. This should be considered only if that gets merged. If you'd like this in git-form, you can get it on the 20160819-linker-table-v4 branch of my linux-next tree on kernel.org, this also includes the series of that introduces linker tables

[Xen-devel] [PATCH v1 1/7] tools: add a userspace tools bug.h

From: "Luis R. Rodriguez" This will be used later by the userspace linker-tables sandbox. As a convenience, include bug.h on kernel.h -- this is not done on upstream kernel.h, however most header files do include bug.h eventually, if we were to only add the ones that need it

[Xen-devel] [PATCH v1 2/7] tools: add a basic tools printk.h

From: "Luis R. Rodriguez" This will be used later by the userspace linker-tables sandbox. Since upstream kernel.h includes printk.h mimic this so we can match and replicate C code as-is on userspace sandbox tools. Signed-off-by: Luis R. Rodriguez ---

[Xen-devel] [PATCH v1 4/7] tools: add __used and enable to override

From: "Luis R. Rodriguez" This adds __used, to be used later in the userspace linker-tables sandbox. If any userspace applicaiton wants to override they can add their own definition and then use include_next. This definition should probably suffice for most uses cases though.

[Xen-devel] [PATCH v4 15/16] kprobes: port .kprobes.text to section range

From: "Luis R. Rodriguez" kprobe makes use of two custom sections, each custom section is folded into one of the standard Linux sections types as follows, it currently relies on the linker script to fold the custom section onto the respective Linux section: type

[Xen-devel] [PATCH v4 09/16] firmware/Makefile: force recompilation if makefile changes

From: "Luis R. Rodriguez" If you modify the target asm we currently do not force the recompilation of the firmware files. The target asm is in the firmware/Makefile, peg this file as a dependency to require re-compilation of firmware targets when the asm changes. v3:

[Xen-devel] [PATCH v4 13/16] dynamic_debug: port to use linker tables

From: "Luis R. Rodriguez" This removes the custom vmlinux.lds.h hacks and uses the generalized solution for .data (SECTION_DATA) entries. This is much more potential for further fine tuning here though in the future. For instance, linker tables enable an extra postfix for

[Xen-devel] [PATCH v4 16/16] kprobes: port blacklist kprobes to linker table

From: "Luis R. Rodriguez" kprobe makes use of two sections, the one dealing with the actual kprobes was recently ported using the standard section range API. The blacklist functionality of kprobes is still using a custom section and declaring its custom section using the

[Xen-devel] [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y

From: "Luis R. Rodriguez" Linux provides a rich array of features, enabling each feature however increases the size of the kernel and there are many features which users often want disabled. The traditional solution to this problem is for each feature to have its own Kconfig

[Xen-devel] [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges

From: "Luis R. Rodriguez" Section ranges are on one of the types of custom sections types used in Linux. This provides a series of helpers for defining them and using them. Most importantly this also enables us to avoid modifying the linker script when we add a new section

[Xen-devel] [PATCH v4 11/16] jump_label: move guard #endif down where it belongs

From: "Luis R. Rodriguez" The ending header guard is misplaced. This has no functional change, this is just an eye-sore. Signed-off-by: Luis R. Rodriguez --- include/linux/jump_label.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Xen-devel] [PATCH v4 05/16] xtensa: skip adding literal when SORT() is used

From: "Luis R. Rodriguez" When SORT(foo.*) is used the current sed replacements add SORT(foo.literal foo.*), this breaks linking. Avoid adding literals for SORT globs, if needed, these need to be added manually. Signed-off-by: Luis R. Rodriguez ---

[Xen-devel] [PATCH v4 12/16] jump_label: port __jump_table to linker tables

From: "Luis R. Rodriguez" Move the __jump_table from the a custom section solution to a generic solution, this avoiding extra vmlinux.lds.h customizations. This also demos the use of the .data (SECTION_DATA) linker table and of the shared asm call push_section_tbl().

[Xen-devel] [PATCH v4 07/16] tables.h: add linker table support

From: "Luis R. Rodriguez" A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications,

[Xen-devel] [PATCH v4 10/16] firmware: port built-in section to linker table

From: "Luis R. Rodriguez" This ports built-in firmware to use linker tables, this replaces the custom section solution with a generic solution. This also demos the use of the .rodata (SECTION_RO) linker tables. Tested with 0 built-in firmware, 1 and 2 built-in firmwares

[Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

From: "Luis R. Rodriguez" Linux makes extensive use of custom ELF header sections, documentation for these are well scatterred. Unify this documentation in a central place and provide helpers to build custom Linux sections. This also generalizes sections code to enable

[Xen-devel] [PATCH v4 07/16] tables.h: add linker table support

From: "Luis R. Rodriguez" A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications,

[Xen-devel] [PATCH v4 00/16] linux: generalize sections, ranges and linker tables

d like this in git-form, you can get it on the 20160819-linker-table-v4 branch of my linux-next tree on kernel.org, this also includes the series of the linker table userspace sandbox: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160819-linker-table-v4 Please l

[Xen-devel] [PATCH v4 01/16] x86: remove LTO_REFERENCE_INITCALL()

From: "Luis R. Rodriguez" The setup for LTO never made it upstream, and although this has some users, this is now really old stuff for a gcc 4.7 LTO problem. We know that at least LTO_REFERENCE_INITCALL() work around can be removed if LTO is not supported on v4.7 anymore. As

[Xen-devel] [PATCH v4 03/16] scripts/module-common.lds: enable generation

From: "Luis R. Rodriguez" scripts/module-common.lds is currently pretty static, in the future this may change and we will want access to kernel macros to help expands certain areas. To get access to use macros we need to generate module-common.lds from module-common.lds.S, for

[Xen-devel] [PATCH v4 10/16] firmware: port built-in section to linker table

From: "Luis R. Rodriguez" This ports built-in firmware to use linker tables, this replaces the custom section solution with a generic solution. This also demos the use of the .rodata (SECTION_RO) linker tables. Tested with 0 built-in firmware, 1 and 2 built-in firmwares

[Xen-devel] [PATCH v4 09/16] firmware/Makefile: force recompilation if makefile changes

From: "Luis R. Rodriguez" If you modify the target asm we currently do not force the recompilation of the firmware files. The target asm is in the firmware/Makefile, peg this file as a dependency to require re-compilation of firmware targets when the asm changes. v3:

[Xen-devel] [PATCH v4 02/16] dell-smo8800: include uaccess.h

From: "Luis R. Rodriguez" sections.h is currently included and it provides dell-smo8800 with what it needs, an upcoming change will decouple uaccess.h from sections.h. This driver needs to explicitly require uaccess.h before this change. v3: new to this series -- needed due

[Xen-devel] [PATCH v4 00/16] linux: generalize sections, ranges and linker tables

d like this in git-form, you can get it on the 20160819-linker-table-v4 branch of my linux-next tree on kernel.org, this also includes the series of the linker table userspace sandbox: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160819-linker-table-v4 Please l

[Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

From: "Luis R. Rodriguez" Linux makes extensive use of custom ELF header sections, documentation for these are well scatterred. Unify this documentation in a central place and provide helpers to build custom Linux sections. This also generalizes sections code to enable

[Xen-devel] [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y

From: "Luis R. Rodriguez" Linux provides a rich array of features, enabling each feature however increases the size of the kernel and there are many features which users often want disabled. The traditional solution to this problem is for each feature to have its own Kconfig

[Xen-devel] [PATCH v4 01/16] x86: remove LTO_REFERENCE_INITCALL()

From: "Luis R. Rodriguez" The setup for LTO never made it upstream, and although this has some users, this is now really old stuff for a gcc 4.7 LTO problem. We know that at least LTO_REFERENCE_INITCALL() work around can be removed if LTO is not supported on v4.7 anymore. As

[Xen-devel] [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges

From: "Luis R. Rodriguez" Section ranges are on one of the types of custom sections types used in Linux. This provides a series of helpers for defining them and using them. Most importantly this also enables us to avoid modifying the linker script when we add a new section

[Xen-devel] [PATCH v4 05/16] xtensa: skip adding literal when SORT() is used

From: "Luis R. Rodriguez" When SORT(foo.*) is used the current sed replacements add SORT(foo.literal foo.*), this breaks linking. Avoid adding literals for SORT globs, if needed, these need to be added manually. Signed-off-by: Luis R. Rodriguez ---

[Xen-devel] [PATCH v4 03/16] scripts/module-common.lds: enable generation

From: "Luis R. Rodriguez" scripts/module-common.lds is currently pretty static, in the future this may change and we will want access to kernel macros to help expands certain areas. To get access to use macros we need to generate module-common.lds from module-common.lds.S, for

[Xen-devel] [PATCH v4 02/16] dell-smo8800: include uaccess.h

From: "Luis R. Rodriguez" sections.h is currently included and it provides dell-smo8800 with what it needs, an upcoming change will decouple uaccess.h from sections.h. This driver needs to explicitly require uaccess.h before this change. v3: new to this series -- needed due

[Xen-devel] [xen-unstable baseline-only test] 67560: regressions - FAIL

This run is configured for baseline tests only. flight 67560 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67560/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 9

[Xen-devel] [xen-unstable-smoke test] 100564: regressions - FAIL

flight 100564 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100564/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 7 host-ping-check-xen fail REGR. vs. 100561 Tests which

[Xen-devel] [qemu-mainline baseline-only test] 67559: regressions - trouble: broken/fail/pass

This run is configured for baseline tests only. flight 67559 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67559/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 3

[Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

Hello Xen Team! Does anybody have any code examples of HVMOP_altp2m_vcpu_enable_notify? I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 in Xen, but doesn't have any documentations/examples for it. I tried xen-access test from tools/tests/xen-access, but looks like it doesn't

[Xen-devel] [ovmf baseline-only test] 67561: all pass

This run is configured for baseline tests only. flight 67561 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67561/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 00bcb5c27a5bb781099482c5763937334be91e76 baseline

[Xen-devel] [distros-debian-jessie test] 67562: tolerable all pass

flight 67562 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67562/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail never pass

Re: [Xen-devel] [PATCH v2] x86/PV: don't wrongly hide/expose CPUID.OSXSAVE from/to user mode

On 19/08/16 18:09, Andrew Cooper wrote: > On 19/08/16 13:53, Jan Beulich wrote: >> User mode code generally cannot be expected to invoke the PV-enabled >> CPUID Xen supports, and prior to the CPUID levelling changes for 4.7 >> (as well as even nowadays on levelling incapable hardware) such CPUID

[Xen-devel] [xen-unstable-smoke test] 100561: tolerable all pass - PUSHED

flight 100561 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100561/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

On 19/08/16 17:50, Doug Goldstein wrote: > On 8/19/16 11:14 AM, Jan Beulich wrote: >> >>> On 19.08.16 at 17:54, wrote: >>> * Drop one piece of trailing whitespace >>> * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig >>> * Spelling and

[Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

Move altp2m specific functions to altp2m files. This makes the code a little easier to read. Also moving ept code to ept specific files as requested in: https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html Signed-off-by: Paul Lai ---

[Xen-devel] [PATCH v2 Altp2m cleanup v3 1/3] altp2m cleanup work

Indent goto labels by one space Inline (header) altp2m functions Define default behavior in switch Define max and min for range of altp2m macroed values Signed-off-by: Paul Lai --- xen/arch/x86/hvm/hvm.c| 46 ---

[Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

Ravi Sahita's dynamically allocated altp2m structs Signed-off-by: Paul Lai Reviewed-by: Ravi Sahita --- xen/arch/x86/hvm/hvm.c | 8 +++--- xen/arch/x86/hvm/vmx/vmx.c | 2 +- xen/arch/x86/mm/altp2m.c | 18 ++---

[Xen-devel] [PATCH v2 Altp2m cleanup v3 0/3] Cleaning up altp2m code

Incorporating comments from v1 altp2m clean code URLs: https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03223.html https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03465.html https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03467.html Older

Re: [Xen-devel] [PATCH v2] x86/PV: don't wrongly hide/expose CPUID.OSXSAVE from/to user mode

On 19/08/16 13:53, Jan Beulich wrote: > User mode code generally cannot be expected to invoke the PV-enabled > CPUID Xen supports, and prior to the CPUID levelling changes for 4.7 > (as well as even nowadays on levelling incapable hardware) such CPUID > invocations actually saw the host

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-4.8-for-linus to your 'for-linus' branch for v4.8-rc3

On 08/19/2016 10:48 AM, Konrad Rzeszutek Wilk wrote: Hey Jens! Please git pull the following three fixes in to your 'for-linus' branch. It is against 'for-linus' instead of 'for-4.8/drivers' because we had some code in xen-blkfront go through the Xen tree (with your Ack). The reason was that

Re: [Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

On 8/19/16 11:14 AM, Jan Beulich wrote: > >>> On 19.08.16 at 17:54, wrote: >> * Drop one piece of trailing whitespace >> * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig >> * Spelling and grammar corrections >> >> Signed-off-by: Andrew

[Xen-devel] [GIT PULL] (xen) stable/for-jens-4.8-for-linus to your 'for-linus' branch for v4.8-rc3

Hey Jens! Please git pull the following three fixes in to your 'for-linus' branch. It is against 'for-linus' instead of 'for-4.8/drivers' because we had some code in xen-blkfront go through the Xen tree (with your Ack). The reason was that you 'for-4.8/drivers' was based on 4.7-rc2, and the fixes

[Xen-devel] [PATCH v3] xen: credit1: fix a race when picking initial pCPU for a vCPU

In the Credit1 hunk of 9f358ddd69463 ("xen: Have schedulers revise initial placement") csched_cpu_pick() is called without taking the runqueue lock of the (temporary) pCPU that the vCPU has been assigned to (e.g., in XEN_DOMCTL_max_vcpus). However, although 'hidden' in the IS_RUNQ_IDLE() macro,

Re: [Xen-devel] Save/Restore is not working properly

Hi again, So save/restore has a bug or not? I still have problem with it when i use LVM. On Sat, Aug 13, 2016 at 11:10 AM, Cendrin Sa wrote: > I used save without any option when my VM was in running state, save won't > work if I pause a VM. > > > On Sat, Aug 13, 2016 at

Re: [Xen-devel] [PATCH 2/2] x86/EFI: use less crude way of generating the build ID

On Mon, Aug 15, 2016 at 10:15:47AM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, Aug 15, 2016 at 01:58:47AM -0600, Jan Beulich wrote: > > >>> On 15.08.16 at 01:42, wrote: > > >> --- a/xen/arch/x86/efi/Makefile > > >> +++ b/xen/arch/x86/efi/Makefile > > >> @@ -9,6 +9,9 @@ efi :=

Re: [Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

>>> On 19.08.16 at 17:54, wrote: > * Drop one piece of trailing whitespace > * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig > * Spelling and grammar corrections > > Signed-off-by: Andrew Cooper Acked-by: Jan

Re: [Xen-devel] [PATCH 1/2] xen/Kconfig: Drop redundant comments from Kconfig files

>>> On 19.08.16 at 17:54, wrote: > Most of the comments are duplicated from the help text, and those without help > provide no useful additional input. > > Signed-off-by: Andrew Cooper Non-ARM parts Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

>>> On 19.08.16 at 18:00, wrote: > PoD is supposed to be entirely transparent to guest, but this interface has > been left exposed for a long time. > > The use of PoD requires careful co-ordination by the toolstack with the > XENMEM_{get,set}_pod_target hypercalls, and

[Xen-devel] [PATCH 1/2] xen/Kconfig: Drop redundant comments from Kconfig files

Most of the comments are duplicated from the help text, and those without help provide no useful additional input. Signed-off-by: Andrew Cooper --- CC: Doug Goldstein CC: Jan Beulich CC: Stefano Stabellini

[Xen-devel] [PATCH v2 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

PoD is supposed to be entirely transparent to guest, but this interface has been left exposed for a long time. The use of PoD requires careful co-ordination by the toolstack with the XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning target. The best a guest can do without toolstack

[Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

* Drop one piece of trailing whitespace * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig * Spelling and grammar corrections Signed-off-by: Andrew Cooper --- CC: Doug Goldstein CC: Jan Beulich ---

[Xen-devel] [xen-unstable test] 100557: tolerable FAIL

flight 100557 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100557/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 100551 pass in 100557

[Xen-devel] [qemu-mainline test] 100559: regressions - FAIL

flight 100559 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100559/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 100546

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

On Thu, Aug 18, 2016 at 04:35:44PM +0100, One Thousand Gnomes wrote: > On Thu, 18 Aug 2016 05:12:54 -0600 > "Jan Beulich" wrote: > > > >>> On 18.08.16 at 12:16, wrote: > > > On 18/08/16 11:06, Jan Beulich wrote: > > > On 17.08.16 at 22:32,

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

>>> On 19.08.16 at 16:52, wrote: > On Thu, Aug 18, 2016 at 04:06:33AM -0600, Jan Beulich wrote: >> >>> On 17.08.16 at 22:32, wrote: >> >Looking at the kernel it assumes that WB is ok for 640KB->1MB. >> >The comment says: >> >" /* Low

Re: [Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

>>> On 19.08.16 at 17:02, wrote: > On 19/08/16 15:58, Jan Beulich wrote: > On 19.08.16 at 16:12, wrote: >>> --- a/xen/common/memory.c >>> +++ b/xen/common/memory.c >>> @@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd, >

Re: [Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

On 19/08/16 15:58, Jan Beulich wrote: On 19.08.16 at 16:12, wrote: >> --- a/xen/common/memory.c >> +++ b/xen/common/memory.c >> @@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd, >> XEN_GUEST_HANDLE_PARAM(void) arg) >> >> if ( op ==

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

On Thu, Aug 18, 2016 at 04:06:33AM -0600, Jan Beulich wrote: > >>> On 17.08.16 at 22:32, wrote: > > One of the interesting things about XSA 154 fix ("x86: enforce consistent > > cachability of MMIO mappings") is that when certain applications (mcelog) > > are trying to map

Re: [Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

>>> On 19.08.16 at 16:12, wrote: > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd, > XEN_GUEST_HANDLE_PARAM(void) arg) > > if ( op == XENMEM_populate_physmap > &&

Re: [Xen-devel] [PATCH 1/2] xen/memop: Latch current->domain in a local variable

>>> On 19.08.16 at 16:12, wrote: > It is more efficient. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v8 05/13] libxl: Load guest BIOS from file

On 18/08/16 15:13, Wei Liu wrote: > From: Anthony PERARD > > The path to the BIOS blob can be overriden by the xl's > bios_path_override option, or provided by u.hvm.bios_firmware in the > domain_build_info struct by other libxl user. > > Signed-off-by: Anthony PERARD

[Xen-devel] [PATCH] tools/firmware: Rename bios.bin to seabios.bin

bios.bin as a name is far too generic. Rename it to seabios.bin. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Anthony PERARD Please rerun autogen.sh --- tools/configure

  1   2   >