On 10.11.19 10:25, Roger Pau Monne wrote:
Hello,
Current code in clear_IO_APIC_pin doesn't properly deal with IO-APIC
entries already configured to point to entries in the iommu interrupt
remapping table, fix this.
Roger Pau Monne (2):
x86/ioapic: remove usage of TRUE and FALSE in
On 11/11/2019 12:25, Jürgen Groß wrote:
> On 11.11.19 13:20, Colin King wrote:
>> From: Colin Ian King
>>
>> The non-zero check on ret is always going to be false because
>> ret was initialized as zero and the only place it is set to
>> non-zero contains a return path before the non-zero check.
Stefano Stabellini writes ("[PATCH] Introduce a description of a new optional
tag for Backports"):
> Signed-off-by: Stefano Stabellini
+2
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and
restore host history"):
> Not mend to bike shed, so just for consideration:
Suggestions are very welcome. Be careful, I'm still looking for a
co-maintainer :-).
> - Have you considered (inline) css for the
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
flight 143996 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143190
On 10.11.2019 10:25, Roger Pau Monne wrote:
> clear_IO_APIC_pin can be called after the iommu has been enabled, and
> using raw reads and writes to modify IO-APIC entries that have been
> setup to use interrupt remapping can lead to issues as some of the
> fields have different meaning when the
On Fri, Nov 08, 2019 at 11:09:52AM -0800, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 11/11/2019 12:00, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up
> and restore host history"):
>> Not mend to bike shed, so just for consideration:
>
> Suggestions are very welcome. Be careful, I'm still looking for a
> co-maintainer :-).
/me
From: Colin Ian King
The non-zero check on ret is always going to be false because
ret was initialized as zero and the only place it is set to
non-zero contains a return path before the non-zero check. Hence
the check is redundant and can be removed.
Addresses-Coverity: ("Logically dead code")
On 08.11.2019 14:34, Roger Pau Monne wrote:
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at a later point when the MSI
> fields are already updated.
>
>
On 11.11.19 13:20, Colin King wrote:
From: Colin Ian King
The non-zero check on ret is always going to be false because
ret was initialized as zero and the only place it is set to
non-zero contains a return path before the non-zero check. Hence
the check is redundant and can be removed.
In 1d3a97b06d2c
xl guest creation: Pause 10s to work around libxl/blkback races
we added a 10s delay to work around a race bug in Linux blkback.
This was intended to be used in combination with ea6626f7edd9
guest_prepare_disk: Only do the umount if we set an env var
after which it is only xl
This reverts commit ea6626f7edd9eb40a3510eaf6816a77cac4f63d0.
Contrary to the assertions in the commit message, this unmount etc. is
actually used by some tests. So removing it breaks things.
Now, we have a different workaround: a 10s sleep before we attempt the
umount. The combination of
On 11/11/2019 13:17, Jürgen Groß wrote:
> On 11.11.19 13:31, Colin Ian King wrote:
>> On 11/11/2019 12:25, Jürgen Groß wrote:
>>> On 11.11.19 13:20, Colin King wrote:
From: Colin Ian King
The non-zero check on ret is always going to be false because
ret was initialized as zero
Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and
restore host history"):
> /me is ducking under the table ;)
> Seems to be quite a lot of intracate Perl, I never was a prince of Perl
> and that hasn't got any better by not using it actively the past years.
Heh.
On 11/11/2019, 08:12, "George Dunlap" wrote:
On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> CC: jbeul...@suse.com
> CC: george.dun...@citrix.com
> CC: jul...@xen.org
> CC: lars.ku...@citrix.com
> CC: andrew.coop...@citrix.com
This can be had with two instead of six insns, by just checking the high
CS.RPL bit.
Also adjust the comment - there would be no #GP in the mentioned cases,
as there's no segment limit violation or alike. Instead there'd be #PF,
but that one reports the target EIP of said branch, not the address
flight 144001 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142750
On 31.10.2019 21:48, Sander Eikelenboom wrote:
> While in the guest it is endlessly repeating:
> [ 231.385566] xhci_hcd :00:05.0: Max number of devices this
> xHCI host supports is 32.
> [ 231.407351] usb usb1-port2: couldn't allocate usb_device
For this one,
There's no apparent reason why it can be used on 64-bit only.
Signed-off-by: Jan Beulich
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
config XEN_MCE_LOG
bool "Xen platform mcelog"
- depends on XEN_DOM0 && X86_64 && X86_MCE
+
On Friday, October 11, 2019, Vladimir Sementsov-Ogievskiy <
vsement...@virtuozzo.com> wrote:
> Add script to automatically commit tree-wide changes per-subsystem.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
Great idea!
Can you just add a comment somewhere close to the top of the
The first patch here fixes another regression from 3c88c692c287
("x86/stackframe/32: Provide consistent pt_regs"), besides the
one already addressed by
https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
The second patch is a minimal bit of cleanup on top.
1: make
Now that SS:ESP always get saved by SAVE_ALL, this also needs to be
accounted for in xen_iret_crit_fixup. Otherwise the old_ax value gets
interpreted as EFLAGS, and hence VM86 mode appears to be active all
the time, leading to random "vm86_32: no user_vm86: BAD" log messages
alongside processes
On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> CC: jbeul...@suse.com
> CC: george.dun...@citrix.com
> CC: jul...@xen.org
> CC: lars.ku...@citrix.com
> CC: andrew.coop...@citrix.com
> CC: ian.jack...@eu.citrix.com
> CC: konrad.w...@oracle.com
> CC: w...@xen.org
On 31.10.2019 21:48, Sander Eikelenboom wrote:
> - The usb3 controller malfunctioning seems indeed to be a separate issue
> (which seems unfortunate,
> because a bisect seems to become even nastier with all the intertwined
> pci-passthrough issues).
>
> Perhaps this one
The 1st change is simple cleanup, noticed while preparing for the
2nd patch, which presents the consumer of the interface extension
proposed in
https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00377.html.
The 3rd patch is sort of optional, considering that 32-bit Xen
support is
On 11.11.19 13:31, Colin Ian King wrote:
On 11/11/2019 12:25, Jürgen Groß wrote:
On 11.11.19 13:20, Colin King wrote:
From: Colin Ian King
The non-zero check on ret is always going to be false because
ret was initialized as zero and the only place it is set to
non-zero contains a return path
This is to augment commit 3f5a7896a5 ("x86/mce: Include the PPIN in MCE
records when available").
I'm also adding "synd" and "ipid" fields to struct xen_mce, in an
attempt to keep field offsets in sync with struct mce. These two fields
won't get populated for now, though.
Signed-off-by: Jan
It has never been part of Xen's public interface, and there's therefore
no guarantee for MCG_CAP's value to always be present in array entry 0.
Signed-off-by: Jan Beulich
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -222,7 +222,7 @@ static int convert_log(struct mc_info *m
On Mon, 11 Nov 2019, Lars Kurth wrote:
> On 11/11/2019, 08:12, "George Dunlap" wrote:
>
> On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
> > CC: jbeul...@suse.com
> > CC: george.dun...@citrix.com
> > CC: jul...@xen.org
> > CC:
flight 144002 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144002/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143158
On 11/11/2019, 11:03, "Stefano Stabellini" wrote:
On Mon, 11 Nov 2019, Lars Kurth wrote:
> On 11/11/2019, 08:12, "George Dunlap" wrote:
>
> On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
> > CC: jbeul...@suse.com
actypes.h and efidef.h both define BOOLEAN as unsigned char, which is buggy in
combination with logic such as "BOOLEAN b = (a & 0x100);" Redefine BOOLEAN as
bool instead, which doesn't truncate.
Both also define TRUE and FALSE, with actypes.h being extra rude and replacing
whatever exists thus
On Sat, 9 Nov 2019, Julien Grall wrote:
> On Sat, 9 Nov 2019, 04:27 Stefano Stabellini, wrote:
> On Thu, 7 Nov 2019, Peng Fan wrote:
> > The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
> >
> > Signed-off-by: Peng Fan
>
> Reviewed-by: Stefano Stabellini
>
>
flight 144005 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142915
flight 144011 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144011/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 995d8b8568fe67afffdaac3012d7b990e7314d0b
baseline version:
ovmf
On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov
>
> ARM Compiler 6 has a proven bug: it compiles data only C files with
> SoftVFP attributes. This leads to a failed linkage afterwards with
> an error:
>
> Error: L6242E: Cannot link object built_in.o as its attributes are
>
On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Also armclang complains about the condition always true,
> because `sgi` is of type enum with all its values under 16.
>
> Signed-off-by: Andrii Anisov
Although I am not completely opposed to this, given the choice I would
On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov
>
> ARM Compiler 6.6 has a proven bug: static data symbols, moved to an init
> section, becomes global. Thus these symbols clash with ones defined in
> gic-v2.c. The straight forward way to resolve the issue is to add the GIC
>
On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Here several ARM Compiler 6.6 issues are solved or provided a work-around:
>
> - Scatter file is pretty primitive, it has no feature to define symbols
> - ARM linker defined symbols are not counted as referred if only
On Mon, 11 Nov 2019, Andrew Cooper wrote:
> actypes.h and efidef.h both define BOOLEAN as unsigned char, which is buggy in
> combination with logic such as "BOOLEAN b = (a & 0x100);" Redefine BOOLEAN as
> bool instead, which doesn't truncate.
>
> Both also define TRUE and FALSE, with actypes.h
On Wed, 6 Nov 2019, Jan Beulich wrote:
> On 06.11.2019 10:19, Andrii Anisov wrote:
> > --- a/xen/include/asm-arm/smccc.h
> > +++ b/xen/include/asm-arm/smccc.h
> > @@ -120,6 +120,8 @@ struct arm_smccc_res {
> > #define __constraint_read_6 __constraint_read_5, "r" (r6)
> > #define
On 11/11/2019 16:35, Jan Beulich wrote:
> On 31.10.2019 21:48, Sander Eikelenboom wrote:
>> - The usb3 controller malfunctioning seems indeed to be a separate issue
>> (which seems unfortunate,
>> because a bisect seems to become even nastier with all the intertwined
>>
"AMD/IOMMU: don't blindly allocate interrupt remapping tables" introduces a
call at runtime from amd_iommu_add_device() to amd_iommu_set_intremap_table()
which is still marked as __init.
On one AMD Rome machine we have, this results in a crash the moment we try to
use an SR-IOV VF in a VM.
flight 144007 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144007/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143190
Hi Julien,
Inline marked with [Peng Fan]
From: Julien Grall
Sent: 2019年11月9日 6:44
To: Stefano Stabellini ; Andre Przywara
Cc: Peng Fan ; Jürgen Groß ;
julien.gr...@arm.com; xen-de...@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range
Hi,
Sorry for
47 matches
Mail list logo
