[Xen-devel] [xen-4.7-testing test] 119182: regressions - FAIL

flight 119182 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119182/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 118721

Re: [Xen-devel] [RFC XEN PATCH v4 00/41] Add vNVDIMM support to HVM domains

On 02/13/18 15:39 +, Roger Pau Monné wrote: > On Tue, Feb 13, 2018 at 06:40:20AM -0700, Jan Beulich wrote: > > >>> On 13.02.18 at 12:13, wrote: > > > On Tue, Feb 13, 2018 at 04:05:45AM -0700, Jan Beulich wrote: > > >> >>> On 13.02.18 at 11:29,

Re: [Xen-devel] [RFC XEN PATCH v4 00/41] Add vNVDIMM support to HVM domains

On 02/12/18 10:05 +, Roger Pau Monné wrote: > On Mon, Feb 12, 2018 at 09:25:42AM +0800, Haozhong Zhang wrote: > > On 02/09/18 12:33 +, Roger Pau Monné wrote: > > > Thanks for the series, I'm however wondering whether it's appropriate > > > to post a v4 as RFC. Ie: at v4 the reviewer

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

flight 119177 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/119177/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 119036 Tests which did

[Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions

It ease code review, unit is explicit. Signed-off-by: Philippe Mathieu-Daudé --- hw/block/xen_disk.c| 4 ++-- hw/xenpv/xen_domainbuild.c | 10 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index

[Xen-devel] [PATCH 22/30] hw/display: use the BYTE-based definitions

It ease code review, unit is explicit. Signed-off-by: Philippe Mathieu-Daudé --- hw/display/cirrus_vga.c | 9 - hw/display/g364fb.c | 2 +- hw/display/qxl.c| 26 +++--- hw/display/vga-isa-mm.c | 4 ++-- hw/display/vga.c| 4

[Xen-devel] [PATCH 08/30] hw/i386: use the BYTE-based definitions

It ease code review, unit is explicit. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/i386/ich9.h | 2 +- hw/i386/acpi-build.c | 4 ++-- hw/i386/pc.c | 18 +- hw/i386/pc_piix.c | 2 +- hw/i386/pc_q35.c | 2 +-

[Xen-devel] [linux-next test] 119169: regressions - trouble: blocked/broken/fail/pass

flight 119169 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/119169/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt broken test-amd64-i386-freebsd10-i386

Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

Abandoning this series as a new version was submitted for the review "[RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver" On Tue, Dec 19, 2017 at 11:29:17AM -0800, Kim, Dongwon wrote: > Upload of intial version of hyper_DMABUF driver enabling > DMA_BUF exchange between two different VMs in

[Xen-devel] [xen-4.6-testing test] 119187: regressions - FAIL

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

[Xen-devel] [libvirt test] 119148: trouble: broken/pass

flight 119148 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/119148/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm broken

Re: [Xen-devel] [PATCH v2 1/4] asm-x86/monitor: Enable svm monitor events

On 02/08/2018 10:25 AM, Alexandru Isaila wrote: This commit separates the svm caps from the vmx caps. Signed-off-by: Alexandru Isaila --- Changes since V1: - Removed the if ( cpu_has_svm ) --- xen/include/asm-x86/monitor.h | 34

Re: [Xen-devel] [PATCH v2 3/4] hvm/svm: Enable MSR events

On 02/08/2018 10:25 AM, Alexandru Isaila wrote: This commit enables MSR events for svm. Signed-off-by: Alexandru Isaila Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list

Re: [Xen-devel] Excited for Xen Project in Outreachy

Hello Kanika, Thanks for your interest in Xen Project! One reply inline below. On Wed, 14 Feb 2018, Lars Kurth wrote: > Hi Kanika, > > I CC'ed two lists and the mentors of projects. Thank you for your interest in > the project. > > > I seek guidance in choosing the suitable sub-project in Xen

[Xen-devel] [xen-unstable test] 119137: regressions - trouble: broken/fail/pass

flight 119137 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/119137/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-ws16-amd64 broken

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

On Wed, Feb 14, 2018 at 10:56 AM, Razvan Cojocaru wrote: > On 02/14/2018 07:47 PM, Andrew Cooper wrote: >> On 12/02/18 15:13, Andrew Cooper wrote: >>> On 12/02/18 15:08, Alexandru Isaila wrote: No monitor features are available on AMD and all capabilities are

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

flight 119208 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119208/ 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 v3 2/4] hvm/svm: Enable Breakpoint events

On 14/02/18 18:22, Andrew Cooper wrote: > On 14/02/18 16:10, Alexandru Stefan ISAILA wrote: >> On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: >>> On 12/02/18 15:08, Alexandru Isaila wrote: @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)

Re: [Xen-devel] [PATCH] xen/arm: cpuerrata: Actually check errata on non-boot CPUs

On Wed, 14 Feb 2018, Julien Grall wrote: > The cpu errata framework was introduced in commit 8b01f6364f "xen/arm: > Detect silicon revision and set cap bits accordingly" and was meant to > detect errata present on any CPUs (via check_local_cpu_errata). However, > the function to check the MIDR

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: Blacklist SMMU on Thunder-X

On Wed, 14 Feb 2018, Julien Grall wrote: > Xen does not yet support Cavium SMMU because it requires some > workaround. For the time being, blacklist them. > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- > Changes in v2: >

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Extend the number of memory banks supported

On Wed, 14 Feb 2018, Julien Grall wrote: > When booting using Grub on Thunder-X, the number of memory available is > greater than 64. Bump the number to 128, so we can take advantage of all > the memory. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini

[Xen-devel] [seabios test] 119162: regressions - trouble: blocked/broken/fail/pass

flight 119162 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119162/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt broken build-amd64-libvirt 4

[Xen-devel] [PATCH v3 1/2] pvcalls-front: introduce a per sock_mapping refcount

Introduce a per sock_mapping refcount, in addition to the existing global refcount. Thanks to the sock_mapping refcount, we can safely wait for it to be 1 in pvcalls_front_release before freeing an active socket, instead of waiting for the global refcount to be 1. Signed-off-by: Stefano

[Xen-devel] [PATCH v3 2/2] pvcalls-front: wait for other operations to return when release passive sockets

Passive sockets can have ongoing operations on them, specifically, we have two wait_event_interruptable calls in pvcalls_front_accept. Add two wake_up calls in pvcalls_front_release, then wait for the potential waiters to return and release the sock_mapping refcount. Signed-off-by: Stefano

[Xen-devel] [PATCH v3 0/2] pvcalls-front improvements

Hi all, this small series introduces a per socket refcount to increase the efficiency on socket release operations, and makes releasing passive sockets safe. Cheers, Stefano Changes in v3: - remove pointless initializers - reorder pvcalls_enter_sock Changes in v2: - add acked-by - fix check

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

On 14/02/18 16:10, Alexandru Stefan ISAILA wrote: > On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: >> On 12/02/18 15:08, Alexandru Isaila wrote: >>> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct >>> cpu_user_regs *regs) >>> break; >>> >>> case VMEXIT_EXCEPTION_BP:

Re: [Xen-devel] [PATCH v2 1/2] pvcalls-front: introduce a per sock_mapping refcount

On Wed, 14 Feb 2018, Juergen Gross wrote: > On 13/02/18 03:13, Stefano Stabellini wrote: > > Introduce a per sock_mapping refcount, in addition to the existing > > global refcount. Thanks to the sock_mapping refcount, we can safely wait > > for it to be 1 in pvcalls_front_release before freeing an

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

On 02/14/2018 07:47 PM, Andrew Cooper wrote: > On 12/02/18 15:13, Andrew Cooper wrote: >> On 12/02/18 15:08, Alexandru Isaila wrote: >>> No monitor features are available on AMD and all >>> capabilities are passed only to the Intel processor architecture. >>> This means that the

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

On 12/02/18 15:13, Andrew Cooper wrote: > On 12/02/18 15:08, Alexandru Isaila wrote: >> No monitor features are available on AMD and all >> capabilities are passed only to the Intel processor architecture. >> This means that the arch_monitor_get_capabilities returns >> capabilities = 0. >> >> This

Re: [Xen-devel] Excited for Xen Project in Outreachy

Hi Kanika, I CC'ed two lists and the mentors of projects. Thank you for your interest in the project. > I seek guidance in choosing the suitable sub-project in Xen according to my > skill set. We have two sets of projects on https://www.outreachy.org/communities/cfp/xen-project/ * 3 around

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

Hi Jan, 2018-02-14 16:37 GMT+08:00 Jan Beulich : On 14.02.18 at 08:15, wrote: >> Hi Jan, >> >> 2018-02-13 23:26 GMT+08:00 Jan Beulich : >> On 13.02.18 at 16:15, wrote: I've updated the comments

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

flight 119190 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119190/ 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

[Xen-devel] [linux-linus test] 119117: regressions - FAIL

flight 119117 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/119117/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324

[Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

The current XPTI implementation isolates the directmap (and therefore a lot of guest data), but a large quantity of CPU0's state (including its stack) remains visible. Furthermore, an attacker able to read .text is in a vastly superior position to normal when it comes to fingerprinting Xen for

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: > On 12/02/18 15:08, Alexandru Isaila wrote: > > > > @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct > > cpu_user_regs *regs) > > break; > > > > case VMEXIT_EXCEPTION_BP: > > -if ( !v->domain->debugger_attached ) >

Re: [Xen-devel] [PATCH V4] x86/hvm: fix domain crash when CR3 has the noflush bit set

On Fri, Feb 9, 2018 at 4:01 AM, Razvan Cojocaru wrote: > The emulation layers of Xen lack PCID support, and as we only offer > PCID to HAP guests, all writes to CR3 are handled by hardware, > except when introspection is involved. Consequently, trying to set > CR3 when

Re: [Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

Hi On Wed, Feb 14, 2018 at 4:47 PM, Oleksandr Tyshchenko wrote: > Hi, Julien. > > On Wed, Feb 14, 2018 at 4:17 PM, Julien Grall wrote: >> Xen does not properly support big.LITTLE platform. All vCPUs of a guest >> will always have the MIDR of the boot

[Xen-devel] [PATCH v2 1/2] xen/arm: Extend the number of memory banks supported

When booting using Grub on Thunder-X, the number of memory available is greater than 64. Bump the number to 128, so we can take advantage of all the memory. Signed-off-by: Julien Grall --- Note that I wasn't able to boot without this patch, because EFI stub is

[Xen-devel] [PATCH v2 2/2] xen/arm: Blacklist SMMU on Thunder-X

Xen does not yet support Cavium SMMU because it requires some workaround. For the time being, blacklist them. Signed-off-by: Julien Grall --- Changes in v2: - Fix compatible string --- xen/arch/arm/platforms/Makefile | 1 + xen/arch/arm/platforms/thunderx.c

[Xen-devel] Osstest linux-arm-xen moved to 4.14

Hi, I have updated the linux-arm-xen branch to use Linux 4.14.19. This is the latest stable and should have better support for Arm64 hardware. At the moment, I merged the linux-stable/linux-4.14.y to linux-arm-xen avoiding a rebase. Once it has pushed by osstest, we should reset the tree to

Re: [Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

Hi, Julien. On Wed, Feb 14, 2018 at 4:17 PM, Julien Grall wrote: > Xen does not properly support big.LITTLE platform. All vCPUs of a guest > will always have the MIDR of the boot CPU (see arch_domain_create). > At best the guest may see unreliable performance (vCPU

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

On Mon, Feb 12, 2018 at 03:24:26PM +, Julien Grall wrote: > > > On 12/02/18 15:17, Zhongze Liu wrote: > > Hi Julien, > > Hi, > > > > > 2018-02-12 23:09 GMT+08:00 Julien Grall : > > > Hi, > > > > > > On 12/02/18 14:52, Zhongze Liu wrote: > > > > > > > > 2018-02-08

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

On Mon, Feb 12, 2018 at 03:24:26PM +, Julien Grall wrote: > > > On 12/02/18 15:17, Zhongze Liu wrote: > > Hi Julien, > > Hi, > > > > > 2018-02-12 23:09 GMT+08:00 Julien Grall : > > > Hi, > > > > > > On 12/02/18 14:52, Zhongze Liu wrote: > > > > > > > > 2018-02-08

Re: [Xen-devel] 回复: Re: 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

On 14/02/18 13:04, zhenzhong.duan wrote: > > 2018年2月14日 20:21于 Andrew Cooper >写道： > > > > On 14/02/18 12:08, zhenzhong.duan wrote: > > > > > > > @@ -286,13 +286,13 @@ > > > > setz %dl > > > > and %dl,

Re: [Xen-devel] [PATCH v4 4/7] libxl: support mapping static shared memory areas during domain creation

On Mon, Feb 12, 2018 at 11:08:01PM +0800, Zhongze Liu wrote: > >> > [...] > >> > > >> > > > + > >> > > > +/* libxl__sshm_do_map -- map pages into slave's physmap > >> > > > + * > >> > > > + * This functions maps > >> > > > + * master gfn: [@msshm->begin + @sshm->offset, @msshm->end + > >>

[Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

Xen does not properly support big.LITTLE platform. All vCPUs of a guest will always have the MIDR of the boot CPU (see arch_domain_create). At best the guest may see unreliable performance (vCPU switching between big and LITTLE), at worst the guest will become unreliable or insecure. This is

Re: [Xen-devel] [PATCH v2 1/2] pvcalls-front: introduce a per sock_mapping refcount

On 13/02/18 03:13, Stefano Stabellini wrote: > Introduce a per sock_mapping refcount, in addition to the existing > global refcount. Thanks to the sock_mapping refcount, we can safely wait > for it to be 1 in pvcalls_front_release before freeing an active socket, > instead of waiting for the

[Xen-devel] [PATCH] x86/entry: Use 32bit xors rater than 64bit xors for clearing GPRs

Intel's Silvermont/Knights Landing architecture treats them as full ALU operations, rather than zeroing idoms. No functional change, and no change in code volume (only changing the bit selection in the REX prefix). Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] 回复: Re: 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

2018年2月14日 20:21于 Andrew Cooper 写道： > > On 14/02/18 12:08, zhenzhong.duan wrote: > > > > > @@ -286,13 +286,13 @@ > > > setz %dl > > > and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14) > > Is it safe to remove the 'xor %edx, %edx' above? setz set

Re: [Xen-devel] [PATCH v2 13/16] Save/Restore Support: Add suspend/restore support for Grant Tables.

On 14/02/18 03:27, Bruno Alvisio wrote: > Signed-off-by: Bruno Alvisio > --- > Changed since v1: > - Moved suspend/resume _gnttab to arch specific files > --- > arch/x86/mm.c| 34 ++ > gnttab.c | 10 ++ >

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

On 14/02/18 12:27, Juergen Gross wrote: > On 14/02/18 13:19, Andrew Cooper wrote: >> On 14/02/18 12:15, Juergen Gross wrote: >>> On 14/02/18 13:03, Juergen Gross wrote: On 14/02/18 12:48, Andrew Cooper wrote: > On 14/02/18 07:54, Juergen Gross wrote: >> On 13/02/18 20:45, Andrew

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

On 14/02/18 09:14, Jan Beulich wrote: On 13.02.18 at 20:45, wrote: >> RFC, because I don't think the stubs handling is particularly sensible. >> >> We allocate 4k of virtual address space per CPU, but squash loads of CPUs >> together onto a single MFN. The stubs

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

On 14/02/18 13:19, Andrew Cooper wrote: > On 14/02/18 12:15, Juergen Gross wrote: >> On 14/02/18 13:03, Juergen Gross wrote: >>> On 14/02/18 12:48, Andrew Cooper wrote: On 14/02/18 07:54, Juergen Gross wrote: > On 13/02/18 20:45, Andrew Cooper wrote: >> The current XPTI implementation

[Xen-devel] [PATCH] xen/arm: cpuerrata: Actually check errata on non-boot CPUs

The cpu errata framework was introduced in commit 8b01f6364f "xen/arm: Detect silicon revision and set cap bits accordingly" and was meant to detect errata present on any CPUs (via check_local_cpu_errata). However, the function to check the MIDR (is_affected_midr_range) mistakenly always use the

Re: [Xen-devel] 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

On 14/02/18 12:08, zhenzhong.duan wrote: > > > @@ -286,13 +286,13 @@ > > setz %dl > > and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14) > Is it safe to remove the 'xor %edx, %edx' above? setz set whole byte 1 > or 0. > It is safe, but it is not a good idea. Using setz is an 8bit

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

On 14/02/18 12:15, Juergen Gross wrote: > On 14/02/18 13:03, Juergen Gross wrote: >> On 14/02/18 12:48, Andrew Cooper wrote: >>> On 14/02/18 07:54, Juergen Gross wrote: On 13/02/18 20:45, Andrew Cooper wrote: > The current XPTI implementation isolates the directmap (and therefore a >

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

On 14/02/18 13:03, Juergen Gross wrote: > On 14/02/18 12:48, Andrew Cooper wrote: >> On 14/02/18 07:54, Juergen Gross wrote: >>> On 13/02/18 20:45, Andrew Cooper wrote: The current XPTI implementation isolates the directmap (and therefore a lot of guest data), but a large quantity

[Xen-devel] 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

2018年2月14日 19:10于 Andrew Cooper 写道： > > DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the > bti_ist_info > field gets zeroed.  Older versions of this code had the DO_OVERWRITE_RSB > register selectable, so reintroduce this ability and use it to cause

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

On 14/02/18 12:48, Andrew Cooper wrote: > On 14/02/18 07:54, Juergen Gross wrote: >> On 13/02/18 20:45, Andrew Cooper wrote: >>> The current XPTI implementation isolates the directmap (and therefore a lot >>> of >>> guest data), but a large quantity of CPU0's state (including its stack) >>>

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

On 14/02/18 11:47, Roger Pau Monné wrote: > >> diff --git a/xen/include/asm-x86/spec_ctrl_asm.h >> b/xen/include/asm-x86/spec_ctrl_asm.h >> index 814f53d..1f78599 100644 >> --- a/xen/include/asm-x86/spec_ctrl_asm.h >> +++ b/xen/include/asm-x86/spec_ctrl_asm.h >> @@ -79,10 +79,10 @@ >> * -

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

On 14/02/18 07:54, Juergen Gross wrote: > On 13/02/18 20:45, Andrew Cooper wrote: >> The current XPTI implementation isolates the directmap (and therefore a lot >> of >> guest data), but a large quantity of CPU0's state (including its stack) >> remains visible. >> >> Furthermore, an attacker able

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

On Wed, Feb 14, 2018 at 11:10:55AM +, Andrew Cooper wrote: > DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info > field gets zeroed. Older versions of this code had the DO_OVERWRITE_RSB > register selectable, so reintroduce this ability and use it to cause the >

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

On Wed, Feb 14, 2018 at 11:10:55AM +, Andrew Cooper wrote: > DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info ^dup > field gets zeroed. Older versions of this code had the DO_OVERWRITE_RSB > register

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

flight 119170 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119170/ 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] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

>>> On 14.02.18 at 12:10, wrote: > DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info > field gets zeroed. Older versions of this code had the DO_OVERWRITE_RSB > register selectable, so reintroduce this ability and use it to cause the >

[Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info field gets zeroed. Older versions of this code had the DO_OVERWRITE_RSB register selectable, so reintroduce this ability and use it to cause the INTR_IST path to use %rdx instead. The use of %dl for the %cs.rpl check

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

flight 119084 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/119084/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-install fail REGR. vs. 119036 Tests which did

[Xen-devel] [xen-unstable-coverity test] 119171: all pass - PUSHED

flight 119171 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/119171/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 3f491d6873be9caa77f02ad8d98f174f0152b819 baseline version: xen

Re: [Xen-devel] [PATCH v3] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

在 2018/2/14 17:58, Jan Beulich 写道: On 14.02.18 at 10:25, wrote: --- a/xen/include/asm-x86/spec_ctrl_asm.h +++ b/xen/include/asm-x86/spec_ctrl_asm.h @@ -269,28 +269,29 @@ * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY * maybexen=1, but with

Re: [Xen-devel] [PATCH 6/7] x86/alt: Drop explicit padding of origin sites

>>> On 12.02.18 at 12:23, wrote: > Now that the alternatives infrastructure can calculate the required padding > automatically, there is no need to hard code it. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

>>> On 12.02.18 at 12:23, wrote: > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -109,13 +109,10 @@ ENTRY(compat_restore_all_guest) > ASSERT_INTERRUPTS_DISABLED > mov

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

>>> On 12.02.18 at 12:23, wrote: > --- a/xen/arch/x86/alternative.c > +++ b/xen/arch/x86/alternative.c > @@ -180,13 +180,37 @@ void init_or_livepatch apply_alternatives(const struct > alt_instr *start, > uint8_t *orig = ALT_ORIG_PTR(a); > uint8_t

Re: [Xen-devel] [PATCH v2] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

On Wed, Feb 14, 2018 at 01:09:28AM -0700, Jan Beulich wrote: > In an IBRS available env, bootup panic when bti=0 like below: > > (XEN) Speculative mitigation facilities: > (XEN) Hardware features: SMEP IBRS/IBPB STIBP > (XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP > (XEN) [

[Xen-devel] [PATCH v3] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

In an IBRS available env, bootup panic when bti=0 like below: (XEN) Speculative mitigation facilities: (XEN) Hardware features: SMEP IBRS/IBPB STIBP (XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP (XEN) [ Xen-4.4.4OVM x86_64 debug=n Tainted:C ] (XEN) CPU:0 (XEN) RIP:

Re: [Xen-devel] [PATCH v2] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

在 2018/2/14 16:09, Jan Beulich 写道: In an IBRS available env, bootup panic when bti=0 like below: (XEN) Speculative mitigation facilities: (XEN) Hardware features: SMEP IBRS/IBPB STIBP (XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP (XEN) [ Xen-4.4.4OVM x86_64 debug=n Tainted:C

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

>>> On 13.02.18 at 20:45, wrote: > RFC, because I don't think the stubs handling is particularly sensible. > > We allocate 4k of virtual address space per CPU, but squash loads of CPUs > together onto a single MFN. The stubs ought to be isolated as well (as they >

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

flight 119150 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119150/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 119098 Tests which

[Xen-devel] [linux-4.9 test] 119074: tolerable FAIL - PUSHED

flight 119074 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/119074/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 118552 Tests which did not succeed,

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

>>> On 14.02.18 at 08:15, wrote: > Hi Jan, > > 2018-02-13 23:26 GMT+08:00 Jan Beulich : > On 13.02.18 at 16:15, wrote: >>> I've updated the comments according to your previous suggestions, >>> do they look good to you? >> >> The

Re: [Xen-devel] [PATCH] Fix a panic in SPEC_CTRL_ENTRY_FROM_INTR_IST

在 2018/2/14 15:56, Jan Beulich 写道: On 14.02.18 at 05:03, wrote: On on IBRS available env, bootup panic when bti=0 like below: (XEN) Speculative mitigation facilities: (XEN) Hardware features: SMEP IBRS/IBPB STIBP (XEN) BTI mitigations: Thunk N/A, Others: IBRS-

Re: [Xen-devel] [PATCH v2 10/16] Save/Restore Support: Add suspend/resume support for timers

On 14/02/18 03:27, Bruno Alvisio wrote: > Signed-off-by: Bruno Alvisio Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v2 05/16] Save/Restore Support: Add kernel shutdown logic to shutdown.c

On 14/02/18 03:27, Bruno Alvisio wrote: > Created shutdown.c for the shutdown thread and all the shutdown related > functions. > > Signed-off-by: Bruno Alvisio > --- > Changesd since v1: >* Updated license to a BSD 3-clause. This license was taken > from the updated

[Xen-devel] [PATCH v2] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

In an IBRS available env, bootup panic when bti=0 like below: (XEN) Speculative mitigation facilities: (XEN) Hardware features: SMEP IBRS/IBPB STIBP (XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP (XEN) [ Xen-4.4.4OVM x86_64 debug=n Tainted:C ] (XEN) CPU:0 (XEN) RIP:

Re: [Xen-devel] [PATCH v2 0/7] x86: Meltdown band-aid overhead reduction

>>> On 13.02.18 at 19:39, wrote: > On Feb 7, 2018, at 11:05, Jan Beulich wrote: >> >> 1: slightly reduce Meltdown band-aid overhead >> 2: remove CR reads from exit-to-guest path >> 3: introduce altinstruction_nop assembler macro >> 4: NOP out most XPTI

Re: [Xen-devel] [PATCH v3 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

>>> On 13.02.18 at 19:37, wrote: > Pardon any weird formatting, I'm replying on my phone. > > Because they are two different things. One is an assert to make sure > nothing wrong is happening with the EFER.SVME bit, and the other changes what > features are enabled. >