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

>>> On 21.02.19 at 18:03, wrote: > On 20/02/2019 14:37, Jan Beulich wrote: > On 19.02.19 at 23:18, wrote: >>> @@ -58,25 +57,67 @@ altp2m_vcpu_destroy(struct vcpu *v) >>> >>> int altp2m_vcpu_enable_ve(struct vcpu *v, gfn_t gfn) >>> { >>> +struct domain *d = v->domain; >>> +struct a

[Xen-devel] [linux-4.19 test] 133350: regressions - trouble: blocked/broken/fail/pass

flight 133350 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133350/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken test-amd64-amd64-rumprun-amd64

[Xen-devel] [linux-3.18 test] 133339: regressions - trouble: blocked/broken/fail/pass

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

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

>>> On 20.02.19 at 20:05, wrote: > On 20/02/2019 08:55, Jan Beulich wrote: >> >> Everything, absolutely everything is possible as a cause for a crash. >> I don't see why device isolation would matter here at all. Page table >> corruption (be it IOMMU or CPU one) can be caused by >> malfunctioning

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

>>> 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 to keep the IOMMU enabled while invoking >> th

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

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 requirements. [1] https://www.misra.org.uk/ Signed-off-by: Oleksandr Andrush

[Xen-devel] [RFC PATCH 3/4] cert:xen/drivers: Add missing default labels to switch statements

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 requirements. [1] https://www.misra.org.uk/ Signed-off-by: Oleksandr Andrush

[Xen-devel] [RFC PATCH 4/4] cert:xen/xsm/flask: Add missing default labels to switch statements

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 requirements. [1] https://www.misra.org.uk/ Signed-off-by: Oleksandr Andrush

[Xen-devel] [RFC PATCH 2/4] cert:xen/common: Add missing default labels to switch statements

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 requirements. [1] https://www.misra.org.uk/ Signed-off-by: Oleksandr Andrush

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

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 which requires that every switch statement has a default label as a

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

On Fri, Feb 22, 2019 at 09:37:50AM +0800, chengyan wrote: > Dear Wei: > > 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. > > I found it is a huge and difficul

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 whi

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 a/xen/a

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 + tools/xenst

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] [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): implementa

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 sane

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] 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 y

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. S

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): im

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 pres

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 cert

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 patches

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 im

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 approac

[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 +++--- tools/xe

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@lis

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 __v

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 Makef

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

Hello Julien, 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 solution is going to help us here? I understand that hittin

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, everybod

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] [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 le

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 p

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 under

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 MFN

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] 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 drivers

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 9

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] [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 t

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] 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 w

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 altog

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 t

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. Con

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 ou

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. > > Furthe

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 disab

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 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] 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 18:

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 effort.

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 real

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 certai

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 signa

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

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 Andrushchen

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

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 solution

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

[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

[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 test

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.

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: > > > > sched_credit2_migrate_resist=0

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 even

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] 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 issue

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 s

[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

[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 +++ b/xen/tools/gen-cpuid.

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(&new_entry, level, > IOMMUF_readable|IOMMUF_writable); > -p2m->write_p2m_en

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 i

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

[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 determ

[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 Tests

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 requireme

[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

[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 fa1581bf5c2

[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 usage

[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 bits

[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(). Sign

[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 change.

[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().

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-dev

[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_ p

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 https:/

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 swi

[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 a

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 switch

[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 ar

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. > >> F

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 configu

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 swit

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 whene

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 -Wswit

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 -Wswitch-de

[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

  1   2   >