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, despit
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
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
test-amd64-i386-xl-qemuu-w
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
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 1
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
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
---
v4
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 set_bit() if possible
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 p
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 fro
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
Acked-by: Jan B
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:
- check multiboot2_tag_mmap_t.e
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 cons
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
and
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 con
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
Reviewed-by: Konrad Rzeszutek
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 instead of "r" for alloc_mem()
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 conv
..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 changed, 25 insertions(+), 27 d
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 b/xen/arch/x86/boot/head.S
index 85770e8..e34351c 100644
..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 +++
1 file changed, 3 insertions(+)
diff -
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, multib
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 li
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 mimic the Linux kernel development
> f
ake 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, 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
> solution to this problem is for each
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 all built in an adhoc manner which
> requ
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
> enables us to avoid modifying the linker scr
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 custom Linux sections.
>
> This also genera
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 b/tools/include/linux/compiler.h
index 556c991de212..6321265
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 a/tools/include/linux/export.h b/tools/include/linux/export.h
ind
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
---
tools/include/linux/init.h | 9 +++
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 link
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 we'd
need to copy a l
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
---
tools/include/linux/kernel.h | 1 +
tools/
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.
Signed-off-by: Lui
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 Linux-section custom section nam
From: "Luis R. Rodriguez"
Often all is needed is these small helpers, instead of compiler.h
or a full kprobes.h. This is important for asm helpers, in fact even
some asm/kprobes.h make use of these helpers... instead just keep a
generic asm file with helpers useful for asm code with the least amo
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: introduced in this series
S
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 order level annotations
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 linker script
as follows:
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 symbol, followed by a
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 range.
It turns out a
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 a/include/linux/jump_label.h b/include/
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
---
arch/xtensa/kernel/Makefile | 8
1 f
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().
Built-in kernel functionali
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, per architecture. T
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 successfully.
v4:
o wo
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 avoiding
modifying the lin
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, per architecture. T
ace linker table application
forintegration into 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...@kern
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 per Andi the DISABLE
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 successfully.
v4:
o wo
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: introduced in this series
S
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
now though only ena
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 to collateral of the
ace linker table application
forintegration into 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...@kern
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 avoiding
modifying the lin
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 symbol, followed by a
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 per Andi the DISABLE
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 range.
It turns out a
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
---
arch/xtensa/kernel/Makefile | 8
1 f
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
now though only ena
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 to collateral of the
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 redhat-
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
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 host-install(3
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 use
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 v
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
test-armhf-ar
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
>>
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 1
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 grammar corrections
>>>
>>> Signe
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/arch/x86/mm/altp2m.c |
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/include/asm-x86/hvm/hvm.h | 19
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/arch/x86/mm/mm-locks.h | 4 +--
xen/arch/x86/mm/p2m-ept
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 com
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 CR4.OSXSAVE
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 you
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 Cooper
>
> Acked-by: Jan Beuli
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
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,
th
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 11:04 AM, Cendrin Sa wr
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 := $(if $(efi),$(shell
>>> 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 Beulich
with one question:
> @@ -141,7 +121,7 @@ conf
>>> 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
albeit being known to rather comment too little I think that shouldn't
b
>>> 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 xenstore ballooning target.
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
CC: Julien Grall
---
xen/arch/arm/Kconfig| 3 ---
xen/common/Kconfig
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
* 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/common/Kconfig | 44 ++--
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
test-armhf-armhf-libvirt-r
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
test-armhf-
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, wrote:
> > >>>Looking at the kernel it as
>>> 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 ISA region is always mapped WB in page table. No ne
>>> 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,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
>>> if ( op ==
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 == XENMEM_populate_physmap
>>
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 /dev/mmap and lurk in IS
>>> 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
> && (reservation.mem_flags & XENMEMF_populate_o
>>> 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
https://lists.xen.org/xen-devel
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
> Acked-by: Wei Liu
This i
1 - 100 of 144 matches
Mail list logo
