flight 172292 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
> On 5 Aug 2022, at 19:06, Andrew Cooper wrote:
>
> On 29/07/2022 18:53, Edwin Török wrote:
>> Add a finalizer on the event channel value, so that it calls
>> `xenevtchn_close` when the value would be GCed.
>>
>> In practice oxenstored seems to be the only user of this,
>> and it creates a sin
Hi Julien,
> On 5 Aug 2022, at 5:14 pm, Julien Grall wrote:
>
>
>
> On 05/08/2022 17:10, Rahul Singh wrote:
>> Hi ,
>
> Hi Rahul,
>
>>> On 22 Jun 2022, at 3:38 pm, Rahul Singh wrote:
>>>
>>> Introduce a new sub-node under /chosen node to establish static event
>>> channel communication bet
In macro psr_mode(), the macro parameter 'm' is used as expression and
therefore it is good to be enclosed in parentheses to prevent against
unintended expansions.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/arm/include/asm/regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
flight 172294 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172294/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
On 08/08/2022 09:28, Edwin Torok wrote:
>> On 5 Aug 2022, at 19:06, Andrew Cooper wrote:
>>
>> On 29/07/2022 18:53, Edwin Török wrote:
>>> +};
>>>
>>> CAMLprim value stub_eventchn_init(void)
>>> {
>>> @@ -48,7 +71,9 @@ CAMLprim value stub_eventchn_init(void)
>>> if (xce == NULL)
>>>
On 03.08.22 11:25, Jan Beulich wrote:
On 02.08.2022 15:27, Juergen Gross wrote:
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3190,6 +3190,66 @@ out:
return ret;
}
+static struct cpu_rm_data *schedule_cpu_rm_alloc(unsigned int cpu)
+{
+struct cpu_rm_data *data;
flight 172291 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
On 03.08.22 11:53, Jan Beulich wrote:
On 02.08.2022 15:36, Juergen Gross wrote:
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -419,6 +419,8 @@ static int cpupool_alloc_affin_masks(struct affinity_masks
*masks)
return 0;
free_cpumask_var(masks->hard);
+
Hi Xenia,
> On 8 Aug 2022, at 10:48 am, Xenia Ragiadakou wrote:
>
> In macro psr_mode(), the macro parameter 'm' is used as expression and
> therefore it is good to be enclosed in parentheses to prevent against
> unintended expansions.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Rahul Si
Hi Juergen,
On 08/08/2022 07:33, Juergen Gross wrote:
On 04.08.22 21:28, Julien Grall wrote:
On 03/08/2022 12:59, Juergen Gross wrote:
Extend the definition of the Xenstore migration stream to cover new
features:
- per domain features
- extended watches (watch depth)
- per domain quota
Signe
"-sdl" is deprecated upstream since 6695e4c0fd9e ("softmmu/vl:
Deprecate the -sdl and -curses option"), QEMU v6.2, and the option is
removed by 707d93d4abc6 ("ui: Remove deprecated options "-sdl" and
"-curses""), in upcoming QEMU v7.1.
Instead, use "-display sdl", available since 1472a95bab1e ("In
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.qemu-deprecated-soundhw-v1
Hi,
There's some more QEMU options that are deprecated. We still don't need to
figure out which QEMU version we are going to run as the options that replace
t
-soundhw is deprecated since 825ff02911c9 ("audio: add soundhw
deprecation notice"), QEMU v5.1, and is been remove for upcoming v7.1
by 039a68373c45 ("introduce -audio as a replacement for -soundhw").
Instead we can just add the sound card with "-device", for most option
that "-soundhw" could hand
On 08.08.22 13:00, Julien Grall wrote:
Hi Juergen,
On 08/08/2022 07:33, Juergen Gross wrote:
On 04.08.22 21:28, Julien Grall wrote:
On 03/08/2022 12:59, Juergen Gross wrote:
Extend the definition of the Xenstore migration stream to cover new
features:
- per domain features
- extended watches
flight 172290 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172296 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
flight 172287 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172287/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-shadow 7 xen-install fail in 172262 pass in 172287
test-amd64-amd64-xl-qemut-stubdo
flight 172299 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
On 05.08.22 18:43, Rahul Singh wrote:
Hello Rahul
Thank you very much for that patch!
From: Oleksandr Andrushchenko
I am not 100% sure regarding that. This is *completely* different patch
from what Oleksandr initially made here:
https://lore.kernel.org/xen-devel/20220719174253.54196
On Fri, Jul 22, 2022 at 01:30:53PM +, Luca Fancellu wrote:
> > On 24 Jun 2022, at 17:04, Anthony PERARD wrote:
> > .PHONY: uninstall
> > uninstall:
> > rm -f $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/, $(LIBBIN))
> > rm -f $(addprefix $(DESTDIR)$(bindir)/, $(SCRIPTS))
> > rm -f $(addpre
flight 172301 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172301/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
flight 172302 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172302/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
flight 172293 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 38 ++
This patch modified the test in the following way
- Dom0 is booted with an alpine linux rootfs with the xen tools.
- Once Dom0 is booted, it starts xenstored, calls init-dom0less to setup
the xenstore interface for the dom0less Dom1, setups the bridged network
and attaches a pv network interface to
Xenia Ragiadakou (2):
automation: qemu-smoke-arm64: Use kernel 5.19
automation: qemu-smoke-arm64: Run ping test over a pv network
interface
automation/gitlab-ci/build.yaml | 11 +
automation/gitlab-ci/test.yaml| 10 +++--
automation/scripts/qemu-smoke-arm
Use kernel 5.19 to unblock testing dom0less enhanced.
This kernel version has the necessary patches for deferring xenbus probe
until xenstore is fully initialized.
Also, build kernel with bridging and xen netback support enabled because
it will be used for testing network connectivity between Dom0
flight 172298 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172298/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
make_virtio_mmio_node() creates the DT node for simple MMIO devices
currently, i.e. the ones that don't require any additional properties.
In order to allow using it for other complex device types, split the
functionality into two, one wher
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-virti
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-v
On 04.08.22 10:01, Viresh Kumar wrote:
Hello,
Hello Viresh
This patchset adds toolstack support for I2C and GPIO virtio devices. This is
inspired from the work done by Oleksandr for the Disk device.
This is developed as part of Linaro's Project Stratos, where we are working
towards Hyper
flight 172306 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
On Mon, 8 Aug 2022, Xenia Ragiadakou wrote:
> Xenia Ragiadakou (2):
> automation: qemu-smoke-arm64: Use kernel 5.19
> automation: qemu-smoke-arm64: Run ping test over a pv network
> interface
>
> automation/gitlab-ci/build.yaml | 11 +
> automation/gitlab-ci/test.yaml
flight 172309 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172309/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
flight 172305 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172305/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
flight 172311 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172311/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
flight 172310 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172310/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
flight 172314 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
On 08-08-22, 21:39, Oleksandr wrote:
>
> On 04.08.22 10:01, Viresh Kumar wrote:
>
> Hello Viresh
>
>
> > Create a separate routine to allocate base and irq for a device as the
> > same code will be required for each device type.
> >
> > Suggested-by: Oleksandr Tyshchenko
> > Signed-off-by: Vi
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-i2c backend (emualator) which is intended to run out of
Qemu and could be run in any domain.
An example of domain configuration for Virtio I2c:
i2c = [ "" ]
Please note, this patch is not enough for virtio-i2c to
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-gpio backend (emualator) which is intended to run out of
Qemu and could be run in any domain.
An example of domain configuration for Virtio Gpio:
gpio = [ "" ]
Please note, this patch is not enough for virtio-gpi
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 41 +++-
1 file changed, 26 insertions(+), 15
make_virtio_mmio_node() creates the DT node for simple MMIO devices
currently, i.e. the ones that don't require any additional properties.
In order to allow using it for other complex device types, split the
functionality into two, one where the fdt node isn't closed and the
other one to create a
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs/light
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs/li
Hello,
This patchset adds toolstack support for I2C and GPIO virtio devices. This is
inspired from the work done by Oleksandr for the Disk device.
This is developed as part of Linaro's Project Stratos, where we are working
towards Hypervisor agnostic Rust based backend [1].
This is based of orig
On 09-08-22, 09:59, Viresh Kumar wrote:
> There is only one use of virtio_enabled after this patch, i.e. do
> check for vpl011. Maybe we can drop the variable and use
> virtio_mmio_irq != GUEST_VIRTIO_MMIO_SPI_FIRST ?
Nevermind, after modifying code I decided to keep the variable
instead.
--
vir
flight 172316 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136
build-i386-libvirt
flight 172307 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
On 08.08.2022 12:21, Juergen Gross wrote:
> On 03.08.22 11:53, Jan Beulich wrote:
>> On 02.08.2022 15:36, Juergen Gross wrote:
>>> switch ( action )
>>> {
>>> case CPU_DOWN_FAILED:
>>> +if ( system_state <= SYS_STATE_active )
>>> +{
>>> +if ( mem )
>>>
On 05.08.2022 17:49, Marek Marczykowski-Górecki wrote:
> On Fri, Aug 05, 2022 at 10:15:59AM +0200, Jan Beulich wrote:
>> On 26.07.2022 05:23, Marek Marczykowski-Górecki wrote:
>>> That's possible, because the capability was designed specifically to
>>> allow separate driver handle it, in parallel t
53 matches
Mail list logo
