flight 157042 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157042/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 872f953262d68a11da7bc2fb3ded16df234b8700
baseline version:
ovmf
flight 157040 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
flight 157037 qemu-mainline real [real]
flight 157046 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157037/
http://logs.test-lab.xenproject.org/osstest/logs/157046/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
flight 157028 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157028/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 157016
flight 157023 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
On Thu, Nov 26, 2020 at 05:38:24PM +, Anthony PERARD wrote:
> On Sun, Nov 08, 2020 at 09:45:33PM +0100, Philippe Mathieu-Daudé wrote:
> > Xen packages are available in CentOS 7, but have been
> > removed from CentOS 8. Use the CentOS 7 container.
>
> Technically Xen has never been in CentOS
On Sun, Nov 08, 2020 at 09:45:33PM +0100, Philippe Mathieu-Daudé wrote:
> Xen packages are available in CentOS 7, but have been
> removed from CentOS 8. Use the CentOS 7 container.
Technically Xen has never been in CentOS 8, I'm working on it, slowly.
> Signed-off-by: Philippe Mathieu-Daudé
>
On Thu, Nov 26, 2020 at 04:09:37PM +0100, Roger Pau Monné wrote:
> >
> > Oh, that's actually very useful. The interrupt is being constantly
> > injected from the hardware and received by Xen, it's just not then
> > injected into dom0 - that's the bit we are missing. Let me look into
> > adding
Linux SMMUv3 code implements the commands-queue insertion based on
atomic operations implemented in Linux. Atomic functions used by the
commands-queue insertion is not implemented in XEN therefore revert the
patch that implemented the commands-queue insertion based on atomic
operations.
Once the
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven wrote:
>
> The maintainer is not necessarily the owner/author of the code, and
> thus may not know the intent of the code.
Agreed, I was not blaming maintainers -- just trying to point out that
the problem is there :-)
In those cases, it is
XArray is not implemented in XEN revert the patch that introduce the
XArray code in SMMUv3 driver.
Once XArray is implemented in XEN this patch can be added in XEN.
Reverted the commit 0299a1a81ca056e79c1a7fb751f936ec0d5c7afe
Signed-off-by: Rahul Singh
---
On 26.11.2020 16:53, Julien Grall wrote:
> On 26/11/2020 15:18, Jan Beulich wrote:
>> On 26.11.2020 14:22, Julien Grall wrote:
>>> On 26/11/2020 11:34, Jan Beulich wrote:
On 25.11.2020 20:48, Stefano Stabellini wrote:
> On Wed, 25 Nov 2020, Jan Beulich wrote:
>> On 25.11.2020 13:15,
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Major differences with regard to Linux driver are as follows:
1. Only Stage-2 translation is supported as compared to the Linux driver
that supports both Stage-1 and Stage-2 translations.
2. Use P2M
struct io_pgtable_ops, struct io_pgtable_cfg, struct iommu_flush_ops,
and struct iommu_ops related code are linux specific.
Remove code related to above struct as code is dead code in XEN.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/arm/smmu-v3.c | 457 --
1
Linux SMMUv3 driver supports both Stage-1 and Stage-2 translations.
As of now only Stage-2 translation support has been tested.
Once Stage-1 translation support is tested this patch can be added.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/arm/smmu-v3.c | 440
PCI ATS functionality is not implemented and tested on ARM. Remove the
PCI ATS support, once PCI ATS support is tested and available this
patch can be added.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/arm/smmu-v3.c | 273 --
1 file changed, 273 deletions(-)
XEN does not support MSI on ARM platforms, therefore remove the MSI
support from SMMUv3 driver.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/arm/smmu-v3.c | 176 +-
1 file changed, 3 insertions(+), 173 deletions(-)
diff --git
Based on tag Linux 5.9.8 commit 951cbbc386ff01b50da4f46387e994e81d9ab431
It's a copy of the Linux SMMUv3 driver. Xen specific code has not
been added yet and code has not been compiled.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/arm/smmu-v3.c | 4164 +
1
This patch series is v2 of the work to add support for the SMMUv3 driver.
Approach taken is to first merge the Linux copy of the SMMUv3 driver
(tag v5.9.8) and then modify the driver to build on XEN.
Linux SMMUv3 code implements the commands-queue insertion based on atomic
operations implemented
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-28368 / XSA-351
version 2
Information leak via power sidechannel
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
Activate TID3 bit in HSR register when starting a guest.
This will trap all coprecessor ID registers so that we can give to guest
values corresponding to what they can actually use and mask some
features to guests even though they would be supported by the underlying
hardware (like SVE or MPAM).
Hi Jan,
On 26/11/2020 15:18, Jan Beulich wrote:
On 26.11.2020 14:22, Julien Grall wrote:
On 26/11/2020 11:34, Jan Beulich wrote:
On 25.11.2020 20:48, Stefano Stabellini wrote:
On Wed, 25 Nov 2020, Jan Beulich wrote:
On 25.11.2020 13:15, Julien Grall wrote:
On 23/11/2020 14:23, Jan Beulich
Add support for emulation of cp15 based ID registers (on arm32 or when
running a 32bit guest on arm64).
The handlers are returning the values stored in the guest_cpuinfo
structure.
In the current status the MVFR registers are no supported.
Signed-off-by: Bertrand Marquis
---
Add vsysreg emulation for registers trapped when TID3 bit is activated
in HSR.
The emulation is returning the value stored in cpuinfo_guest structure
for most values and the hardware value for registers not stored in the
structure (those are mostly registers existing only as a provision for
Add support for cp10 exceptions decoding to be able to emulate the
values for VMFR0 and VMFR1 when TID3 bit of HSR is activated.
This is required for aarch32 guests accessing VMFR0 and VMFR1 using vmrs
and vmsr instructions.
Signed-off-by: Bertrand Marquis
---
xen/arch/arm/traps.c |
Add coprocessor registers definitions for all ID registers trapped
through the TID3 bit of HSR.
Those are the one that will be emulated in Xen to only publish to guests
the features that are supported by Xen and that are accessible to
guests.
Signed-off-by: Bertrand Marquis
---
Create a cpuinfo structure for guest and mask into it the features that
we do not support in Xen or that we do not want to publish to guests.
Modify some values in the cpuinfo structure for guests to mask some
features which we do not want to allow to guests (like AMU) or we do not
support (like
Add definition and entries in cpuinfo for ID registers introduced in
newer Arm Architecture reference manual:
- ID_PFR2: processor feature register 2
- ID_DFR1: debug feature register 1
- ID_MMFR4 and ID_MMFR5: Memory model feature registers 4 and 5
- ID_ISA6: ISA Feature register 6
Add more
The goal of this serie is to emulate coprocessor ID registers so that
Xen only publish to guest features that are supported by Xen and can
actually be used by guests.
One practical example where this is required are SVE support which is
forbidden by Xen as it is not supported, but if Linux is
flight 157020 qemu-mainline real [real]
flight 157034 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157020/
http://logs.test-lab.xenproject.org/osstest/logs/157034/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
Hi Miguel,
On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
wrote:
> On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
> > To make the intent clear, you have to first be certain that you
> > understand the intent; otherwise by adding either a break or a
> > fallthrough to suppress the warning
On 26.11.2020 14:22, Julien Grall wrote:
> On 26/11/2020 11:34, Jan Beulich wrote:
>> On 25.11.2020 20:48, Stefano Stabellini wrote:
>>> On Wed, 25 Nov 2020, Jan Beulich wrote:
On 25.11.2020 13:15, Julien Grall wrote:
> On 23/11/2020 14:23, Jan Beulich wrote:
>> I'm unconvinced of the
On Thu, Nov 26, 2020 at 03:26:35PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 26, 2020 at 03:16:08PM +0100, Manuel Bouyer wrote:
> > On Thu, Nov 26, 2020 at 02:34:44PM +0100, Roger Pau Monné wrote:
> > > On Tue, Nov 24, 2020 at 05:09:14PM +0100, Manuel Bouyer wrote:
> > > > On Tue, Nov 24, 2020
On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
>
> To make the intent clear, you have to first be certain that you
> understand the intent; otherwise by adding either a break or a
> fallthrough to suppress the warning you are just destroying the
> information that "the intent of this code
On Thu, Nov 26, 2020 at 03:16:08PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 26, 2020 at 02:34:44PM +0100, Roger Pau Monné wrote:
> > On Tue, Nov 24, 2020 at 05:09:14PM +0100, Manuel Bouyer wrote:
> > > On Tue, Nov 24, 2020 at 04:49:17PM +0100, Roger Pau Monné wrote:
> > > > Could you also give a
On Thu, Nov 26, 2020 at 02:34:44PM +0100, Roger Pau Monné wrote:
> On Tue, Nov 24, 2020 at 05:09:14PM +0100, Manuel Bouyer wrote:
> > On Tue, Nov 24, 2020 at 04:49:17PM +0100, Roger Pau Monné wrote:
> > > Could you also give a try with ioapic_ack=new on the Xen command line?
> >
> > With this I
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'dev' not described in 'frontend_changed'
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'frontend_state' not described in
Resending the stragglers.
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (8):
net: ethernet: smsc: smc91x: Demote non-conformant kernel function
header
net: xen-netback:
On Tue, Nov 24, 2020 at 05:09:14PM +0100, Manuel Bouyer wrote:
> On Tue, Nov 24, 2020 at 04:49:17PM +0100, Roger Pau Monné wrote:
> > Could you also give a try with ioapic_ack=new on the Xen command line?
>
> With this I still have the interrupt issue, but Xen doesn't panic on 'i'.
>
Hi Jan,
On 26/11/2020 11:34, Jan Beulich wrote:
On 25.11.2020 20:48, Stefano Stabellini wrote:
On Wed, 25 Nov 2020, Jan Beulich wrote:
On 25.11.2020 13:15, Julien Grall wrote:
On 23/11/2020 14:23, Jan Beulich wrote:
All of the array allocations in grant_table_init() can exceed a page's
-- Forwarded message -
Gönderen: Ganime Yalur
Date: 26 Kas 2020 Per 12:57
Subject: subscribe
To:
I Need additional help to verifiy Benchmarkresults with nginx and nee
librarys like -lwip -lpthread-embeddd
-lnewlibc .
Is this enough to set in configure Script of nginx latest
flight 157025 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157025/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 21f984cedec1c613218480bc3eb5e92349a7a812
baseline version:
ovmf
On 25.11.2020 20:48, Stefano Stabellini wrote:
> On Wed, 25 Nov 2020, Jan Beulich wrote:
>> On 25.11.2020 13:15, Julien Grall wrote:
>>> On 23/11/2020 14:23, Jan Beulich wrote:
All of the array allocations in grant_table_init() can exceed a page's
worth of memory, which xmalloc()-based
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2020年11月26日 18:55
> To: Wei Chen ; Stefano Stabellini
> Cc: Penny Zheng ; xen-devel@lists.xenproject.org;
> Andre Przywara ; Bertrand Marquis
> ; Kaly Xin ; nd
>
> Subject: Re: [PATCH] xen/arm: Add Cortex-A73 erratum 858921
On 26.11.2020 09:03, Juergen Gross wrote:
> When the host crashes it would sometimes be nice to have additional
> debug data available which could be produced via debug keys, but
> halting the server for manual intervention might be impossible due to
> the need to reboot/kexec rather sooner than
Hi Wei,
Your e-mail font seems to be different to the usual plain text one. Are
you sending the e-mail using HTML by any chance?
On 26/11/2020 02:07, Wei Chen wrote:
Hi Stefano,
-Original Message-
From: Stefano Stabellini
Sent: 2020年11月26日 8:00
To: Wei Chen
Cc: Julien Grall ;
flight 157016 xen-unstable real [real]
flight 157026 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157016/
http://logs.test-lab.xenproject.org/osstest/logs/157026/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Wed, Nov 25, 2020 at 05:11:07PM -0800, Minchan Kim wrote:
> With this patch, how deal with the race?
>
> CPU 1 CPU 2
>
> hot_remove_store
> zram_remove
> zram_busy
> return -EBUSY
> open /dev/zram0
>
flight 157022 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
> On 25 Nov 2020, at 18:21, Rahul Singh wrote:
>
> Hello Julien,
>
>> On 25 Nov 2020, at 6:16 pm, Rahul Singh wrote:
>>
>> The NS16550 driver is assuming that NS16550 PCI card are usable if the
>> architecture supports PCI (i.e. CONFIG_HAS_PCI=y). However, the code is
>> very x86 focus and
> On 25 Nov 2020, at 18:16, Rahul Singh wrote:
>
> If mem-sharing, mem-paging, or log-dirty functionality is not enabled
> for architecture when HAS_PCI is enabled, the compiler will throw an
> error.
>
> Move code to x86 specific file to fix compilation error.
>
> Also, modify the code to
> On 25 Nov 2020, at 18:16, Rahul Singh wrote:
>
> passthrough/pci.c file is common for all architecture, but there is x86
> specific code in this file.
>
> Move x86 specific code to the drivers/passthrough/io.c file to avoid
> compilation error for other architecture.
>
> As
When the host crashes it would sometimes be nice to have additional
debug data available which could be produced via debug keys, but
halting the server for manual intervention might be impossible due to
the need to reboot/kexec rather sooner than later.
Add support for automatic debug key actions
53 matches
Mail list logo
