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

On 21/02/2019 00:39, Marek Marczykowski-Górecki wrote: > On Wed, Feb 20, 2019 at 08:15:30PM +, 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.e. grant

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

On Wed, Feb 20, 2019 at 10:03:57PM +, Julien Grall wrote: > Hi Boris, > > On 2/20/19 9:46 PM, Boris Ostrovsky wrote: > > On 2/20/19 3:46 PM, Julien Grall wrote: > > > (+ Andrew and Jan for feedback on the event channel interrupt) > > > > > > Hi Boris, > > > > > > Thank you for the your feedb

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

Guests can issue event channel interaction with guest specified data. To avoid speculative out-of-bound accesses, we use the nospec macros, or the domain_vcpu function. Where appropriate, we use the vcpu_id of the seleceted vcpu instead of the parameter that can be influenced by the guest, so that

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

On 19/02/2019 18:31, Julien Grall wrote: > Hi all, > > I have been looking at using Linux RT in Dom0. Once the guest is started, > the console is ending to have a lot of warning (see trace below). > > After some investigation, this is because the irq handler will now be > threaded. > I can repro

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

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. Furthermore, variables are initialized and the compi

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

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 the evaluation of conditionals that are pr

[Xen-devel] SpectreV1+L1TF Patch Series v7

Dear all, This patch series attempts to mitigate the issue that have been raised in the XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html), namely to avoid touching memory from the hypervisor speculatively that would not be touched without speculation. To block speculative execution on Intel

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

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. Signed-off-by: Norbert Manthey --- Note

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

Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into L1 cache is problematic, because when hyperthreading is used as well, a guest running on the sibling core can leak this potentially secret data. To prevent these speculative accesses, we block speculation after accessing the

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

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 certain field. Since this memory access is slow,

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

The params array in hvm can be accessed with get and set functions. As the index is guest controlled, make sure no out-of-bound accesses can be performed. As we cannot influence how future compilers might modify the instructions that enforce the bounds, we furthermore block speculation, so that th

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

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. Consequently, the function page_get_owner_and

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

Guests can issue grant table operations and provide guest controlled data to them. This data is also used for memory loads. To avoid speculative out-of-bound accesses, we use the array_index_nospec macro where applicable. However, there are also memory accesses that cannot be protected by a single

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

Hi Roger, On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, wrote: > FWIW, you can also mask the interrupt while waiting for the thread to > execute the interrupt handler. Ie: > Thank you for providing steps, however where would the masking be done? By the irqchip or a custom solution? > 1. Interru

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

On 21/02/2019 09:38, Julien Grall wrote: > Hi Roger, > > On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, > wrote: > > FWIW, you can also mask the interrupt while waiting for the thread to > execute the interrupt handler. Ie: > > > Thank you for providing steps,

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

On Thu, Feb 21, 2019 at 08:38:39AM +, Julien Grall wrote: > Hi Roger, > > On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, wrote: > > > FWIW, you can also mask the interrupt while waiting for the thread to > > execute the interrupt handler. Ie: > > > > Thank you for providing steps, however wher

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

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

Re: [Xen-devel] [PATCH v3 11/25] xen: Let xencons_send() take a 'size' argument

> -Original Message- > From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com] > Sent: 20 February 2019 01:02 > To: qemu-de...@nongnu.org; Prasad J Pandit ; Marc- > André Lureau ; Paolo Bonzini > > Cc: Jason Wang ; Anthony Perard > ; qemu-...@nongnu.org; Stefan Berger > ; David Gibson ; Ge

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

Hi Norbert, On 21/02/2019 08:16, Norbert Manthey wrote: > diff --git a/xen/include/asm-arm/nospec.h b/xen/include/asm-arm/nospec.h > new file mode 100644 > --- /dev/null > +++ b/xen/include/asm-arm/nospec.h > @@ -0,0 +1,20 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* Copyright 2018 Amazon.co

[Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file

Add x86 architecture support for a new processor: Hygon Dhyana Family 18h. Carve out initialization codes from amd.c needed by Dhyana into a separate file hygon.c by removing unnecessary codes and make Hygon initialization codes more clear. To identify Hygon Dhyana CPU, add a new vendor type X86_V

[Xen-devel] [PATCH v2 04/14] x86/cpu/mce: Add Hygon Dhyana support to the MCA infrastructure

The machine check architecture for Hygon Dhyana CPU is similar to the AMD family 17h one. Add vendor checking for Hygon Dhyana to share the code path of AMD family 17h. Signed-off-by: Pu Wen --- xen/arch/x86/cpu/common.c | 3 ++- xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 5 +++-- xen

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

As a new x86 CPU Vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co., Ltd., and aims at providing high performance x86 processor for China server market. The first generation Hygon's processor(Dhyana) originates from AMD techno

[Xen-devel] [PATCH v2 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

The PMU architecture for the Hygon Dhyana CPU is similar to the AMD family 17h one. So add Hygon Dhyana support in vpmu_arch_initialise and vpmu_init by using the code path of AMD. Since current Xen vPMU still not support Zen(0x17), so add both 0x17 and 0x18 support by using the 0x15's case in amd

[Xen-devel] [PATCH v2 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon Dhyana support to print the value of TOP_MEM2. Signed-off-by: Pu Wen --- xen/arch/x86/cpu/mtrr/generic.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86

[Xen-devel] [PATCH v2 05/14] x86/spec_ctrl: Add Hygon Dhyana to the respective mitigation machinery

The Hygon Dhyana CPU has the same speculative execution as AMD family 17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana. Signed-off-by: Pu Wen --- xen/arch/x86/spec_ctrl.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/spec_ctrl.c b/xen

[Xen-devel] [PATCH v2 10/14] x86/domain: Add Hygon Dhyana support

Add Hygon Dhyana support to handle HyperTransport range. Also loading a nul selector does not clear bases and limits on Hygon CPUs, so add Hygon Dhyana support to the function preload_segment. Signed-off-by: Pu Wen --- xen/arch/x86/dom0_build.c | 3 ++- xen/arch/x86/domain.c | 9 +

[Xen-devel] [PATCH v2 06/14] x86/apic: Add Hygon Dhyana support

Add Hygon Dhyana support to use modern APIC. Signed-off-by: Pu Wen --- xen/arch/x86/apic.c | 5 + 1 file changed, 5 insertions(+) diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c index 2a24326..004d685 100644 --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -92,6 +92,11 @@ stati

[Xen-devel] [PATCH v2 07/14] x86/acpi: Add Hygon Dhyana support

Add Hygon Dhyana support to the acpi cpufreq and cpuidle subsystems by using the code path of AMD. Signed-off-by: Pu Wen --- xen/arch/x86/acpi/cpu_idle.c | 3 ++- xen/arch/x86/acpi/cpufreq/cpufreq.c | 8 +--- xen/arch/x86/acpi/cpufreq/powernow.c | 3 ++- 3 files changed, 9 insertion

[Xen-devel] [PATCH v2 12/14] x86/traps: Add Hygon Dhyana support

The Hygon Dhyana processor has the methold to get the last exception source IP from MSR_01DD. So add support for it if the boot param ler is true. Signed-off-by: Pu Wen Acked-by: Jan Beulich --- xen/arch/x86/traps.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/x86/traps.c

[Xen-devel] [PATCH v2 08/14] x86/iommu: Add Hygon Dhyana support

The IOMMU architecture for the Hygon Dhyana CPU is similar to the AMD family 17h one. So add Hygon Dhyana support to it by sharing the code path of AMD. Signed-off-by: Pu Wen --- xen/include/asm-x86/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/include/asm-x86/iommu.h b/xen/inc

[Xen-devel] [PATCH v2 14/14] tools/libxc: Add Hygon Dhyana support

Add Hygon Dhyana support to caculate the cpuid policies for creating PV or HVM guest by using the code path of AMD. Signed-off-by: Pu Wen Acked-by: Wei Liu --- tools/libxc/xc_cpuid_x86.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/tools/libxc/xc_cpuid_x

[Xen-devel] [PATCH v2 11/14] x86/domctl: Add Hygon Dhyana support

Add Hygon Dhyana support to update cpuid info for creating PV guest. Signed-off-by: Pu Wen --- xen/arch/x86/domctl.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 9bf2d08..3a9e290 100644 --- a/xen/arch/x86/d

[Xen-devel] [PATCH v2 13/14] x86/cpuid: Add Hygon Dhyana support

The Hygon Dhyana family 18h processor shares the same cpuid leaves as the AMD family 17h one. So add Hygon Dhyana support to caculate the cpuid policies as the AMD CPU does. Signed-off-by: Pu Wen --- xen/arch/x86/cpuid.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --gi

[Xen-devel] [PATCH v2 09/14] x86/pv: Add Hygon Dhyana support to emulate MSRs access

The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and counter MSRs, hardware configuration MSR, MMIO configuration base address MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the PV emulation infrastructure by using the code path of AMD. Signed-off-by: Pu

Re: [Xen-devel] [RFC PATCH v3 13/25] xen: Let buffer_append() return a size_t

> -Original Message- > From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com] > Sent: 20 February 2019 01:02 > To: qemu-de...@nongnu.org; Prasad J Pandit ; Marc- > André Lureau ; Paolo Bonzini > > Cc: Jason Wang ; Anthony Perard > ; qemu-...@nongnu.org; Stefan Berger > ; David Gibson ;

Re: [Xen-devel] [PATCH] drm: add func to better detect wether swiotlb is needed

> -Original Message- > From: Michael D Labriola [mailto:michael.d.labri...@gmail.com] > Sent: 19 February 2019 23:08 > To: dri-de...@lists.freedesktop.org; Alex Deucher > ; Christian Koenig ; > Chunming Zhou ; amd-...@lists.freedesktop.org; Monk > Liu > Cc: Juergen Gross ; Christoph Hellwi

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

On Wed, Feb 20, 2019 at 05:08:09PM +, Wei Liu 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 bigge

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

Hi Oleksandr, On 20/02/2019 21:28, Oleksandr Tyshchenko wrote: > ср, 20 февр. 2019 г., 22:14 Julien Grall >: > If I am not mistaken, the diff between BSP's and mainline device trees is in > reserved memory area. BSP device tree (1) contains reserved memory regions,

[Xen-devel] About Porting Virtio to the XEN

Dear Expert:    I want to porting the Virtio to the XEN via reference to the below links.    https://wiki.xen.org/wiki/Virtio_On_Xen.        If I have ported the Virtio as the following guides ,whether it may reach my requirement,which is in the HV

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

On Thu, Feb 21, 2019 at 06:13:32PM +0800, chengyan wrote: > Dear Expert: > >    I want to porting the Virtio to the XEN via reference to > the below links. > >    https://wiki.xen.org/wiki/Virtio_On_Xen. The wikipage you mention is very outdated AFAICT. The follow

[Xen-devel] [libvirt test] 133320: regressions - FAIL

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

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

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.e. grant >> table and interdomain events. Ne

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

On 2/20/19 11:39 PM, Marek Marczykowski-Górecki wrote: > On Wed, Feb 20, 2019 at 08:15:30PM +, 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.e. grant

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

On Thu, Feb 21, 2019 at 06:13:32PM +0800, chengyan wrote: > Dear Expert: > >    I want to porting the Virtio to the XEN via reference to > the below links. > >    https://wiki.xen.org/wiki/Virtio_On_Xen. That page is very dated. > >        If I have p

Re: [Xen-devel] [PATCH for-next v2] xen: make grant table configurable

On Fri, Jan 18, 2019 at 12:43:57PM +, Wei Liu wrote: > Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm > hypervisors build with grant table disabled. > > Signed-off-by: Wei Liu I know this patch can only be applied after the tree is reopen but ... > > diff --git a/xen

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

On 2/21/19 7:57 AM, Juergen Gross wrote: > On 21/02/2019 00:39, Marek Marczykowski-Górecki wrote: >> On Wed, Feb 20, 2019 at 08:15:30PM +, Joao Martins wrote: >>> 2. PV Driver support (patches 17 - 39) >>> >>> We start by redirecting hypercalls from the backend to routines >>> which emulate

Re: [Xen-devel] [PATCH for-next v2] xen: make grant table configurable

On 21/02/2019 12:01, Wei Liu wrote: On Fri, Jan 18, 2019 at 12:43:57PM +, Wei Liu wrote: Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm hypervisors build with grant table disabled. Signed-off-by: Wei Liu I know this patch can only be applied after the tree is reo

Re: [Xen-devel] [PATCH for-next v2] xen: make grant table configurable

On Thu, Feb 21, 2019 at 12:02:13PM +, Julien Grall wrote: > > > On 21/02/2019 12:01, Wei Liu wrote: > > On Fri, Jan 18, 2019 at 12:43:57PM +, Wei Liu wrote: > > > Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm > > > hypervisors build with grant table disabled. > > >

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

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. This is liable to be millions of times for a reasonably sized guest, and is a serialising bottleneck now tha

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

On 21/02/2019 13:22, 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. > > This is liable to be millions of times for a reasonably

Re: [Xen-devel] [PATCH tentitively for-4.12 0/4] x86/altp2m: Fix multiple security issues

On 19/02/2019 23:18, Andrew Cooper wrote: > There are no XSAs because altp2m isn't security supported. However, it would > be very nice to have it in a less broken state for 4.12. > > Overall the risk of regression to other parts of Xen is minimal, as most of > these changes are only in altp2m-en

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

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. > > This is liable to be millions of ti

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

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

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

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/xenstat/libxenstat/src/xenstat.h

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki wrote: > Add documentation for upcoming Linux stubdomain for qemu-upstream. > > Signed-off-by: Marek Marczykowski-Górecki > --- > docs/misc/stubdom.txt | 50 - > 1 file changed, 50 in

Re: [Xen-devel] [PATCH v3 04/17] libxl: Allow running qemu-xen in stubdomain

On Mon, Jan 28, 2019 at 10:30:21PM +0100, Marek Marczykowski-Górecki wrote: > Do not prohibit anymore using stubdomain with qemu-xen. > To help distingushing MiniOS and Linux stubdomain, add helper inline > functions libxl__stubdomain_is_linux() and > libxl__stubdomain_is_linux_running(). Those sho

Re: [Xen-devel] [PATCH v3 10/17] libxl: typo fix in comment

On Mon, Jan 28, 2019 at 10:30:27PM +0100, Marek Marczykowski-Górecki wrote: > Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 05/17] libxl: Handle Linux stubdomain specific QEMU options.

On Mon, Jan 28, 2019 at 10:30:22PM +0100, Marek Marczykowski-Górecki wrote: > From: Eric Shelton > > This patch creates an appropriate command line for the QEMU instance > running in a Linux-based stubdomain. > > NOTE: a number of items are not currently implemented for Linux-based > stubdomains

Re: [Xen-devel] [PATCH v3 06/17] libxl: write qemu arguments into separate xenstore keys

On Mon, Jan 28, 2019 at 10:30:23PM +0100, Marek Marczykowski-Górecki wrote: > This allows using arguments with spaces, like -append, without > nominating any special "separator" character. > > Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu _

Re: [Xen-devel] [PATCH v3 07/17] libxl: create vkb device only for guests with graphics output

On Mon, Jan 28, 2019 at 10:30:24PM +0100, Marek Marczykowski-Górecki wrote: > The forced vkb device is meant for better performance of qemu access > (at least according to ebbd2561b4cefb299f0f68a88b2788504223de18 "libxl: > Add a vkbd frontend/backend pair for HVM guests"), which isn't used if > the

Re: [Xen-devel] [PATCH v3 11/17] libxl: move xswait declaration up in libxl_internal.h

On Mon, Jan 28, 2019 at 10:30:28PM +0100, Marek Marczykowski-Górecki wrote: > It will be needed for qmp_ev_* over vchan. > > No functional change. > > Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@l

Re: [Xen-devel] [PATCH v3 09/17] tools/libvchan: notify server when client is connected

On Mon, Jan 28, 2019 at 10:30:26PM +0100, Marek Marczykowski-Górecki wrote: > Let the server know when the client is connected. Otherwise server will > notice only when client send some data. > This change does not break existing clients, as libvchan user should > handle spurious notifications anyw

Re: [Xen-devel] [PATCH v3 08/17] xl: add stubdomain related options to xl config parser

On Mon, Jan 28, 2019 at 10:30:25PM +0100, Marek Marczykowski-Górecki wrote: > Signed-off-by: Marek Marczykowski-Górecki > Reviewed-by: Jason Andryuk > --- > docs/man/xl.cfg.5.pod.in | 23 +++ > tools/xl/xl_parse.c | 7 +++ > 2 files changed, 26 insertions(+), 4 dele

Re: [Xen-devel] [PATCH v3 15/17] tools: add missing libxenvchan cflags

On Mon, Jan 28, 2019 at 10:30:32PM +0100, Marek Marczykowski-Górecki wrote: > libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built > with it needs applicable -I in CFLAGS too. > > Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu __

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote: > Hi, > > I've been trying to use the pkg-config files generated in > tools/pkg-config/ when building QEMU, but those files only contains > "-Wl,-rpath-link" and "-l" options. At link times, the linker just > doesn't find the *.so. >

Re: [Xen-devel] [PATCH v4 3/6] libxl: don't try to manipulate json config for stubdomain

On Thu, Feb 07, 2019 at 01:07:46AM +0100, Marek Marczykowski-Górecki wrote: > Stubdomain do not have it's own config file - its configuration is > derived from target domains. Do not try to manipulate it when attaching > PCI device. > > This bug prevented starting HVM with stubdomain and PCI passt

Re: [Xen-devel] [PATCH v2] vm_event: Add a new opcode to get VM_EVENT_INTERFACE_VERSION

On Thu, Feb 14, 2019 at 04:18:11PM +0200, Petre Pircalabu wrote: > Currently, the VM_EVENT_INTERFACE_VERSION is determined at runtime, by > inspecting the corresponding field in a vm_event_request. This helper > opcode will query the hypervisor supported version before the vm_event > related struct

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

I think the version should have been v5? Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v5 0/5] pvh/dom0/shadow/amd fixes

The remaining set of patches contain changes to the p2m code that could affect HVM guests. Note that without those changes a PVH dom0 running on AMD hardware will be unable to create guests. Overall the patches are a nice cleanup to the handling of p2m_ioreq_server and p2m_map_foreign types IMO. T

[Xen-devel] [PATCH v5 2/5] x86/mm: split p2m ioreq server pages special handling into helper

So that it can be shared by both ept, npt and shadow code, instead of duplicating it. No change in functionality intended. Signed-off-by: Roger Pau Monné Reviewed-by: Paul Durrant Reviewed-by: George Dunlap Reviewed-by: Kevin Tian --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Cc:

[Xen-devel] [PATCH v5 4/5] x86/mm: handle foreign mappings in p2m_entry_modify

So that the specific handling can be removed from atomic_write_ept_entry and be shared with npt and shadow code. This commit also removes the check that prevent non-ept PVH dom0 from mapping foreign pages. Signed-off-by: Roger Pau Monné Reviewed-by: Kevin Tian --- Cc: George Dunlap Cc: Jan Beu

[Xen-devel] [PATCH v5 1/5] x86/p2m: pass the p2m to write_p2m_entry handlers

Current callers pass the p2m to paging_write_p2m_entry, but the implementation specific handlers of the write_p2m_entry hook instead of a p2m get a domain struct due to the handling done in paging_write_p2m_entry. Change the code so that the implementations of write_p2m_entry take a p2m instead of

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

This is in preparation for also changing p2m_entry_modify to return an error code. No functional change intended. Signed-off-by: Roger Pau Monné --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Tim Deegan --- Changes since v4: - Handle errors in loops to avoid overwr

[Xen-devel] [PATCH v5 5/5] npt/shadow: allow getting foreign page table entries

Current npt and shadow code to get an entry will always return INVALID_MFN for foreign entries. Allow to return the entry mfn for foreign entries, like it's done for grant table entries. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Co

Re: [Xen-devel] [PATCH v5 1/5] x86/p2m: pass the p2m to write_p2m_entry handlers

On Thu, Feb 21, 2019 at 05:50:37PM +0100, Roger Pau Monne wrote: > Current callers pass the p2m to paging_write_p2m_entry, but the > implementation specific handlers of the write_p2m_entry hook instead > of a p2m get a domain struct due to the handling done in > paging_write_p2m_entry. > > Change

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

On Thu, Feb 21, 2019 at 05:50:39PM +0100, Roger Pau Monne wrote: [...] > diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c > index 04e9d81cf6..254c5dfd19 100644 > --- a/xen/arch/x86/mm/p2m-pt.c > +++ b/xen/arch/x86/mm/p2m-pt.c > @@ -184,6 +184,8 @@ p2m_next_level(struct p2m_domain *p

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

On Fri, Feb 08, 2019 at 11:17:05AM +0100, Marek Marczykowski-Górecki wrote: > Stubdomains need to be given sufficient privilege over the guest which it > provides emulation for in order for PCI passthrough to work correctly. > When a HVM domain try to enable MSI, QEMU in stubdomain calls > PHYSDEVO

Re: [Xen-devel] [PATCH v5 4/5] x86/mm: handle foreign mappings in p2m_entry_modify

On Thu, Feb 21, 2019 at 05:50:40PM +0100, Roger Pau Monne wrote: > > static void ept_p2m_type_to_flags(struct p2m_domain *p2m, ept_entry_t *entry, > diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c > index 254c5dfd19..7f94fdb6a3 100644 > --- a/xen/arch/x86/mm/p2m-pt.c > +++ b/xen

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

On Thu, Feb 21, 2019 at 03:39:25PM +, Wei Liu wrote: > On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki wrote: > > Add documentation for upcoming Linux stubdomain for qemu-upstream. > > > > Signed-off-by: Marek Marczykowski-Górecki > > --- > > docs/misc/stubdom.txt | 50 +

Re: [Xen-devel] [PATCH v3 04/17] libxl: Allow running qemu-xen in stubdomain

On Thu, Feb 21, 2019 at 04:01:59PM +, Wei Liu wrote: > On Mon, Jan 28, 2019 at 10:30:21PM +0100, Marek Marczykowski-Górecki wrote: > > Do not prohibit anymore using stubdomain with qemu-xen. > > To help distingushing MiniOS and Linux stubdomain, add helper inline > > functions libxl__stubdomain

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

On 21/02/2019 17:12, Wei Liu wrote: > On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote: >> Hi, >> >> I've been trying to use the pkg-config files generated in >> tools/pkg-config/ when building QEMU, but those files only contains >> "-Wl,-rpath-link" and "-l" options. At link times, t

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

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 altp2mvcpu *a = &vcpu_altp2m(v); >> p2m

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

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

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

On 21/02/2019 18:11, Juergen Gross wrote: > On 21/02/2019 17:12, Wei Liu wrote: >> On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote: >>> Hi, >>> >>> I've been trying to use the pkg-config files generated in >>> tools/pkg-config/ when building QEMU, but those files only contains >>> "-

Re: [Xen-devel] Are xen.git/tools/pkg-config/*.pc used anywere/working ?

On Thu, Feb 21, 2019 at 06:16:43PM +0100, Juergen Gross wrote: > On 21/02/2019 18:11, Juergen Gross wrote: > > On 21/02/2019 17:12, Wei Liu wrote: > >> On Mon, Jan 21, 2019 at 06:28:34PM +, Anthony PERARD wrote: > >>> Hi, > >>> > >>> I've been trying to use the pkg-config files generated in > >

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

On Thu, Feb 21, 2019 at 06:08:22PM +0100, Marek Marczykowski-Górecki wrote: > On Thu, Feb 21, 2019 at 03:39:25PM +, Wei Liu wrote: > > On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki wrote: > > > Add documentation for upcoming Linux stubdomain for qemu-upstream. > > > > >

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

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 Makefile creating them, too. Signed-off-by: Juergen Gross --- tools/Rules.m

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

CC Anthony 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

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] [PATCH v4.1 4/6] xen/x86: Allow stubdom access to irq created for msi.

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: > > Stubdomains need to be given sufficient privilege over the guest which it > > provides emulation for in order for PCI passthrough to work correctly. > >

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

On Thu, Feb 21, 2019 at 10:59:41AM +0100, Roger Pau Monné wrote: > On Wed, Feb 20, 2019 at 05:08:09PM +, Wei Liu 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 th

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

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

Re: [Xen-devel] [PATCH v3 04/17] libxl: Allow running qemu-xen in stubdomain

On Thu, Feb 21, 2019 at 06:06:31PM +0100, Marek Marczykowski-Górecki wrote: > On Thu, Feb 21, 2019 at 04:01:59PM +, Wei Liu wrote: > > On Mon, Jan 28, 2019 at 10:30:21PM +0100, Marek Marczykowski-Górecki wrote: > > > Do not prohibit anymore using stubdomain with qemu-xen. > > > To help distingu

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

Hi, > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index d9836779d1..08b9cd2c44 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo) > printk("Loading dom0 DTB

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol

On Thu, Feb 21, 2019 at 05:31:54PM +, Wei Liu wrote: > On Thu, Feb 21, 2019 at 06:08:22PM +0100, Marek Marczykowski-Górecki wrote: > > On Thu, Feb 21, 2019 at 03:39:25PM +, Wei Liu wrote: > > > On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki > > > wrote: > > > > Add do

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

Hi, > (1) > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1 > > (2) > https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts Yeah, this is what I tho

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

Hi Julien Actually, the main difference for the "early printk" support is in two reg offsets: +#define SCIFA_SCASSR   0x14    /* Serial status register */ +#define SCIFA_SCAFTDR  0x20    /* Transmit FIFO data register */ +#define SCIF_SCFSR 0x10    /* Serial status register */ +#d

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

Hi Oleksandr, On 2/21/19 6:22 PM, Oleksandr wrote: => Actually, the main difference for the "early printk" support is in two reg offsets: +#define SCIFA_SCASSR   0x14    /* Serial status register */ +#define SCIFA_SCAFTDR  0x20    /* Transmit FIFO data register */ +#define SCIF_SCFSR  

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

On 21.02.19 20:20, Amit Tomer wrote: Hi, Hi (1) https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1 (2) https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7

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

On 21.02.19 20:43, Julien Grall wrote: Hi Oleksandr, Hi Julien On 2/21/19 6:22 PM, Oleksandr wrote: => Actually, the main difference for the "early printk" support is in two reg offsets: +#define SCIFA_SCASSR   0x14    /* Serial status register */ +#define SCIFA_SCAFTDR  0x20    /* T

  1   2   >