flight 165349 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165349/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 61e6f40b07d256bd62ae7b231a3eeecd49d0b15b
baseline version:
xtf 91d215a4ed1463ab14d1f6
Hi Stefano,
> On 5 Oct 2021, at 1:38 am, Stefano Stabellini wrote:
>
> On Mon, 4 Oct 2021, Rahul Singh wrote:
>> The existing VPCI support available for X86 is adapted for Arm.
>> When the device is added to XEN via the hyper call
>> “PHYSDEVOP_pci_device_add”, VPCI handler for the config space
Hi Stefano,
> On 5 Oct 2021, at 1:57 am, Stefano Stabellini wrote:
>
> I committed patches #1, #4, #5 of this series
>
Thank you.
Regards,
Rahul
On Tue, 5 Oct 2021, 01:46 Stefano Stabellini,
wrote:
>
> Given that only ARM needs the !CONFIG_HAS_PCI stub, I would add it
> directly to xen/arch/arm/physdev.c. Or just add an #ifdef directly
> within do_physdev_op in xen/arch/arm/physdev.c.
If we want to keep the stub, then it should be the g
flight 165347 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165347/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4cc1458dbe004b1d70534caa55f475f6d19fe14a
baseline version:
ovmf 442e46d3b6c1931b54111
On 04.10.21 11:14, Marek Marczykowski-Górecki wrote:
On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote:
On 03.10.21 06:47, Marek Marczykowski-Górecki wrote:
Hi,
After updating a PVH domU to 5.4.150, I see xen-balloon thread using
100% CPU (one thread).
This is a domain started with
Hi Stefano,
> On 5 Oct 2021, at 12:46 am, Stefano Stabellini wrote:
>
> On Mon, 4 Oct 2021, Rahul Singh wrote:
>> Hardware domain is in charge of doing the PCI enumeration and will
>> discover the PCI devices and then will communicate to XEN via hyper
>> call PHYSDEVOP_pci_device_add(..) to add
flight 165373 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165373/
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
flight 165346 linux-5.4 real [real]
flight 165375 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165346/
http://logs.test-lab.xenproject.org/osstest/logs/165375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
Hi Stefano,
> On 5 Oct 2021, at 1:38 am, Stefano Stabellini wrote:
>
> On Mon, 4 Oct 2021, Rahul Singh wrote:
>> libxl will create an emulated PCI device tree node in the device tree to
>> enable the guest OS to discover the virtual PCI during guest boot.
>> Emulated PCI device tree node will on
flight 165348 linux-linus real [real]
flight 165376 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165348/
http://logs.test-lab.xenproject.org/osstest/logs/165376/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Branch Harden is enabled by default at compile and boot time. Invert the code
to compile with lfence by default and nop out in the non-default case.
This has several advantages. It removes 3829 patch points (in the random
build of Xen I have to hand) by default on boot, 70% (!) of the
.altinstr_
As so often with virtio-mem changes that mess with common MM
infrastructure, this might be a good candiate to go via Andrew's tree.
--
After removing /dev/kmem, sanitizing /proc/kcore and handling /dev/mem,
this series tackles the last sane way how a VM could accidentially access
logically unplug
The callback is only used for the vmcore nowadays.
Reviewed-by: Boris Ostrovsky
Signed-off-by: David Hildenbrand
---
arch/x86/xen/mmu_hvm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
index 57409373750f..b242d1f4b4
Let's simplify return handling.
Signed-off-by: David Hildenbrand
---
arch/x86/xen/mmu_hvm.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
index b242d1f4b426..d1b38c77352b 100644
--- a/arch/x86/xen/mmu_hvm.c
+++
HVMOP_get_mem_type is not expected to fail, "This call failing is
indication of something going quite wrong and it would be good to know
about this." [1]
Let's add a pr_warn_once().
[1] https://lkml.kernel.org/r/3b935aa0-6d85-0bcd-100e-15098add3...@oracle.com
Suggested-by: Boris Ostrovsky
Signe
The callback should deal with errors internally, it doesn't make sense to
expose these via pfn_is_ram(). We'll rework the callbacks next. Right now
we consider errors as if "it's RAM"; no functional change.
Signed-off-by: David Hildenbrand
---
fs/proc/vmcore.c | 8
1 file changed, 4 ins
Let's support multiple registered callbacks, making sure that
registering vmcore callbacks cannot fail. Make the callback return a
bool instead of an int, handling how to deal with errors internally.
Drop unused HAVE_OLDMEM_PFN_IS_RAM.
We soon want to make use of this infrastructure from other dri
Let's prepare for a new virtio-mem kdump mode in which we don't actually
hot(un)plug any memory but only observe the state of device blocks.
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 81 -
1 file changed, 44 insertions(+), 37 deletions
Let's prepare for a new virtio-mem kdump mode in which we don't actually
hot(un)plug any memory but only observe the state of device blocks.
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 87 +++--
1 file changed, 45 insertions(+), 42 deletions
Let's prepare for a new virtio-mem kdump mode in which we don't actually
hot(un)plug any memory but only observe the state of device blocks.
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers
Although virtio-mem currently supports reading unplugged memory in the
hypervisor, this will change in the future, indicated to the device via
a new feature flag. We similarly sanitized /proc/kcore access recently. [1]
Let's register a vmcore callback, to allow vmcore code to check if a PFN
belong
On Tue, Oct 05, 2021 at 10:05:39AM +0200, Juergen Gross wrote:
> On 04.10.21 11:14, Marek Marczykowski-Górecki wrote:
> > On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote:
> > > On 03.10.21 06:47, Marek Marczykowski-Górecki wrote:
> > > > Hi,
> > > >
> > > > After updating a PVH domU
On Tue, Oct 5, 2021 at 4:05 AM Juergen Gross wrote:
>
> On 04.10.21 11:14, Marek Marczykowski-Górecki wrote:
> > On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote:
> >> On 03.10.21 06:47, Marek Marczykowski-Górecki wrote:
> >>> Hi,
> >>>
> >>> After updating a PVH domU to 5.4.150, I se
In case a ballooning action is cancelled the new kernel thread handling
the ballooning might end up in a busy loop.
Fix that by handling the cancelled action gracefully.
While at it introduce a short wait for the BP_WAIT case.
Cc: sta...@vger.kernel.org
Fixes: 8480ed9c2bbd56 ("xen/balloon: use a
flight 165377 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165377/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c49cb8f30e6223dc6b55903af178afa1dfde857f
baseline version:
ovmf 4cc1458dbe004b1d70534
flight 165371 xen-unstable real [real]
flight 165381 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165371/
http://logs.test-lab.xenproject.org/osstest/logs/165381/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28702 / XSA-386
PCI devices with RMRRs not deassigned correctly
ISSUE DESCRIPTION
=
Certain PCI devices in a system might be assigned Reserved Memory
Regions (specified via Res
On 10/5/21 8:14 AM, David Hildenbrand wrote:
> Let's simplify return handling.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Boris Ostrovsky
On 10/5/21 8:14 AM, David Hildenbrand wrote:
> HVMOP_get_mem_type is not expected to fail, "This call failing is
> indication of something going quite wrong and it would be good to know
> about this." [1]
>
> Let's add a pr_warn_once().
>
> [1] https://lkml.kernel.org/r/3b935aa0-6d85-0bcd-100e-15
On 30.09.21 01:52, Oleksandr Tyshchenko wrote:
Hi Stefano, Julien.
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the dom
On 05.10.21 00:11, Stefano Stabellini wrote:
Hi Stefano
On Sat, 2 Oct 2021, Oleksandr wrote:
On 02.10.21 10:35, Julien Grall wrote:
Thank you for your comments!
Hi
On Sat, 2 Oct 2021, 01:24 Stefano Stabellini,
wrote:
Bertrand, see comment on ID_AA64MMFR0_EL1 below,
On Mon, 4 Oct 2021, Stefano Stabellini wrote:
> On Tue, 5 Oct 2021, Ian Jackson wrote:
> > i...@xenbits.xen.org writes ("[adhoc test] 165359: tolerable truncated"):
> > > [adhoc play]
> > > harness 3a3089c9: mfi-common: Drop Linux dom0 i386 tests for newer Lin...
> > > 165359: tolerable truncated
Juergen Gross, le lun. 04 oct. 2021 16:19:23 +0200, a ecrit:
> CONFIG_GC is requiring external support, so disable it in testbuilds.
>
> The only reason this is working right now is its usage being inside
> a HAVE_LIBC section.
>
> Make that more obvious by making the default setting of CONFIG_XC
Juergen Gross, le lun. 04 oct. 2021 16:19:24 +0200, a ecrit:
> Today close hooks into libxenctrl, libxenevtchn and libxengnttab are
> under the CONFIG_XC umbrella. In order to support Mini-OS builds using
> stable Xen libraries only, add CONFIG_LIBXENCTRL, CONFIG_LIBXENEVTCHN
> and CONFIG_LIBXENGNT
On Tue, 5 Oct 2021, Rahul Singh wrote:
> > On 5 Oct 2021, at 1:38 am, Stefano Stabellini
> > wrote:
> >
> > On Mon, 4 Oct 2021, Rahul Singh wrote:
> >> libxl will create an emulated PCI device tree node in the device tree to
> >> enable the guest OS to discover the virtual PCI during guest boot.
flight 165374 qemu-mainline real [real]
flight 165389 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165374/
http://logs.test-lab.xenproject.org/osstest/logs/165389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Tue, 5 Oct 2021, Oleksandr wrote:
> > From: Oleksandr Tyshchenko
> >
> > The extended region (safe range) is a region of guest physical
> > address space which is unused and could be safely used to create
> > grant/foreign mappings instead of wasting real RAM pages from
> > the domain memory f
On Tue, 5 Oct 2021, Oleksandr Andrushchenko wrote:
> On 05.10.21 04:24, Stefano Stabellini wrote:
> > On Mon, 4 Oct 2021, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> PCI host bridges are special devices in terms of implementing PCI
> >> passthrough. According to [1]
flight 165383 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165383/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Fam,
Patchew is not applying patches any longer from xen-devel. Would you be
able to look into the issue? We are only 2 weeks away from the Xen 4.16
code freeze; it would be great to have Patchew working (the underlying
gitlab-ci tests are known to work.) If you can't look into it at the
moment
flight 165378 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 165206
Tests which are faili
On 10/5/21 9:34 AM, Juergen Gross wrote:
> In case a ballooning action is cancelled the new kernel thread handling
> the ballooning might end up in a busy loop.
>
> Fix that by handling the cancelled action gracefully.
>
> While at it introduce a short wait for the BP_WAIT case.
>
> Cc: sta...@vg
flight 165379 linux-linus real [real]
flight 165393 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165379/
http://logs.test-lab.xenproject.org/osstest/logs/165393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On 06.10.21 00:43, Stefano Stabellini wrote:
> On Tue, 5 Oct 2021, Oleksandr Andrushchenko wrote:
>> On 05.10.21 04:24, Stefano Stabellini wrote:
>>> On Mon, 4 Oct 2021, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
PCI host bridges are special devices in terms of i
flight 165382 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165382/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 942c9bd357d87cc6eed7c8250c213eff218d674e
baseline version:
ovmf c49cb8f30e6223dc6b559
xen_pvh_init() is lacking a prototype in a header, add it.
Reported-by: kernel test robot
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/hypervisor.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/include/asm/xen/hypervisor.h
b/arch/x86/include/asm/xen/hypervisor.h
47 matches
Mail list logo