flight 144309 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144309/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl
> -Original Message-
> From: Xen-devel On Behalf Of Ian
> Jackson
> Sent: 26 November 2019 17:36
> To: George Dunlap
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Paul Durrant ; Andrew Cooper
> ; Konrad Rzeszutek Wilk
> ; Marek Marczykowski-Górecki
> ; Hans van K
On Tue, Nov 26, 2019 at 04:09:08PM +, Andrew Cooper wrote:
> On 26/11/2019 15:34, Roger Pau Monné wrote:
> > On Tue, Nov 26, 2019 at 12:03:56PM +, Andrew Cooper wrote:
> >> ICEBP isn't handled well by SVM.
> >>
> >> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
>
On 26.11.2019 19:32, Marek Marczykowski-Górecki wrote:
> Anyway, if I understand correctly, MMIO region should be mapped as UC,
> right?
While MMIO typically would want to be UC, there are clearly cases
where they'd better be WC, and there may even be cases where they
want to be WT, WP, or WB. He
On 26.11.2019 21:18, Andrew Cooper wrote:
> On 26/11/2019 20:12, Roman Shaposhnik wrote:
>> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
>>> So, to improve Xen's hardware/firmware compatibility, I have two ideas:
>>>
>>> 1. Make efi=attr=uc the default (it's still possible to disable
On Tue, Nov 26, 2019 at 04:36:05PM +0100, SeongJae Park wrote:
> From: SeongJae Park
>
> For each I/O request, blkback first maps the foreign pages for the
> request to its local pages. If an allocation of a local page for the
> mapping fails, it should unmap every mapping already made for the
>
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 thread and Xen 4.13, that would be
> EFI_SET_VIRTUAL_ADDRESS_
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 one
> location exposing its off-by-one nature.
>
>
On 27.11.2019 05:32, Jürgen Groß wrote:
> On 26.11.19 18:17, George Dunlap wrote:
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -364,8 +364,8 @@
>>*/
>> #define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
>>
>> -#define LIBXL_MAX_GRANT_FRAMES_DEFAULT 32
>> -#define LIBXL_MAX_MAPT
> 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 Tue, 26 Nov 2019, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On 26/11/2019 20:43, Stefano Stabellini
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 Tue, 26 Nov 2019, Julien Grall wrote:
Hi,
On 26/11/2019 20:43, Stefano Stabellini
On 27.11.19 10:25, Jan Beulich wrote:
On 27.11.2019 05:32, Jürgen Groß wrote:
On 26.11.19 18:17, George Dunlap wrote:
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -364,8 +364,8 @@
*/
#define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
-#define LIBXL_MAX_GRANT_FRAMES_DEFAULT 32
-#d
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 as well as DMA remapping errors.
>
> Before:
> (
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 means that if the guest is not shutdo
> Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
> range
>
> 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/201
On 26.11.2019 19:02, 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
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 quite
confusing. Fix this by starting ucode u
On 27/11/2019 09:49, Peng Fan wrote:
Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
range
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
On 27.11.2019 07:24, Yi Sun wrote:
> During test, we found a crash on Xen with below trace.
> (XEN) Xen call trace:
> (XEN)[] R psr.c#l3_cdp_write_msr+0x1e/0x22
> (XEN)[] F psr.c#do_write_psr_msrs+0x6d/0x109
> (XEN)[] F smp_call_function_interrupt+0x5a/0xac
> (XEN)[] F call_function
flight 144321 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144321/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 5530782cfe70ed22fe44358f6a10c38916443b42
baseline version:
xen 183f
On 27/11/2019 10: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 situatio
On 27/11/2019 03:10, Chao Gao wrote:
> On Tue, Nov 26, 2019 at 03:41:53PM +, 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 microc
On Tue, Nov 26, 2019 at 03:49:20PM +, George Dunlap wrote:
> Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
> ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
> introduced PCI device "quarantine" behavior, but did not document how
> the pci-assignable-add and
On Wed, 27 Nov 2019 at 10:14, Wei Liu wrote:
>
> On Tue, Nov 26, 2019 at 03:49:20PM +, George Dunlap wrote:
> > Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
> > ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
> > introduced PCI device "quarantine" behavior
Andrew, thanks for the report. Redirecting to xen-devel, as it looks
like a bug in a development version of Xen.
-George
On Wed, Nov 27, 2019 at 4:27 AM Andrew wrote:
>
> Hi Everyone,
>
> We have been trying to get Xen + QEMU 4.x working with Ceph/rbd. A
> like-for-like build process works wi
On Wed, Nov 27, 2019 at 4:33 AM Jürgen Groß wrote:
>
> On 26.11.19 18:17, George Dunlap wrote:
> > 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-li
> -Original Message-
> From: Jan Beulich
> Sent: 27 November 2019 09:44
> To: Durrant, Paul ; Grall, Julien
> 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 27.11.2019 11:57, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 November 2019 09:44
>> To: Durrant, Paul ; Grall, Julien
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Roger Pau Monné ; Wei
>> Liu
>> Subject: Re: [PATCH] xen/x86: vpmu: Unmap
On Wed, Nov 27, 2019 at 02:07:16AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Monday, November 18, 2019 10:56 PM
> >
> > On Mon, Nov 18, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
> > > On 18.11.2019 15:03, Roger Pau Monné wrote:
> > > > On Mon, Nov 18, 2019 at 01:26:46PM +0
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 updates
> -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
> ; Han
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;
>
>
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 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 wr
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 hvm_vcpu_has_pe
> -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 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 hyperv
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: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 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: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 logi
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:
> Th
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
> >>> @
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 mea
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 thre
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 cl
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
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.
>>
>>
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 t
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 at
flight 144315 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144315/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail
REGR. vs. 1390
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 qu
(+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 the
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
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
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 1
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 t
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
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 burd
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 as-i
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 wra
> -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 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
>
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 s
> -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 t
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
> -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
>
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:
> --- a/xen/arch/x86/hvm/
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
> +
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 alw
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
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 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
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 'ats.c#__l
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 asm-
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 i
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 __u
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 n
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' (82d0802e
> -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
> ; S
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,
>>>
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: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' (82d08
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: Initializat
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 start_x
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 'asid.c#g
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 suc
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
> gene
> -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 ; xen-devel@lists
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: 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 p
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 Marczykows
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 o
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 = get_field_fro
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 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 di
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 = iommu_get_devid_from_event
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 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 Ma
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 as
1 - 100 of 130 matches
Mail list logo
