Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote: > On 07/23/2018 02:40 PM, Mark Railton wrote: > > On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote: > >> On 07/23/2018 02:34 PM, Mark Railton wrote: > >>> Fixed issue with multi line comment > >> > >> Fix [not Fixed] > >> >

[Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

Fixed issue with multi line comment Signed-off-by: Mark Railton --- drivers/xen/xlate_mmu.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c index 23f1387b3ef7..3b03bc1641ed 100644 --- a/drivers/xen/xlate_mmu.c +++

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote: > On 07/23/2018 02:34 PM, Mark Railton wrote: > > Fixed issue with multi line comment > > Fix [not Fixed] > > > > > Signed-off-by: Mark Railton > > --- > > drivers/xen/xlate_mmu.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2

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

On Sat, 14 Jul 2018, Srivatsa S. Bhat wrote: > 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). FWIW -- not sure how much inspiration you took from our SLE 4.4-based

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

On Mon, Jul 23, 2018 at 02:55:12PM -0700, Randy Dunlap wrote: > On 07/23/2018 02:48 PM, Mark Railton wrote: > > On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote: > >> On 07/23/2018 02:40 PM, Mark Railton wrote: > >>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote: >

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

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

[Xen-devel] [ovmf test] 125531: all pass - PUSHED

flight 125531 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125531/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 005c855dc6be0f61f76de0d7ec4a62ee737518d6 baseline version: ovmf

[Xen-devel] [qemu-upstream-4.11-testing test] 125508: regressions - FAIL

flight 125508 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125508/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl broken in 125498

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

On Mon, Jul 23, 2018 at 12:25 AM, Greg KH wrote: > 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. >> >>

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

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

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

On Mon, Jul 23, 2018 at 2:26 AM, Andrew Cooper wrote: > 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

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

This run is configured for baseline tests only. flight 74998 ovmf real [real] http://osstest.xensource.com/osstest/logs/74998/ 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 74996

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

On 07/23/2018 06:02 PM, Boris Ostrovsky wrote: > On 07/23/2018 10:42 AM, Andrew Cooper wrote: >> 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

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

On 07/23/2018 10:42 AM, Andrew Cooper wrote: > 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

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

On 07/23/2018 02:48 PM, Mark Railton wrote: > On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote: >> On 07/23/2018 02:40 PM, Mark Railton wrote: >>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote: On 07/23/2018 02:34 PM, Mark Railton wrote: > Fixed issue with multi

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

On 07/23/2018 02:40 PM, Mark Railton wrote: > On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote: >> On 07/23/2018 02:34 PM, Mark Railton wrote: >>> Fixed issue with multi line comment >> >> Fix [not Fixed] >> >>> >>> Signed-off-by: Mark Railton >>> --- >>> drivers/xen/xlate_mmu.c | 5

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

On 07/23/2018 02:34 PM, Mark Railton wrote: > Fixed issue with multi line comment Fix [not Fixed] > > Signed-off-by: Mark Railton > --- > drivers/xen/xlate_mmu.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c >

[Xen-devel] [ovmf test] 125523: all pass - PUSHED

flight 125523 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125523/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 549ae85ce1b00228c3abcf6a9e4022c4f4fba5ed baseline version: ovmf

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

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

[Xen-devel] [linux-3.18 test] 125505: regressions - FAIL

flight 125505 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125505/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125138

Re: [Xen-devel] [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests

On Mon, 23 Jul 2018, Andrii Anisov wrote: > Hello Stefano, > > > On 07.07.18 02:11, Stefano Stabellini wrote: > > Extend allocate_memory to work for non 1:1 mapped domUs. Specifically, > > memory allocated for domU will be mapped into the domU pseudo-physical > > address space at the appropriate

Re: [Xen-devel] [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests

Hello Stefano, On 07.07.18 02:11, Stefano Stabellini wrote: Extend allocate_memory to work for non 1:1 mapped domUs. Specifically, memory allocated for domU will be mapped into the domU pseudo-physical address space at the appropriate addresses according to the guest memory map:

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

flight 125503 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/125503/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit2 broken in 125485 test-arm64-arm64-libvirt-xsm

Re: [Xen-devel] [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree

On Mon, 23 Jul 2018, Andrii Anisov wrote: > Hello Stefano, > > On 07.07.18 02:11, Stefano Stabellini wrote: > > The device tree based boot protocol is extended to carry information > > about DomUs. Based on that information, Xen creates and starts one or > > more DomUs. > Please consider also

Re: [Xen-devel] [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree

On Mon, 23 Jul 2018, Julien Grall wrote: > On 18/07/18 18:48, Stefano Stabellini wrote: > > On Wed, 18 Jul 2018, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 13/07/18 21:54, Stefano Stabellini wrote: > > > > On Thu, 12 Jul 2018, Julien Grall wrote: > > > > > Hi, > > > > > > > > > > Would

Re: [Xen-devel] [PATCH v2] hvm/altp2m: Clarify the proper way to extend the altp2m interface

On 07/23/2018 08:09 PM, George Dunlap wrote: > The altp2m functionality was originally envisioned to be used in > several different configurations, one of which was a single in-guest > agent that had full operational control of altp2m. This required the > single hypercall to be an HVMOP rather

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

On 7/23/18 4:26 AM, Greg KH wrote: > 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

Re: [Xen-devel] [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree

Hello Stefano, On 07.07.18 02:11, Stefano Stabellini wrote: The device tree based boot protocol is extended to carry information about DomUs. Based on that information, Xen creates and starts one or more DomUs. Please consider also status monitoring and restarting for those domains. DomUs

Re: [Xen-devel] [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree

On 18/07/18 18:48, Stefano Stabellini wrote: On Wed, 18 Jul 2018, Julien Grall wrote: Hi Stefano, On 13/07/18 21:54, Stefano Stabellini wrote: On Thu, 12 Jul 2018, Julien Grall wrote: Hi, Would it be possible to provide a branch with the patch applied? It would be nice to have that for

Re: [Xen-devel] [PATCH 00/15] xen/arm: Bunch of clean-up/improvement

Ping? Cheers, On 16/07/18 18:26, Julien Grall wrote: Hi all, This is patch series is a bunch of clean-up/improvement I collected while working on the P2M and trap subsystems. Cheers, Julien Grall (15): xen/arm: cpregs: Allow HSR_CPREG* to receive more than 1 parameter xen/arm: cpregs:

[Xen-devel] [PATCH v2] hvm/altp2m: Clarify the proper way to extend the altp2m interface

The altp2m functionality was originally envisioned to be used in several different configurations, one of which was a single in-guest agent that had full operational control of altp2m. This required the single hypercall to be an HVMOP rather than a DOMCTL, since HVM guests are not allowed to make

[Xen-devel] [PATCH 1/2] automation: add debian unstable images

This will get us the latest toolchain available in Debian. Signed-off-by: Wei Liu --- automation/build/debian/unstable-i386.dockerfile | 50 automation/build/debian/unstable.dockerfile | 48 +++ 2 files changed, 98 insertions(+) create mode

[Xen-devel] [PATCH 2/2] automation: build with debian unstable

Signed-off-by: Wei Liu --- .gitlab-ci.yml | 64 ++ 1 file changed, 64 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 682e48ef51..8aae194136 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -103,6 +103,70 @@

[Xen-devel] [PATCH 0/2] automation: build test with debian unstable

Using unstable gets us the latest toolchain available in Debian. See: https://gitlab.com/liuw/xen/pipelines/26330873 Wei Liu (2): automation: add debian unstable images automation: build with debian unstable .gitlab-ci.yml | 64

[Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing

Hi all, Wei and Doug have recently been improving [xen.git] / automation / build, implementing some of the functionality outlined in [1] (see "CI / CD" heading).  We are intending to take every patch series that is sent to xen-devel and create a branch at https://gitlab.com/xen-project/xen.git

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

[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

[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

[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

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’:

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

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

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

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

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

[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

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

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

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

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

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

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

[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

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 ;

[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

[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

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 >

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

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

[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

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

[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

[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

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

[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

[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

[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

[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

[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

[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

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

[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

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

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

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

[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

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:

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

[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

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

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

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

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

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

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

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

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

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

[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

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

  1   2   >