flight 144331 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144331/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-xsm 7 xen-boot fail in 144316 pass in 144331
test-amd64-amd64-xl-rtds
On 27.11.19 23:32, Hans van Kranenburg wrote:
Hi all,
On 11/27/19 12:13 PM, Durrant, Paul wrote:
-Original Message-
From: Ian Jackson
Sent: 27 November 2019 11:10
[...]
Subject: RE: [Xen-devel] [PATCH for-4.13 2/2] Rationalize max_grant_frames
and max_maptrack_frames handling
flight 144324 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144324/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 139091
libxl_arm_acpi.c is using BUILD_BUG_ON but it is not including
xen-tools/libs.h that defines it.
Signed-off-by: Stefano Stabellini
---
tools/libxl/libxl_arm_acpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index
flight 144323 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144323/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 144313
On Wed, 27 Nov 2019, Jürgen Groß wrote:
> On 27.11.19 10:31, Peng Fan wrote:
> > > Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
> > > range
> > >
> > > On 27.11.19 01:01, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 26/11/2019 23:17, Stefano Stabellini wrote:
On Wed, 27 Nov 2019, Julien Grall wrote:
> On Tue, 26 Nov 2019, 23:18 Stefano Stabellini, wrote:
> On Fri, 15 Nov 2019, Stewart Hildebrand wrote:
> > Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
> >
> > Use vcpu argument in vgic_connect_hw_irq.
> >
>
On Fri, 27 Sep 2019, Jan Beulich wrote:
> On 26.09.2019 21:39, Lars Kurth wrote:
> > +### Verbose vs. terse
> > +Due to the time it takes to review and compose code reviewer, reviewers
> > often adopt a
> > +terse style. It is not unusual to see review comments such as
> > +> typo
> > +>
On Thu, 26 Sep 2019, Lars Kurth wrote:
> From: Lars Kurth
>
> This guide covers the bulk on Best Practice related to code review
> It primarily focusses on code review interactions
> It also covers how to deal with Misunderstandings and Cultural
> Differences
>
> Signed-off-by: Lars Kurth
>
On Thu, 26 Sep 2019, Lars Kurth wrote:
> From: Lars Kurth
>
> This guide provides Best Practice on identifying and resolving
> common classes of disagreement
>
> Signed-off-by: Lars Kurth
> --
> Cc: minios-de...@lists.xenproject.org
> Cc: xen-...@lists.xenproject.org
> Cc:
On Thu, 26 Sep 2019, Lars Kurth wrote:
> From: Lars Kurth
>
> This document highlights what reviewers such as maintainers and committers
> look
> for when reviewing code. It sets expectations for code authors and provides
> a framework for code reviewers.
I think the document is missing a
On 29/10/2019, 12:41, "Stefano Stabellini" wrote:
On Tue, 29 Oct 2019, Julien Grall wrote:
> On 28/10/2019 21:43, Stefano Stabellini wrote:
> > On Mon, 28 Oct 2019, Julien Grall wrote:
> >> Hi,
> >>
> >> On 25/10/2019 11:31, Jan Beulich wrote:
> >>> All,
> >>>
On Wed, 27 Nov 2019, Andrew Cooper wrote:
> On 27/11/2019 22:44, Stefano Stabellini wrote:
> > Hi all,
> >
> > GCC 9 introduced a new warning: address-of-packed-member. It warns when
> > a pointer points to a member of a packed struct, leading to a build
> > failure in Xen (cross compiling Xen on
On 27/11/2019 22:44, Stefano Stabellini wrote:
> Hi all,
>
> GCC 9 introduced a new warning: address-of-packed-member. It warns when
> a pointer points to a member of a packed struct, leading to a build
> failure in Xen (cross compiling Xen on Arm with GCC 9.2):
>
> 556 trace.c: In function
Hi all,
GCC 9 introduced a new warning: address-of-packed-member. It warns when
a pointer points to a member of a packed struct, leading to a build
failure in Xen (cross compiling Xen on Arm with GCC 9.2):
556 trace.c: In function '__trace_hypercall':
557 trace.c:826:19: error: taking
On Wed, 27 Nov 2019, Julien Grall wrote:
> On 25/11/2019 15:10, Jan Beulich wrote:
> > All,
>
> Hi,
>
> >
> > the 4.12.2 stable release is due in about 2 weeks time. Please point
> > out backporting candidates that you find missing from the respective
> > stable trees.
>
> Most of the series
Hi all,
On 11/27/19 12:13 PM, Durrant, Paul wrote:
>> -Original Message-
>> From: Ian Jackson
>> Sent: 27 November 2019 11:10
>> [...]
>> Subject: RE: [Xen-devel] [PATCH for-4.13 2/2] Rationalize max_grant_frames
>> and max_maptrack_frames handling
>>
>> Durrant, Paul writes ("RE:
flight 144319 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144319/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144299
test-amd64-i386-xl-pvshim12
flight 144335 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144335/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Paul,
On 27/11/2019 12:00, Paul Durrant wrote:
From: Julien Grall
A guest will setup a shared page with the hypervisor for each vCPU via
XENPMU_init. The page will then get mapped in the hypervisor and only
released when XENPMU_finish is called.
This means that if the guest fails to
Hi,
On 27/11/2019 18:48, Stefano Stabellini wrote:
Yes, I think that is a good suggestion. I take that you mean that in
vgic_disable_irqs for PPIs we would only clear GIC_IRQ_GUEST_ENABLED
then return basically, right?
Not really, I am only suggesting to remove the part
if ( desc != NULL )
On Tue, 26 Nov 2019, Julien Grall wrote:
> On 26/11/2019 22:36, Stefano Stabellini wrote:
> > On Mon, 25 Nov 2019, Julien Grall wrote:
> > > On 23/11/2019 20:35, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 15/11/2019 20:10, Stewart Hildebrand wrote:
> > > > > Allow vgic_get_hw_irq_desc to
Sorry, forgot to set the subject prefix correctly. It should be: [PATCH v3 0/3].
On Wed, Nov 27, 2019 at 1:44 PM Pavel Tatashin
wrote:
>
> Changelog
> v3:
> - Added Acked-by from Stefano Stabellini
> - Addressed comments from Mark Rutland
> v2:
> - Addressed Russell
privcmd_call requires to enable access to userspace for the
duration of the hypercall.
Currently, this is done via assembly macros. Change it to C
inlines instead.
Signed-off-by: Pavel Tatashin
Acked-by: Stefano Stabellini
---
arch/arm/include/asm/assembler.h | 2 +-
The __uaccess_ttbr0_disable and __uaccess_ttbr0_enable,
are the last two macros defined in asm-uaccess.h.
For now move them to entry.S where they are used. Eventually,
these macros should be replaced with C wrappers to reduce the
maintenance burden.
Also, once these macros are unified with the C
Changelog
v3:
- Added Acked-by from Stefano Stabellini
- Addressed comments from Mark Rutland
v2:
- Addressed Russell King's concern by not adding
uaccess_* to ARM.
- Removed the accidental change to xtensa
Convert the remaining uaccess_* calls from ASM
We currently duplicate the logic to enable/disable uaccess via TTBR0,
with C functions and assembly macros. This is a maintenenace burden
and is liable to lead to subtle bugs, so let's get rid of the assembly
macros, and always use the C functions. This requires refactoring
some assembly functions
On 21/11/2019 08:34, Jan Beulich wrote:
> On 20.11.2019 18:13, Andrew Cooper wrote:
>> On 20/11/2019 16:40, Jürgen Groß wrote:
>>> On 20.11.19 17:30, Jan Beulich wrote:
On 08.11.2019 12:18, Jan Beulich wrote:
> The .file assembler directives generated by the compiler do not include
>
On 11/27/19 7:48 AM, Roger Pau Monne wrote:
> When using posted interrupts on Intel hardware it's possible that the
> vCPU resumes execution with a stale local APIC IRR register because
> depending on the interrupts to be injected vlapic_has_pending_irq
> might not be called, and thus PIR won't be
Hi,
On 15/11/2019 20:10, Stewart Hildebrand wrote:
These will be used in a follow-up patch.
Signed-off-by: Stewart Hildebrand
---
v3: new patch
---
xen/include/asm-arm/irq.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/irq.h
On 27/11/2019 09:40, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 03:01:12PM +, Andrew Cooper wrote:
>> Print the PCI coordinates in its common format and use d%u notation for the
>> domain. As well as printing flags, decode them. IO_PAGE_FAULT is used for
>> interrupt remapping errors
On Wed, Nov 27, 2019 at 12:01 PM Mark Rutland wrote:
>
> On Wed, Nov 27, 2019 at 11:09:35AM -0500, Pavel Tatashin wrote:
> > On Wed, Nov 27, 2019 at 11:03 AM Mark Rutland wrote:
> > >
> > > On Wed, Nov 27, 2019 at 10:31:54AM -0500, Pavel Tatashin wrote:
> > > > On Wed, Nov 27, 2019 at 10:12 AM
This patch introduces a new iommu_op to facilitate a per-implementation
quarantine set up, and then further code for x86 implementations
(amd and vtd) to set up a read-only scratch page to serve as the source
for DMA reads whilst a device is assigned to dom_io. DMA writes will
continue to fault as
On 27/11/2019 17:02, Jan Beulich wrote:
> On 26.11.2019 16:01, Andrew Cooper wrote:
>> @@ -560,18 +557,26 @@ static void parse_event_log_entry(struct amd_iommu
>> *iommu, u32 entry[])
>>
>> if ( code == IOMMU_EVENT_IO_PAGE_FAULT )
>> {
>> -device_id =
On Fri, Nov 08, 2019 at 12:18:40PM +0100, Jan Beulich wrote:
> The .file assembler directives generated by the compiler do not include
> any path components (gcc) or just the ones specified on the command line
> (clang, at least version 5), and hence multiple identically named source
> files (in
On Wed, Nov 27, 2019 at 11:09:35AM -0500, Pavel Tatashin wrote:
> On Wed, Nov 27, 2019 at 11:03 AM Mark Rutland wrote:
> >
> > On Wed, Nov 27, 2019 at 10:31:54AM -0500, Pavel Tatashin wrote:
> > > On Wed, Nov 27, 2019 at 10:12 AM Mark Rutland
> > > wrote:
> > > >
> > > > On Thu, Nov 21, 2019 at
On 26.11.2019 16:01, Andrew Cooper wrote:
> @@ -560,18 +557,26 @@ static void parse_event_log_entry(struct amd_iommu
> *iommu, u32 entry[])
>
> if ( code == IOMMU_EVENT_IO_PAGE_FAULT )
> {
> -device_id = iommu_get_devid_from_event(entry[0]);
> -domain_id =
On 27.11.2019 10:19, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 03:01:11PM +, Andrew Cooper wrote:
>> Unhandled IOMMU errors (i.e. not IO_PAGE_FAULT) should still be printed, and
>> not hidden behind iommu=debug.
>>
>> While adjusting this, factor out the symbolic name handling to just
On 11/27/19 4:43 PM, Durrant, Paul wrote:
>> -Original Message-
>> From: George Dunlap
>> Sent: 27 November 2019 16:34
>> To: Jan Beulich ; Durrant, Paul
>> Cc: AndrewCooper ; Anthony PERARD
>> ; Roger Pau Monné ;
>> Volodymyr Babchuk ; George Dunlap
>> ; Ian Jackson ;
>> Marek
> -Original Message-
> From: Boris Ostrovsky
> Sent: 27 November 2019 16:32
> To: Jan Beulich ; Durrant, Paul
> Cc: Grall, Julien ; Andrew Cooper
> ; Roger Pau Monné ; Jun
> Nakajima ; Kevin Tian ; Wei
> Liu ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2] xen/x86: vpmu: Unmap
flight 144328 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 144322
Tests which
> -Original Message-
> From: George Dunlap
> Sent: 27 November 2019 16:34
> To: Jan Beulich ; Durrant, Paul
> Cc: AndrewCooper ; Anthony PERARD
> ; Roger Pau Monné ;
> Volodymyr Babchuk ; George Dunlap
> ; Ian Jackson ;
> Marek Marczykowski-Górecki ; Stefano
> Stabellini ;
On 11/27/19 4:35 PM, Jürgen Groß wrote:
> On 27.11.19 17:25, Jan Beulich wrote:
>> On 27.11.2019 17:21, George Dunlap wrote:
>>> On 11/27/19 4:14 PM, Jan Beulich wrote:
On 27.11.2019 17:01, Roger Pau Monne wrote:
> Live-patching requires unique symbols, and sadly the clang build
>
flight 144318 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144318/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 144304
Tests which did not
On 27.11.19 17:25, Jan Beulich wrote:
On 27.11.2019 17:21, George Dunlap wrote:
On 11/27/19 4:14 PM, Jan Beulich wrote:
On 27.11.2019 17:01, Roger Pau Monne wrote:
Live-patching requires unique symbols, and sadly the clang build
generates a lot of duplicate symbols:
Duplicate symbol
On 11/27/19 4:20 PM, Jan Beulich wrote:
> On 27.11.2019 17:14, Durrant, Paul wrote:
>>> From: Jan Beulich
>>> Sent: 27 November 2019 15:56
>>>
>>> On 27.11.2019 15:37, Paul Durrant wrote:
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -789,7 +789,7 @@ void __init
On 11/27/19 10:44 AM, Jan Beulich wrote:
> On 27.11.2019 13:00, Paul Durrant wrote:
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -479,6 +479,8 @@ static int vpmu_arch_initialise(struct vcpu *v)
>>
>> if ( ret )
>> printk(XENLOG_G_WARNING "VPMU:
On 27.11.2019 17:21, George Dunlap wrote:
> On 11/27/19 4:14 PM, Jan Beulich wrote:
>> On 27.11.2019 17:01, Roger Pau Monne wrote:
>>> Live-patching requires unique symbols, and sadly the clang build
>>> generates a lot of duplicate symbols:
>>>
>>> Duplicate symbol 'asid.c#get_cpu_info'
On 11/27/19 4:14 PM, Jan Beulich wrote:
> On 27.11.2019 17:01, Roger Pau Monne wrote:
>> Live-patching requires unique symbols, and sadly the clang build
>> generates a lot of duplicate symbols:
>>
>> Duplicate symbol 'asid.c#get_cpu_info' (82d0803032c0 != 82d0802e0f50)
>> Duplicate symbol
On 27.11.2019 17:14, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 27 November 2019 15:56
>>
>> On 27.11.2019 15:37, Paul Durrant wrote:
>>> --- a/xen/arch/arm/setup.c
>>> +++ b/xen/arch/arm/setup.c
>>> @@ -789,7 +789,7 @@ void __init start_xen(unsigned long
>> boot_phys_offset,
>>>
> -Original Message-
> From: Jan Beulich
> Sent: 27 November 2019 15:56
> To: Durrant, Paul ; George Dunlap
>
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Anthony PERARD ;
> Roger Pau Monné ; Volodymyr Babchuk
> ; George Dunlap ;
> Ian Jackson ; Marek Marczykowski-Górecki
> ;
On 27.11.2019 17:01, Roger Pau Monne wrote:
> Live-patching requires unique symbols, and sadly the clang build
> generates a lot of duplicate symbols:
>
> Duplicate symbol 'asid.c#get_cpu_info' (82d0803032c0 != 82d0802e0f50)
> Duplicate symbol 'asid.c#get_cpu_info_from_stack'
flight 144316 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 144305
Tests which did
On Wed, Nov 27, 2019 at 11:03 AM Mark Rutland wrote:
>
> On Wed, Nov 27, 2019 at 10:31:54AM -0500, Pavel Tatashin wrote:
> > On Wed, Nov 27, 2019 at 10:12 AM Mark Rutland wrote:
> > >
> > > On Thu, Nov 21, 2019 at 09:24:06PM -0500, Pavel Tatashin wrote:
> > > > The __uaccess_ttbr0_disable and
On 27.11.19 16:48, Roger Pau Monne wrote:
When using posted interrupts on Intel hardware it's possible that the
vCPU resumes execution with a stale local APIC IRR register because
depending on the interrupts to be injected vlapic_has_pending_irq
might not be called, and thus PIR won't be synced
On Wed, Nov 27, 2019 at 10:31:54AM -0500, Pavel Tatashin wrote:
> On Wed, Nov 27, 2019 at 10:12 AM Mark Rutland wrote:
> >
> > On Thu, Nov 21, 2019 at 09:24:06PM -0500, Pavel Tatashin wrote:
> > > The __uaccess_ttbr0_disable and __uaccess_ttbr0_enable,
> > > are the last two macros defined in
Live-patching requires unique symbols, and sadly the clang build
generates a lot of duplicate symbols:
Duplicate symbol 'asid.c#get_cpu_info' (82d0803032c0 != 82d0802e0f50)
Duplicate symbol 'asid.c#get_cpu_info_from_stack' (82d0802e1080 !=
82d0803032f0)
Duplicate symbol
On 27.11.2019 16:48, Roger Pau Monne wrote:
> When using posted interrupts on Intel hardware it's possible that the
> vCPU resumes execution with a stale local APIC IRR register because
> depending on the interrupts to be injected vlapic_has_pending_irq
> might not be called, and thus PIR won't be
On 27/11/2019 15:22, Wieczorkiewicz, Pawel wrote:
>
>
>> On 27. Nov 2019, at 12:16, Sergey Dyasli wrote:
>>
>> On 26/11/2019 18:37, Wieczorkiewicz, Pawel wrote:
>>> It looks like gcc plays the usual dirty tricks with local variables
>>> renaming:
>>>
>>> - xen-syms
>>> 7529: 82d0805fed50
On 27.11.2019 15:37, Paul Durrant wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -789,7 +789,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
> .max_evtchn_port = -1,
> .max_grant_frames
When using posted interrupts on Intel hardware it's possible that the
vCPU resumes execution with a stale local APIC IRR register because
depending on the interrupts to be injected vlapic_has_pending_irq
might not be called, and thus PIR won't be synced into IRR.
Fix this by making sure PIR is
On 27.11.2019 13:00, Paul Durrant wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -479,6 +479,8 @@ static int vpmu_arch_initialise(struct vcpu *v)
>
> if ( ret )
> printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
> +else
> +
On 27.11.2019 12:56, Roger Pau Monné wrote:
> On Wed, Nov 27, 2019 at 12:30:06PM +0100, Jan Beulich wrote:
>> On 27.11.2019 12:22, Roger Pau Monné wrote:
>>> On Tue, Nov 26, 2019 at 05:50:32PM +0100, Jan Beulich wrote:
On 26.11.2019 14:26, Roger Pau Monne wrote:
> ---
> -Original Message-
> From: Jan Beulich
> Sent: 27 November 2019 15:26
> To: Durrant, Paul
> Cc: Kevin Tian ; xen-devel@lists.xenproject.org;
> Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> Subject: Re: [Xen-devel] [PATCH] x86 / iommu: set up a scratch page in the
> quarantine domain
>
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 20 November 2019 13:52
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
> Roger Pau Monné ; Wei Liu ; Andrew
> Cooper
> Subject: Re: [Xen-devel] [PATCH] x86 / iommu: set up a scratch page in
On Wed, Nov 27, 2019 at 10:12 AM Mark Rutland wrote:
>
> On Thu, Nov 21, 2019 at 09:24:06PM -0500, Pavel Tatashin wrote:
> > The __uaccess_ttbr0_disable and __uaccess_ttbr0_enable,
> > are the last two macros defined in asm-uaccess.h.
> >
> > Replace them with C wrappers and call C functions from
On 27.11.2019 16:18, Durrant, Paul wrote:
>> -Original Message-
>> From: Tian, Kevin
>> Sent: 25 November 2019 08:22
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich ; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>>
>> Subject: RE: [PATCH] x86 / iommu: set up a
> On 27. Nov 2019, at 12:16, Sergey Dyasli wrote:
>
> On 26/11/2019 18:37, Wieczorkiewicz, Pawel wrote:
>> It looks like gcc plays the usual dirty tricks with local variables renaming:
>>
>> - xen-syms
>> 7529: 82d0805fed50 8 OBJECT LOCAL DEFAULT 4230 lastpage.22857
>> - livepatch
> -Original Message-
> From: Tian, Kevin
> Sent: 25 November 2019 08:22
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: RE: [PATCH] x86 / iommu: set up a scratch page in the quarantine
> domain
>
> > From:
On Wed, Nov 27, 2019 at 10:10:07AM -0500, Pavel Tatashin wrote:
> Hi Mark,
>
> Thank you for reviewing this work.
> > The 'arch_' prefix should probably be 'asm_' (or have an '_asm' suffix),
> > since this is entirely local to the arch code, and even then should only
> > be called from the C
On Thu, Nov 21, 2019 at 09:24:06PM -0500, Pavel Tatashin wrote:
> The __uaccess_ttbr0_disable and __uaccess_ttbr0_enable,
> are the last two macros defined in asm-uaccess.h.
>
> Replace them with C wrappers and call C functions from
> kernel_entry and kernel_exit.
For now, please leave those
Hi Mark,
Thank you for reviewing this work.
> A commit message should provide rationale, rather than just a
> description of the patch. Something like:
>
> | We currently duplicate the logic to enable/disable uaccess via TTBR0,
> | with C functions and assembly macros. This is a maintenenace
Hi Pavel,
On Thu, Nov 21, 2019 at 09:24:05PM -0500, Pavel Tatashin wrote:
> Replace the uaccess_ttbr0_disable/uaccess_ttbr0_enable via
> inline variants, and remove asm macros.
A commit message should provide rationale, rather than just a
description of the patch. Something like:
| We currently
From: George Dunlap
Xen used to have single, system-wide limits for the number of grant
frames and maptrack frames a guest was allowed to create. Increasing
or decreasing this single limit on the Xen command-line would change
the limit for all guests on the system.
Later, per-domain limits for
flight 144322 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144322/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Thanks George,
I have the system setup for testing, so happy to test any patches that
may come out.
Best Regards,
Andrew.
On 27/11/19 20:38, George Dunlap wrote:
Andrew, thanks for the report. Redirecting to xen-devel, as it looks
like a bug in a development version of Xen.
-George
On
On 27.11.19 13:50, Julien Grall wrote:
(+Juergen)
Hi,
On 26/11/2019 14:05, Jan Beulich wrote:
On 26.11.2019 14:30, Julien Grall wrote:
Commit d661611d08 "docs/markdown: Switch to using pandoc, and fix
underscore escaping" converted the livepatch documentation from markdown
to pandoc.
Update
(+Juergen)
Hi,
On 26/11/2019 14:05, Jan Beulich wrote:
On 26.11.2019 14:30, Julien Grall wrote:
Commit d661611d08 "docs/markdown: Switch to using pandoc, and fix
underscore escaping" converted the livepatch documentation from markdown
to pandoc.
Update MAINTAINERS to reflect the change so
On 27.11.19 11:04, Sergey Dyasli wrote:
Currently if a user tries to live-load the same or older ucode revision
than CPU already has, he will get a single message in Xen log like:
(XEN) 128 cores are to update their microcode
No actual ucode loading will happen and this situation can be
On 25/11/2019 15:10, Jan Beulich wrote:
All,
Hi,
the 4.12.2 stable release is due in about 2 weeks time. Please point
out backporting candidates that you find missing from the respective
stable trees.
Most of the series "xen/arm: XSA-201 and XSA-263 fixes" [1] should be
backported to
On 27.11.19 13:07, George Dunlap wrote:
On 11/27/19 4:34 AM, Jürgen Groß wrote:
On 26.11.19 18:30, George Dunlap wrote:
On 11/26/19 5:17 PM, George Dunlap wrote:
- xl will use the libxl default for maptrack, but does its own default
calculation for grant frames: either 32 or 64, based on
On 11/27/19 4:34 AM, Jürgen Groß wrote:
> On 26.11.19 18:30, George Dunlap wrote:
>> On 11/26/19 5:17 PM, George Dunlap wrote:
>>> - xl will use the libxl default for maptrack, but does its own default
>>> calculation for grant frames: either 32 or 64, based on the max
>>> possible mfn.
>>
flight 144313 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144313/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail REGR. vs. 144301
test-armhf-armhf-xl-rtds
From: Julien Grall
A guest will setup a shared page with the hypervisor for each vCPU via
XENPMU_init. The page will then get mapped in the hypervisor and only
released when XENPMU_finish is called.
This means that if the guest fails to invoke XENPMU_finish, e.g if it is
destroyed rather than
On Nov 27, 2019, at 04:16, Jan Beulich wrote:
>
> On 26.11.2019 22:20, Rich Persaud wrote:
>> As an intermediate step, could we have an umbrella opt-in
>> Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that
>> enables multiple EFI options for maximum hardware compatibility?
>> For this
Hi,
On 27/11/2019 09:44, Jan Beulich wrote:
On 26.11.2019 18:17, Paul Durrant wrote:
From: Julien Grall
A guest will setup a shared page with the hypervisor for each vCPU via
XENPMU_init. The page will then get mapped in the hypervisor and only
released when XEMPMU_finish is called.
This
On Wed, Nov 27, 2019 at 12:30:06PM +0100, Jan Beulich wrote:
> On 27.11.2019 12:22, Roger Pau Monné wrote:
> > On Tue, Nov 26, 2019 at 05:50:32PM +0100, Jan Beulich wrote:
> >> On 26.11.2019 14:26, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/hvm/irq.c
> >>> +++ b/xen/arch/x86/hvm/irq.c
> >>>
On Wed, Nov 27, 2019 at 12:34:09PM +0100, Jan Beulich wrote:
> On 27.11.2019 12:29, Roger Pau Monné wrote:
> > On Wed, Nov 27, 2019 at 12:16:37PM +0100, Jan Beulich wrote:
> >> On 27.11.2019 12:03, Roger Pau Monné wrote:
> >>> On Wed, Nov 27, 2019 at 02:07:16AM +, Tian, Kevin wrote:
>
On 27.11.2019 12:29, Roger Pau Monné wrote:
> On Wed, Nov 27, 2019 at 12:16:37PM +0100, Jan Beulich wrote:
>> On 27.11.2019 12:03, Roger Pau Monné wrote:
>>> On Wed, Nov 27, 2019 at 02:07:16AM +, Tian, Kevin wrote:
Then what's the difference from original logic?
>>>
>>> The original
On Wed, Nov 27, 2019 at 10:14:56AM +0100, Jan Beulich wrote:
> On 26.11.2019 22:20, Rich Persaud wrote:
> > As an intermediate step, could we have an umbrella opt-in
> > Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that
> > enables multiple EFI options for maximum hardware compatibility?
> >
On 27.11.2019 12:22, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 05:50:32PM +0100, Jan Beulich wrote:
>> On 26.11.2019 14:26, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -515,7 +515,11 @@ void hvm_set_callback_via(struct domain *d, uint64_t
On Wed, Nov 27, 2019 at 12:16:37PM +0100, Jan Beulich wrote:
> On 27.11.2019 12:03, Roger Pau Monné wrote:
> > On Wed, Nov 27, 2019 at 02:07:16AM +, Tian, Kevin wrote:
> >> Then what's the difference from original logic?
> >
> > The original logic is:
> >
> > if ( running && (in_irq() || (v
On 27.11.2019 12:14, Julien Grall wrote:
> Hi,
>
> On 27/11/2019 09:44, Jan Beulich wrote:
>> On 26.11.2019 18:17, Paul Durrant wrote:
>>> From: Julien Grall
>>>
>>> A guest will setup a shared page with the hypervisor for each vCPU via
>>> XENPMU_init. The page will then get mapped in the
> -Original Message-
> From: Julien Grall
> Sent: 27 November 2019 11:15
> To: Jan Beulich ; Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monné ; Wei
> Liu
> Subject: Re: [PATCH] xen/x86: vpmu: Unmap per-vCPU PMU page when the
> domain is destroyed
>
On Tue, Nov 26, 2019 at 05:50:32PM +0100, Jan Beulich wrote:
> On 26.11.2019 14:26, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/irq.c
> > +++ b/xen/arch/x86/hvm/irq.c
> > @@ -515,7 +515,11 @@ void hvm_set_callback_via(struct domain *d, uint64_t
> > via)
> > struct hvm_intack
On Wed, Nov 27, 2019 at 03:09:51AM +, Tian, Kevin wrote:
> > From: Jan Beulich
> > Sent: Wednesday, November 27, 2019 12:59 AM
> >
> > On 26.11.2019 17:47, Roger Pau Monné wrote:
> > > On Tue, Nov 26, 2019 at 05:32:04PM +0100, Jan Beulich wrote:
> > >> On 26.11.2019 14:26, Roger Pau Monne
On 26/11/2019 18:37, Wieczorkiewicz, Pawel wrote:
> It looks like gcc plays the usual dirty tricks with local variables renaming:
>
> - xen-syms
> 7529: 82d0805fed50 8 OBJECT LOCAL DEFAULT 4230 lastpage.22857
> - livepatch
>289: 8 OBJECT GLOBAL DEFAULT UND
On 27.11.2019 12:03, Roger Pau Monné wrote:
> On Wed, Nov 27, 2019 at 02:07:16AM +, Tian, Kevin wrote:
>> Then what's the difference from original logic?
>
> The original logic is:
>
> if ( running && (in_irq() || (v != current)) )
> {
> unsigned int cpu = v->processor;
>
>
> -Original Message-
> From: Ian Jackson
> Sent: 27 November 2019 11:10
> To: Durrant, Paul
> Cc: Ian Jackson ; George Dunlap
> ; Juergen Gross ; Stefano
> Stabellini ; Julien Grall ; Wei
> Liu ; Paul Durrant ; Andrew Cooper
> ; Konrad Rzeszutek Wilk
> ; Marek Marczykowski-Górecki
> ;
Durrant, Paul writes ("RE: [Xen-devel] [PATCH for-4.13 2/2] Rationalize
max_grant_frames and max_maptrack_frames handling"):
> > -Original Message-
> > From: Xen-devel On Behalf Of Ian
> > Jackson
> > I have seen reports of users who ran out of grant/maptrack frames
> > because of
1 - 100 of 129 matches
Mail list logo
