Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Fri 20-07-18 17:09:02, Andrew Morton wrote: [...] > Please take a look? Are you OK to have these in a separate patch? -- Michal Hocko SUSE Labs ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/

[Xen-devel] An issue in sharing the pages again in xen-memshare

Hi all, I have written a program that can share memory pages of two VMs every x milliseconds. To do so, I modified xen and added an unshare event to be able to capture it. However, for some pages, when I receive the unshare event that contains the information about the pages which was about to be

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Mon 23-07-18 09:03:06, Michal Hocko wrote: > On Fri 20-07-18 17:09:02, Andrew Morton wrote: > [...] > > Please take a look? > > Are you OK to have these in a separate patch? Btw. I will rebase this patch once oom stuff in linux-next settles. At least oom_lock removal from oom_reaper will confl

Re: [Xen-devel] An issue in sharing the pages again in xen-memshare

On 07/23/2018 05:37 AM, sepanta s wrote: > I have written a program that can share memory pages of two VMs every x > milliseconds. To do so, I modified xen and added an unshare event to be > able to capture it. However,  for some pages, when I receive the unshare > event that contains the informati

Re: [Xen-devel] [PATCH] x86/entry/64: Remove %ebx handling from error_entry/exit

On Sun, Jul 22, 2018 at 11:05:09AM -0700, Andy Lutomirski wrote: > error_entry and error_exit communicate the user vs kernel status of > the frame using %ebx. This is unnecessary -- the information is in > regs->cs. Just use regs->cs. > > This makes error_entry simpler and makes error_exit more

[Xen-devel] [PATCH] automation: build with 32 bit stretch

Signed-off-by: Wei Liu --- See: https://gitlab.com/liuw/xen/pipelines/26289145 Clang build failed. That should be fixed separately. --- .gitlab-ci.yml | 32 1 file changed, 32 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 682e48ef51..1b9877b34

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Mon 23-07-18 09:11:54, Michal Hocko wrote: > On Mon 23-07-18 09:03:06, Michal Hocko wrote: > > On Fri 20-07-18 17:09:02, Andrew Morton wrote: > > [...] > > > Please take a look? > > > > Are you OK to have these in a separate patch? > > Btw. I will rebase this patch once oom stuff in linux-next

[Xen-devel] [ovmf baseline-only test] 74996: tolerable FAIL

This run is configured for baseline tests only. flight 74996 ovmf real [real] http://osstest.xensource.com/osstest/logs/74996/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 74995 test

Re: [Xen-devel] [PATCH] firmware/shim : filter output files during Xen tree setup

On Fri, Jul 20, 2018 at 02:15:05PM -0700, Christopher Clark wrote: > Exclude named output files from the Xen tree setup. > > The linkfarm.stamp content will differ between top level "make" > and "make install" invocations, due to the introduction of these > output files that are produced during th

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/20/2018 05:08 PM, Boris Ostrovsky wrote: On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Fri 20-07-18 16:01:25, Andrew Morton wrote: > On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote: > > > > Any suggestions regarding how the driver developers can test this code > > > path? I don't think we presently have a way to fake an oom-killing > > > event? Perhaps we should add such

Re: [Xen-devel] [PATCH] firmware/shim : filter output files during Xen tree setup

On Fri, Jul 20, 2018 at 02:15:05PM -0700, Christopher Clark wrote: > Exclude named output files from the Xen tree setup. > > The linkfarm.stamp content will differ between top level "make" > and "make install" invocations, due to the introduction of these > output files that are produced during th

Re: [Xen-devel] [PATCH v3] drm: Replace NULL with error value in drm_prime_pages_to_sg

On 07/19/2018 01:24 PM, Dan Carpenter wrote: Reviewed-by: Dan Carpenter regards, dan carpenter Applied to drm-misc-next ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] firmware/shim : filter output files during Xen tree setup

On 23/07/18 10:09, Roger Pau Monné wrote: > On Fri, Jul 20, 2018 at 02:15:05PM -0700, Christopher Clark wrote: >> Exclude named output files from the Xen tree setup. >> >> The linkfarm.stamp content will differ between top level "make" >> and "make install" invocations, due to the introduction of t

[Xen-devel] Patch "x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend" has been added to the 4.4-stable tree

This is a note to let you know that I've just added the patch titled x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-xen-

[Xen-devel] [PATCH 1/2] tools/gdbsx: fix build with clang 3.8

Currently building gdbsx with clang 3.8 gives the following errors: xg_main.c:783:17: error: 'aligned' attribute ignored when parsing type [-Werror,-Wignored-attributes] iop->uva = (uint64_aligned_t)((unsigned long)tobuf); ^~~~ /builds/liuw/xen/tools/debugger/gdbsx

[Xen-devel] [PATCH 2/2] ocaml: remove undefined behaviour in systemd_stubs.c

Clang complains: systemd_stubs.c:51:8: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] ret = Val_int(-1U); ^~~~ Simply change the return value to 0. Signed-off-by: Wei Liu --- Cc: Christian Lindig Cc: David Scott See: https

[Xen-devel] [PATCH 0/2] tools: fix clang build

See individual patch for details. Wei Liu (2): tools/gdbsx: fix build with clang 3.8 ocaml: remove undefined behaviour in systemd_stubs.c tools/debugger/gdbsx/Rules.mk | 4 tools/ocaml/xenstored/systemd_stubs.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) -- 2.11.0

[Xen-devel] [distros-debian-sid test] 74997: tolerable FAIL

flight 74997 distros-debian-sid real [real] http://osstest.xensource.com/osstest/logs/74997/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 74976 test-amd64-amd64-i386-sid-netboot-pygru

Re: [Xen-devel] [PATCH] xenstore-client: Add option for raw in-/output

On Sat, Jul 21, 2018 at 04:35:37PM +0200, Marek Marczykowski-Górecki wrote: > From: Simon Gaiser > > Parsing/generating the escape sequences used by xenstore-client is non > trivial. So make scripting (for use in stubdom) easier by adding a raw > option. Should a description for this option be a

Re: [Xen-devel] [PATCH 1/2] tools/gdbsx: fix build with clang 3.8

On Mon, Jul 23, 2018 at 10:30:38AM +0100, Wei Liu wrote: > Currently building gdbsx with clang 3.8 gives the following errors: > > xg_main.c:783:17: error: 'aligned' attribute ignored when parsing type > [-Werror,-Wignored-attributes] > iop->uva = (uint64_aligned_t)((unsigned long)tobuf); >

Re: [Xen-devel] [PATCH 2/2] ocaml: remove undefined behaviour in systemd_stubs.c

On 23/07/18 10:30, Wei Liu wrote: > Clang complains: > > systemd_stubs.c:51:8: error: shifting a negative signed value is undefined > [-Werror,-Wshift-negative-value] > ret = Val_int(-1U); > ^~~~ > > Simply change the return value to 0. That will break the function t

Re: [Xen-devel] [PATCH 2/2] ocaml: remove undefined behaviour in systemd_stubs.c

On Mon, Jul 23, 2018 at 10:47:04AM +0100, Andrew Cooper wrote: > On 23/07/18 10:30, Wei Liu wrote: > > Clang complains: > > > > systemd_stubs.c:51:8: error: shifting a negative signed value is undefined > > [-Werror,-Wshift-negative-value] > > ret = Val_int(-1U); > > ^~~~

Re: [Xen-devel] [PATCH 2/2] ocaml: remove undefined behaviour in systemd_stubs.c

> On 23 Jul 2018, at 10:52, Wei Liu wrote: > > On Mon, Jul 23, 2018 at 10:47:04AM +0100, Andrew Cooper wrote: >> On 23/07/18 10:30, Wei Liu wrote: >>> Clang complains: >>> >>> systemd_stubs.c:51:8: error: shifting a negative signed value is undefined >>> [-Werror,-Wshift-negative-value] >>>

Re: [Xen-devel] [PATCH 2/2] ocaml: remove undefined behaviour in systemd_stubs.c

On 23/07/18 10:52, Wei Liu wrote: > On Mon, Jul 23, 2018 at 10:47:04AM +0100, Andrew Cooper wrote: >> On 23/07/18 10:30, Wei Liu wrote: >>> Clang complains: >>> >>> systemd_stubs.c:51:8: error: shifting a negative signed value is undefined >>> [-Werror,-Wshift-negative-value] >>> ret = Val

Re: [Xen-devel] [PATCH] xenstore-client: Add option for raw in-/output

On Mon, Jul 23, 2018 at 11:39:05AM +0200, Roger Pau Monné wrote: > On Sat, Jul 21, 2018 at 04:35:37PM +0200, Marek Marczykowski-Górecki wrote: > > From: Simon Gaiser > > > > Parsing/generating the escape sequences used by xenstore-client is non > > trivial. So make scripting (for use in stubdom)

[Xen-devel] [PATCH v2 0/2] tools: fix clang build

Wei Liu (2): tools/gdbsx: fix build with clang 3.8 ocaml: remove undefined behaviour in systemd_stubs.c tools/debugger/gdbsx/Rules.mk | 2 ++ tools/ocaml/xenstored/systemd_stubs.c | 10 ++ 2 files changed, 4 insertions(+), 8 deletions(-) -- 2.11.0

[Xen-devel] [PATCH v2 1/2] tools/gdbsx: fix build with clang 3.8

Currently building gdbsx with clang 3.8 gives the following errors: xg_main.c:783:17: error: 'aligned' attribute ignored when parsing type [-Werror,-Wignored-attributes] iop->uva = (uint64_aligned_t)((unsigned long)tobuf); ^~~~ /builds/liuw/xen/tools/debugger/gdbsx

[Xen-devel] [PATCH v2 2/2] ocaml: remove undefined behaviour in systemd_stubs.c

Clang complains: systemd_stubs.c:51:8: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] ret = Val_int(-1U); ^~~~ Since sd_notify_fd has a signature of unit -> unit, we simply change the return value to Val_unit. Signed-off-by: W

Re: [Xen-devel] [PATCH v2 2/2] ocaml: remove undefined behaviour in systemd_stubs.c

> On 23 Jul 2018, at 11:26, Wei Liu wrote: > > Clang complains: > > systemd_stubs.c:51:8: error: shifting a negative signed value is undefined > [-Werror,-Wshift-negative-value] >ret = Val_int(-1U); > ^~~~ > > Since sd_notify_fd has a signature of unit -> unit, w

Re: [Xen-devel] [PATCH V5] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index

On 07/20/2018 07:02 PM, Razvan Cojocaru wrote: > On 07/20/2018 08:18 PM, George Dunlap wrote: >> Furthermore, imagine the following scenario: >> >> * dom0 enables altp2m on domain A >> * dom0 switches altp2m to view 1 on domain A >> * dom0 enables #VE on domain A >> * domain A has a vmexit >> ->

Re: [Xen-devel] [PATCH v2 0/2] tools: fix clang build

On 23/07/18 11:26, Wei Liu wrote: > Wei Liu (2): > tools/gdbsx: fix build with clang 3.8 > ocaml: remove undefined behaviour in systemd_stubs.c Both Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xen

Re: [Xen-devel] RFC: Boot Domain, domB

Hello Christopher, On 20.06.18 03:58, Christopher Clark wrote: Mixed-criticality and safety-critical systems under development need support for timely boot of multiple domains at system launch -- “Initial Domains” -- with static assignment of resources between them, each isolated from the oth

Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM

Hi I think the main questions here are: 1. Do we need a separated KConfig option for SILO 2. Can we use indirect call like "dummy_xsm_ops.grant_copy" Any suggestion? Best regards Xin(Talons) Li > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Mo

Re: [Xen-devel] [PATCH v7 07/12] arm: add a tiny kconfig configuration

Hi Stefano, On 07/07/18 00:13, Stefano Stabellini wrote: Add a tiny kconfig configuration. Enabled only the credit scheduler. It only carries non-default options (use make menuconfig or make olddefconfig to produce a complete .config file). Signed-off-by: Stefano Stabellini Acked-by: Julien

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

Hi Stefano, On 07/07/18 00:13, Stefano Stabellini wrote: +config QEMU_PLATFORM + bool + +config RCAR3_PLATFORM + bool Those 2 options do nothing. So I would prefer if they are removed. With that fixed: Acked-by: Julien Grall Cheers, -- Julien Grall __

[Xen-devel] Patch "x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths" has been added to the 4.4-stable tree

This is a note to let you know that I've just added the patch titled x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the pat

Re: [Xen-devel] [PATCH v7 09/12] xen: add per-platform defaults for NR_CPUS

Hi Stefano, On 07/07/18 00:14, Stefano Stabellini wrote: Add specific per-platform defaults for NR_CPUS. Note that the order of the defaults matter: they need to go first, otherwise the generic defaults will be applied. This is done so that Xen builds customized for a specific hardware platform

Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote: > Hi Greg, > > This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS) > and patches for the Speculative Store Bypass vulnerability to 4.4.y > (they apply cleanly on top of 4.4.140). > > I used 4.9.y as my reference whe

Re: [Xen-devel] [PATCH V3] xen/altp2m: set access_required properly for all altp2ms

On 06/28/2018 08:54 AM, Razvan Cojocaru wrote: > For the hostp2m, access_required starts off as 0, then it can be > set with xc_domain_set_access_required(). However, all the altp2ms > set it to 1 on init, and ignore both the hostp2m and the hypercall. > This patch sets access_required to the value

Re: [Xen-devel] [PATCH V5] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index

On 07/23/2018 01:29 PM, George Dunlap wrote: > It's possible my analysis is wrong there (I'm not intimately familiar > with the code), but I think my patch is better anyway for a couple of > reasons: > > * The logic to keep EPTP_INDEX in sync is explicit, and all in the same > file. > > * It does

Re: [Xen-devel] [PATCH v7 12/12] xen: clarify the security-support status of Kconfig options on ARM

Hi, On 07/07/18 00:14, Stefano Stabellini wrote: Signed-off-by: Stefano Stabellini CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- SUPPORT.md | 10 ++ 1 file changed, 10 insertions(+) diff --git a/SUPPORT.md b/SUP

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

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

Re: [Xen-devel] [PATCH V3] xen/altp2m: set access_required properly for all altp2ms

On 07/16/2018 09:53 AM, Jan Beulich wrote: On 16.07.18 at 10:35, wrote: >> On 06/28/2018 07:19 PM, Tamas K Lengyel wrote: >>> On Thu, Jun 28, 2018 at 1:54 AM Razvan Cojocaru >>> wrote: For the hostp2m, access_required starts off as 0, then it can be set with xc_domain_set_acce

[Xen-devel] PVH dom0 creation fails - the system freezes

Hello, For the last few days, I have been trying to get a PVH dom0 running, however I encountered the following problem: the system seems to freeze after the hypervisor boots, the screen goes black. I have tried to debug it via a serial console (using Minicom) and managed to get some more Xen out

[Xen-devel] [freebsd-master test] 125515: regressions - trouble: blocked/fail

flight 125515 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125515/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317 Tests which did

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

flight 125513 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125513/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail REGR. vs. 125510 Tests which did not succee

[Xen-devel] [PATCH] libgnttab: Add support for Linux dma-buf

From: Oleksandr Andrushchenko Add support for Linux grant device driver extension which allows converting existing dma-buf's into an array of grant references and vise versa. This is only implemented for Linux as other OSes have no Linux dma-buf support. Bump gnttab library minor version to 3.

[Xen-devel] [PATCH 4.4 036/107] x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream. Older Xen versions (4.5 and before) might have problems migrating pv guests with MSR_IA32_SPEC_CTRL having a non-zero val

[Xen-devel] [PATCH 4.4 098/107] x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 74899d92e3dc7671a8017b3146dcd4735f3b upstream. Commit: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD") ... added speculative_store_bypass_ht_init() to

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

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

Re: [Xen-devel] [PATCH V3] xen/altp2m: set access_required properly for all altp2ms

Hi, On 23/07/18 12:40, George Dunlap wrote: On 07/16/2018 09:53 AM, Jan Beulich wrote: On 16.07.18 at 10:35, wrote: On 06/28/2018 07:19 PM, Tamas K Lengyel wrote: On Thu, Jun 28, 2018 at 1:54 AM Razvan Cojocaru wrote: For the hostp2m, access_required starts off as 0, then it can be set wi

Re: [Xen-devel] [PATCH V3] xen/altp2m: set access_required properly for all altp2ms

On 07/23/2018 01:58 PM, Julien Grall wrote: > Hi, > > On 23/07/18 12:40, George Dunlap wrote: >> On 07/16/2018 09:53 AM, Jan Beulich wrote: >> On 16.07.18 at 10:35, wrote: On 06/28/2018 07:19 PM, Tamas K Lengyel wrote: > On Thu, Jun 28, 2018 at 1:54 AM Razvan Cojocaru > wrote: >

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

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

[Xen-devel] [PATCH v2 13/17] x86/xen: enable Hygon support to Xen

To make Xen work correctly on Hygon platforms, reuse AMD's Xen support code path and add vendor check for Hygon along with AMD. Signed-off-by: Pu Wen --- arch/x86/xen/pmu.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c in

[Xen-devel] [PATCH v2 11/17] x86/mce: enable Hygon support to MCE infrastructure

Hygon machine check arch is similar to AMD family 17h. To enable the MCE infrastructure support, add CPU vendor check for Hygon to share the code path of AMD. Add hygon mce init function mce_hygon_feature_init() to minimize further maintenance effort. Signed-off-by: Pu Wen --- arch/x86/include/

[Xen-devel] [PATCH v2 16/17] driver/edac: enable Hygon support to AMD64 EDAC driver

To make AMD64 MCE and EDAC drivers working on Hygon platforms, add Hygon vendor check for them. Also Hygon PCI Device ID DF_F0/DF_F6(0x1460/0x1466) of Host bridge is needed for these drivers. And support Dhyana processors by using AMD 0x17 codes. Signed-off-by: Pu Wen --- drivers/edac/amd64_edac

[Xen-devel] [PATCH v2 07/17] x86/pci: add Hygon PCI vendor and northbridge support

As Hygon register its PCI Vendor ID as a new one "0x1d94", so add a new definition PCI_VENDOR_ID_HYGON in include/linux/pci_ids.h. Also Hygon PCI Device ID(0x1450/0x1463/0x1464) for Host bridge is added to amd_nb.c. And it need to define new arrays for Hygon: hygon_root_ids[], hygon_nb_misc_ids[],

[Xen-devel] [PATCH v2 08/17] x86/apic: add modern APIC support for Hygon

Hygon processors use modern APIC, so just return in modern_apic() and sync_Arb_IDs(). And should break in switch case in detect_init_API(). Signed-off-by: Pu Wen --- arch/x86/kernel/apic/apic.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/api

[Xen-devel] [PATCH v2 04/17] x86/smpboot: smp init nodelay and no flush caches before sleep

Dhyana use no delay in smp_quirk_init_udelay(), and return in mwait_play_dead() as AMD does. Signed-off-by: Pu Wen --- arch/x86/kernel/smpboot.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index db9656e..26cb2c9 100

[Xen-devel] [PATCH v2 00/17] 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 09/17] x86/bugs: add lfence mitigation to spectre v2 and no meltdown for Hygon

To share codes between AMD and Hygon to mitigate Spectre V2 Retpoline vulnerability, rename macros SPECTRE_V2_RETPOLINE_MINIMAL_AMD to SPECTRE_V2_RETPOLINE_MINIMAL_LFENCE, and SPECTRE_V2_CMD_RETPOLINE_AMD to SPECTRE_V2_CMD_RETPOLINE_LFENCE. As Hygon processors is not affected by meltdown vulnerabi

[Xen-devel] [PATCH v2 02/17] x86/cache: get Dhyana cache size/leaves and setup cache cpumap

Hygon Dhyana processor has the topology extensions bit in CPUID. With this bit kernel can get the cache info. So add support in cpuid4_cache_lookup_regs() to get the correct cache size. Dhyana also find num_cache_leaves via CPUID leaf 0x801d, so add Hygon support in find_num_cache_leaves(). A

[Xen-devel] [PATCH v2 05/17] x86/perfctr: return perf counter and event selection bit offset

Hygon Dhyana shares similar perfctr arch with AMD family 17h. It returns the bit offset of the performance counter register and the event selection register for Hygon CPU in the similar way as AMD does. Signed-off-by: Pu Wen --- arch/x86/kernel/cpu/perfctr-watchdog.c | 8 1 file changed

[Xen-devel] [PATCH v2 14/17] driver/acpi: enable Hygon support to ACPI driver

For Dhyana processors have NONSTOP TSC feature, so enable the support to ACPI driver. Signed-off-by: Pu Wen --- drivers/acpi/acpi_pad.c | 1 + drivers/acpi/processor_idle.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c index 552c1f7

[Xen-devel] [PATCH v2 01/17] x86/cpu: create Dhyana init file and register new cpu_dev to system

Add x86 architecture support for new processor Hygon Dhyana Family 18h. Rework to create a separated file(arch/x86/kernel/cpu/hygon.c) from the AMD init one(arch/x86/kernel/cpu/amd.c) to initialize Dhyana CPU. In this way we can remove old AMD architecture support codes from Hygon code path and gen

[Xen-devel] [PATCH v2 15/17] driver/cpufreq: enable Hygon support to cpufreq driver

Enable ACPI cpufreq driver support for Hygon by adding family ID check along with AMD. As Hygon platforms have SMBus device(PCI device ID 0x790b), enable Hygon support to function amd_freq_sensitivity_init(). Signed-off-by: Pu Wen --- drivers/cpufreq/acpi-cpufreq.c | 11 +++ dri

[Xen-devel] [PATCH v2 03/17] x86/mtrr: get MTRR number and support TOP_MEM2

Hygon CPU have a special magic MSR way to force WB for memory >4GB, and also support TOP_MEM2. Therefore, it is necessary to add Hygon support in amd_special_default_mtrr(). The MtrrFixDramModEn bit on Hygon platform should also be set to 1 during BIOS initialization of the fixed MTRRs, then clear

[Xen-devel] [PATCH v2 12/17] x86/kvm: enable Hygon support to KVM infrastructure

Hygon Dhyana CPU has the SVM feature as AMD family 17h does. Add Hygon support in the KVM infrastructure. Signed-off-by: Pu Wen --- arch/x86/include/asm/kvm_emulate.h | 4 arch/x86/include/asm/virtext.h | 5 +++-- arch/x86/kvm/emulate.c | 11 ++- 3 files changed, 1

[Xen-devel] [PATCH v2 10/17] x86/events: enable Hygon support to PMU infrastructure

Hygon PMU arch is similar to AMD Family 17h. To support Hygon PMU, the initialization flow for it just call amd_pmu_init() and change PMU name to "HYGON". To share AMD's flow, add code check for Hygon family ID 18h to run the code path of AMD family 17h in core/uncore functions. Signed-off-by: Pu

[Xen-devel] [PATCH v2 06/17] x86/nops: init ideal_nops for Hygon

The ideal_nops for Dhyana processors should be p6_nops. Signed-off-by: Pu Wen --- arch/x86/kernel/alternative.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index a481763..8f4925b 100644 --- a/arch/x86/kernel/alternative.c

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: On 07/20/2018 05:08 PM, Boris Ostrovsky wrote: On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux

Re: [Xen-devel] [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU

On 07/22/2018 11:31 PM, Wanpeng Li wrote: > On Fri, 20 Jul 2018 at 06:03, Waiman Long wrote: >> On 07/19/2018 05:54 PM, Davidlohr Bueso wrote: >>> On Thu, 19 Jul 2018, Waiman Long wrote: >>> On a VM with only 1 vCPU, the locking fast paths will always be successful. In this case, there i

Re: [Xen-devel] [PATCH v3 12/13] x86: add iommu_ops to modify and flush IOMMU mappings

On Tue, Jul 17, 2018 at 02:38:15PM +0100, Paul Durrant wrote: > [...] > +static int iommuop_map(struct xen_iommu_op_map *op) > +{ > +struct domain *d, *currd = current->domain; > +struct domain_iommu *iommu = dom_iommu(currd); > +bool readonly = op->flags & XEN_IOMMUOP_map_readonly; >

Re: [Xen-devel] [PATCH v3 12/13] x86: add iommu_ops to modify and flush IOMMU mappings

> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: 23 July 2018 14:35 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; > Andrew Cooper ; George Dunlap > ; Ian Jackson ; Julien > Grall ; Konrad Rzeszutek Wilk > ; Stefano Stabellini ; Tim > (Xen.o

[Xen-devel] [PATCH v4] x86/mm: Add mem access rights to NPT

From: Isaila Alexandru This patch adds access control for NPT mode. There aren’t enough extra bits to store the access rights in the NPT p2m table, so we add a radix tree to store the rights. For efficiency, remove entries which match the default permissions rather than continuing to store them

[Xen-devel] [PATCH] x86/spec-ctrl: Fix the parsing of xpti= on fixed Intel hardware

The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will always evaluate false. As a result, the default case won't disable XPTI on Intel hardware which advertises ARCH_CAPABILITIES_RDCL_NO. Simplify p

[Xen-devel] [PATCH] x86/hvm: Disallow unknown MSR_EFER bits

It turns out that nothing ever prevented HVM guests from trying to set unknown EFER bits. Generally, this results in a vmentry failure. For Intel hardware, all implemented bits are covered by the checks. For AMD hardware, the only EFER bit which isn't covered by the checks is TCE (which AFAICT i

Re: [Xen-devel] [PATCH v3 12/13] x86: add iommu_ops to modify and flush IOMMU mappings

On Mon, Jul 23, 2018 at 02:40:05PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Wei Liu [mailto:wei.l...@citrix.com] > > Sent: 23 July 2018 14:35 > > To: Paul Durrant > > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; > > Andrew Cooper ; George Dunlap > > ; Ian Jackson ;

Re: [Xen-devel] [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU

On 07/23/2018 12:42 AM, Davidlohr Bueso wrote: > On Mon, 23 Jul 2018, Wanpeng Li wrote: > >> On Fri, 20 Jul 2018 at 06:03, Waiman Long wrote: >>> >>> On 07/19/2018 05:54 PM, Davidlohr Bueso wrote: >>> > On Thu, 19 Jul 2018, Waiman Long wrote: >>> > >>> >> On a VM with only 1 vCPU, the locking fast

Re: [Xen-devel] [PATCH] x86/hvm: Disallow unknown MSR_EFER bits

On Mon, Jul 23, 2018 at 02:49:50PM +0100, Andrew Cooper wrote: > It turns out that nothing ever prevented HVM guests from trying to set unknown > EFER bits. Generally, this results in a vmentry failure. > > For Intel hardware, all implemented bits are covered by the checks. > > For AMD hardware,

Re: [Xen-devel] [PATCH] x86/spec-ctrl: Fix the parsing of xpti= on fixed Intel hardware

On 23/07/18 15:48, Andrew Cooper wrote: > The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data > hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will > always evaluate false. > > As a result, the default case won't disable XPTI on Intel hardware which

Re: [Xen-devel] [PATCH v3 12/13] x86: add iommu_ops to modify and flush IOMMU mappings

On Tue, Jul 17, 2018 at 02:38:15PM +0100, Paul Durrant wrote: [...] > +static int iommuop_unmap(struct xen_iommu_op_unmap *op) > +{ [...] > + > +if ( !iommu_unmap_page(currd, bfn) ) > +rc = -EIO; So it is an error to unmap the page successfully? In fact this same line is changed in the

Re: [Xen-devel] [PATCH v3 12/13] x86: add iommu_ops to modify and flush IOMMU mappings

> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: 23 July 2018 15:26 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; > Andrew Cooper ; George Dunlap > ; Ian Jackson ; Julien > Grall ; Konrad Rzeszutek Wilk > ; Stefano Stabellini ; Tim > (Xen.o

Re: [Xen-devel] [PATCH] x86/spec-ctrl: Fix the parsing of xpti= on fixed Intel hardware

On Mon, Jul 23, 2018 at 02:48:02PM +0100, Andrew Cooper wrote: > The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data > hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will > always evaluate false. > > As a result, the default case won't disable XPTI

Re: [Xen-devel] [PATCH v1] earlyprintk configuration for rk3399 boards

On 06/07/18 12:04, Ігор Матущак wrote: Hello Julien, Hi Ihor, Sorry for the late reply. I suppose there is no such documentation, at least I didn't find any. Bringing up XEN 4.10.0 on RK3399 is my pet-project. My current target board is Ibox3399

Re: [Xen-devel] [PATCH] x86/hvm: Disallow unknown MSR_EFER bits

On Mon, Jul 23, 2018 at 02:49:50PM +0100, Andrew Cooper wrote: > It turns out that nothing ever prevented HVM guests from trying to set unknown > EFER bits. Generally, this results in a vmentry failure. > > For Intel hardware, all implemented bits are covered by the checks. > > For AMD hardware,

[Xen-devel] [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support

Because of a bug in 2010, LMSL support didn't functioned in Xen. c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In addition to migration problems, changes to the segmentation logic for emulation would be needed before the feature could be enabled. This feature is entir

Re: [Xen-devel] [PATCH v1] earlyprintk configuration for rk3399 boards

Hi Julien, Sure, I would be glad to do that. I suppose it should be placed somewhere on wiki.xenproject.org? *BR,* *Ihor Matushchak* 2018-07-23 17:33 GMT+03:00 Julien Grall : > On 06/07/18 12:04, Ігор Матущак wrote: > >> Hello Julien, >> > > Hi Ihor, > > Sorry for the late reply. > > >> I supp

Re: [Xen-devel] [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen

On 07/21/2018 07:18 PM, M. Vefa Bicakci wrote: > On 07/21/2018 05:19 PM, Boris Ostrovsky wrote: >> On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote: >>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S >>> index c7449f377a77..96e8ff34129e 100644 >>> --- a/arch/x86/entry/entry_64.S >>

Re: [Xen-devel] [PATCH v1] earlyprintk configuration for rk3399 boards

On 23/07/18 15:47, Ihor Matushchak wrote: Hi Julien, Hi Ihor, Sure, I would be glad to do that. I suppose it should be placed somewhere on wiki.xenproject.org ? We usually create a new platform under https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualizat

Re: [Xen-devel] [PATCH 2/2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

On 07/22/2018 11:57 AM, M. Vefa Bicakci wrote: > On 07/21/2018 07:17 PM, M. Vefa Bicakci wrote: >> On 07/21/2018 05:25 PM, Boris Ostrovsky wrote: >>> On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote: diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 439a94bf89ad..8

Re: [Xen-devel] [PATCH 6/6] x86/shadow: a little bit of style cleanup

At 04:51 -0600 on 19 Jul (1531975863), Jan Beulich wrote: > Correct indentation of a piece of code, adjusting comment style at the > same time. Constify gl3e pointers and drop a bogus (and useless once > corrected) cast. > > Signed-off-by: Jan Beulich Acked-by: Tim Deegan _

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: > On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: >> >>> data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function >>> ‘gntdev_ioctl_dmabuf_exp_from_refs’: >>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning: >

Re: [Xen-devel] [PATCH 3/6] x86/HVM: implement memory read caching

Hi, At 04:48 -0600 on 19 Jul (1531975717), Jan Beulich wrote: > Emulation requiring device model assistance uses a form of instruction > re-execution, assuming that the second (and any further) pass takes > exactly the same path. This is a valid assumption as far use of CPU > registers goes (as th

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 06:22 PM, Boris Ostrovsky wrote: On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function ‘gntdev_ioctl_dmabuf_exp_from_refs’: /data/upstream/linux-xen/drivers/xen

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

flight 125519 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125519/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail in 125513 REGR. vs. 125510 Tests which are failing in

[Xen-devel] [PATCH] docs: use the make wildcard function instead of find

The regexp used with find in order to list the man pages doesn't work with FreeBSD find, so use a wildcard instead. No functional change. Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson Cc: Wei Liu --- docs/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a

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

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

Re: [Xen-devel] [PATCH v1] earlyprintk configuration for rk3399 boards

Julien, Got it, thanks. *BR,* *Ihor Matushchak* 2018-07-23 17:59 GMT+03:00 Julien Grall : > > > On 23/07/18 15:47, Ihor Matushchak wrote: > >> Hi Julien, >> > > Hi Ihor, > > >> Sure, I would be glad to do that. >> >> I suppose it should be placed somewhere on wiki.xenproject.org < >> http://wik

  1   2   >