Re: [Xen-devel] [PATCH v2] drm/xen-front: fix pointer casts

On 05/23/2018 02:46 PM, Juergen Gross wrote: On 23/05/18 13:36, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Building for a 32-bit target results in warnings from casting between a 32-bit pointer and a 64-bit integer. Fix the warnings by

Re: [Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

On 24/05/18 16:07, Andrew Cooper wrote: > This helps debug #DF's which occur in alternative patches > > Reported-by: George Dunlap > Signed-off-by: Andrew Cooper Release-acked-by: Juergen Gross Juergen

[Xen-devel] [xen-4.10-testing test] 123086: tolerable FAIL - PUSHED

flight 123086 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123086/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd

[Xen-devel] [PATCH v5 2/6] libxl: introduce a new structure to represent static shared memory regions

From: Zhongze Liu Author: Zhongze Liu Add a new structure to the IDL family to represent static shared memory regions as proposed in the proposal "Allow setting up shared memory areas between VMs from xl config file" (see [1]). And deleted some

[Xen-devel] [PATCH v5 5/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

From: Zhongze Liu Author: Zhongze Liu Add the parsing utils for the newly introduced libxl_static_sshm struct to the libxl/libxlu_* family. And add realated parsing code in xl to parse the struct from xl config files. This is for the proposal "Allow

[Xen-devel] [PATCH v5 6/6] docs: documentation about static shared memory regions

From: Zhongze Liu Author: Zhongze Liu Add docs to document the motivation, usage, use cases and other relevant information about the static shared memory feature. This is for the proposal "Allow setting up shared memory areas between VMs from xl

[Xen-devel] [PATCH v5 3/6] libxl: support mapping static shared memory areas during domain creation

From: Zhongze Liu Author: Zhongze Liu Add libxl__sshm_add to map shared pages from one DomU to another, The mapping process involves the following steps: * Set defaults and check for further errors in the static_shm configs: overlapping areas,

[Xen-devel] [PATCH v5 4/6] libxl: support unmapping static shared memory areas during domain destruction

From: Zhongze Liu Author: Zhongze Liu Add libxl__sshm_del to unmap static shared memory areas mapped by libxl__sshm_add during domain creation. The unmapping process is: * For a master: decrease the refcount of the sshm region, if the refcount

[Xen-devel] [PATCH v5 0/6] Allow setting up shared memory areas between VMs from xl config files

Hi, This series implements a new xl config entry. Users can use the new config entry to statically setup shared memory areas among VMs that don't have grant table support so that they could communicate with each other through the static shared memory areas. It was originally developed by

[Xen-devel] [PATCH v5 1/6] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

From: Zhongze Liu Author: Zhongze Liu The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids a Dom0 to map memory pages from one DomU to another, which restricts some useful yet not dangerous use cases -- such as sharing pages

[Xen-devel] xsa263 wont apply

Hi there I'm trying to apply xsa263 patches, specifically for 4.10. However they dont seem to on top of 4.10.1 release. I see they do apply cleanly to current 4.10 staging branch. Are staging trees for stable branches like 4.10 considered suitable/safe to rebase to for packaging purposes?

[Xen-devel] [ovmf baseline-only test] 74741: all pass

This run is configured for baseline tests only. flight 74741 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74741/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 77ca824c652443bdf3edaa0bb109fd8225a71cd3 baseline

[Xen-devel] [linux-3.18 baseline-only test] 74739: regressions - FAIL

This run is configured for baseline tests only. flight 74739 linux-3.18 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74739/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-examine 11

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

flight 123079 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/123079/ 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] [distros-debian-wheezy test] 74740: all pass

flight 74740 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74740/ Perfect :-) All tests in this flight passed as required baseline version: flight 74722 jobs: build-amd64 pass

Re: [Xen-devel] Likely build race, "/usr/bin/ld: cannot find -lvirt"

On 05/24/2018 04:27 AM, Ian Jackson wrote: Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""): tl;dr: I think there is a bug in libvirt's build system which, with low probability, causes a build failure containing this message: /usr/bin/ld: cannot find -lvirt

[Xen-devel] [GIT PULL] (swiotlb) stable/for-linus-4.17

Hey Linus, Please git pull the following branch in your tree: git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git stable/for-linus-4.17 There is one single fix in there - that is under Xen the DMA32 heap (in the hypervisor) would end up looking like swiss cheese. The

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

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

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

On Thu, May 24, 2018 at 1:16 PM Steven Rostedt wrote: > On Thu, 24 May 2018 13:40:24 +0200 > Petr Mladek wrote: > > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > > > When using -fPIE/PIC with function tracing, the compiler generates a > > > call

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

flight 123075 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/123075/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 122357

Re: [Xen-devel] [v2 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

On 05/24/2018 01:58 AM, Jan Beulich wrote: On 24.05.18 at 02:46, wrote: Pull common defines for SMMU drives in a local header. Signed-off-by: Sameer Goel --- xen/drivers/passthrough/arm/arm_smmu.h | 125 + This being

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

On 05/23/2018 10:48 PM, Manish Jaggi wrote: Hi Sameer, General Comment, please use appropriate variable names for XXX_domain structures in code which is xen specific. I thought that we had discussed this before on one of the RFCs. At this point we are just using the format used for smmu-v2.

Re: [Xen-devel] [v2 1/6] Port WARN_ON_ONCE() from Linux

On 05/24/2018 01:53 AM, Jan Beulich wrote: On 24.05.18 at 02:46, wrote: Port WARN_ON_ONCE macro from Linux. In such a case you should justify adjustments you've made: I can add more details, but have mostly just changed variable names. The macro is self explanatory.

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

Can you please point out the specific instances? This patch is no different than the last v1 patch. I have just added tasklets to it. On 05/23/2018 10:48 PM, Manish Jaggi wrote: Hi Sameer, General Comment, please use appropriate variable names for XXX_domain structures in code which is xen

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

On Thu, 24 May 2018 13:40:24 +0200 Petr Mladek wrote: > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > > When using -fPIE/PIC with function tracing, the compiler generates a > > call through the GOT (call *__fentry__@GOTPCREL). This instruction > > takes 6 bytes instead of

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

On 5/24/18 7:01 AM, Joe Perches wrote: > On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote: >> On 5/23/18 4:35 PM, Joe Perches wrote: >>> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: On 5/23/18 2:05 PM, Joe Perches wrote: > Convert the S_ symbolic permissions to their octal

Re: [Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

On Thu, 24 May 2018, Julien Grall wrote: > Hi Artem, > > Title: It would be good to specify the subsystem you modify. > > arm: vgic: ... > > On 24/05/18 16:24, Artem Mygaiev wrote: > > vgic_vcpu_pending_irq() uses find_next_bit() library function with single > > 'unsigned long' variable, while

Re: [Xen-devel] [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head

On Thu, 24 May 2018, Julien Grall wrote: > Hi Stefano, > > On 24/05/18 00:47, Stefano Stabellini wrote: > > On Tue, 22 May 2018, Julien Grall wrote: > > > Using current is fairly expensive, so save up into a variable. > > > > > > Signed-off-by: Julien Grall > > > > Good

Re: [Xen-devel] [PATCH v2 10/10] xen: add cloc target

On Thu, 24 May 2018, Jan Beulich wrote: > >>> On 23.05.18 at 20:21, wrote: > > On Wed, 23 May 2018, Jan Beulich wrote: > >> >>> On 22.05.18 at 22:08, wrote: > >> > On Tue, 22 May 2018, Jan Beulich wrote: > >> >> >>> On 22.05.18 at 02:53,

[Xen-devel] [linux-4.9 test] 123074: regressions - FAIL

flight 123074 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123074/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 122969

[Xen-devel] [PATCH] x86/CPUID: don't override tool stack decision to hide STIBP

On 22/05/18 11:33, Jan Beulich wrote: > Other than in the feature sets, where we indeed want to offer the > feature even if not enumerated on hardware, we shouldn't dictate the > feature being available if tool stack or host admin have decided not > to expose it (for whatever [questionable?]

Re: [Xen-devel] [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

On Thu, May 24, 2018 at 4:04 AM Pavel Machek wrote: > On Wed 2018-05-23 12:54:05, Thomas Garnier wrote: > > Change the assembly code to use only relative references of symbols for the > > kernel to be PIE compatible. > > > > Position Independent Executable (PIE) support will allow

Re: [Xen-devel] [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

On Thu, May 24, 2018 at 4:03 AM Pavel Machek wrote: > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > > Change the assembly code to use only relative references of symbols for the > > kernel to be PIE compatible. > > > > Position Independent Executable (PIE) support will allow

Re: [Xen-devel] [PATCH 7/9] x86/vmx: Support load-only guest MSR list entries

>>> On 22.05.18 at 13:20, wrote: > Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load > and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and > VM_ENTRY_MSR_LOAD_ADDR > at the same page, and setting VM_EXIT_MSR_STORE_COUNT and >

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

Jan Beulich: On 24.05.18 at 17:10, wrote: >> Jan Beulich: >> On 24.05.18 at 16:14, wrote: Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich: >>> In commit d1d6fc97d6

[Xen-devel] [PATCH 3/5] tools: link arch-shared directory

Signed-off-by: Wei Liu --- Cc: Ian Jackson --- .gitignore | 1 + tools/include/Makefile | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 7004349d5a..808f4f5497 100644 ---

[Xen-devel] [PATCH 4/5] libxc: introduce xc_cpuid_x86.h

Collect cpuid related things into a header file. Provide the necessary macros to make it work. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson ---

[Xen-devel] [PATCH 2/5] x86: split out cpuid objects and helpers

They are moved to a new header which is going to be consumed by both the hypervisor and toolstack. Create a new directory for this kind of headers in anticipation of more will come. No functional change. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc:

[Xen-devel] [PATCH 1/5] x86: move definition of struct cpuid_leaf to cpuid.h

This is a step towards consolidating relevant data structures and defines to one location. It then requires defining cpuid_leaf in user space harness headers to make them continue to compile. No functional change. Signed-off-by: Wei Liu --- Cc: Jan Beulich

[Xen-devel] [PATCH 5/5] XXX DO NOT APPLY: compilation test

--- tools/libxc/xc_cpuid_x86.c | 17 + 1 file changed, 17 insertions(+) diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index 89ded718bc..0af04a4e5a 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -869,3 +869,20 @@ int

[Xen-devel] [PATCH 0/5] Share CPUID stuff between hypervisor and toolstack

The hypervisor has some nice objects and definitions that toolstack can use, too. Make that happen. The anticipation is in the future MSR objects and definitions should be shared, too. Cc: Ian Jackson Cc: Jan Beulich Cc: Andrew Cooper

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote: > Intel hardware only uses 4 bits in MSR_EFER. Changes to LME and LMA are > handled automatically via the VMENTRY_CTLS.IA32E_MODE bit. > > SCE is handled by ad-hoc logic in context_switch(), vmx_restore_guest_msrs() > and

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

On 24/05/18 16:08, Jan Beulich wrote: On 22.05.18 at 13:20, wrote: >> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen >> updates a host MSR load list entry with the current hardware value of >> MSR_DEBUGCTL. This is wrong. >> >> On

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

>>> On 24.05.18 at 17:10, wrote: > Jan Beulich: > On 24.05.18 at 16:14, wrote: >>> Jan Beulich: >>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really

Re: [Xen-devel] [PATCH 8/9] x86/vmx: Support removing MSRs from the host/guest load/save lists

On 24/05/18 16:42, Roger Pau Monné wrote: > On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote: >> Up until this point, the MSR load/save lists have only ever accumulated >> content. Introduce vmx_del_msr() as a companion to vmx_add_msr(). >> >> Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 8/9] x86/vmx: Support removing MSRs from the host/guest load/save lists

On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote: > Up until this point, the MSR load/save lists have only ever accumulated > content. Introduce vmx_del_msr() as a companion to vmx_add_msr(). > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich

Re: [Xen-devel] [PATCH 7/9] x86/vmx: Support load-only guest MSR list entries

On Tue, May 22, 2018 at 12:20:44PM +0100, Andrew Cooper wrote: > Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load > and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and VM_ENTRY_MSR_LOAD_ADDR > at the same page, and setting VM_EXIT_MSR_STORE_COUNT and >

Re: [Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

Hi Artem, Title: It would be good to specify the subsystem you modify. arm: vgic: ... On 24/05/18 16:24, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions and offsets. It

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

>>> On 24.05.18 at 17:10, wrote: > Jan Beulich: > On 24.05.18 at 16:14, wrote: >>> Jan Beulich: >>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu 24-05-18 08:18:18, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > > If we had eight ZONEs, we could offer: > > > > No, please no more zones. What we have is quite a maint. burden on its > > own. Ideally we should only have lowmem, highmem and

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

>>> On 22.05.18 at 13:20, wrote: > Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen > updates a host MSR load list entry with the current hardware value of > MSR_DEBUGCTL. This is wrong. > > On VMExit, hardware automatically resets

[Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions and offsets. It would be more correct to use the find_first_bit() function instead. Signed-off-by: Artem Mygaiev diff

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > If we had eight ZONEs, we could offer: > > No, please no more zones. What we have is quite a maint. burden on its > own. Ideally we should only have lowmem, highmem and special/device > zones for directly kernel accessible memory,

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

Andrew Cooper: > On 24/05/18 15:35, Simon Gaiser wrote: >> Andrew Cooper: >>> On 24/05/18 15:14, Simon Gaiser wrote: Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich: >>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen

Re: [Xen-devel] [PATCH 4/9] x86/vmx: Support remote access to the MSR lists

>>> On 22.05.18 at 13:20, wrote: > @@ -537,25 +544,27 @@ enum vmx_msr_list_type { > VMX_MSR_GUEST, > }; > > -int vmx_add_msr(uint32_t msr, enum vmx_msr_list_type type); > +int vmx_add_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type); > > -static

Re: [Xen-devel] [PATCH 6/9] x86/vmx: Pass an MSR value into vmx_msr_add()

>>> On 22.05.18 at 13:20, wrote: > The main purpose of this change is to allow us to set a specific MSR value, > without needing to know whether there is already a load/save list slot for > it. > Previously, callers wanting this property needed to call both

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

Jan Beulich: On 24.05.18 at 16:14, wrote: >> Jan Beulich: >> On 24.05.18 at 16:00, wrote: Jan Beulich: > In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") > I've failed to remember the fact

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

> On May 24, 2018, at 3:53 PM, Andrew Cooper wrote: > > On 24/05/18 15:35, Simon Gaiser wrote: >> Andrew Cooper: >>> On 24/05/18 15:14, Simon Gaiser wrote: Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich:

Re: [Xen-devel] [PATCH 2/9] x86/vmx: Internal cleanup for MSR load/save infrastructure

>>> On 22.05.18 at 13:20, wrote: > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > @@ -1292,48 +1292,50 @@ static int vmx_msr_entry_key_cmp(const void *key, > const void *elt) > struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

On 24/05/18 15:35, Simon Gaiser wrote: > Andrew Cooper: >> On 24/05/18 15:14, Simon Gaiser wrote: >>> Jan Beulich: >>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >> I've failed

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

Andrew Cooper: > On 24/05/18 15:14, Simon Gaiser wrote: >> Jan Beulich: >> On 24.05.18 at 16:00, wrote: Jan Beulich: > In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") > I've failed to remember the fact that multiple CPUs share

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

>>> On 24.05.18 at 16:24, wrote: > On 24/05/18 15:22, Jan Beulich wrote: > On 24.05.18 at 16:18, wrote: >>> Can you try with the "x86/traps: Dump the instruction stream even for >>> double faults" patch I've just posted, and show the full

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

>>> On 24.05.18 at 16:14, wrote: > Jan Beulich: > On 24.05.18 at 16:00, wrote: >>> Jan Beulich: In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") I've failed to remember the fact that multiple CPUs

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

On 24/05/18 15:22, Jan Beulich wrote: On 24.05.18 at 16:18, wrote: >> Can you try with the "x86/traps: Dump the instruction stream even for >> double faults" patch I've just posted, and show the full #DF panic log >> please? (Its conceivable that there are

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

On 24/05/18 15:07, Artem Mygaiev wrote: Hi Julien Hi Artem, On 24.05.18 16:49, Julien Grall wrote: Hi Artem, Thank you for the report. On 24/05/18 14:20, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

>>> On 24.05.18 at 16:14, wrote: > How many bug-fixes vs. XSAs are typically in a stable branch? I was under > the impression that historically, the vast majority used to be XSAs with very > few backports. > However, this year this has really changed because Spectre and

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

On 24/05/18 15:14, Simon Gaiser wrote: > Jan Beulich: > On 24.05.18 at 16:00, wrote: >>> Jan Beulich: In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") I've failed to remember the fact that multiple CPUs share a stub mapping

Re: [Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

>>> On 24.05.18 at 16:07, wrote: > This helps debug #DF's which occur in alternative patches > > Reported-by: George Dunlap > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

On 24/05/2018, 10:00, "Jan Beulich" wrote: >>> On 24.05.18 at 15:50, wrote: > > On 24/05/2018, 01:48, "Steven Haigh" wrote: > > On 2018-05-22 20:52, Steven Haigh wrote: > > On Tuesday, 22 May

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich: >>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >>> I've failed to remember the fact that multiple CPUs share a stub >>> mapping page. Therefore it is wrong to unconditionally

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

>>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >> I've failed to remember the fact that multiple CPUs share a stub >> mapping page. Therefore it is wrong to unconditionally zap the mapping >>

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

Hi Julien On 24.05.18 16:49, Julien Grall wrote: Hi Artem, Thank you for the report. On 24/05/18 14:20, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions. Nothing wrong is

[Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

This helps debug #DF's which occur in alternative patches Reported-by: George Dunlap Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Juergen Gross --- xen/arch/x86/traps.c| 2 +-

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

>>> On 24.05.18 at 15:48, wrote: > On 24/05/18 14:41, Jan Beulich wrote: >> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >> I've failed to remember the fact that multiple CPUs share a stub >> mapping page. Therefore it is wrong to

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

>>> On 24.05.18 at 15:50, wrote: > > On 24/05/2018, 01:48, "Steven Haigh" wrote: > > On 2018-05-22 20:52, Steven Haigh wrote: > > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote: > >> >>> On 18.05.18 at 19:53,

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

>>> On 24.05.18 at 14:39, wrote: > On 24/05/18 13:14, Roger Pau Monné wrote: >> On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote: >>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen >>> updates a host MSR load list entry with the

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

On 24/05/2018, 01:48, "Steven Haigh" wrote: On 2018-05-22 20:52, Steven Haigh wrote: > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote: >> >>> On 18.05.18 at 19:53, wrote: >> > Alternative workaround for this would

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

Hi Artem, Thank you for the report. On 24/05/18 14:20, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions. Nothing wrong is happening since 'offset' is set to 0 (other

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

On 24/05/18 14:41, Jan Beulich wrote: > In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") > I've failed to remember the fact that multiple CPUs share a stub > mapping page. Therefore it is wrong to unconditionally zap the mapping > when bringing down a CPU; it may only be

[Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") I've failed to remember the fact that multiple CPUs share a stub mapping page. Therefore it is wrong to unconditionally zap the mapping when bringing down a CPU; it may only be unmapped when no other online CPU uses that same

Re: [Xen-devel] Test for osstest, features used in Qubes OS

Jan Beulich: On 23.05.18 at 00:21, wrote: >> I have done some more testing in the meantime. The issue also affect >> 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter. >> A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text

[Xen-devel] [linux-4.14 test] 123073: regressions - FAIL

flight 123073 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123073/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 6 xen-install fail REGR. vs. 122974 Tests which did not

Re: [Xen-devel] Test for osstest, features used in Qubes OS

>>> On 23.05.18 at 00:21, wrote: > I have done some more testing in the meantime. The issue also affect > 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter. > A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and > all

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote: > On 5/23/18 4:35 PM, Joe Perches wrote: > > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: > > > On 5/23/18 2:05 PM, Joe Perches wrote: > > > > Convert the S_ symbolic permissions to their octal equivalents as > > > > using octal and not

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

On 5/23/18 4:35 PM, Joe Perches wrote: > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: >> On 5/23/18 2:05 PM, Joe Perches wrote: >>> Convert the S_ symbolic permissions to their octal equivalents as >>> using octal and not symbolic permissions is preferred by many as more >>> readable. >>>

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

On 24/05/18 13:14, Roger Pau Monné wrote: > On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote: >> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen >> updates a host MSR load list entry with the current hardware value of >> MSR_DEBUGCTL. This is wrong. >> >> On

Re: [Xen-devel] [PULL v2 00/15] xen-20180522-tag

On 22 May 2018 at 19:46, Stefano Stabellini wrote: > The following changes since commit d32e41a1188e929cc0fb16829ce3736046951e39: > > Merge remote-tracking branch > 'remotes/famz/tags/docker-and-block-pull-request' into staging (2018-05-18 > 14:11:52 +0100) > > are

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Wed 23-05-18 22:19:19, Matthew Wilcox wrote: > On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote: > > So why is this any better than the current code. Sure I am not a great > > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this > > doesn't look too much better, yet

Re: [Xen-devel] [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Wed 23-05-18 16:07:16, Huaisheng HS1 Ye wrote: > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Wednesday, May 23, 2018 2:37 AM > > > > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > > > From: Huaisheng Ye > > > > > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

On Thu, May 24, 2018 at 11:59:07AM +0100, Andrew Cooper wrote: > On 24/05/18 11:53, Roger Pau Monné wrote: > > On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote: > >> On 23/05/18 17:39, Roger Pau Monné wrote: > >>> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote: >

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote: > Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen > updates a host MSR load list entry with the current hardware value of > MSR_DEBUGCTL. This is wrong. > > On VMExit, hardware automatically resets

Re: [Xen-devel] [PATCH 4/9] x86/vmx: Support remote access to the MSR lists

On 24/05/18 12:50, Roger Pau Monné wrote: > On Tue, May 22, 2018 at 12:20:41PM +0100, Andrew Cooper wrote: >> At the moment, all modifications of the MSR lists are in current context. >> However, future changes may need to put MSR_EFER into the lists from domctl >> hypercall context. >> >> Plumb a

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > When using -fPIE/PIC with function tracing, the compiler generates a > call through the GOT (call *__fentry__@GOTPCREL). This instruction > takes 6 bytes instead of 5 on the usual relative call. > > If PIE is enabled, replace the 6th byte of the

Re: [Xen-devel] [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

On Wed 2018-05-23 12:54:05, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. > >

Re: [Xen-devel] [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. What

[Xen-devel] Developmentstatus for Xen with Ceph as replicated storage

Hi everybody, in 2013 there was an announcment, that XenServer will fully support the RBDs from Ceph, to use them as blockdevice for VMs (see ) What is about Xen itself, how it is supported? I know that you can map an RBD as device and

[Xen-devel] [xen-4.7-testing test] 123066: regressions - FAIL

flight 123066 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123066/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR.

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

On 24/05/18 11:53, Roger Pau Monné wrote: > On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote: >> On 23/05/18 17:39, Roger Pau Monné wrote: >>> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote: Instead of having multiple algorithms searching the MSR lists, implement a

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote: > On 23/05/18 17:39, Roger Pau Monné wrote: > > On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote: > >> Instead of having multiple algorithms searching the MSR lists, implement a > >> single one. It has the semantics

Re: [Xen-devel] Likely build race, "/usr/bin/ld: cannot find -lvirt"

Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""): > tl;dr: > > I think there is a bug in libvirt's build system which, with > low probability, causes a build failure containing this message: > /usr/bin/ld: cannot find -lvirt > > Complete build logs of two attempts: >

  1   2   >