[Xen-devel] [linux-4.14 test] 133353: regressions - trouble: blocked/broken/fail/pass

flight 133353 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133353/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64-xsmbroken test-amd64-amd64-libvirt-xsm

[Xen-devel] [xen-unstable test] 133345: regressions - trouble: blocked/broken/pass

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

[Xen-devel] [linux-4.4 test] 133352: regressions - trouble: blocked/broken/fail/pass

flight 133352 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133352/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 broken test-armhf-armhf-xl

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

flight 133382 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133382/ 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/hvm: Intercept RDPMC when vPMU is disabled

On 2/22/19 5:44 PM, Andrew Cooper wrote: > On 22/02/2019 21:58, Boris Ostrovsky wrote: >> On 2/22/19 4:13 PM, Andrew Cooper wrote: >>> vPMU isn't security supported, and in general guests can't access any of the >>> performance counter MSRs. However, the RDPMC instruction isn't intercepted, >>>

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 23:22, Julien Grall wrote: > Hi, > > On 22/02/2019 22:34, Andrew Cooper wrote: >> On 22/02/2019 22:11, Julien Grall wrote: >>> Hi Stefano, >>> >>> On 22/02/2019 21:58, Stefano Stabellini wrote: On Fri, 22 Feb 2019, Andrew Cooper wrote: > On 22/02/2019 21:00, Stefano

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi, On 22/02/2019 22:38, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Andrew Cooper wrote: >> On 22/02/2019 22:11, Julien Grall wrote: >>> Hi Stefano, >>> >>> On 22/02/2019 21:58, Stefano Stabellini wrote: On Fri, 22 Feb 2019, Andrew Cooper wrote: > On 22/02/2019 21:00, Stefano

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi, On 22/02/2019 22:34, Andrew Cooper wrote: > On 22/02/2019 22:11, Julien Grall wrote: >> Hi Stefano, >> >> On 22/02/2019 21:58, Stefano Stabellini wrote: >>> On Fri, 22 Feb 2019, Andrew Cooper wrote: On 22/02/2019 21:00, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien Grall

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi, On 22/02/2019 22:34, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien Grall wrote: >> Hi Stefano, >> >> On 22/02/2019 21:58, Stefano Stabellini wrote: >>> On Fri, 22 Feb 2019, Andrew Cooper wrote: On 22/02/2019 21:00, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi, On 22/02/2019 22:34, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien Grall wrote: >> Hi Stefano, >> >> On 22/02/2019 21:58, Stefano Stabellini wrote: >>> On Fri, 22 Feb 2019, Andrew Cooper wrote: On 22/02/2019 21:00, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien

Re: [Xen-devel] [PATCH] x86/hvm: Intercept RDPMC when vPMU is disabled

On 22/02/2019 21:58, Boris Ostrovsky wrote: > On 2/22/19 4:13 PM, Andrew Cooper wrote: >> vPMU isn't security supported, and in general guests can't access any of the >> performance counter MSRs. However, the RDPMC instruction isn't intercepted, >> meaning that guest software can read the

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On Fri, 22 Feb 2019, Andrew Cooper wrote: > On 22/02/2019 22:11, Julien Grall wrote: > > Hi Stefano, > > > > On 22/02/2019 21:58, Stefano Stabellini wrote: > >> On Fri, 22 Feb 2019, Andrew Cooper wrote: > >>> On 22/02/2019 21:00, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien Grall

[Xen-devel] [qemu-mainline test] 133346: regressions - trouble: blocked/broken/fail/pass

flight 133346 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/133346/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-shadow broken test-amd64-i386-xl-pvshim

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 22:11, Julien Grall wrote: > Hi Stefano, > > On 22/02/2019 21:58, Stefano Stabellini wrote: >> On Fri, 22 Feb 2019, Andrew Cooper wrote: >>> On 22/02/2019 21:00, Stefano Stabellini wrote: On Fri, 22 Feb 2019, Julien Grall wrote: BTW, I checked the series with

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On Fri, 22 Feb 2019, Julien Grall wrote: > Hi Stefano, > > On 22/02/2019 21:58, Stefano Stabellini wrote: > > On Fri, 22 Feb 2019, Andrew Cooper wrote: > >> On 22/02/2019 21:00, Stefano Stabellini wrote: > >>> On Fri, 22 Feb 2019, Julien Grall wrote: > >>> BTW, I checked the series with

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi Stefano, On 22/02/2019 21:58, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Andrew Cooper wrote: >> On 22/02/2019 21:00, Stefano Stabellini wrote: >>> On Fri, 22 Feb 2019, Julien Grall wrote: >>> BTW, I checked the series with -Wswitch-default: >>> -Wswitch-default >>> Warn

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 21:00, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien Grall wrote: > BTW, I checked the series with -Wswitch-default: > -Wswitch-default > Warn whenever a switch statement does not have a default case. >> Furthermore, using BUG() is a pretty bad idea in

Re: [Xen-devel] [PATCH] x86/hvm: Intercept RDPMC when vPMU is disabled

On 2/22/19 4:13 PM, Andrew Cooper wrote: > vPMU isn't security supported, and in general guests can't access any of the > performance counter MSRs. However, the RDPMC instruction isn't intercepted, > meaning that guest software can read the instantaneous counter values. > > When vPMU isn't

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On Fri, 22 Feb 2019, Andrew Cooper wrote: > On 22/02/2019 21:00, Stefano Stabellini wrote: > > On Fri, 22 Feb 2019, Julien Grall wrote: > > BTW, I checked the series with -Wswitch-default: > > -Wswitch-default > > Warn whenever a switch statement does not have a default case. > >>

[Xen-devel] [xen-unstable-smoke test] 133375: trouble: broken/pass

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

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 21:00, Stefano Stabellini wrote: > On Fri, 22 Feb 2019, Julien Grall wrote: > BTW, I checked the series with -Wswitch-default: > -Wswitch-default > Warn whenever a switch statement does not have a default case. >> Furthermore, using BUG() is a pretty bad idea in

[Xen-devel] [PATCH] x86/hvm: Intercept RDPMC when vPMU is disabled

vPMU isn't security supported, and in general guests can't access any of the performance counter MSRs. However, the RDPMC instruction isn't intercepted, meaning that guest software can read the instantaneous counter values. When vPMU isn't configured, intercept RDPMC and unconditionally fail it

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On Fri, 22 Feb 2019, Julien Grall wrote: > > > > BTW, I checked the series with -Wswitch-default: > > > > -Wswitch-default > > > > Warn whenever a switch statement does not have a default case. > > > > > Furthermore, using BUG() is a pretty bad idea in switch. > > > > It is and not only in the

Re: [Xen-devel] XEN on R-CAR H3

Hello, > Did removing reserved-memory regions together with users work out well > for you? Sorry, didn't get chance to work on this today. I would test it and let you know. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [PATCH 5/6] x86/vtd: Drop struct iommu_flush

It is unclear why this abstraction exists, but iommu_get_flush() returns possibly NULL and every user unconditionally dereferences the result. In practice, I can't spot a path where iommu is NULL, so I think it is mostly dead. Move the two function pointers into struct vtd_iommu (using a flush_

Re: [Xen-devel] XEN on R-CAR H3

Hi Amit Likely, it is because you left device nodes (mmngr,adsp,etc) which had links to reserved-memory regions ... Did removing reserved-memory regions together with users work out well for you? -- Regards, Oleksandr Tyshchenko ___

[Xen-devel] [PATCH 3/6] x86/vtd: Drop struct qi_ctrl

It is unclear why this abstraction exists, but iommu_qi_ctrl() returns possibly NULL and every user unconditionally dereferences the result. In practice, I can't spot a path where iommu is NULL, so I think it is mostly dead. Move the sole member into struct vtd_iommu, and delete iommu_qi_ctrl().

[Xen-devel] [PATCH 6/6] x86/vtd: Drop struct intel_iommu

The sole remaining member of struct intel_iommu is the drhd backpointer. Move this into struct vtd_iommu, replacing the the 'intel' pointer. This removes one dynamic memory allocation per IOMMU on the system. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Paul Durrant CC: Kevin Tian

[Xen-devel] [PATCH 2/6] x86/vtd: Rename struct iommu to vtd_iommu

VT-d's local struct iommu is an overly-generic name, for a structure which in practice maps 1-to-1 with the real IOMMUs in the system. Additionally, address style issues on impacted lines. This is mostly positioning of * for pointers and unnecessay casts with void pointers. No functional

[Xen-devel] [PATCH 4/6] x86/vtd: Drop struct ir_ctrl

It is unclear why this abstraction exists, but iommu_ir_ctrl() returns possibly NULL and every user unconditionally dereferences the result. In practice, I can't spot a path where iommu is NULL, so I think it is mostly dead. Move the fields into struct vtd_iommu, and delete iommu_ir_ctrl().

[Xen-devel] [PATCH 0/6] x86/vtd: Removal of unnecessary abstractions

Patch 1 of this series was XSA-283 before people pointed out that I'd got my maths wrong. The rest of the series was the work I was doing at the time, to try and clean up the IOMMU code. This series comes with a net bloat-o-meter reduction of -536, a reduction in code volume, runtime memory

[Xen-devel] [PATCH 1/6] x86/vtd: Don't include control register state in the table pointers

iremap_maddr and qinval_maddr point to the base of a block of contiguous RAM, allocated by the driver, holding the Interrupt Remapping table, and the Queued Invalidation ring. Despite their name, they are actually the values of the hardware register, including control metadata in the lower 12

[Xen-devel] [freebsd-master test] 133365: all pass - PUSHED

flight 133365 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/133365/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 559f0dfc7a5f8f6a3ba157087820ce5e93c21486 baseline version: freebsd

[Xen-devel] [xen-4.9-testing test] 133342: regressions - trouble: blocked/broken/fail/pass

flight 133342 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/133342/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-cubietruck broken build-amd64

Re: [Xen-devel] [RFC PATCH 1/4] cert:arch/arm: Add missing default labels to switch statements

Hi Oleksandr, On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko It is required by MISRA [1] that every switch statement has a default label as a measure of defensive programming technique. The changes in this patch are to match MISRA C:2012: Rule 16.4

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

flight 133371 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133371/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 133343

[Xen-devel] Xen Security Advisory 283 v2 - Withdrawn Xen Security Advisory number

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-283 version 2 Withdrawn Xen Security Advisory number SUMMARY === The advisory XSA-283 has been withdrawn. This is because, on further analysis, we have

Re: [Xen-devel] [PATCH V2 3/3] xen/arm: Add SCIFA UART support for early printk

Hi, Julien Your solution below require to overwrite EARLY_PRINTK_INC and not very easy to extend of other version (e.g scifb). As I suggested earlier, we can introduce an option the same way REG_SHIFT exist for 8250. The definition of CONFIG_EARLY_PRINTK is: CONFIG_EARLY_PRINTK=,, would

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On 21/02/19 12:45, Joao Martins wrote: > On 2/20/19 9:09 PM, Paolo Bonzini wrote: >> On 20/02/19 21:15, Joao Martins wrote: >>> 2. PV Driver support (patches 17 - 39) >>> >>> We start by redirecting hypercalls from the backend to routines >>> which emulate the behaviour that PV backends expect

Re: [Xen-devel] [PATCH v5 3/5] p2m: change write_p2m_entry to return an error code

>>> On 21.02.19 at 17:50, wrote: > @@ -202,13 +204,14 @@ p2m_next_level(struct p2m_domain *p2m, void **table, > new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW); > > p2m_add_iommu_flags(_entry, level, > IOMMUF_readable|IOMMUF_writable); > -

[Xen-devel] [PATCH] x86/cpuid: add missing PCLMULQDQ dependency

Since we can't seem to be able to settle our discussion for the wider adjustment previously posted, let's at least add the missing dependency for 4.12. I'm not convinced though that attaching it to SSE is correct. Signed-off-by: Jan Beulich --- a/xen/tools/gen-cpuid.py +++

[Xen-devel] [linux-linus test] 133341: regressions - trouble: blocked/broken/fail/pass

flight 133341 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/133341/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun broken test-amd64-i386-xl-raw

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

Hi everyone, I made some progress on the agenda: see https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit There are still a few gaps that need filling: feedback, additional

Re: [Xen-devel] rootfs about xen on FVP-Base-ReVC-2xAEMv8A

On 22/02/2019 05:57, 敏 wrote: hello Hello, now ，I am trying to run domain0（xen on FVP-Base-ReVC-2xAEMv8A）but there is a issue about rootfs ， kernel panic  VFS：ubable to mount root fs on unknown-block the filesystem image is xenial-server-cloudimg-arm64-uefi1.img I can not resolve this

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 9/9] common/grant_table: block speculative out-of-bound accesses

>>> On 21.02.19 at 09:16, wrote: > @@ -226,10 +228,18 @@ nr_maptrack_frames(struct grant_table *t) > static grant_entry_header_t * > shared_entry_header(struct grant_table *t, grant_ref_t ref) > { > -if ( t->gt_version == 1 ) > +switch ( t->gt_version ) > +{ > +case 1: > +

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 8/9] x86/hvm: add nospec to hvmop param

>>> On 21.02.19 at 09:16, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -4109,6 +4109,13 @@ static int hvmop_set_param( > if ( a.index >= HVM_NR_PARAMS ) > return -EINVAL; > > +/* > + * Make sure the guest controlled value a.index is bounded

Re: [Xen-devel] Fwd: xen: credit2: credit2 can’t reach the throughput as expected

On Mon, 2019-02-18 at 14:04 +, zheng chuan wrote: > Hi, Dario > Hi, > [sorry for the html email format, resend by text.] > Thanks! :-) > > On Fri, 2019-02-15 at 06:15 +, zheng chuan wrote: > > > > > Now, can I ask you a favour? Can you rerun with: > > > >

Re: [Xen-devel] [PATCH v2 3/4] x86/vmx: Fix security issue when a guest balloons out the #VE info page

On 22/02/2019 12:24, Jan Beulich wrote: On 21.02.19 at 21:18, wrote: >> The logic in altp2m_vcpu_{en,dis}able_ve() and vmx_vcpu_update_vmfunc_ve() is >> dangerous. After #VE has been set up, the guest can balloon out and free the >> nominated GFN, after which the processor may write to it.

[Xen-devel] [ovmf test] 133354: regressions - FAIL

flight 133354 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/133354/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 133291 version targeted for

[Xen-devel] [libvirt test] 133347: regressions - trouble: blocked/broken/fail/pass

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

Re: [Xen-devel] xen/evtchn and forced threaded irq

Hi, On 22/02/2019 12:38, Oleksandr Andrushchenko wrote: On 2/20/19 10:46 PM, Julien Grall wrote: Discussing with my team, a solution that came up would be to introduce one atomic field per event to record the number of event received. I will explore that solution tomorrow. How will this help

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 11:53, Andrii Anisov wrote: Hello Julien, Hi, On 22.02.19 13:30, Julien Grall wrote: While review tend to be very thorough, it is sometimes hard to spot when we miss a case. This is where -Wswitch comes into place to spot missing how. How the BUG/ASSERT_UNREACHABLE

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

>>> On 22.02.19 at 14:24, wrote: On 22.02.19 at 14:19, wrote: > > I have only realised this today: essentially we will end up implementing > > xmalloc with vmalloc, which at the moment depends on xmalloc to allocate > > the array of mfns. > > Which (potential locking issues aside) is not a

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi, On 22/02/2019 12:01, Oleksandr Andrushchenko wrote: On 2/22/19 1:27 PM, Julien Grall wrote: Hi Oleksandr, On 22/02/2019 11:13, Oleksandr Andrushchenko wrote: On 2/22/19 1:05 PM, Julien Grall wrote: Hi, On 22/02/2019 10:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

>>> On 22.02.19 at 14:19, wrote: > I have only realised this today: essentially we will end up implementing > xmalloc with vmalloc, which at the moment depends on xmalloc to allocate > the array of mfns. Which (potential locking issues aside) is not a problem, as the size of the MFN array will

Re: [Xen-devel] [PATCH v2] iommu: leave IOMMU enabled by default during kexec crash transition

>>> On 21.02.19 at 23:08, wrote: > It's unsafe to disable IOMMU on a live system which is the case > if we're crashing since remapping hardware doesn't usually know what > to do with ongoing bus transactions and frequently raises NMI/MCE/SMI, > etc. (depends on the firmware configuration) to

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 5/9] is_control_domain: block speculation

>>> On 21.02.19 at 09:16, wrote: > Checks of domain properties, such as is_hardware_domain or is_hvm_domain, > might be bypassed by speculatively executing these instructions. A reason > for bypassing these checks is that these macros access the domain > structure via a pointer, and check a

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 6/9] is_hvm/pv_domain: block speculation

>>> On 21.02.19 at 09:16, wrote: > When checking for being an hvm domain, or PV domain, we have to make > sure that speculation cannot bypass that check, and eventually access > data that should not end up in cache for the current domain type. > > This is part of the speculative hardening

Re: [Xen-devel] [PATCH v2 00/14] Add support for Hygon Dhyana Family 18h processor

On Fri, Feb 22, 2019 at 10:30:17AM +0800, Pu Wen wrote: > On 2019/2/22 0:38, Wei Liu wrote: > > I think the version should have been v5? > > Aha. This is the second revision of the patch series. So why should it > have been v5? I have seen several previous postings from last year. But I just

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

On Fri, Feb 22, 2019 at 05:47:13AM -0700, Jan Beulich wrote: > >>> On 22.02.19 at 13:11, wrote: > > On Fri, Feb 22, 2019 at 05:06:03AM -0700, Jan Beulich wrote: > >> >>> On 22.02.19 at 12:50, wrote: > >> > On Fri, Feb 22, 2019 at 04:48:09AM -0700, Jan Beulich wrote: > >> >> >>> On 20.02.19 at

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 4/9] nospec: introduce evaluate_nospec

>>> On 21.02.19 at 09:16, wrote: > --- /dev/null > +++ b/xen/include/asm-x86/nospec.h > @@ -0,0 +1,38 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved. */ > + > +#ifndef _ASM_X86_NOSPEC_H > +#define _ASM_X86_NOSPEC_H > + >

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 3/9] spec: add l1tf-barrier

>>> On 21.02.19 at 09:16, wrote: > To control the runtime behavior on L1TF vulnerable platforms better, the > command line option l1tf-barrier is introduced. This option controls > whether on vulnerable x86 platforms the lfence instruction is used to > prevent speculative execution from bypassing

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 22/02/2019 12:51, Jan Beulich wrote: On 22.02.19 at 13:40, wrote: >> There are several reasons why it's better: >> a) kernel is able to perform device reset properly as it has bus >> specific code that does this. There is even a comment in the code >> mentioning that at the moment it

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 2/9] x86/vioapic: block speculative out-of-bound accesses

>>> On 21.02.19 at 09:16, wrote: > When interacting with io apic, a guest can specify values that are used > as index to structures, and whose values are not compared against > upper bounds to prevent speculative out-of-bound accesses. This change > prevents these speculative accesses. > >

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 1/9] xen/evtchn: block speculative out-of-bound accesses

>>> On 21.02.19 at 09:16, wrote: > @@ -813,6 +817,7 @@ int set_global_virq_handler(struct domain *d, uint32_t > virq) > > if (virq >= NR_VIRQS) > return -EINVAL; > + > if (!virq_is_global(virq)) > return -EINVAL; > Stray (but benign) change. Easy enough to take

Re: [Xen-devel] [PATCH SpectreV1+L1TF v7 7/9] common/memory: block speculative out-of-bound accesses

>>> On 21.02.19 at 09:16, wrote: > The get_page_from_gfn method returns a pointer to a page that belongs > to a gfn. Before returning the pointer, the gfn is checked for being > valid. Under speculation, these checks can be bypassed, so that > the function get_page is still executed partially.

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

>>> On 22.02.19 at 13:40, wrote: > On 22/02/2019 09:52, Jan Beulich wrote: > On 20.02.19 at 19:19, wrote: >>> On 20/02/2019 08:48, Jan Beulich wrote: Some entity needs to decide whether to add the respective command line option to the crash kernel's command line. It should be

Re: [Xen-devel] [PATCH] x86/shadow: don't use map_domain_page_global() on paths that may not fail

>>> On 22.02.19 at 13:33, wrote: > At 08:15 -0700 on 20 Feb (1550650529), Jan Beulich wrote: >> The assumption (according to one comment) and hope (according to >> another) that map_domain_page_global() can't fail are both wrong on >> large enough systems. Do away with the guest_vtable field

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

>>> On 22.02.19 at 13:11, wrote: > On Fri, Feb 22, 2019 at 05:06:03AM -0700, Jan Beulich wrote: >> >>> On 22.02.19 at 12:50, wrote: >> > On Fri, Feb 22, 2019 at 04:48:09AM -0700, Jan Beulich wrote: >> >> >>> On 20.02.19 at 18:08, wrote: >> >> > On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu

Re: [Xen-devel] [PATCH v2] iommu: leave IOMMU enabled by default during kexec crash transition

On 22/02/2019 12:34, Jan Beulich wrote: On 21.02.19 at 23:08, wrote: >> Modern Linux kernels taught to copy all the necessary DMAR/IR tables >> following kexec from the previous kernel (Xen in our case) - so it's >> currently normal to keep IOMMU enabled. It might require minor changes to >>

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 22/02/2019 09:52, Jan Beulich wrote: On 20.02.19 at 19:19, wrote: >> On 20/02/2019 08:48, Jan Beulich wrote: >>> >>> Some entity needs to decide whether to add the respective command >>> line option to the crash kernel's command line. It should be this same >>> entity to tell Xen whether

Re: [Xen-devel] [PATCH for-4.12] x86: Improve the efficiency of domain_relinquish_resources()

>>> On 21.02.19 at 14:31, wrote: > On Thu, Feb 21, 2019 at 12:22:13PM +, Andrew Cooper wrote: >> pci_release_devices() takes the global PCI lock. Once pci_release_devices() >> has completed, it will be called redundantly each time paging_teardown() and >> vcpu_destroy_pagetables() continue.

Re: [Xen-devel] xen/evtchn and forced threaded irq

On 2/20/19 10:46 PM, Julien Grall wrote: (+ Andrew and Jan for feedback on the event channel interrupt) Hi Boris, Thank you for the your feedback. On 2/20/19 8:04 PM, Boris Ostrovsky wrote: On 2/20/19 1:05 PM, Julien Grall wrote: Hi, On 20/02/2019 17:07, Boris Ostrovsky wrote: On 2/20/19

Re: [Xen-devel] [PATCH v2] iommu: leave IOMMU enabled by default during kexec crash transition

>>> On 21.02.19 at 23:08, wrote: > Modern Linux kernels taught to copy all the necessary DMAR/IR tables > following kexec from the previous kernel (Xen in our case) - so it's > currently normal to keep IOMMU enabled. It might require minor changes to > kdump command line that enables IOMMU

Re: [Xen-devel] [PATCH] x86/shadow: don't use map_domain_page_global() on paths that may not fail

At 08:15 -0700 on 20 Feb (1550650529), Jan Beulich wrote: > The assumption (according to one comment) and hope (according to > another) that map_domain_page_global() can't fail are both wrong on > large enough systems. Do away with the guest_vtable field altogether, > and establish / tear down the

Re: [Xen-devel] [PATCH v2 3/4] x86/vmx: Fix security issue when a guest balloons out the #VE info page

>>> On 21.02.19 at 21:18, wrote: > The logic in altp2m_vcpu_{en,dis}able_ve() and vmx_vcpu_update_vmfunc_ve() is > dangerous. After #VE has been set up, the guest can balloon out and free the > nominated GFN, after which the processor may write to it. Also, the unlocked > GFN query means the

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

On Fri, Feb 22, 2019 at 05:06:03AM -0700, Jan Beulich wrote: > >>> On 22.02.19 at 12:50, wrote: > > On Fri, Feb 22, 2019 at 04:48:09AM -0700, Jan Beulich wrote: > >> >>> On 20.02.19 at 18:08, wrote: > >> > On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu wrote: > >> > [...] > >> >> I think

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

>>> On 22.02.19 at 12:50, wrote: > On Fri, Feb 22, 2019 at 04:48:09AM -0700, Jan Beulich wrote: >> >>> On 20.02.19 at 18:08, wrote: >> > On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu wrote: >> > [...] >> >> I think under-allocate-then-map looks plausible. xmalloc will need >> >> to allocate

Re: [Xen-devel] [PATCH] tools: add link path flag for local build to pkg-config files

On 22/02/2019 12:52, Wei Liu wrote: > On Thu, Feb 21, 2019 at 06:36:13PM +0100, Juergen Gross wrote: >> The qemu build process is requiring the link path of Xen libraries >> to be specified both with -L and -Wl,-rpath-link. Add the -L flag >> to the local pkg-config files. >> >> At the same time

Re: [Xen-devel] [PATCH] tools: add link path flag for local build to pkg-config files

On Fri, Feb 22, 2019 at 01:02:51PM +0100, Juergen Gross wrote: > On 22/02/2019 12:52, Wei Liu wrote: > > On Thu, Feb 21, 2019 at 06:36:13PM +0100, Juergen Gross wrote: > >> The qemu build process is requiring the link path of Xen libraries > >> to be specified both with -L and -Wl,-rpath-link. Add

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 2/22/19 1:27 PM, Julien Grall wrote: Hi Oleksandr, On 22/02/2019 11:13, Oleksandr Andrushchenko wrote: On 2/22/19 1:05 PM, Julien Grall wrote: Hi, On 22/02/2019 10:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello,

Re: [Xen-devel] [PATCH] tools: add link path flag for local build to pkg-config files

On Thu, Feb 21, 2019 at 06:36:13PM +0100, Juergen Gross wrote: > The qemu build process is requiring the link path of Xen libraries > to be specified both with -L and -Wl,-rpath-link. Add the -L flag > to the local pkg-config files. > > At the same time let the pkg-config files depend on the

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

On Fri, Feb 22, 2019 at 04:48:09AM -0700, Jan Beulich wrote: > >>> On 20.02.19 at 18:08, wrote: > > On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu wrote: > > [...] > >> I think under-allocate-then-map looks plausible. xmalloc will need > >> to allocate pages, put them into an array and call

Re: [Xen-devel] [PATCH v2] tools/xentop: Display '-' when stats are not available.

On Fri, Feb 22, 2019 at 11:48:06AM +, Ronan Abhamon wrote: > From: Pritha Srivastava > > Displaying 0 is misleading. > > Signed-off-by: Pritha Srivastava > Signed-off-by: Ronan Abhamon Acked-by: Wei Liu ___ Xen-devel mailing list

[Xen-devel] [PATCH v2] tools/xentop: Display '-' when stats are not available.

From: Pritha Srivastava Displaying 0 is misleading. Signed-off-by: Pritha Srivastava Signed-off-by: Ronan Abhamon --- tools/xenstat/libxenstat/src/xenstat.c | 6 + tools/xenstat/libxenstat/src/xenstat.h | 5 + tools/xenstat/libxenstat/src/xenstat_linux.c | 47 +++---

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

>>> On 20.02.19 at 18:08, wrote: > On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu wrote: > [...] >> I think under-allocate-then-map looks plausible. xmalloc will need >> to allocate pages, put them into an array and call __vmap on that array >> directly. > > The biggest issue with this

Re: [Xen-devel] xen/evtchn and forced threaded irq

>>> On 20.02.19 at 23:03, wrote: > On 2/20/19 9:46 PM, Boris Ostrovsky wrote: >> On 2/20/19 3:46 PM, Julien Grall wrote: >>> On 2/20/19 8:04 PM, Boris Ostrovsky wrote: On 2/20/19 1:05 PM, Julien Grall wrote: Some sort of a FIFO that stores {irq, data} tuple. It could obviously be

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 11:30, Julien Grall wrote: On 22/02/2019 11:21, Andrii Anisov wrote: On 22.02.19 12:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, everybody! We at EPAM Systems would like to present first series of

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 11:21, Andrii Anisov wrote: On 22.02.19 12:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, everybody! We at EPAM Systems would like to present first series of patches targeting Xen on ARM Functional Safety

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi Oleksandr, On 22/02/2019 11:13, Oleksandr Andrushchenko wrote: On 2/22/19 1:05 PM, Julien Grall wrote: Hi, On 22/02/2019 10:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, everybody! We at EPAM Systems would like to

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hello Andrew, On 22.02.19 12:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, everybody! We at EPAM Systems would like to present first series of patches targeting Xen on ARM Functional Safety certification (ISO61508 based):

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hello Andrew, On 22.02.19 12:27, Andrew Cooper wrote: Can someone attempt to justify why actively breaking -Wswitch is going to result in safer/better code? I would express my vision of that MISRA rule requirement: It requires handling (in any meaning) all possible incoming values explicitly.

Re: [Xen-devel] About Porting Virtio to the XEN

On 22/02/2019 01:37, chengyan wrote: Dear Wei: Hello, Now,  I only make a demo in x86 platform and it is just a try. Not sure that whether it is successful using Virtio tech in the XEN project. Not all virtio drivers has a Xen counterpart. So it depends what

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 2/22/19 1:05 PM, Julien Grall wrote: Hi, On 22/02/2019 10:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, everybody! We at EPAM Systems would like to present first series of patches targeting Xen on ARM Functional Safety

Re: [Xen-devel] [PATCH v4.1 4/6] xen/x86: Allow stubdom access to irq created for msi.

>>> On 22.02.19 at 11:42, wrote: > Jan do you know whether pci_remove_device is supposed to be used > against devices assigned to a domain different than the hardware > domain? No, I don't think it ought to be used on any other devices. I guess the omission of the check goes back to assuming

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

Hi, On 22/02/2019 10:27, Andrew Cooper wrote: On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, everybody! We at EPAM Systems would like to present first series of patches targeting Xen on ARM Functional Safety certification (ISO61508 based):

Re: [Xen-devel] [PATCH] tools/xentop: Display '-' when stats are not available.

On Fri, Feb 22, 2019 at 10:47:24AM +, Ronan Abhamon wrote: > Le 21/02/2019 à 16:32, Wei Liu a écrit : > > > On Wed, Feb 20, 2019 at 04:19:25PM +, Ronan Abhamon wrote: > > > From: Pritha Srivastava > > > > > > Displaying 0 is misleading. > > > > > > Signed-off-by: Pritha Srivastava > >

Re: [Xen-devel] [PATCH] tools/xentop: Display '-' when stats are not available.

Le 21/02/2019 à 16:32, Wei Liu a écrit : On Wed, Feb 20, 2019 at 04:19:25PM +, Ronan Abhamon wrote: From: Pritha Srivastava Displaying 0 is misleading. Signed-off-by: Pritha Srivastava Signed-off-by: Ronan Abhamon --- tools/xenstat/libxenstat/src/xenstat.c | 6 +

Re: [Xen-devel] [PATCH v4.1 4/6] xen/x86: Allow stubdom access to irq created for msi.

On Thu, Feb 21, 2019 at 06:40:40PM +0100, Marek Marczykowski-Górecki wrote: > On Thu, Feb 21, 2019 at 05:47:51PM +0100, Roger Pau Monné wrote: > > On Fri, Feb 08, 2019 at 11:17:05AM +0100, Marek Marczykowski-Górecki wrote: > > > return -EINVAL; > > > } > > > > > > diff --git

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

On 22/02/2019 09:57, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hello, everybody! > > We at EPAM Systems would like to present first series of patches targeting Xen > on ARM Functional Safety certification (ISO61508 based): implementation of > MISRA [1] C:2012 Rule 16.4

  1   2   >