[PATCH v5 2/2] xen/arm: vpl011: add ASSERT_UNREACHABLE in vpl011_mmio_read

In vpl011_mmio_read switch block, all cases should have a return. Add ASSERT_UNREACHABLE to catch case where the return is not added. Signed-off-by: Jiamei Xie --- v4 -> v5 - don't remove "return 1" and add ASSERT_UNREACHABLE v3 -> v4 - Don't consolidate check registers access - Don't remove labe

[PATCH v5 1/2] xen/arm: vpl011: emulate non-SBSA registers as WI/RAZ

When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", Linux SBSA PL011 driver will access PL011 DMACR register in some functions. As chapter "B Generic UART" in "ARM Server Base System Architecture"[1] documentation describes, SBSA UART doesn't support DMA. In current code, when the

[PATCH v5 0/2] xen/arm: refine vpl011

This patch is the version 5 for "xen/arm: vpl011: Make access to DMACR write-ignore" [1]. [1] https://patchwork.kernel.org/project/xen-devel/patch/20221122054644.1092173-1-jiamei@arm.com/ Thanks, Jiamei Xie v4 -> v5 - don't remove "return 1" and add ASSERT_UNREACHABLE v3 -> v4 - remove the

[qemu-mainline test] 175043: tolerable FAIL - PUSHED

flight 175043 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175043/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174993 test-armhf-armhf-libvirt 16 sav

Re: [PATCH V6 2/3] xl: Add support to parse generic virtio device

On 02-12-22, 19:16, Oleksandr Tyshchenko wrote: > Interesting, I see you allow user to configure virtio-mmio params (irq and > base), as far as I remember for virtio-disk these are internal only > (allocated by tools/libs/light/libxl_arm.c). It is a mistake. Will drop it. -- viresh

Re: [PATCH V6 1/3] libxl: Add support for generic virtio device

Hi Oleksandr, On 02-12-22, 16:52, Oleksandr Tyshchenko wrote: > > This patch adds basic support for configuring and assisting generic > > Virtio backend which could run in any domain. > > > > An example of domain configuration for mmio based Virtio I2C device is: > > virtio = ["type=virtio,device

[linux-linus test] 175042: regressions - FAIL

flight 175042 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175042/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-xl

[ovmf test] 175045: all pass - PUSHED

flight 175045 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175045/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 735a7496cb35e48ccad51aad0934844a475e3fef baseline version: ovmf 7de1c71dd2f4e04bd832f

[PATCH 2/3] xen/arm: Extend the memory overlap check to include bootmodules

Similarly as the static regions defined in bootinfo.reserved_mem, the bootmodule regions defined in bootinfo.modules should also not be overlapping with memory regions in either bootinfo.reserved_mem or bootinfo.modules. Therefore, this commit extends the check in function `check_reserved_regions_

[PATCH 3/3] xen/arm: Extend the memory overlap check to include EfiACPIReclaimMemory

Similarly as the static regions and boot modules, memory regions with EfiACPIReclaimMemory type (defined in bootinfo.acpi if CONFIG_ACPI is enabled) should also not be overlapping with memory regions in bootinfo.reserved_mem and bootinfo.modules. Therefore, this commit further extends the check in

[PATCH 1/3] xen/arm: Add memory overlap check for bootinfo.reserved_mem

As we are having more and more types of static region, and all of these static regions are defined in bootinfo.reserved_mem, it is necessary to add the overlap check of reserved memory regions in Xen, because such check will help user to identify the misconfiguration in the device tree at the early

[PATCH 0/3] Memory region overlap check in device tree

As we are having more and more types of memory region defined in the device tree, it is necessary to add the overlap check of these memory regions in Xen, because such check will help user to identify the misconfiguration in the device tree at the early stage of boot time. The first patch introduc

[linux-linus test] 175041: regressions - FAIL

flight 175041 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175041/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-xl

Re: [PATCH V6 3/3] docs: Add documentation for generic virtio devices

On 08.11.22 13:24, Viresh Kumar wrote: Hello Viresh [sorry for the possible format issues if any] This patch updates xl.cfg man page with details of generic Virtio device related information. So as I understand current series adds support for two virtio devices (i2c/gpio) that require

[xen-unstable test] 175040: tolerable FAIL

flight 175040 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175040/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-examine-uefi 6 xen-install fail in 175037 pass in 175040 test-amd64-i386-pair 11

[linux-linus test] 175038: regressions - FAIL

flight 175038 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175038/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-xl