flight 156554 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156554/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
baseline version:
xen 7056
flight 156538 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156538/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-start fail REGR. vs. 156443
test-amd64-i386-li
flight 156540 qemu-upstream-unstable real [real]
flight 156559 qemu-upstream-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156540/
http://logs.test-lab.xenproject.org/osstest/logs/156559/
Regressions :-(
Tests which did not succeed and are blocking,
including tests
flight 156545 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156545/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1366cd58cd4459f00b4ecf5abed13e77ac4ad06c
baseline version:
ovmf dc0dae2d18d4b6f904e99
flight 156543 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156543/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow219 guest-localmigrate/x10 fail like 136311
test-armhf-armhf-libvi
When device is removed, backend domain (which may be a driver domain) is
responsible for removing backend entries from xenstore. But in case of
driver domain, it has no access to remove all of them - specifically the
directory named after frontend-id remains. This may accumulate enough to
exceed xe
On 06/11/20 20:03, Christoph Hellwig wrote:
revalidate_disk_size just updates the block device size from the disk
size. Thus calling it from revalidate_disk_size doesn't actually do
s/revalidate_disk_size/virtblk_update_cache_mode/
anything.
flight 156549 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156549/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Mon, 2 Nov 2020 15:42:50 +0100
Mauro Carvalho Chehab wrote:
> Em Mon, 2 Nov 2020 13:46:41 +0100
> Greg Kroah-Hartman escreveu:
>
> > On Mon, Nov 02, 2020 at 12:04:36PM +0100, Fabrice Gasnier wrote:
> > > On 10/30/20 11:09 AM, Mauro Carvalho Chehab wrote:
> > > > Em Fri, 30 Oct 2020 10:
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-xsm
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.or
On 10/31/20 11:25 AM, Thomas Huth wrote:
> On 30/10/2020 18.13, Paolo Bonzini wrote:
>> On 30/10/20 12:35, Eduardo Habkost wrote:
>>>
>>> What is necessary to make sure we have a CONFIG_XEN=y job in
>>> gitlab CI? Maybe just including xen-devel in some of the
>>> container images is enough?
>>
>>
flight 156547 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156547/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR.
vs. 152332
test-amd
Xen packages are available in CentOS 7, but have been
removed from CentOS 8. Use the CentOS 7 container.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Eduardo Habkost
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: xen-devel@lists.xenproject.org
---
.gitlab-ci.yml | 21 +++
flight 156552 qemu-mainline real [real]
flight 156573 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156552/
http://logs.test-lab.xenproject.org/osstest/logs/156573/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 156556 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-start fail REGR. vs. 156443
test-amd64-amd64-x
flight 156560 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156560/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 156301
test-amd64-amd64-qemuu-nes
On 07.11.20 02:11, Brian Masney wrote:
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/0x60
...
Hardware name: Xen HVM
On 09.11.20 03:09, osstest service owner wrote:
flight 156556 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-start
Hello, Rahul!
On 11/6/20 4:41 PM, Rahul Singh wrote:
Hello Oleksandr,
On 6 Nov 2020, at 2:22 pm, Oleksandr Andrushchenko
wrote:
Hi, Rahul!
On 11/6/20 3:58 PM, Rahul Singh wrote:
Hello Oleksandr,
On 6 Nov 2020, at 1:00 pm, Oleksandr Andrushchenko
wrote:
Hello, Rahul!
On 11/6/20 2:48
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabling interrupts for
taking the lock.
The lock is needed f
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen the
event needs to change queues and the old queue needs to be kept for
keeping the links between queue elements intact. For this purpose
the event channel contains last_prior
The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.
Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has been changed for a specific event channel.
The second patch is modifying the per ev
Hi Oleksandr,
> -Original Message-
> From: Xen-devel On Behalf Of
> Oleksandr Tyshchenko
> Sent: 2020年10月16日 0:45
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Ian Jackson
> ; Wei Liu ; Anthony PERARD
> ; Julien Grall ; Stefano Stabellini
>
> Subject: [PATCH V2 23/23]
On Fri, Nov 6, 2020 at 8:04 PM Christoph Hellwig wrote:
>
> Use set_capacity_and_notify to set the size of both the disk and block
> device. This also gets the uevent notifications for the resize for free.
>
> Signed-off-by: Christoph Hellwig
Thanks, Christoph!
Acked-by: Jack Wang
> ---
> driv
flight 156569 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156569/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR.
vs. 152332
test-amd
flight 156579 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 11/6/20 8:03 PM, Christoph Hellwig wrote:
There is no good reason to call revalidate_disk_size separately.
Signed-off-by: Christoph Hellwig
---
drivers/nvme/host/core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/cor
27 matches
Mail list logo