[Xen-devel] [seabios test] 117929: regressions - FAIL

flight 117929 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/117929/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

[Xen-devel] Clarification regarding Meltdown and 64-bit PV guests

Hi, In : "On Intel processors, only 64-bit PV mode guests can attack Xen using Variant 3. Guests running in 32-bit PV mode, HVM mode, and PVH mode (both v1 and v2) cannot attack the hypervisor using Variant

Re: [Xen-devel] [PATCH] fix potential null dereference

(CC the REST maintainers) On 01/12/2018 11:40 PM, Stefano Stabellini wrote: handles can theoretically be NULL, check for it explicitly before dereferencing it. I doubt handles could be NULL if LocateHandle succeed. This seems to be confirmed by the spec (Page 208 in UEFI spec 2.7). So I am

[Xen-devel] [xen-4.8-testing test] 117871: regressions - FAIL

flight 117871 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117871/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 117697 Tests which

[Xen-devel] [xen-4.9-testing test] 117868: regressions - FAIL

flight 117868 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117868/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair 6 host-ping-check-native/src_host fail REGR. vs. 117739 Regressions

[Xen-devel] [qemu-mainline baseline-only test] 74335: trouble: blocked/broken

This run is configured for baseline tests only. flight 74335 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74335/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64

[Xen-devel] [PATCH] remove dead code in allocate_memory

lowmem is unchanged until after this loop, there is no point in testing for its value. Moreover, Coverity complains about dead code. Remove the lowmem test in the first loop. CID: 1381832 Signed-off-by: Stefano Stabellini diff --git a/xen/arch/arm/domain_build.c

[Xen-devel] [PATCH] don't pass r12/x16 as reference

r12 and x16 are of different sizes; when passing r12 as a reference to do_trap_hypercall on arm64, we end up dereferencing it as a pointer to a 64bit value, but actually it isn't. Instead, pass r12/x16 as values and explicitly overwrite them when necessary, using the pointer name. CID: 1457708

Re: [Xen-devel] [PATCH] vixen: transmit NUL characters received from guest serial port

On Fri, Jan 12, 2018 at 3:39 PM, Sarah Newman wrote: > Certain programs, such as the NetBSD installer, include NUL characters > in their output. Using null-terminated strings for transmitting data > from the guest to the L0 hypervisor meant the output was being corrupted. > > This

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

flight 117833 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/117833/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 117764

[Xen-devel] [PATCH] vixen: transmit NUL characters received from guest serial port

Certain programs, such as the NetBSD installer, include NUL characters in their output. Using null-terminated strings for transmitting data from the guest to the L0 hypervisor meant the output was being corrupted. This makes only the required changes for vixen to work properly. Future work could

[Xen-devel] [PATCH] fix potential null dereference

handles can theoretically be NULL, check for it explicitly before dereferencing it. CID: 1381838 Signed-off-by: Stefano Stabellini diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 469bf98..431fe2e 100644 --- a/xen/common/efi/boot.c +++

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

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

Re: [Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

On 1/12/18 12:37 PM, Andrew Cooper wrote: > Windows is the only OS which pages out kernel datastructures, so chances are > good that this is a vestigial remnant of the PV Windows XP experiment. > Furthermore the implementation is incomplete; it only functions for a present > => not-present

Re: [Xen-devel] [PATCH v2] kexec-tools: Perform run-time linking of libxenctrl.so

Daniel, Thanks for the feedback, see responses inline below. I've posted v3 of the patch. Eric On 12/18/2017 07:43 AM, Daniel Kiper wrote: On Thu, Dec 14, 2017 at 04:48:01PM -0600, Eric DeVolder wrote: When kexec is utilized in a Xen environment, it has an explicit run-time dependency on

[Xen-devel] [PATCH v3] kexec-tools: Perform run-time linking of libxenctrl.so

When kexec is utilized in a Xen environment, it has an explicit run-time dependency on libxenctrl.so. This dependency occurs during the configure stage and when building kexec-tools. When kexec is utilized in a non-Xen environment (either bare metal or KVM), the configure and build of kexec-tools

Re: [Xen-devel] Vixen - does no migration imply no save/restore?

On Fri, Jan 12, 2018 at 08:04:57PM +, Andy Smith wrote: > Hi, > > I understand that Vixen does not support migration at this stage. > Does that also mean that save/restore is also not expected to work > for PV guests running with Vixen? > > I tried it and it doesn't work, whereas it does

Re: [Xen-devel] [PATCH v2 31/62] x86: xen pv clock time source

On 01/12/2018 11:28 AM, Wei Liu wrote: > It is a variant of TSC clock source. > > Signed-off-by: Wei Liu > Signed-off-by: Andrew Cooper > Signed-off-by: Roger Pau Monné > --- > Changes since v1: > - Use the mapped

Re: [Xen-devel] Vixen - does no migration imply no save/restore?

Migrate and Save/Restore are identical operations (to a first approximation) One is serialise the VM into a network socket, while the other is onto disk. It is the same algorithm actually doing the work. ~Andrew From: Xen-devel

Re: [Xen-devel] Xen_Project_Release_Features page update?

On Fri, Jan 12, 2018 at 06:20:05PM +, Julien Grall wrote: > Hi Lars, > > As I understand from Xen 4.10 [1] , we are going to use SUPPORT.MD or the > list of features existing. > > I guess we should retire the features matrix [2]? But this also means that > we have not anymore an easy way to

[Xen-devel] [seabios test] 117887: regressions - FAIL

flight 117887 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/117887/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 117818 REGR. vs. 115539 Tests which are

Re: [Xen-devel] [PATCH 3/5] x86/pv: Break handle_ldt_mapping_fault() out of handle_gdt_ldt_mapping_fault()

On 1/12/18 12:37 PM, Andrew Cooper wrote: > Adjust handle_ldt_mapping_fault() exclude the use of this fixup path for > non-PV guests. Well-formed code shouldn't reference the LDT while in HVM vcpu > context, but currently on a context switch from PV to HVM context, there may > be a stale LDT

[Xen-devel] [qemu-upstream-unstable baseline-only test] 74316: trouble: blocked/broken

This run is configured for baseline tests only. flight 74316 qemu-upstream-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74316/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64

Re: [Xen-devel] [PATCH 2/5] x86/pv: Rename invalidate_shadow_ldt() to pv_destroy_ldt()

On 1/12/18 12:37 PM, Andrew Cooper wrote: > and move it into pv/descriptor-tables.c beside its GDT counterpart. Reduce > the !in_irq() check from a BUG_ON() to ASSERT(). > > Signed-off-by: Andrew Cooper Reviewed-by: Doug Goldstein -- Doug

Re: [Xen-devel] [PATCH 1/5] x86/idt: Factor out enabling and disabling of ISTs

On 1/12/18 12:37 PM, Andrew Cooper wrote: > All alteration of IST settings (other than the crash path) happen in an > identical triple. Introduce helpers to keep the triple in sync, and reduce > the risk of opencoded mistakes. > > Signed-off-by: Andrew Cooper

[Xen-devel] Vixen - does no migration imply no save/restore?

Hi, I understand that Vixen does not support migration at this stage. Does that also mean that save/restore is also not expected to work for PV guests running with Vixen? I tried it and it doesn't work, whereas it does when the guest is started normal PV. I thought I better check expectations

[Xen-devel] [PATCH 1/5] x86/idt: Factor out enabling and disabling of ISTs

All alteration of IST settings (other than the crash path) happen in an identical triple. Introduce helpers to keep the triple in sync, and reduce the risk of opencoded mistakes. Signed-off-by: Andrew Cooper --- CC: Jan Beulich ---

[Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

Windows is the only OS which pages out kernel datastructures, so chances are good that this is a vestigial remnant of the PV Windows XP experiment. Furthermore the implementation is incomplete; it only functions for a present => not-present transition, rather than a present => read/write

[Xen-devel] [PATCH 3/5] x86/pv: Break handle_ldt_mapping_fault() out of handle_gdt_ldt_mapping_fault()

Adjust handle_ldt_mapping_fault() exclude the use of this fixup path for non-PV guests. Well-formed code shouldn't reference the LDT while in HVM vcpu context, but currently on a context switch from PV to HVM context, there may be a stale LDT selector loaded, over an unmapped region. By

[Xen-devel] [PATCH 0/5] x86: Misc improvements from KAISER-prep work

This is a misc set of improvements I made when doing the KAISER-prep work, but stand on their own merit irrespective of that series. Andrew Cooper (5): x86/idt: Factor out enabling and disabling of ISTs x86/pv: Rename invalidate_shadow_ldt() to pv_destroy_ldt() x86/pv: Break

[Xen-devel] [PATCH 2/5] x86/pv: Rename invalidate_shadow_ldt() to pv_destroy_ldt()

and move it into pv/descriptor-tables.c beside its GDT counterpart. Reduce the !in_irq() check from a BUG_ON() to ASSERT(). Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/mm.c | 51

[Xen-devel] [PATCH 5/5] x86/monitor: Capture Xen's intent to use monitor at boot time

The ACPI idle driver uses an IPI to retrieve cpuid_ecx(5). This is wasteful. Introduce X86_FEATURE_XEN_MONITOR as a synthetic feature bit meaning MONITOR && EXTENSIONS && INTERRUPT_BREAK, and calculate it when a cpu comes up rather than repeatedly at runtime. Drop the duplicate defines for

[Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- v7: * Use the opt_ibpb boolean rather than using a cpufeature flag. --- docs/misc/xen-command-line.markdown | 5 - xen/arch/x86/domain.c | 3 +++ xen/arch/x86/spec_ctrl.c

[Xen-devel] [PATCH v8 14/17] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

ret instructions are speculated directly to values recorded in the RSB/RAS, as there is no uncertainty in well-formed code. Guests can take advantage of this in two ways: 1) If they can find a path in Xen which executes more ret instructions than call instructions. (At least one in the

[Xen-devel] [PATCH v8 17/17] x86/idle: Clear SPEC_CTRL while idle

On contemporary hardware, setting IBRS/STIBP has a performance impact on adjacent hyperthreads. It is therefore recommended to clear the setting before becoming idle, to avoid an idle core preventing adjacent userspace execution from running at full performance. Care must be taken to ensure

Re: [Xen-devel] Backport request for Arm

On 01/11/2018 08:38 PM, Stefano Stabellini wrote: Backports done, I skipped 43208a9cb4c3decce67b653539c1b860121fbb5e I am happy with that. Thank you for the backporting! Cheers, On Mon, 18 Dec 2017, Julien Grall wrote: Hi, Below a list of potential backport patches for Xen 4.{10,9,8,7}.

[Xen-devel] [PATCH v8 10/17] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

For performance reasons, HVM guests should have direct access to these MSRs when possible. Signed-off-by: Andrew Cooper --- v7: * Drop excess brackets --- xen/arch/x86/domctl.c | 19 +++ xen/arch/x86/hvm/svm/svm.c | 5 +

[Xen-devel] [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

Signed-off-by: Andrew Cooper --- v7: * static, and tweak comment --- docs/misc/xen-command-line.markdown | 6 ++- xen/arch/x86/spec_ctrl.c| 104 ++-- 2 files changed, 105 insertions(+), 5 deletions(-) diff --git

[Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads

Set STIBP behind the guests back if it knows about IBRS but not STIBP, and no MSR_SPEC_CTRL protection active. Signed-off-by: Andrew Cooper --- v7: * Move logic into a static inline helper. --- xen/arch/x86/domain.c| 8 xen/arch/x86/msr.c

[Xen-devel] Xen_Project_Release_Features page update?

Hi Lars, As I understand from Xen 4.10 [1] , we are going to use SUPPORT.MD or the list of features existing. I guess we should retire the features matrix [2]? But this also means that we have not anymore an easy way to know until when a release is supported/security supported. Do you have

[Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

Introduce INDIRECT_CALL and INDIRECT_JMP which either degrade to a normal indirect branch, or dispatch to the __x86_indirect_thunk_* symbols. Update all the manual indirect branches in to use the new thunks. The indirect branches in the early boot and kexec path are left intact as we can't use

[Xen-devel] [PATCH v8 06/17] x86/feature: Definitions for Indirect Branch Controls

Contemporary processors are gaining Indirect Branch Controls via microcode updates. Intel are introducing one bit to indicate IBRS and IBPB support, and a second bit for STIBP. AMD are introducing IBPB only, so enumerate it with a separate bit. Furthermore, depending on compiler and microcode

[Xen-devel] [PATCH v8 01/17] x86: Support compiling with indirect branch thunks

Use -mindirect-branch=thunk-extern/-mindirect-branch-register when available. To begin with, use the retpoline thunk. Later work will add alternative thunks which can be selected at boot time. Signed-off-by: Andrew Cooper --- v7: * Alter thunk symbols to match the

[Xen-devel] [PATCH v8 00/17] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection

This series is availabe in git form from: http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/sp2-mitigations-v8 In addition to this software series, you will need the following: 1) A compiler which understands -mindirect-branch=thunk-external and

[Xen-devel] [PATCH v8 03/17] x86/boot: Report details of speculative mitigations

Nothing very interesting at the moment, but the logic will grow as new mitigations are added. Signed-off-by: Andrew Cooper Acked-by: Jan Beulich --- xen/arch/x86/Makefile | 1 + xen/arch/x86/setup.c| 3 ++

[Xen-devel] [PATCH v8 04/17] x86/amd: Try to set lfence as being Dispatch Serialising

This property is required for the AMD's recommended mitigation for Branch Target Injection, but Xen needs to cope with being unable to detect or modify the MSR. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- xen/arch/x86/cpu/amd.c

[Xen-devel] [PATCH v8 09/17] x86/migrate: Move MSR_SPEC_CTRL on migrate

Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Jan Beulich --- xen/arch/x86/domctl.c | 2 ++ xen/arch/x86/hvm/hvm.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/xen/arch/x86/domctl.c

[Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- xen/arch/x86/msr.c| 35 +++ xen/include/asm-x86/msr.h | 12 2 files changed, 47 insertions(+) diff --git a/xen/arch/x86/msr.c

[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 7 Information leak via side effects of speculative execution UPDATES IN VERSION 7 PVH shim ("Comet")

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

On Fri, 12 Jan 2018, Jan Beulich wrote: > >>> On 12.01.18 at 18:02, wrote: > > On Fri, Jan 12, 2018 at 03:19:38AM -0700, Jan Beulich wrote: > >> @@ -799,6 +982,10 @@ void __init smp_prepare_cpus(unsigned in > >> > >> stack_base[0] = stack_start; > >> > >> +if (

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 12/01/18 17:17, Nathan March wrote: >>> In the matrix I see "Is a user space attack on the guest kernel possible >>> (when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1] >>> Impacts Intel CPUs only. >>> >>> Is there any mitigation for this? i.e. How to protect a guest VM from >>>

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

> > In the matrix I see "Is a user space attack on the guest kernel possible > > (when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1] > > Impacts Intel CPUs only. > > > > Is there any mitigation for this? i.e. How to protect a guest VM from > > its own userspace processes. > > That

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

>>> On 12.01.18 at 18:02, wrote: > On Fri, Jan 12, 2018 at 03:19:38AM -0700, Jan Beulich wrote: >> @@ -799,6 +982,10 @@ void __init smp_prepare_cpus(unsigned in >> >> stack_base[0] = stack_start; >> >> +if ( !setup_cpu_root_pgt(0) ) >> +panic("No memory

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

On Fri, Jan 12, 2018 at 03:19:38AM -0700, Jan Beulich wrote: > This is a very simplistic change limiting the amount of memory a running > 64-bit PV guest has mapped (and hence available for attacking): Only the > mappings of stack, IDT, and TSS are being cloned from the direct map > into per-CPU

[Xen-devel] [adhoc test] 117925: regressions - trouble: blocked/fail/pass/preparing/queued/running

[adhoc adhoc] harness ce04250: smoke tests: Fix job reuse globs in cr-daily-branch 117925: regressions - trouble: blocked/fail/pass/preparing/queued/running flight 117925 xen-unstable running [adhoc] http://logs.test-lab.xenproject.org/osstest/logs/117925/ Regressions :-( Tests which did not

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

>>> On 12.01.18 at 11:19, wrote: > @@ -727,6 +907,9 @@ static int cpu_smpboot_alloc(unsigned in > set_ist(_tables[cpu][TRAP_nmi], IST_NONE); > set_ist(_tables[cpu][TRAP_machine_check], IST_NONE); > > +if ( !setup_cpu_root_pgt(cpu) ) > +goto

[Xen-devel] [GIT PULL] xen: fixes for 4.15-rc8

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.15-rc8-tag xen: fixes for 4.15-rc8 It contains 2 build fixes for clang and 2 fixes for rather unlikely situations in the Xen gntdev driver. Thanks. Juergen

Re: [Xen-devel] [PATCH] x86/link: Don't merge .init.text and .init.data

On 12/01/18 11:23, Jan Beulich wrote: On 11.01.18 at 15:17, wrote: >> c/s 1308f0170c merged .init.text and .init.data, because EFI might properly >> write-protect r/o sections. >> >> However, this change makes xen-syms unusable for disassembly analysis. In >>

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

On Fri, Jan 12, 2018 at 10:19 AM, Jan Beulich wrote: > This is a very simplistic change limiting the amount of memory a running > 64-bit PV guest has mapped (and hence available for attacking): Only the > mappings of stack, IDT, and TSS are being cloned from the direct map >

[Xen-devel] [PATCH] fixup! libxl: pvshim: Provide first-class config settings to enable shim mode

Earlier versions of this patch have an erroneous hunk which will stop PV guests from working at all! Signed-off-by: Ian Jackson CC: Wei Liu --- tools/libxl/libxl_create.c | 4 1 file changed, 4 insertions(+) diff --git

[Xen-devel] [PATCH] fixup! libxl: pvshim: Provide first-class config settings to enable shim mode

Earlier versions of this patch have an erroneous hunk which will stop PV guests from working at all! Signed-off-by: Ian Jackson CC: Wei Liu --- tools/libxl/libxl_create.c | 4 1 file changed, 4 insertions(+) diff --git

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Fri, Jan 12, 2018 at 02:18:33PM +, Roger Pau Monné wrote: > On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote: > > Hi all, > > > > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the > > other is called Comet. The long term goal is to merge the two > >

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

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote: > On Fri, Jan 12, Wei Liu wrote: > > > Vixen Comet > > Guest console Output onlyBi-directional > > With the proper patch input works for Vixen. Unless this item

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Fri, Jan 12, 2018 at 06:57:09AM -0700, Jan Beulich wrote: > >>> On 12.01.18 at 14:24, wrote: > > Here I list the differences between the two implementations. > > Thanks for the summary. > > > Vixen Comet > > Boot mode

Re: [Xen-devel] Rudolph: merging Vixen and Comet

>>> On 12.01.18 at 14:24, wrote: > Here I list the differences between the two implementations. Thanks for the summary. > Vixen Comet > Boot mode HVMPVH + HVM > Kconfig options

[Xen-devel] Rudolph: merging Vixen and Comet

Hi all, Two solutions are proposed to mitigate Meltdown. One is called Vixen and the other is called Comet. The long term goal is to merge the two implementations to one. Here I list the differences between the two implementations. Vixen Comet Boot

Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

>>> On 09.01.18 at 20:43, wrote: > When I compiled the snippet on x86 and Arm, no relocation is available > for the pointers to string in the array in the final binary. Yet they > are available in the object. I can see them there in the binary I look at. I use my own

[Xen-devel] vixen and vfb, missing vfb support in qemu

It seems the list of missing features of vixen does not cover the lack of framebuffer support. 'xl create -Vf PV.cfg' would show the guest console in the VNC window. With vixen this can not work because the vfb code triggers only for PV guests. Is that missing feature on anyones radar already? At

[Xen-devel] [PATCH v3 3/6] x86/hvm: Provide XEN_DMOP_pin_memory_cacheattr

Provide XEN_DMOP_pin_memory_cacheattr to allow a deprivileged QEMU to pin the caching type of RAM after moving the VRAM. It is equivalent to XEN_DOMCTL_pin_memory_cacheattr. Signed-off-by: Ross Lagerwall Reviewed-by: Paul Durrant Reviewed-by:

[Xen-devel] [PATCH v3 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and have it call the new dmop. Leave the definitions of XEN_DOMCTL_MEM_CACHEATTR_* since

[Xen-devel] [PATCH v3 2/6] x86/hvm: Provide XEN_DMOP_add_to_physmap

Provide XEN_DMOP_add_to_physmap, a limited version of XENMEM_add_to_physmap to allow a deprivileged QEMU to move VRAM when a guest programs its BAR. It is equivalent to XENMEM_add_to_physmap with space == XENMAPSPACE_gmfn_range. Signed-off-by: Ross Lagerwall ---

[Xen-devel] [PATCH v3 5/6] tools: libxendevicemodel: Provide xendevicemodel_pin_memory_cacheattr

Signed-off-by: Ross Lagerwall Acked-by: Ian Jackson Reviewed-by: Paul Durrant --- tools/libs/devicemodel/core.c | 19 +++ tools/libs/devicemodel/include/xendevicemodel.h | 14

[Xen-devel] [PATCH v2 31/62] x86: xen pv clock time source

It is a variant of TSC clock source. Signed-off-by: Wei Liu Signed-off-by: Andrew Cooper Signed-off-by: Roger Pau Monné --- Changes since v1: - Use the mapped vcpu_info. --- xen/arch/x86/time.c | 89

[Xen-devel] [PATCH v2 62/62] xl: Default guest mode changed from PV to PVH with PV shim

From: Ian Jackson If the config file specifies a type (or builder), it overrides this default. But if it doesn't, you now get a PV-in-PVH guest. Signed-off-by: Ian Jackson --- v2: New patch --- tools/xl/xl_parse.c | 13 ++--- 1

[Xen-devel] [PATCH v2 39/62] tools/firmware: Build and install xen-shim

From: Andrew Cooper Link a minimum set of files to build the shim. The linkfarm rune can handle creation and deletion of files. Introduce build-shim and install-shim targets in xen/Makefile. We can do better by properly generate the dependency from the list of files

[Xen-devel] [PATCH v2 59/62] libxl: pvshim: Provide first-class config settings to enable shim mode

From: Ian Jackson This is API-compatible because old callers are supposed to call libxl_*_init to initialise the struct; and the updated function clears these members. It is ABI-compatible because the new fields make this member of the guest type union larger but only

[Xen-devel] [PATCH v2 18/62] x86: produce a binary that can be booted as PVH

Produce a binary that can be booted as PVH. It doesn't do much yet. Signed-off-by: Wei Liu Signed-off-by: Andrew Cooper --- v2: 1. Remove shim-y dependency. 2. Remove extraneous blank line. 3. Fix bugs in xen.lds.S. 4. Haven't split code into

[Xen-devel] [PATCH v2 43/62] xen/pvshim: skip Dom0-only domain builder parts

From: Roger Pau Monne Do not allow access to any iomem or ioport by the shim, and also remove the check for Dom0 kernel support. Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich --- xen/arch/x86/dom0_build.c| 4

[Xen-devel] [PATCH v2 55/62] xen/shim: modify shim_mem parameter behaviour

From: Roger Pau Monne shim_mem will now account for both the memory used by the hypervisor loaded in memory and the free memory slack given to the shim for runtime usage. From experimental testing it seems like the total amount of MiB used by the shim (giving it ~1MB of

[Xen-devel] [PATCH v2 26/62] xen: introduce rangeset_claim_range

Reserve a hole in a rangeset. Signed-off-by: Roger Pau Monne Signed-off-by: Wei Liu --- Changes since v1: - Change function name. - Use a local variable instead of *s. - Add unlikely to the !prev case. - Move the function prototype position in the

[Xen-devel] [PATCH v2 20/62] x86/boot: Map more than the first 16MB

From: Andrew Cooper TODO: Replace somehow (bootstrap_map() ?) Signed-off-by: Andrew Cooper --- xen/arch/x86/boot/x86_64.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/arch/x86/boot/x86_64.S

[Xen-devel] [PATCH v2 40/62] xen/x86: make VGA support selectable

From: Roger Pau Monne Through a Kconfig option. Enable it by default, and disable it for the PV-in-PVH shim. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich Signed-off-by: Wei Liu ---

[Xen-devel] [PATCH v2 15/62] x86/Kconfig: Options for Xen and PVH support

From: Andrew Cooper Introduce two options. One to detect whether the binary is running on Xen, the other enables PVH ABI support. The former will be useful to PV in HVM approach. Both will be used by PV in PVH approach. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH v2 50/62] xen/pvshim: add migration support

From: Roger Pau Monne Signed-off-by: Roger Pau Monné --- Changes since v1: - Use bitmap_zero instead of memset. - Don't drop the __init attribute of unshare_xen_page_with_guest, it's not needed for migration. - Remove BUG_ON to check correct

[Xen-devel] [PATCH v2 56/62] xen/pvshim: use default position for the m2p mappings

From: Roger Pau Monne When running a 32bit kernel as Dom0 on a 64bit hypervisor the hypervisor will try to shrink the hypervisor hole to the minimum needed, and thus requires the Dom0 to use XENMEM_machphys_mapping in order to fetch the position of the start of the

[Xen-devel] [PATCH v2 25/62] xen/console: Introduce console=xen

This specifies whether to use Xen specific console output. There are two variants: one is the hypervisor console, the other is the magic debug port 0xe9. Signed-off-by: Andrew Cooper Signed-off-by: Wei Liu --- xen/drivers/char/console.c

[Xen-devel] [PATCH v2 37/62] x86/guest: use PV console for Xen/Dom0 I/O

From: Sergey Dyasli Signed-off-by: Sergey Dyasli Signed-off-by: Wei Liu --- docs/misc/xen-command-line.markdown | 5 - xen/arch/x86/guest/xen.c| 3 +++ xen/drivers/char/console.c | 16

[Xen-devel] [PATCH v2 58/62] xen/shim: allow DomU to have as many vcpus as available

From: Roger Pau Monne Since the shim VCPUOP_{up/down} hypercall is wired to the plug/unplug of CPUs to the shim itself, start the shim DomU with only the BSP online, and let the guest bring up other CPUs as it needs them. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v2 11/62] tools/ocaml: Expose arch_config in domaininfo

From: Andrew Cooper Signed-off-by: Andrew Cooper --- tools/ocaml/libs/xc/xenctrl.ml | 29 + tools/ocaml/libs/xc/xenctrl.mli | 28 tools/ocaml/libs/xc/xenctrl_stubs.c | 26

[Xen-devel] [PATCH v2 10/62] xen/domctl: Return arch_config via getdomaininfo

From: Andrew Cooper This allows toolstack software to distinguish HVM from PVH guests. Signed-off-by: Andrew Cooper Signed-off-by: Wei Liu Reviewed-by: Jan Beulich --- v2: bump domctl version number

[Xen-devel] [PATCH v2 42/62] sched/null: skip vCPUs on the waitqueue that are blocked

From: Roger Pau Monne Avoid scheduling vCPUs that are down, there's no point in assigning them to a pCPU because they are not going to run anyway. Since down vCPUs are not assigned to pCPUs after this change, force a rescheduling when a vCPU is brought up if it's on the

[Xen-devel] [PATCH v2 41/62] xen/pvh: do not mark the low 1MB as IO mem

From: Roger Pau Monne On PVH there's nothing special on the low 1MB. This is an optional patch that doesn't affect the functionality of the shim. Signed-off-by: Roger Pau Monné Signed-off-by: Andrew Cooper ---

[Xen-devel] [PATCH v2 17/62] x86: introduce ELFNOTE macro

It is needed later for introducing PVH entry point. Signed-off-by: Wei Liu --- v2: 1. Specify section attribute and type. 2. Use p2align. 3. Align instructions. 4. Haven't used .L or turned it into assembly macro. --- xen/include/asm-x86/asm_defns.h | 12 1

[Xen-devel] [PATCH v2 22/62] x86/guest: Hypercall support

From: Andrew Cooper Signed-off-by: Andrew Cooper Signed-off-by: Wei Liu --- v2: append underscores to tmp. --- xen/arch/x86/guest/Makefile | 1 + xen/arch/x86/guest/hypercall_page.S | 79

[Xen-devel] [PATCH v2 32/62] x86: APIC timer calibration when running as a guest

The timer calibration currently depends on PIT. Introduce a variant to wait for a tick's worth of time to elapse when running as a PVH guest. Signed-off-by: Wei Liu Reviewed-by: Jan Beulich --- xen/arch/x86/apic.c | 38

[Xen-devel] [PATCH v2 36/62] x86/guest: add PV console code

From: Sergey Dyasli Signed-off-by: Sergey Dyasli Signed-off-by: Andrew Cooper Signed-off-by: Wei Liu --- xen/drivers/char/Makefile | 1 + xen/drivers/char/xen_pv_console.c |

[Xen-devel] [PATCH v2 29/62] xen/guest: fetch vCPU ID from Xen

From: Roger Pau Monne If available. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich [ wei: fix non-shim build ] Signed-off-by: Wei Liu --- xen/arch/x86/guest/xen.c| 23 +++

[Xen-devel] [PATCH v2 33/62] x86: read wallclock from Xen when running in pvh mode

Signed-off-by: Wei Liu Reviewed-by: Jan Beulich --- xen/arch/x86/time.c | 32 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index 4cbd068d17..c90524de9c 100644 ---

[Xen-devel] [PATCH v2 13/62] x86/fixmap: Modify fix_to_virt() to return a void pointer

From: Andrew Cooper Almost all users of fix_to_virt() actually want a pointer. Include the cast within the definition, so the callers don't need to. Two users which need the integer value are switched to using __fix_to_virt() directly. A few users stay fully

  1   2   >