[ovmf test] 162972: regressions - FAIL
flight 162972 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162972/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf d9a7612f8d1da197883bd1cb9f91f229522d39b1 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 19 days Failing since162368 2021-06-04 15:42:59 Z 18 days 39 attempts Testing same since 162972 2021-06-22 11:39:57 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Daoxiang Li gaoliming Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Maurice Ma Ni, Ray Patrick Rudolph Ray Ni Rebecca Cran Scottie Kuo Sean Brogan Sean Brogan Sumana Venur Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2211 lines long.)
[linux-linus test] 162968: regressions - FAIL
flight 162968 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/162968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 13 debian-fixup fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl 13 debian-fixup fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15
Re: Windows 10 Kernel Debugging on Xen
I figured it out. Microsoft did not document that testsigning needs to be enabled for kdnet to work. On Tue, Jun 22, 2021 at 2:12 PM Tamas K Lengyel wrote: > Make sure windbg is already waiting for the connection from the > debugee by the time Windows starts booting. If you try to attach > windbg later it won't work. It worked for me but obviously YMMV. > > Tamas > > On Tue, Jun 22, 2021 at 2:07 PM Neil Sikka wrote: > > > > I tried that, but it seems like I'm getting an interrupt storm on the > debugger VM (CPU spends all its time in the kernel) when I try to attach > the debugger. This observation furthers my suspicion that there is > communication, but there is something wrong with the protocol... > > > > On Tue, Jun 22, 2021 at 12:43 PM Tamas K Lengyel < > tamas.k.leng...@gmail.com> wrote: > >> > >> I used Xen 4.15 and a pretty new version of Windows 10. It is a bit > >> finicky, you have to run the debug commands on the debugee and then > >> reboot. When the VM is rebooting the domain ID changes so you have to > >> start the serial bridge then. Windbg will attach afterwards. Just make > >> sure both VMs have serial='pty' set in their config file. > >> > >> Tamas > >> > >> On Tue, Jun 22, 2021 at 12:33 PM Neil Sikka > wrote: > >> > > >> > Thanks for the quick response, Tamas. I tried what you said and > windbg waits and the debugee hangs when I click the break button in windbg, > but I don't see any output in windbg. This means that there is SOME > communication over the serial port that causes the debugee to hang when I > click break. Could it be a debugger protocol issue? I also tried the > guidance here by running the crlf program: > >> > https://www.qubes-os.org/doc/windows-debugging/ > >> > But windbg waits and the debugee hangs in a similar manner. > >> > > >> > What versions of WIndows and Xen are you using? > >> > > >> > On Tue, Jun 22, 2021 at 12:10 PM Tamas K Lengyel < > tamas.k.leng...@gmail.com> wrote: > >> >> > >> >> I have managed to get windbg working with a serial bridge between two > >> >> Win10 VMs using the following script: > >> >> > https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/serial-bridge.sh > . > >> >> The debugee has to enable a couple options so that windbg can attach: > >> >> > https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/debug.cmd > . > >> >> > >> >> Tamas > >> >> > >> >> On Tue, Jun 22, 2021 at 12:01 PM Neil Sikka > wrote: > >> >> > > >> >> > Hello, > >> >> > Has anyone gotten a Windows10 (Version 1709 of later) kernel > debugger attached when running the Windows10 debugger VM and the Windows10 > debugee VM on Xen 4.13.0 hypervisor? I am getting a "NIC hardware > initialization failed" error. I tried the suggestions in the discussion > here (https://bugzilla.redhat.com/show_bug.cgi?id=1947015): > >> >> > -cpu > Skylake-Server-IBRS,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,amd-ssbd=on, > \ > >> >> > > skip-l1dfl-vmentry=on,mpx=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KVMKVMKVM > >> >> > > >> >> > note: i had to remove the following 2 arguments due to errors from > QEMU: > >> >> > pschange-mc-no=on > >> >> > hv_vpindex > >> >> > > >> >> > Here was the error: > >> >> > C:\Users\user\Desktop\oldDebuggers\x64>kdnet.exe > >> >> > > >> >> > Network debugging is supported on the following NICs: > >> >> > busparams=0.4.0, Intel(R) PRO/1000 MT Network Connection, Plugged > in. > >> >> > The Microsoft hypervisor running this VM does not support KDNET. > >> >> > Please upgrade to the hypervisor shipped in Windows 8 or WS2012 or > later. > >> >> > > >> >> > KDNET initialization failed. Status = 0xC182. > >> >> > NIC hardware initialization failed. > >> >> > > >> >> > I am using an Intel e1000 NIC emulated through QEMU because its > supposedly a supported NIC for Windows kernel NET debugging. > >> >> > > >> >> > Thanks in Advance! > >> >> > > >> >> > -- > >> >> > My Blog: http://www.neilscomputerblog.blogspot.com/ > >> >> > Twitter: @neilsikka > >> > > >> > > >> > > >> > -- > >> > My Blog: http://www.neilscomputerblog.blogspot.com/ > >> > Twitter: @neilsikka > > > > > > > > -- > > My Blog: http://www.neilscomputerblog.blogspot.com/ > > Twitter: @neilsikka > -- My Blog: http://www.neilscomputerblog.blogspot.com/ Twitter: @neilsikka
Re: smmuv1 breakage
Hi Rahul, Do you have an opinion on how we should move forward on this? Do you think it is OK to go for a full revert of "xen/arm: smmuv1: Intelligent SMR allocation" or do you think it is best to go with an alternative fix? If so, do you have something in mind? On Tue, 15 Jun 2021, Stefano Stabellini wrote: > On Tue, 15 Jun 2021, Rahul Singh wrote: > > Hi Stefano > > > > > On 15 Jun 2021, at 3:21 am, Stefano Stabellini > > > wrote: > > > > > > Hi Rahul, > > > > > > Unfortunately, after bisecting, I discovered a few more breakages due to > > > your smmuv1 series (commits e889809b .. 3e6047ddf) on Xilinx ZynqMP. I > > > attached the DTB as reference. Please note that I made sure to > > > cherry-pick "xen/arm: smmuv1: Revert associating the group pointer with > > > the S2CR" during bisection. So the errors are present also on staging. > > > > > > The first breakage is an error at boot time in smmu.c#find_smmu_master, > > > see log1. I think it is due to the lack of ability to parse the new smmu > > > bindings in the old smmu driver. > > > > > > After removing all the "smmus" and "#stream-id-cells" properties in > > > device tree, I get past the previous error, everything seems to be OK at > > > early boot, but I actually get SMMU errors as soon as dom0 starting > > > using devices: > > > > > > (XEN) smmu: /smmu@fd80: Unexpected global fault, this could be serious > > > (XEN) smmu: /smmu@fd80: GFSR 0x8002, GFSYNR0 0x, > > > GFSYNR1 0x0877, GFSYNR2 0x > > > > This fault is "Unidentified stream fault” for StreamID “ 0x877” that means > > SMMU SMR is not configured for streamID “0x877" > > > > > > > [ 10.419681] macb ff0e.ethernet eth0: DMA bus error: HRESP not OK > > > [ 10.426452] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > > > Do you think you'll be able to help fix them? > > > > > > > > > You should be able to reproduce the two issues using Xilinx QEMU (but to > > > be honest I haven't tested it on QEMU yet, I was testing on real > > > hardware): > > > - clone and compile xilinx QEMU https://github.com/Xilinx/qemu.git > > > ./configure --target-list=aarch64-softmmu > > > make > > > - clone and build git://github.com/Xilinx/qemu-devicetrees.git > > > - use the attached script to run it > > >- kernel can be upstream defconfig 5.10 > > > > > > > I tried to reproduce the issue on Xilinx QEMU as per the steps shared above > > but I am not observing any issue on Xilinx QEMU. > > I tried on QEMU and it doesn't repro. I cannot explain why it works on > QEMU and it fails on real hardware. > > > > I also tested and confirmed on QEMU that SMMU is configured correctly > > for specifically StreamID “ 0x877” and for other streamIDs. > > > > I check the xen.dtb shared by you and found out the there is no > > "stream-id-cells” > > property in the master device but the "mmu-masters" property is present in > > the > > smmu node. For legacy smmu binding we need both "stream-id-cells” and > > "mmu-masters”. > > If you need to add the new smmu binding please add the "iommu-cells” > > property in the smmu node and the “iommus” property in the master device. > > In regards to the missing "stream-id-cells" property, I shared the wrong > dtb before, sorry. I was running a number of tests and I might have > picked the wrong file. The proper dtb comes with "stream-id-cells" for > the 0x877 device, see attached. > > > > > Can you please share the xen boot logs with me so that I can debug further > > why the error is observed? > > See attached. I did some debugging and discovered that it crashes while > accessing master->of_node in find_smmu_master. If I revert your series, > the crash goes away. It is very strange because your patches don't touch > find_smmu_master or insert_smmu_master directly. > > I did a git reset --hard on the commit "xen/arm: smmuv1: Add a stream > map entry iterator" and it worked, which points to "xen/arm: smmuv1: > Intelligent SMR allocation" being the problem, even if I have the revert > cherry-picked on top. Maybe the revert is not reverting enough? > > After this test, I switched back to staging and did: > git revert 9f6cd4983715cb31f0ea540e6bbb63f799a35d8a > git revert 0435784cc75dcfef3b5f59c29deb1dbb84265ddb > > And it worked! So the issue truly is that > 9f6cd4983715cb31f0ea540e6bbb63f799a35d8a doesn't revert "enough". > See "full-revert" for the patch reverting the remaining code. That on > top of staging fixes boot for me.
Re: [PATCH v14 01/12] swiotlb: Refactor swiotlb init functions
On Sat, 19 Jun 2021, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
> Tested-by: Stefano Stabellini
> Tested-by: Will Deacon
Acked-by: Stefano Stabellini
> ---
> kernel/dma/swiotlb.c | 50 ++--
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 52e2ac526757..1f9b2b9e7490 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -168,9 +168,28 @@ void __init swiotlb_update_mem_attributes(void)
> memset(vaddr, 0, bytes);
> }
>
> -int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
> verbose)
> +static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t
> start,
> + unsigned long nslabs, bool late_alloc)
> {
> + void *vaddr = phys_to_virt(start);
> unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> +
> + mem->nslabs = nslabs;
> + mem->start = start;
> + mem->end = mem->start + bytes;
> + mem->index = 0;
> + mem->late_alloc = late_alloc;
> + spin_lock_init(>lock);
> + for (i = 0; i < mem->nslabs; i++) {
> + mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> + mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> + mem->slots[i].alloc_size = 0;
> + }
> + memset(vaddr, 0, bytes);
> +}
> +
> +int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
> verbose)
> +{
> struct io_tlb_mem *mem;
> size_t alloc_size;
>
> @@ -186,16 +205,8 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned
> long nslabs, int verbose)
> if (!mem)
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
> - mem->nslabs = nslabs;
> - mem->start = __pa(tlb);
> - mem->end = mem->start + bytes;
> - mem->index = 0;
> - spin_lock_init(>lock);
> - for (i = 0; i < mem->nslabs; i++) {
> - mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> - mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> - mem->slots[i].alloc_size = 0;
> - }
> +
> + swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
>
> io_tlb_default_mem = mem;
> if (verbose)
> @@ -282,8 +293,8 @@ swiotlb_late_init_with_default_size(size_t default_size)
> int
> swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
> {
> - unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> struct io_tlb_mem *mem;
> + unsigned long bytes = nslabs << IO_TLB_SHIFT;
>
> if (swiotlb_force == SWIOTLB_NO_FORCE)
> return 0;
> @@ -297,20 +308,9 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
> nslabs)
> if (!mem)
> return -ENOMEM;
>
> - mem->nslabs = nslabs;
> - mem->start = virt_to_phys(tlb);
> - mem->end = mem->start + bytes;
> - mem->index = 0;
> - mem->late_alloc = 1;
> - spin_lock_init(>lock);
> - for (i = 0; i < mem->nslabs; i++) {
> - mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> - mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> - mem->slots[i].alloc_size = 0;
> - }
> -
> + memset(mem, 0, sizeof(*mem));
> set_memory_decrypted((unsigned long)tlb, bytes >> PAGE_SHIFT);
> - memset(tlb, 0, bytes);
> + swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true);
>
> io_tlb_default_mem = mem;
> swiotlb_print_info();
> --
> 2.32.0.288.g62a8d224e6-goog
>
[xen-unstable-smoke test] 162977: tolerable all pass - PUSHED
flight 162977 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/162977/ 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen c7691f5e340f3b579d40c77548f63133cdf5aac7 baseline version: xen c9b59f9032d41be8bade8a25d9148cf6ed203704 Last test of basis 162973 2021-06-22 12:00:28 Z0 days Testing same since 162977 2021-06-22 18:00:26 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git c9b59f9032..c7691f5e34 c7691f5e340f3b579d40c77548f63133cdf5aac7 -> smoke
Re: [PATCH v2 4/6] libxc: use multicall for memory-op on Linux (and Solaris)
On 22/06/2021 16:19, Jan Beulich wrote: > Some sub-functions, XENMEM_maximum_gpfn and XENMEM_maximum_ram_page in > particular, can return values requiring more than 31 bits to represent. > Hence we cannot issue the hypercall directly when the return value of > ioctl() is used to propagate this value (note that this is not the case > for the BSDs, and MiniOS already wraps all hypercalls in a multicall). It took me 3 readings to realise you weren't saying that BSDs used multicall (which they don't). Instead, I'd suggest rewording it. "Some sub-functions, XENMEM_maximum_gpfn and XENMEM_maximum_ram_page in particular, can return values requiring more than 31 bits to represent. The BSDs deliberately avoid using the ioctl() return value, and MiniOS already uses a multicall. They aren't affected. Linux and Solaris however do use the ioctl() return value, which must be avoided in this case to avoid truncation." Or something similar. With a suitable improvement along these lines, Acked-by: Andrew Cooper
Re: [PATCH v2 6/6] libxc: make xc_domain_maximum_gpfn() endianness-agnostic
On 22/06/2021 16:20, Jan Beulich wrote: > libxc generally uses uint32_t to represent domain IDs. This is fine as > long as addresses of such variables aren't taken, to then pass into > hypercalls: To the hypervisor, a domain ID is a 16-bit value. Introduce > a wrapper struct to deal with the issue. (On architectures with > arguments passed in registers, an intermediate variable would have been > created by the compiler already anyway, just one of the wrong type.) > > The public interface change is both source and binary compatible for > the architectures we currently support. > > Signed-off-by: Jan Beulich > Acked-by: Ian Jackson Reviewed-by: Andrew Cooper > --- > v2: Introduce wrapper struct in public interface. > --- > Together with the comment change I was half tempted to also rename the > sub-function identifier to XENMEM_maximum_gfn. But I then decided this > would go too far here. We ought to fix it, but that could be a followup, or could be when this interface disappears in ABIv2. ~Andrew
Re: [PATCH v2 5/6] libxencall: drop bogus mentioning of xencall6()
On 22/06/2021 16:19, Jan Beulich wrote: > There's no xencall6(), so the version script also shouldn't mention it. > If such a function would ever appear, it shouldn't land in version 1.0. > > Signed-off-by: Jan Beulich > Acked-by: Ian Jackson Reviewed-by: Andrew Cooper This really does need backporting, and it is probably worth stating explicitly that there is no change in the resulting object, nor abi-dumper's view of the object. ~Andrew
Re: [PATCH v2 3/6] libxencall: introduce variant of xencall2() returning long
On 22/06/2021 16:18, Jan Beulich wrote: > Some hypercalls, memory-op in particular, can return values requiring > more than 31 bits to represent. Hence the underlying layers need to make > sure they won't truncate such values. > > Signed-off-by: Jan Beulich > Acked-by: Ian Jackson Acked-by: Andrew Cooper
[PATCH 4/4] tests/xenstore: Rework Makefile
In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.
This causes the code to be noticed by CI, which objects as follows:
test-xenstore.c: In function 'main':
test-xenstore.c:486:5: error: ignoring return value of 'asprintf', declared
with attribute warn_unused_result [-Werror=unused-result]
asprintf(, "%s/%u", TEST_PATH, getpid());
^
Address the CI failure by checking the asprintf() return value and exiting.
Rename xs-test to test-xenstore to be consistent with other tests. Honour
APPEND_FLAGS too.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulich
CC: Roger Pau Monné
CC: Juergen Gross
v2:
* Drop -f's
* Fix CI breakage, now that CI can build the test.
---
.gitignore | 1 -
tools/tests/xenstore/.gitignore| 1 +
tools/tests/xenstore/Makefile | 31 +++---
.../tests/xenstore/{xs-test.c => test-xenstore.c} | 8 --
4 files changed, 29 insertions(+), 12 deletions(-)
create mode 100644 tools/tests/xenstore/.gitignore
rename tools/tests/xenstore/{xs-test.c => test-xenstore.c} (98%)
diff --git a/.gitignore b/.gitignore
index d4b90303b2..8ebb51b6c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -275,7 +275,6 @@ tools/tests/x86_emulator/*sse*.[ch]
tools/tests/x86_emulator/test_x86_emulator
tools/tests/x86_emulator/x86_emulate
tools/tests/x86_emulator/xop*.[ch]
-tools/tests/xenstore/xs-test
tools/tests/vpci/list.h
tools/tests/vpci/vpci.[hc]
tools/tests/vpci/test_vpci
diff --git a/tools/tests/xenstore/.gitignore b/tools/tests/xenstore/.gitignore
new file mode 100644
index 00..4b44f5dd60
--- /dev/null
+++ b/tools/tests/xenstore/.gitignore
@@ -0,0 +1 @@
+test-xenstore
diff --git a/tools/tests/xenstore/Makefile b/tools/tests/xenstore/Makefile
index a367d88803..b9969dd090 100644
--- a/tools/tests/xenstore/Makefile
+++ b/tools/tests/xenstore/Makefile
@@ -1,11 +1,7 @@
XEN_ROOT=$(CURDIR)/../../..
include $(XEN_ROOT)/tools/Rules.mk
-CFLAGS += -Werror
-
-CFLAGS += $(CFLAGS_libxenstore)
-
-TARGETS-y := xs-test
+TARGETS-y := test-xenstore
TARGETS := $(TARGETS-y)
.PHONY: all
@@ -16,14 +12,31 @@ build: $(TARGETS)
.PHONY: clean
clean:
- $(RM) *.o $(TARGETS) *~ $(DEPS_RM)
+ $(RM) -- *.o $(TARGETS) $(DEPS_RM)
.PHONY: distclean
distclean: clean
+ $(RM) -- *~
+
+.PHONY: install
+install: all
+ $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+ $(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC_BIN))
+
+.PHONY: uninstall
+uninstall:
+ $(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGETS))
+
+CFLAGS += -Werror
+CFLAGS += $(CFLAGS_libxenstore)
+CFLAGS += $(APPEND_CFLAGS)
+
+LDFLAGS += $(LDLIBS_libxenstore)
+LDFLAGS += $(APPEND_LDFLAGS)
-xs-test: xs-test.o Makefile
- $(CC) -o $@ $< $(LDFLAGS) $(LDLIBS_libxenstore)
+%.o: Makefile
-install uninstall:
+test-xenstore: test-xenstore.o
+ $(CC) -o $@ $< $(LDFLAGS)
-include $(DEPS_INCLUDE)
diff --git a/tools/tests/xenstore/xs-test.c
b/tools/tests/xenstore/test-xenstore.c
similarity index 98%
rename from tools/tests/xenstore/xs-test.c
rename to tools/tests/xenstore/test-xenstore.c
index c4c99c0661..d3574b3fa2 100644
--- a/tools/tests/xenstore/xs-test.c
+++ b/tools/tests/xenstore/test-xenstore.c
@@ -20,6 +20,7 @@
*/
#define _GNU_SOURCE
+#include
#include
#include
#include
@@ -483,11 +484,14 @@ int main(int argc, char *argv[])
return 0;
}
-asprintf(, "%s/%u", TEST_PATH, getpid());
+if ( asprintf(, "%s/%u", TEST_PATH, getpid()) < 0 )
+err(2, "asprintf() malloc failure\n");
+
for ( t = 0; t < WRITE_BUFFERS_N; t++ )
{
memset(write_buffers[t], 'a' + t, WRITE_BUFFERS_SIZE);
-asprintf([t], "%s/%c", path, 'a' + t);
+if ( asprintf([t], "%s/%c", path, 'a' + t) < 0 )
+err(2, "asprintf() malloc failure\n");
}
xsh = xs_open(0);
--
2.11.0
[PATCH 3/4] tests/cpu-policy: Rework Makefile
In particular, fill in the install/uninstall rules so this test can be packaged to be automated sensibly. Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the unconditional -O3 and use the default instead, and drop CFLAGS from the link line but honour APPEND_LDFLAGS. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Jan Beulich CC: Roger Pau Monné CC: Juergen Gross v2: * Drop -f's * Use %.o rather than *.o for Make level wildcards --- tools/tests/cpu-policy/Makefile | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/tools/tests/cpu-policy/Makefile b/tools/tests/cpu-policy/Makefile index 70ff154da6..161732ad16 100644 --- a/tools/tests/cpu-policy/Makefile +++ b/tools/tests/cpu-policy/Makefile @@ -1,21 +1,19 @@ XEN_ROOT = $(CURDIR)/../../.. include $(XEN_ROOT)/tools/Rules.mk -TARGET-y := test-cpu-policy +TARGETS := # For brevity, these tests make extensive use of designated initialisers in # anonymous unions, but GCCs older than 4.6 can't cope. Ignore the test in # this case. -ifneq ($(clang),y) -TARGET-$(call cc-ver,$(CC),lt,0x040600) := -endif - -ifeq ($(TARGET-y),) +ifneq ($(gcc)$(call cc-ver,$(CC),lt,0x040600),yy) +TARGETS += test-cpu-policy +else $(warning Test harness not built, use newer compiler than "$(CC)" (version $(shell $(CC) -dumpversion))) endif .PHONY: all -all: $(TARGET-y) +all: $(TARGETS) .PHONY: run run: $(TARGET-y) @@ -23,23 +21,32 @@ run: $(TARGET-y) .PHONY: clean clean: - $(RM) -f -- *.o .*.d .*.d2 test-cpu-policy + $(RM) -- *.o $(TARGETS) $(DEPS_RM) .PHONY: distclean distclean: clean - $(RM) -f -- *~ + $(RM) -- *~ .PHONY: install install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) + $(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC_BIN)) .PHONY: uninstall +uninstall: + $(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGETS)) -CFLAGS += -Werror $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -O3 +CFLAGS += -Werror -D__XEN_TOOLS__ +CFLAGS += $(CFLAGS_xeninclude) CFLAGS += $(APPEND_CFLAGS) -vpath %.c ../../../xen/lib/x86 +LDFLAGS += $(APPEND_LDFLAGS) + +vpath %.c $(XEN_ROOT)/xen/lib/x86 + +%.o: Makefile test-cpu-policy: test-cpu-policy.o msr.o cpuid.o policy.o - $(CC) $(CFLAGS) $^ -o $@ + $(CC) $^ -o $@ $(LDFLAGS) -include $(DEPS_INCLUDE) -- 2.11.0
[PATCH 2/4] tests/resource: Rework Makefile
In particular, fill in the install/uninstall rules so this test can be packaged to be automated sensibly. Make all object files depend on the Makefile, drop redundant -f's for $(RM), and use $(TARGET) when appropriate. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Jan Beulich CC: Roger Pau Monné CC: Juergen Gross v2: * Fix typo in commit message * Drop -f's * Use %.o rather than *.o for Make level wildcards --- tools/tests/resource/Makefile | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/tests/resource/Makefile b/tools/tests/resource/Makefile index 4bef482966..1c3aee4ff7 100644 --- a/tools/tests/resource/Makefile +++ b/tools/tests/resource/Makefile @@ -12,17 +12,20 @@ run: $(TARGET) .PHONY: clean clean: - $(RM) -f -- *.o $(TARGET) $(DEPS_RM) + $(RM) -- *.o $(TARGET) $(DEPS_RM) .PHONY: distclean distclean: clean - $(RM) -f -- *~ + $(RM) -- *~ .PHONY: install install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) + $(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN) .PHONY: uninstall uninstall: + $(RM) -- $(DESTDIR)$(LIBEXEC_BIN)/$(TARGET) CFLAGS += -Werror CFLAGS += $(CFLAGS_xeninclude) @@ -34,7 +37,9 @@ LDFLAGS += $(LDLIBS_libxenctrl) LDFLAGS += $(LDLIBS_libxenforeignmemory) LDFLAGS += $(APPEND_LDFLAGS) -test-resource: test-resource.o +%.o: Makefile + +$(TARGET): test-resource.o $(CC) -o $@ $< $(LDFLAGS) -include $(DEPS_INCLUDE) -- 2.11.0
[PATCH 1/4] tools/tests: Drop obsolete mce-test infrastructure
mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases. Drop the test infrasturcture.
Move the one useful remaining item, xen-mceinj, into misc/, fixing some minor
style issues as it goes.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulich
CC: Roger Pau Monné
CC: Juergen Gross
---
.gitignore | 1 -
tools/misc/.gitignore | 1 +
tools/misc/Makefile| 4 +
tools/{tests/mce-test/tools => misc}/xen-mceinj.c | 32 +--
tools/tests/Makefile | 1 -
tools/tests/mce-test/Makefile | 12 -
tools/tests/mce-test/README| 75 --
tools/tests/mce-test/cases/srao_llc/dom0/cases.sh | 73 --
tools/tests/mce-test/cases/srao_llc/guest/cases.sh | 94
tools/tests/mce-test/cases/srao_llc/xen/cases.sh | 69 --
tools/tests/mce-test/cases/srao_mem/dom0/cases.sh | 73 --
tools/tests/mce-test/cases/srao_mem/guest/cases.sh | 94
tools/tests/mce-test/cases/srao_mem/xen/cases.sh | 69 --
tools/tests/mce-test/cases/ucna_llc/dom0/cases.sh | 72 --
tools/tests/mce-test/cases/ucna_llc/guest/cases.sh | 92
tools/tests/mce-test/cases/ucna_llc/xen/cases.sh | 68 --
tools/tests/mce-test/config/setup.conf | 24 --
tools/tests/mce-test/lib/xen-mceinj-tool.sh| 260 -
tools/tests/mce-test/tools/Makefile| 24 --
tools/tests/mce-test/tools/README | 24 --
20 files changed, 24 insertions(+), 1138 deletions(-)
rename tools/{tests/mce-test/tools => misc}/xen-mceinj.c (97%)
delete mode 100644 tools/tests/mce-test/Makefile
delete mode 100644 tools/tests/mce-test/README
delete mode 100644 tools/tests/mce-test/cases/srao_llc/dom0/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_llc/guest/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_llc/xen/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_mem/dom0/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_mem/guest/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_mem/xen/cases.sh
delete mode 100644 tools/tests/mce-test/cases/ucna_llc/dom0/cases.sh
delete mode 100644 tools/tests/mce-test/cases/ucna_llc/guest/cases.sh
delete mode 100644 tools/tests/mce-test/cases/ucna_llc/xen/cases.sh
delete mode 100644 tools/tests/mce-test/config/setup.conf
delete mode 100644 tools/tests/mce-test/lib/xen-mceinj-tool.sh
delete mode 100644 tools/tests/mce-test/tools/Makefile
delete mode 100644 tools/tests/mce-test/tools/README
diff --git a/.gitignore b/.gitignore
index 38a085e398..d4b90303b2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -276,7 +276,6 @@ tools/tests/x86_emulator/test_x86_emulator
tools/tests/x86_emulator/x86_emulate
tools/tests/x86_emulator/xop*.[ch]
tools/tests/xenstore/xs-test
-tools/tests/mce-test/tools/xen-mceinj
tools/tests/vpci/list.h
tools/tests/vpci/vpci.[hc]
tools/tests/vpci/test_vpci
diff --git a/tools/misc/.gitignore b/tools/misc/.gitignore
index ce6f937d0c..73ce95e6d7 100644
--- a/tools/misc/.gitignore
+++ b/tools/misc/.gitignore
@@ -1,4 +1,5 @@
xen-access
+xen-mceinj
xen-memshare
xen-ucode
xen-vmtrace
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 2b683819d4..1a07191d83 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -22,6 +22,7 @@ INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
INSTALL_SBIN-$(CONFIG_X86) += xen-hvmcrash
INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx
INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
+INSTALL_SBIN-$(CONFIG_X86) += xen-mceinj
INSTALL_SBIN-$(CONFIG_X86) += xen-memshare
INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
INSTALL_SBIN-$(CONFIG_X86) += xen-ucode
@@ -97,6 +98,9 @@ xen-memshare: xen-memshare.o
xen-vmtrace: xen-vmtrace.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl)
$(LDLIBS_libxenforeignmemory) $(APPEND_LDFLAGS)
+xen-mceinj: xen-mceinj.o
+ $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
+
xenperf: xenperf.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
diff --git a/tools/tests/mce-test/tools/xen-mceinj.c b/tools/misc/xen-mceinj.c
similarity index 97%
rename from tools/tests/mce-test/tools/xen-mceinj.c
rename to tools/misc/xen-mceinj.c
index 1187d01e5f..df55eefbac 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/misc/xen-mceinj.c
@@ -137,7 +137,7 @@ static void err(xc_interface *xc_handle, const char *fmt,
...)
va_list args;
va_start(args, fmt);
-if (vasprintf(, fmt, args) < 0)
+if ( vasprintf(, fmt, args) < 0 )
abort();
perror(buf);
va_end(args);
@@ -173,7 +173,7 @@ static unsigned int
[PATCH v2 0/4] tools/tests: More cleanup for automation improvements
v2:
* Fix CI failures from newly-exposed logic
* Drop -f's from $(RM)
* Drop the 'run' rune patch. Its clearly controvertial, but ignoring the
problems isn't an available option in the longterm.
All other RFC questions still outstanding.
Andrew Cooper (4):
tools/tests: Drop obsolete mce-test infrastructure
tests/resource: Rework Makefile
tests/cpu-policy: Rework Makefile
tests/xenstore: Rework Makefile
.gitignore | 2 -
tools/misc/.gitignore | 1 +
tools/misc/Makefile| 4 +
tools/{tests/mce-test/tools => misc}/xen-mceinj.c | 32 +--
tools/tests/Makefile | 1 -
tools/tests/cpu-policy/Makefile| 31 ++-
tools/tests/mce-test/Makefile | 12 -
tools/tests/mce-test/README| 75 --
tools/tests/mce-test/cases/srao_llc/dom0/cases.sh | 73 --
tools/tests/mce-test/cases/srao_llc/guest/cases.sh | 94
tools/tests/mce-test/cases/srao_llc/xen/cases.sh | 69 --
tools/tests/mce-test/cases/srao_mem/dom0/cases.sh | 73 --
tools/tests/mce-test/cases/srao_mem/guest/cases.sh | 94
tools/tests/mce-test/cases/srao_mem/xen/cases.sh | 69 --
tools/tests/mce-test/cases/ucna_llc/dom0/cases.sh | 72 --
tools/tests/mce-test/cases/ucna_llc/guest/cases.sh | 92
tools/tests/mce-test/cases/ucna_llc/xen/cases.sh | 68 --
tools/tests/mce-test/config/setup.conf | 24 --
tools/tests/mce-test/lib/xen-mceinj-tool.sh| 260 -
tools/tests/mce-test/tools/Makefile| 24 --
tools/tests/mce-test/tools/README | 24 --
tools/tests/resource/Makefile | 11 +-
tools/tests/xenstore/.gitignore| 1 +
tools/tests/xenstore/Makefile | 31 ++-
.../tests/xenstore/{xs-test.c => test-xenstore.c} | 8 +-
25 files changed, 80 insertions(+), 1165 deletions(-)
rename tools/{tests/mce-test/tools => misc}/xen-mceinj.c (97%)
delete mode 100644 tools/tests/mce-test/Makefile
delete mode 100644 tools/tests/mce-test/README
delete mode 100644 tools/tests/mce-test/cases/srao_llc/dom0/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_llc/guest/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_llc/xen/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_mem/dom0/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_mem/guest/cases.sh
delete mode 100644 tools/tests/mce-test/cases/srao_mem/xen/cases.sh
delete mode 100644 tools/tests/mce-test/cases/ucna_llc/dom0/cases.sh
delete mode 100644 tools/tests/mce-test/cases/ucna_llc/guest/cases.sh
delete mode 100644 tools/tests/mce-test/cases/ucna_llc/xen/cases.sh
delete mode 100644 tools/tests/mce-test/config/setup.conf
delete mode 100644 tools/tests/mce-test/lib/xen-mceinj-tool.sh
delete mode 100644 tools/tests/mce-test/tools/Makefile
delete mode 100644 tools/tests/mce-test/tools/README
create mode 100644 tools/tests/xenstore/.gitignore
rename tools/tests/xenstore/{xs-test.c => test-xenstore.c} (98%)
--
2.11.0
Re: Windows 10 Kernel Debugging on Xen
Make sure windbg is already waiting for the connection from the debugee by the time Windows starts booting. If you try to attach windbg later it won't work. It worked for me but obviously YMMV. Tamas On Tue, Jun 22, 2021 at 2:07 PM Neil Sikka wrote: > > I tried that, but it seems like I'm getting an interrupt storm on the > debugger VM (CPU spends all its time in the kernel) when I try to attach the > debugger. This observation furthers my suspicion that there is communication, > but there is something wrong with the protocol... > > On Tue, Jun 22, 2021 at 12:43 PM Tamas K Lengyel > wrote: >> >> I used Xen 4.15 and a pretty new version of Windows 10. It is a bit >> finicky, you have to run the debug commands on the debugee and then >> reboot. When the VM is rebooting the domain ID changes so you have to >> start the serial bridge then. Windbg will attach afterwards. Just make >> sure both VMs have serial='pty' set in their config file. >> >> Tamas >> >> On Tue, Jun 22, 2021 at 12:33 PM Neil Sikka wrote: >> > >> > Thanks for the quick response, Tamas. I tried what you said and windbg >> > waits and the debugee hangs when I click the break button in windbg, but I >> > don't see any output in windbg. This means that there is SOME >> > communication over the serial port that causes the debugee to hang when I >> > click break. Could it be a debugger protocol issue? I also tried the >> > guidance here by running the crlf program: >> > https://www.qubes-os.org/doc/windows-debugging/ >> > But windbg waits and the debugee hangs in a similar manner. >> > >> > What versions of WIndows and Xen are you using? >> > >> > On Tue, Jun 22, 2021 at 12:10 PM Tamas K Lengyel >> > wrote: >> >> >> >> I have managed to get windbg working with a serial bridge between two >> >> Win10 VMs using the following script: >> >> https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/serial-bridge.sh. >> >> The debugee has to enable a couple options so that windbg can attach: >> >> https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/debug.cmd. >> >> >> >> Tamas >> >> >> >> On Tue, Jun 22, 2021 at 12:01 PM Neil Sikka wrote: >> >> > >> >> > Hello, >> >> > Has anyone gotten a Windows10 (Version 1709 of later) kernel debugger >> >> > attached when running the Windows10 debugger VM and the Windows10 >> >> > debugee VM on Xen 4.13.0 hypervisor? I am getting a "NIC hardware >> >> > initialization failed" error. I tried the suggestions in the discussion >> >> > here (https://bugzilla.redhat.com/show_bug.cgi?id=1947015): >> >> > -cpu >> >> > Skylake-Server-IBRS,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,amd-ssbd=on, >> >> > \ >> >> > skip-l1dfl-vmentry=on,mpx=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KVMKVMKVM >> >> > >> >> > note: i had to remove the following 2 arguments due to errors from QEMU: >> >> > pschange-mc-no=on >> >> > hv_vpindex >> >> > >> >> > Here was the error: >> >> > C:\Users\user\Desktop\oldDebuggers\x64>kdnet.exe >> >> > >> >> > Network debugging is supported on the following NICs: >> >> > busparams=0.4.0, Intel(R) PRO/1000 MT Network Connection, Plugged in. >> >> > The Microsoft hypervisor running this VM does not support KDNET. >> >> > Please upgrade to the hypervisor shipped in Windows 8 or WS2012 or >> >> > later. >> >> > >> >> > KDNET initialization failed. Status = 0xC182. >> >> > NIC hardware initialization failed. >> >> > >> >> > I am using an Intel e1000 NIC emulated through QEMU because its >> >> > supposedly a supported NIC for Windows kernel NET debugging. >> >> > >> >> > Thanks in Advance! >> >> > >> >> > -- >> >> > My Blog: http://www.neilscomputerblog.blogspot.com/ >> >> > Twitter: @neilsikka >> > >> > >> > >> > -- >> > My Blog: http://www.neilscomputerblog.blogspot.com/ >> > Twitter: @neilsikka > > > > -- > My Blog: http://www.neilscomputerblog.blogspot.com/ > Twitter: @neilsikka
Re: Windows 10 Kernel Debugging on Xen
I tried that, but it seems like I'm getting an interrupt storm on the debugger VM (CPU spends all its time in the kernel) when I try to attach the debugger. This observation furthers my suspicion that there is communication, but there is something wrong with the protocol... On Tue, Jun 22, 2021 at 12:43 PM Tamas K Lengyel wrote: > I used Xen 4.15 and a pretty new version of Windows 10. It is a bit > finicky, you have to run the debug commands on the debugee and then > reboot. When the VM is rebooting the domain ID changes so you have to > start the serial bridge then. Windbg will attach afterwards. Just make > sure both VMs have serial='pty' set in their config file. > > Tamas > > On Tue, Jun 22, 2021 at 12:33 PM Neil Sikka wrote: > > > > Thanks for the quick response, Tamas. I tried what you said and windbg > waits and the debugee hangs when I click the break button in windbg, but I > don't see any output in windbg. This means that there is SOME communication > over the serial port that causes the debugee to hang when I click break. > Could it be a debugger protocol issue? I also tried the guidance here by > running the crlf program: > > https://www.qubes-os.org/doc/windows-debugging/ > > But windbg waits and the debugee hangs in a similar manner. > > > > What versions of WIndows and Xen are you using? > > > > On Tue, Jun 22, 2021 at 12:10 PM Tamas K Lengyel < > tamas.k.leng...@gmail.com> wrote: > >> > >> I have managed to get windbg working with a serial bridge between two > >> Win10 VMs using the following script: > >> > https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/serial-bridge.sh > . > >> The debugee has to enable a couple options so that windbg can attach: > >> > https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/debug.cmd > . > >> > >> Tamas > >> > >> On Tue, Jun 22, 2021 at 12:01 PM Neil Sikka > wrote: > >> > > >> > Hello, > >> > Has anyone gotten a Windows10 (Version 1709 of later) kernel debugger > attached when running the Windows10 debugger VM and the Windows10 debugee > VM on Xen 4.13.0 hypervisor? I am getting a "NIC hardware initialization > failed" error. I tried the suggestions in the discussion here ( > https://bugzilla.redhat.com/show_bug.cgi?id=1947015): > >> > -cpu > Skylake-Server-IBRS,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,amd-ssbd=on, > \ > >> > > skip-l1dfl-vmentry=on,mpx=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KVMKVMKVM > >> > > >> > note: i had to remove the following 2 arguments due to errors from > QEMU: > >> > pschange-mc-no=on > >> > hv_vpindex > >> > > >> > Here was the error: > >> > C:\Users\user\Desktop\oldDebuggers\x64>kdnet.exe > >> > > >> > Network debugging is supported on the following NICs: > >> > busparams=0.4.0, Intel(R) PRO/1000 MT Network Connection, Plugged in. > >> > The Microsoft hypervisor running this VM does not support KDNET. > >> > Please upgrade to the hypervisor shipped in Windows 8 or WS2012 or > later. > >> > > >> > KDNET initialization failed. Status = 0xC182. > >> > NIC hardware initialization failed. > >> > > >> > I am using an Intel e1000 NIC emulated through QEMU because its > supposedly a supported NIC for Windows kernel NET debugging. > >> > > >> > Thanks in Advance! > >> > > >> > -- > >> > My Blog: http://www.neilscomputerblog.blogspot.com/ > >> > Twitter: @neilsikka > > > > > > > > -- > > My Blog: http://www.neilscomputerblog.blogspot.com/ > > Twitter: @neilsikka > -- My Blog: http://www.neilscomputerblog.blogspot.com/ Twitter: @neilsikka
Re: [PATCH V7 01/18] perf/core: Use static_call to optimize perf_guest_info_callbacks
On 6/22/21 5:38 AM, Zhu Lingshan wrote:
> -static int xen_is_user_mode(void)
> -{
> - const struct xen_pmu_data *xenpmu_data = get_xenpmu_data();
> + state |= PERF_GUEST_ACTIVE;
>
> - if (!xenpmu_data) {
> - pr_warn_once("%s: pmudata not initialized\n", __func__);
> - return 0;
> + if (xenpmu_data->pmu.pmu_flags & PMU_SAMPLE_PV) {
> + if (xenpmu_data->pmu.pmu_flags & PMU_SAMPLE_USER)
> + state |= PERF_GUEST_USER;
> + } else {
> + if (!!(xenpmu_data->pmu.r.regs.cpl & 3))
> + state |= PERF_GUEST_USER;
Please drop "!!", it's not needed here. And use "else if".
With that, for Xen bits:
Reviewed-by: Boris Ostrovsky
-boris
[PATCH 13/15] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
Goes through all the drivers and deletes the default hook since it's
the default now.
Acked-by: David Lechner
Acked-by: Noralf Trønnes
Acked-by: Oleksandr Andrushchenko
Acked-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: "Noralf Trønnes"
Cc: Linus Walleij
Cc: Emma Anholt
Cc: David Lechner
Cc: Kamlesh Gurudasani
Cc: Oleksandr Andrushchenko
Cc: Daniel Vetter
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: Andy Shevchenko
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-devel@lists.xenproject.org
---
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 -
drivers/gpu/drm/gud/gud_drv.c| 1 -
drivers/gpu/drm/mcde/mcde_display.c | 1 -
drivers/gpu/drm/pl111/pl111_display.c| 1 -
drivers/gpu/drm/tiny/hx8357d.c | 1 -
drivers/gpu/drm/tiny/ili9225.c | 1 -
drivers/gpu/drm/tiny/ili9341.c | 1 -
drivers/gpu/drm/tiny/ili9486.c | 1 -
drivers/gpu/drm/tiny/mi0283qt.c | 1 -
drivers/gpu/drm/tiny/repaper.c | 1 -
drivers/gpu/drm/tiny/st7586.c| 1 -
drivers/gpu/drm/tiny/st7735r.c | 1 -
drivers/gpu/drm/tve200/tve200_display.c | 1 -
drivers/gpu/drm/xen/xen_drm_front_kms.c | 1 -
14 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index 098f96d4d50d..827e62c1daba 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -220,7 +220,6 @@ static const struct drm_simple_display_pipe_funcs
aspeed_gfx_funcs = {
.enable = aspeed_gfx_pipe_enable,
.disable= aspeed_gfx_pipe_disable,
.update = aspeed_gfx_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
.enable_vblank = aspeed_gfx_enable_vblank,
.disable_vblank = aspeed_gfx_disable_vblank,
};
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index e8b672dc9832..1925df9c0fb7 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -364,7 +364,6 @@ static void gud_debugfs_init(struct drm_minor *minor)
static const struct drm_simple_display_pipe_funcs gud_pipe_funcs = {
.check = gud_pipe_check,
.update = gud_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static const struct drm_mode_config_funcs gud_mode_config_funcs = {
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 4ddc55d58f38..ce12a36e2db4 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -1479,7 +1479,6 @@ static struct drm_simple_display_pipe_funcs
mcde_display_funcs = {
.update = mcde_display_update,
.enable_vblank = mcde_display_enable_vblank,
.disable_vblank = mcde_display_disable_vblank,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
int mcde_display_init(struct drm_device *drm)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 6fd7f13f1aca..b5a8859739a2 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -440,7 +440,6 @@ static struct drm_simple_display_pipe_funcs
pl111_display_funcs = {
.enable = pl111_display_enable,
.disable = pl111_display_disable,
.update = pl111_display_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static int pl111_clk_div_choose_div(struct clk_hw *hw, unsigned long rate,
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index da5df93450de..9b33c05732aa 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -184,7 +184,6 @@ static const struct drm_simple_display_pipe_funcs
hx8357d_pipe_funcs = {
.enable = yx240qv29_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static const struct drm_display_mode yx350hv15_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index 69265d8a3beb..976d3209f164 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -328,7 +328,6 @@ static const struct drm_simple_display_pipe_funcs
ili9225_pipe_funcs = {
.enable = ili9225_pipe_enable,
.disable= ili9225_pipe_disable,
.update = ili9225_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static const struct drm_display_mode ili9225_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
index ad9ce7b4f76f..37e0c33399c8 100644
--- a/drivers/gpu/drm/tiny/ili9341.c
+++ b/drivers/gpu/drm/tiny/ili9341.c
@@ -140,7 +140,6 @@ static const struct
Re: Windows 10 Kernel Debugging on Xen
I used Xen 4.15 and a pretty new version of Windows 10. It is a bit finicky, you have to run the debug commands on the debugee and then reboot. When the VM is rebooting the domain ID changes so you have to start the serial bridge then. Windbg will attach afterwards. Just make sure both VMs have serial='pty' set in their config file. Tamas On Tue, Jun 22, 2021 at 12:33 PM Neil Sikka wrote: > > Thanks for the quick response, Tamas. I tried what you said and windbg waits > and the debugee hangs when I click the break button in windbg, but I don't > see any output in windbg. This means that there is SOME communication over > the serial port that causes the debugee to hang when I click break. Could it > be a debugger protocol issue? I also tried the guidance here by running the > crlf program: > https://www.qubes-os.org/doc/windows-debugging/ > But windbg waits and the debugee hangs in a similar manner. > > What versions of WIndows and Xen are you using? > > On Tue, Jun 22, 2021 at 12:10 PM Tamas K Lengyel > wrote: >> >> I have managed to get windbg working with a serial bridge between two >> Win10 VMs using the following script: >> https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/serial-bridge.sh. >> The debugee has to enable a couple options so that windbg can attach: >> https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/debug.cmd. >> >> Tamas >> >> On Tue, Jun 22, 2021 at 12:01 PM Neil Sikka wrote: >> > >> > Hello, >> > Has anyone gotten a Windows10 (Version 1709 of later) kernel debugger >> > attached when running the Windows10 debugger VM and the Windows10 debugee >> > VM on Xen 4.13.0 hypervisor? I am getting a "NIC hardware initialization >> > failed" error. I tried the suggestions in the discussion here >> > (https://bugzilla.redhat.com/show_bug.cgi?id=1947015): >> > -cpu >> > Skylake-Server-IBRS,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,amd-ssbd=on, >> > \ >> > skip-l1dfl-vmentry=on,mpx=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KVMKVMKVM >> > >> > note: i had to remove the following 2 arguments due to errors from QEMU: >> > pschange-mc-no=on >> > hv_vpindex >> > >> > Here was the error: >> > C:\Users\user\Desktop\oldDebuggers\x64>kdnet.exe >> > >> > Network debugging is supported on the following NICs: >> > busparams=0.4.0, Intel(R) PRO/1000 MT Network Connection, Plugged in. >> > The Microsoft hypervisor running this VM does not support KDNET. >> > Please upgrade to the hypervisor shipped in Windows 8 or WS2012 or later. >> > >> > KDNET initialization failed. Status = 0xC182. >> > NIC hardware initialization failed. >> > >> > I am using an Intel e1000 NIC emulated through QEMU because its supposedly >> > a supported NIC for Windows kernel NET debugging. >> > >> > Thanks in Advance! >> > >> > -- >> > My Blog: http://www.neilscomputerblog.blogspot.com/ >> > Twitter: @neilsikka > > > > -- > My Blog: http://www.neilscomputerblog.blogspot.com/ > Twitter: @neilsikka
Re: [PATCH] iommu/arm: ipmmu-vmsa: Add compatible for Renesas R-Car M3-W+ SoC
Hi Oleksandr,
On 14/06/2021 21:18, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "renesas,r8a77961" string identifies M3-W+ (aka M3-W ES3.0)
instead of "renesas,r8a7796" since Linux commit:
"9c9f7891093b02eb64ca4e1c7ab776a4296c058f soc: renesas: Identify R-Car M3-W+".
Add new compatible to the Xen driver.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
Cheers,
---
xen/drivers/passthrough/arm/ipmmu-vmsa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
index 8b8e3a0..1255b0d 100644
--- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -1316,6 +1316,7 @@ static const struct dt_device_match ipmmu_dt_match[]
__initconst =
DT_MATCH_COMPATIBLE("renesas,ipmmu-r8a7795"),
DT_MATCH_COMPATIBLE("renesas,ipmmu-r8a77965"),
DT_MATCH_COMPATIBLE("renesas,ipmmu-r8a7796"),
+DT_MATCH_COMPATIBLE("renesas,ipmmu-r8a77961"),
{ /* sentinel */ },
};
--
Julien Grall
Re: Windows 10 Kernel Debugging on Xen
Thanks for the quick response, Tamas. I tried what you said and windbg waits and the debugee hangs when I click the break button in windbg, but I don't see any output in windbg. This means that there is SOME communication over the serial port that causes the debugee to hang when I click break. Could it be a debugger protocol issue? I also tried the guidance here by running the crlf program: https://www.qubes-os.org/doc/windows-debugging/ But windbg waits and the debugee hangs in a similar manner. What versions of WIndows and Xen are you using? On Tue, Jun 22, 2021 at 12:10 PM Tamas K Lengyel wrote: > I have managed to get windbg working with a serial bridge between two > Win10 VMs using the following script: > > https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/serial-bridge.sh > . > The debugee has to enable a couple options so that windbg can attach: > > https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/debug.cmd > . > > Tamas > > On Tue, Jun 22, 2021 at 12:01 PM Neil Sikka wrote: > > > > Hello, > > Has anyone gotten a Windows10 (Version 1709 of later) kernel debugger > attached when running the Windows10 debugger VM and the Windows10 debugee > VM on Xen 4.13.0 hypervisor? I am getting a "NIC hardware initialization > failed" error. I tried the suggestions in the discussion here ( > https://bugzilla.redhat.com/show_bug.cgi?id=1947015): > > -cpu > Skylake-Server-IBRS,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,amd-ssbd=on, > \ > > > skip-l1dfl-vmentry=on,mpx=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KVMKVMKVM > > > > note: i had to remove the following 2 arguments due to errors from QEMU: > > pschange-mc-no=on > > hv_vpindex > > > > Here was the error: > > C:\Users\user\Desktop\oldDebuggers\x64>kdnet.exe > > > > Network debugging is supported on the following NICs: > > busparams=0.4.0, Intel(R) PRO/1000 MT Network Connection, Plugged in. > > The Microsoft hypervisor running this VM does not support KDNET. > > Please upgrade to the hypervisor shipped in Windows 8 or WS2012 or later. > > > > KDNET initialization failed. Status = 0xC182. > > NIC hardware initialization failed. > > > > I am using an Intel e1000 NIC emulated through QEMU because its > supposedly a supported NIC for Windows kernel NET debugging. > > > > Thanks in Advance! > > > > -- > > My Blog: http://www.neilscomputerblog.blogspot.com/ > > Twitter: @neilsikka > -- My Blog: http://www.neilscomputerblog.blogspot.com/ Twitter: @neilsikka
Re: [PATCH] Revert "tools/firmware/ovmf: Use OvmfXen platform file is exist"
On 22/06/2021 17:10, Jan Beulich wrote: > On 22.06.2021 17:39, Andrew Cooper wrote: >> This reverts commit aad7b5c11d51d57659978e04702ac970906894e8. >> >> The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby >> OvmfXen maps its shared info page at the top of address space. When trying >> to >> migrate such a domain, XENMEM_maximum_gpfn returns a very large value. This >> has uncovered multiple issues: >> >> 1) The userspace hypercall wrappers truncate all return values to int on >> Linux and Solaris. This needs fixing in Xen. >> 2) 32bit toolstacks can't migrate any domain with RAM above the 2^40 mark, >> because of virtual address constraints. This needs fixing in OVMF. > And I suspect even that presently enforce boundary of 2^40 is actually > too high, and things still wouldn't work when getting close. At the > very least the tool stack then depends on a fairly big chunk of memory > (2^30 bytes) to be available in one single, virtually contiguous piece. > Iirc 32-bit Linux can be configured to not even leave this much space > for user mode. I tested it once during Migration v2 development, and it worked for me, but I do expect that that is as much testing as it has had since... A 3G/1G split is the default under multiple 32bit kernels, and the allocation is made right at the start, so there is a reasonable chance of finding space. After all, it only needs 4k alignment. Whether ASLR has changed the chances in the meantime remains to be seen, but honestly - 32bit toolstacks on x86 really don't exist in production any more, and Arm still hasn't implemented logdirty support, so the limit has little practical consequence. ~Andrew
Re: [PATCH] tools/misc/xen-vmtrace: handle more signals and install by default
Patch ping.
On Fri, May 7, 2021 at 11:28 AM Tamas K Lengyel wrote:
>
> Signed-off-by: Tamas K Lengyel
> ---
> tools/misc/Makefile | 2 +-
> tools/misc/xen-vmtrace.c | 12 +---
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/tools/misc/Makefile b/tools/misc/Makefile
> index 2b683819d4..c32c42d546 100644
> --- a/tools/misc/Makefile
> +++ b/tools/misc/Makefile
> @@ -25,6 +25,7 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
> INSTALL_SBIN-$(CONFIG_X86) += xen-memshare
> INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
> INSTALL_SBIN-$(CONFIG_X86) += xen-ucode
> +INSTALL_SBIN-$(CONFIG_X86) += xen-vmtrace
> INSTALL_SBIN += xencov
> INSTALL_SBIN += xenhypfs
> INSTALL_SBIN += xenlockprof
> @@ -51,7 +52,6 @@ TARGETS_COPY += xenpvnetboot
> TARGETS_BUILD := $(filter-out $(TARGETS_COPY),$(TARGETS_ALL))
>
> # ... including build-only targets
> -TARGETS_BUILD-$(CONFIG_X86)+= xen-vmtrace
> TARGETS_BUILD += $(TARGETS_BUILD-y)
>
> .PHONY: all build
> diff --git a/tools/misc/xen-vmtrace.c b/tools/misc/xen-vmtrace.c
> index 35d14c6a9b..5b688a54af 100644
> --- a/tools/misc/xen-vmtrace.c
> +++ b/tools/misc/xen-vmtrace.c
> @@ -44,7 +44,7 @@ static size_t size;
> static char *buf;
>
> static sig_atomic_t interrupted;
> -static void int_handler(int signum)
> +static void close_handler(int signum)
> {
> interrupted = 1;
> }
> @@ -78,8 +78,14 @@ int main(int argc, char **argv)
> int rc, exit = 1;
> xenforeignmemory_resource_handle *fres = NULL;
>
> -if ( signal(SIGINT, int_handler) == SIG_ERR )
> -err(1, "Failed to register signal handler\n");
> +struct sigaction act;
> +act.sa_handler = close_handler;
> +act.sa_flags = 0;
> +sigemptyset(_mask);
> +sigaction(SIGHUP, , NULL);
> +sigaction(SIGTERM, , NULL);
> +sigaction(SIGINT, , NULL);
> +sigaction(SIGALRM, , NULL);
>
> if ( argc != 3 )
> {
> --
> 2.27.0
>
Re: [PATCH] Revert "tools/firmware/ovmf: Use OvmfXen platform file is exist"
On 22.06.2021 17:39, Andrew Cooper wrote: > This reverts commit aad7b5c11d51d57659978e04702ac970906894e8. > > The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby > OvmfXen maps its shared info page at the top of address space. When trying to > migrate such a domain, XENMEM_maximum_gpfn returns a very large value. This > has uncovered multiple issues: > > 1) The userspace hypercall wrappers truncate all return values to int on > Linux and Solaris. This needs fixing in Xen. > 2) 32bit toolstacks can't migrate any domain with RAM above the 2^40 mark, > because of virtual address constraints. This needs fixing in OVMF. And I suspect even that presently enforce boundary of 2^40 is actually too high, and things still wouldn't work when getting close. At the very least the tool stack then depends on a fairly big chunk of memory (2^30 bytes) to be available in one single, virtually contiguous piece. Iirc 32-bit Linux can be configured to not even leave this much space for user mode. Jan
Re: Windows 10 Kernel Debugging on Xen
I have managed to get windbg working with a serial bridge between two Win10 VMs using the following script: https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/serial-bridge.sh. The debugee has to enable a couple options so that windbg can attach: https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/debug.cmd. Tamas On Tue, Jun 22, 2021 at 12:01 PM Neil Sikka wrote: > > Hello, > Has anyone gotten a Windows10 (Version 1709 of later) kernel debugger > attached when running the Windows10 debugger VM and the Windows10 debugee VM > on Xen 4.13.0 hypervisor? I am getting a "NIC hardware initialization failed" > error. I tried the suggestions in the discussion here > (https://bugzilla.redhat.com/show_bug.cgi?id=1947015): > -cpu > Skylake-Server-IBRS,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,amd-ssbd=on, > \ > skip-l1dfl-vmentry=on,mpx=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KVMKVMKVM > > note: i had to remove the following 2 arguments due to errors from QEMU: > pschange-mc-no=on > hv_vpindex > > Here was the error: > C:\Users\user\Desktop\oldDebuggers\x64>kdnet.exe > > Network debugging is supported on the following NICs: > busparams=0.4.0, Intel(R) PRO/1000 MT Network Connection, Plugged in. > The Microsoft hypervisor running this VM does not support KDNET. > Please upgrade to the hypervisor shipped in Windows 8 or WS2012 or later. > > KDNET initialization failed. Status = 0xC182. > NIC hardware initialization failed. > > I am using an Intel e1000 NIC emulated through QEMU because its supposedly a > supported NIC for Windows kernel NET debugging. > > Thanks in Advance! > > -- > My Blog: http://www.neilscomputerblog.blogspot.com/ > Twitter: @neilsikka
Windows 10 Kernel Debugging on Xen
Hello, Has anyone gotten a Windows10 (Version 1709 of later) kernel debugger attached when running the Windows10 debugger VM and the Windows10 debugee VM on Xen 4.13.0 hypervisor? I am getting a "NIC hardware initialization failed" error. I tried the suggestions in the discussion here ( https://bugzilla.redhat.com/show_bug.cgi?id=1947015): -cpu Skylake-Server-IBRS,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,amd-ssbd=on, \ skip-l1dfl-vmentry=on,mpx=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=KVMKVMKVM note: i had to remove the following 2 arguments due to errors from QEMU: pschange-mc-no=on hv_vpindex Here was the error: C:\Users\user\Desktop\oldDebuggers\x64>kdnet.exe Network debugging is supported on the following NICs: busparams=0.4.0, Intel(R) PRO/1000 MT Network Connection, Plugged in. The Microsoft hypervisor running this VM does not support KDNET. Please upgrade to the hypervisor shipped in Windows 8 or WS2012 or later. KDNET initialization failed. Status = 0xC182. NIC hardware initialization failed. I am using an Intel e1000 NIC emulated through QEMU because its supposedly a supported NIC for Windows kernel NET debugging. Thanks in Advance! -- My Blog: http://www.neilscomputerblog.blogspot.com/ Twitter: @neilsikka
Re: [PATCH] Revert "tools/firmware/ovmf: Use OvmfXen platform file is exist"
On Tue, Jun 22, 2021 at 04:39:30PM +0100, Andrew Cooper wrote: > This reverts commit aad7b5c11d51d57659978e04702ac970906894e8. > > The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby > OvmfXen maps its shared info page at the top of address space. When trying to > migrate such a domain, XENMEM_maximum_gpfn returns a very large value. This > has uncovered multiple issues: > > 1) The userspace hypercall wrappers truncate all return values to int on > Linux and Solaris. This needs fixing in Xen. > 2) 32bit toolstacks can't migrate any domain with RAM above the 2^40 mark, > because of virtual address constraints. This needs fixing in OVMF. > > Fixes for both of these aren't completely trivial. Revert the change to > unblock staging in the meantime. > > Signed-off-by: Andrew Cooper Acked-by: Anthony PERARD Thanks, -- Anthony PERARD
[PATCH] Revert "tools/firmware/ovmf: Use OvmfXen platform file is exist"
This reverts commit aad7b5c11d51d57659978e04702ac970906894e8. The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby OvmfXen maps its shared info page at the top of address space. When trying to migrate such a domain, XENMEM_maximum_gpfn returns a very large value. This has uncovered multiple issues: 1) The userspace hypercall wrappers truncate all return values to int on Linux and Solaris. This needs fixing in Xen. 2) 32bit toolstacks can't migrate any domain with RAM above the 2^40 mark, because of virtual address constraints. This needs fixing in OVMF. Fixes for both of these aren't completely trivial. Revert the change to unblock staging in the meantime. Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall --- tools/firmware/ovmf-makefile | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile index 637ee509c3..55f9992145 100644 --- a/tools/firmware/ovmf-makefile +++ b/tools/firmware/ovmf-makefile @@ -17,14 +17,8 @@ all: build .PHONY: build build: if test -e .git ; then $(GIT) submodule update --init --recursive ; fi - set -ex; \ - if test -e OvmfPkg/OvmfXen.dsc; then \ - OvmfPkg/build.sh -a X64 -b $(TARGET) -n 4 -p OvmfPkg/OvmfXen.dsc; \ - cp Build/OvmfXen/$(TARGET)_GCC*/FV/OVMF.fd ovmf.bin; \ - else \ - OvmfPkg/build.sh -a X64 -b $(TARGET) -n 4; \ - cp Build/OvmfX64/$(TARGET)_GCC*/FV/OVMF.fd ovmf.bin; \ - fi + OvmfPkg/build.sh -a X64 -b $(TARGET) -n 4 + cp Build/OvmfX64/$(TARGET)_GCC*/FV/OVMF.fd ovmf.bin .PHONY: clean clean: -- 2.11.0
[xen-unstable-smoke test] 162973: tolerable all pass - PUSHED
flight 162973 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/162973/ 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen c9b59f9032d41be8bade8a25d9148cf6ed203704 baseline version: xen 8af4b47f061edf6450f2b0a0a8134fdf1c13b3e5 Last test of basis 162880 2021-06-17 17:00:36 Z4 days Testing same since 162942 2021-06-21 16:00:26 Z0 days6 attempts People who touched revisions under test: George Dunlap Nick Rosbrook Nick Rosbrook jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 8af4b47f06..c9b59f9032 c9b59f9032d41be8bade8a25d9148cf6ed203704 -> smoke
[PATCH v2 6/6] libxc: make xc_domain_maximum_gpfn() endianness-agnostic
libxc generally uses uint32_t to represent domain IDs. This is fine as
long as addresses of such variables aren't taken, to then pass into
hypercalls: To the hypervisor, a domain ID is a 16-bit value. Introduce
a wrapper struct to deal with the issue. (On architectures with
arguments passed in registers, an intermediate variable would have been
created by the compiler already anyway, just one of the wrong type.)
The public interface change is both source and binary compatible for
the architectures we currently support.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
---
v2: Introduce wrapper struct in public interface.
---
Together with the comment change I was half tempted to also rename the
sub-function identifier to XENMEM_maximum_gfn. But I then decided this
would go too far here.
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -856,7 +856,8 @@ int xc_domain_get_tsc_info(xc_interface
int xc_domain_maximum_gpfn(xc_interface *xch, uint32_t domid, xen_pfn_t *gpfns)
{
-long rc = do_memory_op(xch, XENMEM_maximum_gpfn, , sizeof(domid));
+struct xen_memory_domain dom = { .domid = domid };
+long rc = do_memory_op(xch, XENMEM_maximum_gpfn, , sizeof(dom));
if ( rc >= 0 )
{
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1351,7 +1351,6 @@ long do_memory_op(unsigned long cmd, XEN
long rc;
struct xen_memory_reservation reservation;
struct memop_args args;
-domid_t domid;
unsigned long start_extent = cmd >> MEMOP_EXTENT_SHIFT;
int op = cmd & MEMOP_CMD_MASK;
@@ -1452,13 +1451,16 @@ long do_memory_op(unsigned long cmd, XEN
case XENMEM_current_reservation:
case XENMEM_maximum_reservation:
case XENMEM_maximum_gpfn:
+{
+struct xen_memory_domain domain;
+
if ( unlikely(start_extent) )
return -EINVAL;
-if ( copy_from_guest(, arg, 1) )
+if ( copy_from_guest(, arg, 1) )
return -EFAULT;
-d = rcu_lock_domain_by_any_id(domid);
+d = rcu_lock_domain_by_any_id(domain.domid);
if ( d == NULL )
return -ESRCH;
@@ -1486,6 +1488,7 @@ long do_memory_op(unsigned long cmd, XEN
rcu_unlock_domain(d);
break;
+}
case XENMEM_add_to_physmap:
{
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -148,16 +148,23 @@ DEFINE_XEN_GUEST_HANDLE(xen_memory_excha
*/
#define XENMEM_maximum_ram_page 2
+struct xen_memory_domain {
+/* [IN] Domain information is being queried for. */
+domid_t domid;
+};
+
/*
* Returns the current or maximum memory reservation, in pages, of the
* specified domain (may be DOMID_SELF). Returns -ve errcode on failure.
- * arg == addr of domid_t.
+ * arg == addr of struct xen_memory_domain.
*/
#define XENMEM_current_reservation 3
#define XENMEM_maximum_reservation 4
/*
- * Returns the maximum GPFN in use by the guest, or -ve errcode on failure.
+ * Returns the maximum GFN in use by the specified domain (may be DOMID_SELF).
+ * Returns -ve errcode on failure.
+ * arg == addr of struct xen_memory_domain.
*/
#define XENMEM_maximum_gpfn 14
[PATCH v2 5/6] libxencall: drop bogus mentioning of xencall6()
There's no xencall6(), so the version script also shouldn't mention it.
If such a function would ever appear, it shouldn't land in version 1.0.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
---
v2: Split out of earlier patch.
--- a/tools/libs/call/libxencall.map
+++ b/tools/libs/call/libxencall.map
@@ -9,7 +9,6 @@ VERS_1.0 {
xencall3;
xencall4;
xencall5;
- xencall6;
xencall_alloc_buffer;
xencall_free_buffer;
[PATCH v2 4/6] libxc: use multicall for memory-op on Linux (and Solaris)
Some sub-functions, XENMEM_maximum_gpfn and XENMEM_maximum_ram_page in
particular, can return values requiring more than 31 bits to represent.
Hence we cannot issue the hypercall directly when the return value of
ioctl() is used to propagate this value (note that this is not the case
for the BSDs, and MiniOS already wraps all hypercalls in a multicall).
Suggested-by: Jürgen Groß
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
--- a/tools/libs/ctrl/xc_private.c
+++ b/tools/libs/ctrl/xc_private.c
@@ -337,8 +337,47 @@ long do_memory_op(xc_interface *xch, int
goto out1;
}
-ret = xencall2(xch->xcall, __HYPERVISOR_memory_op,
- cmd, HYPERCALL_BUFFER_AS_ARG(arg));
+#if defined(__linux__) || defined(__sun__)
+/*
+ * Some sub-ops return values which don't fit in "int". On platforms
+ * without a specific hypercall return value field in the privcmd
+ * interface structure, issue the request as a single-element multicall,
+ * to be able to capture the full return value.
+ */
+if ( sizeof(long) > sizeof(int) )
+{
+multicall_entry_t multicall = {
+.op = __HYPERVISOR_memory_op,
+.args[0] = cmd,
+.args[1] = HYPERCALL_BUFFER_AS_ARG(arg),
+}, *call =
+DECLARE_HYPERCALL_BOUNCE(call, sizeof(*call),
+ XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+
+if ( xc_hypercall_bounce_pre(xch, call) )
+{
+PERROR("Could not bounce buffer for memory_op hypercall");
+goto out1;
+}
+
+ret = do_multicall_op(xch, HYPERCALL_BUFFER(call), 1);
+
+xc_hypercall_bounce_post(xch, call);
+
+if ( !ret )
+{
+ret = multicall.result;
+if ( multicall.result > ~0xfffUL )
+{
+errno = -ret;
+ret = -1;
+}
+}
+}
+else
+#endif
+ret = xencall2L(xch->xcall, __HYPERVISOR_memory_op,
+cmd, HYPERCALL_BUFFER_AS_ARG(arg));
xc_hypercall_bounce_post(xch, arg);
out1:
[PATCH v2 3/6] libxencall: introduce variant of xencall2() returning long
Some hypercalls, memory-op in particular, can return values requiring
more than 31 bits to represent. Hence the underlying layers need to make
sure they won't truncate such values.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
---
v2: Move dropping of xencall6 from the version script to a separate
patch.
---
I wasn't sure whether equivalents for the other xencall() should also
be introduced, and hence I went for the minimal solution first. Otoh
there's also xencall0() without any users ...
--- a/tools/include/xencall.h
+++ b/tools/include/xencall.h
@@ -113,6 +113,10 @@ int xencall5(xencall_handle *xcall, unsi
uint64_t arg1, uint64_t arg2, uint64_t arg3,
uint64_t arg4, uint64_t arg5);
+/* Variant(s) of the above, as needed, returning "long" instead of "int". */
+long xencall2L(xencall_handle *xcall, unsigned int op,
+ uint64_t arg1, uint64_t arg2);
+
/*
* Allocate and free memory which is suitable for use as a pointer
* argument to a hypercall.
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -127,6 +127,17 @@ int xencall2(xencall_handle *xcall, unsi
return osdep_hypercall(xcall, );
}
+long xencall2L(xencall_handle *xcall, unsigned int op,
+ uint64_t arg1, uint64_t arg2)
+{
+privcmd_hypercall_t call = {
+.op = op,
+.arg = { arg1, arg2 },
+};
+
+return osdep_hypercall(xcall, );
+}
+
int xencall3(xencall_handle *xcall, unsigned int op,
uint64_t arg1, uint64_t arg2, uint64_t arg3)
{
--- a/tools/libs/call/libxencall.map
+++ b/tools/libs/call/libxencall.map
@@ -27,3 +27,8 @@ VERS_1.2 {
global:
xencall_fd;
} VERS_1.1;
+
+VERS_1.3 {
+ global:
+ xencall2L;
+} VERS_1.2;
[PATCH v2 2/6] libxencall: osdep_hypercall() should return long
Some hypercalls, memory-op in particular, can return values requiring
more than 31 bits to represent. Hence the underlying layers need to make
sure they won't truncate such values. (Note that for Solaris the
function also gets renamed, to match the other OSes.)
Due to them merely propagating ioctl()'s return value, this change is
benign on Linux and Solaris. IOW there's an actual effect here only for
the BSDs and MiniOS, but even then further adjustments are needed at the
xencall() level.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Acked-by: Ian Jackson
--- a/tools/libs/call/freebsd.c
+++ b/tools/libs/call/freebsd.c
@@ -62,7 +62,7 @@ int osdep_xencall_close(xencall_handle *
return close(fd);
}
-int osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
+long osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
{
int fd = xcall->fd;
int ret;
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -80,7 +80,7 @@ int osdep_xencall_close(xencall_handle *
return 0;
}
-int osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
+long osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
{
return ioctl(xcall->fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
}
--- a/tools/libs/call/minios.c
+++ b/tools/libs/call/minios.c
@@ -38,7 +38,7 @@ int osdep_xencall_close(xencall_handle *
return 0;
}
-int osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
+long osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
{
multicall_entry_t call;
int i, ret;
--- a/tools/libs/call/netbsd.c
+++ b/tools/libs/call/netbsd.c
@@ -96,7 +96,7 @@ void osdep_free_pages(xencall_handle *xc
free(ptr);
}
-int osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
+long osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
{
int fd = xcall->fd;
int error = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
--- a/tools/libs/call/private.h
+++ b/tools/libs/call/private.h
@@ -55,7 +55,7 @@ struct xencall_handle {
int osdep_xencall_open(xencall_handle *xcall);
int osdep_xencall_close(xencall_handle *xcall);
-int osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall);
+long osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall);
void *osdep_alloc_pages(xencall_handle *xcall, size_t nr_pages);
void osdep_free_pages(xencall_handle *xcall, void *p, size_t nr_pages);
--- a/tools/libs/call/solaris.c
+++ b/tools/libs/call/solaris.c
@@ -80,7 +80,7 @@ void osdep_free_hypercall_buffer(xencall
free(ptr);
}
-int do_xen_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
+long osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall)
{
int fd = xcall->fd;
return ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
[PATCH v2 1/6] x86/HVM: wire up multicalls
To be able to use them from, in particular, the tool stack, they need to
be supported for all guest types. Note that xc_resource_op() already
does, so would not work without this on PVH Dom0.
Signed-off-by: Jan Beulich
Begrudingly acked-by: Andrew Cooper
Acked-by: Ian Jackson
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -125,6 +126,7 @@ static const struct {
hypercall_fn_t *native, *compat;
} hvm_hypercall_table[] = {
HVM_CALL(memory_op),
+COMPAT_CALL(multicall),
#ifdef CONFIG_GRANT_TABLE
HVM_CALL(grant_table_op),
#endif
@@ -334,6 +336,39 @@ int hvm_hypercall(struct cpu_user_regs *
return curr->hcall_preempted ? HVM_HCALL_preempted : HVM_HCALL_completed;
}
+enum mc_disposition hvm_do_multicall_call(struct mc_state *state)
+{
+struct vcpu *curr = current;
+hypercall_fn_t *func = NULL;
+
+if ( hvm_guest_x86_mode(curr) == 8 )
+{
+struct multicall_entry *call = >call;
+
+if ( call->op < ARRAY_SIZE(hvm_hypercall_table) )
+func = array_access_nospec(hvm_hypercall_table, call->op).native;
+if ( func )
+call->result = func(call->args[0], call->args[1], call->args[2],
+call->args[3], call->args[4], call->args[5]);
+else
+call->result = -ENOSYS;
+}
+else
+{
+struct compat_multicall_entry *call = >compat_call;
+
+if ( call->op < ARRAY_SIZE(hvm_hypercall_table) )
+func = array_access_nospec(hvm_hypercall_table, call->op).compat;
+if ( func )
+call->result = func(call->args[0], call->args[1], call->args[2],
+call->args[3], call->args[4], call->args[5]);
+else
+call->result = -ENOSYS;
+}
+
+return !hvm_get_cpl(curr) ? mc_continue : mc_preempt;
+}
+
/*
* Local variables:
* mode: C
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -20,6 +20,7 @@
*/
#include
+#include
#ifdef CONFIG_COMPAT
#define ARGS(x, n) \
@@ -273,13 +274,18 @@ int hypercall_xlat_continuation(unsigned
return rc;
}
-#ifndef CONFIG_PV
-/* Stub for arch_do_multicall_call */
-enum mc_disposition arch_do_multicall_call(struct mc_state *mc)
+enum mc_disposition arch_do_multicall_call(struct mc_state *state)
{
+const struct domain *currd = current->domain;
+
+if ( is_pv_domain(currd) )
+return pv_do_multicall_call(state);
+
+if ( is_hvm_domain(currd) )
+return hvm_do_multicall_call(state);
+
return mc_exit;
}
-#endif
/*
* Local variables:
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PV32
@@ -245,7 +246,7 @@ void pv_hypercall(struct cpu_user_regs *
perfc_incr(hypercalls);
}
-enum mc_disposition arch_do_multicall_call(struct mc_state *state)
+enum mc_disposition pv_do_multicall_call(struct mc_state *state)
{
struct vcpu *curr = current;
unsigned long op;
--- /dev/null
+++ b/xen/include/asm-x86/multicall.h
@@ -0,0 +1,12 @@
+/**
+ * asm-x86/multicall.h
+ */
+
+#ifndef __ASM_X86_MULTICALL_H__
+#define __ASM_X86_MULTICALL_H__
+
+#include
+
+typeof(arch_do_multicall_call) pv_do_multicall_call, hvm_do_multicall_call;
+
+#endif /* __ASM_X86_MULTICALL_H__ */
[PATCH v2 0/6] allow xc_domain_maximum_gpfn() to observe full GFN value
The present remaining osstest failures are due to truncation of the GFN
resulting from the hypercall return value being passed back through the
ioctl() return value (on Linux and Solaris), which is "int", plus the
same for some further internal interfaces (osdep_hypercall(),
xencall()). Some of the memory-op sub-ops, like the one involved
here, may pass back values which don't fit into "int".
Different effects can be observed with a 32- and 64-bit tool stack,
each causing one test to fail. The changes here will only deal with
the truncation resulting when sizeof(int) < sizeof(long), i.e. only on
64-bit. For the 32-bit tool stack case to work in such a situation,
yet uglier hackery would be needed. But even if the full value got
passed back, we'd then hit:
#ifdef __i386__
/* Very large domains (> 1TB) will exhaust virtual address space. */
if ( nr_pfns > 0x0fff )
{
errno = E2BIG;
PERROR("Cannot save this big a guest");
return -1;
}
#endif
in xg_sr_save_x86_hvm.c:x86_hvm_setup() (and there's a similar check
on the restore path).
I wonder in how far a guest property can legitimately cause an osstest
push to be prevented by causing a failure like this one. And of course
I'm also puzzled by the ovmf change having managed to make it through
its push gate.
Note that I can't tell at this point whether there aren't further
issues, as I've not actually tried the ovmf case. I could easily see
there being oom issues there then, once to full value gets used for
setting up the p2m monitoring during migration. Or processing might
then take overly long.
See the individual patches for changes in v2, all of which are to
address review feedback.
1: x86/HVM: wire up multicalls
2: libxencall: osdep_hypercall() should return long
3: libxencall: introduce variant of xencall2() returning long
4: libxc: use multicall for memory-op on Linux (and Solaris)
5: libxencall: drop bogus mentioning of xencall6()
6: libxc: make xc_domain_maximum_gpfn() endianness-agnostic
Jan
Re: Interrupt for port 19, but apparently not enabled; per-user 000000004af23acc
On 22.06.21 14:21, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut here ]
[ 7.581899] Interrupt for port 19, but apparently not
enabled;
per-user 4af23acc
[ 7.583401] WARNING: CPU: 0 PID: 467 at
/home/ANT.AMAZON.COM/jgrall/works/oss/linux/drivers/xen/evtchn.c:169
evtchn_interrupt+0xd5/0x100
[ 7.585583] Modules linked in:
[ 7.586188] CPU: 0 PID: 467 Comm: xenstore-read Not
tainted
5.13.0-rc6 #240
[ 7.587462] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 7.589462] RIP: e030:evtchn_interrupt+0xd5/0x100
[ 7.590361] Code: 48 8d bb d8 01 00 00 ba 01 00 00 00
be 1d 00 00 00
e8 5f 72 c4 ff eb b2 8b 75 20 48 89 da 48 c7 c7 a8 03 5f 82 e8 6b 2d 96
ff <0f> 0b e9 4d ff ff ff 41 0f b6 f4 48 c7 c7 80 da a2 82 e8 f0
[ 7.593662] RSP: e02b:c90040003e60 EFLAGS: 00010082
[ 7.594636] RAX: RBX: 888102328c00 RCX:
0027
[ 7.595924] RDX: RSI: 88817fe18ad0 RDI:
88817fe18ad8
[ 7.597216] RBP: 888108ef8140 R08: R09:
0001
[ 7.598522] R10: R11: 7075727265746e49 R12:
[ 7.599810] R13: c90040003ec4 R14: 8881001b8000 R15:
888109b36f80
[ 7.601113] FS: () GS:88817fe0()
knlGS:
[ 7.602570] CS: 1e030 DS: ES: CR0:80050033
[ 7.603700] CR2: 7f15b390e368 CR3: 00010bb04000 CR4:
00050660
[ 7.604993] Call Trace:
[ 7.605501]
[ 7.605929] __handle_irq_event_percpu+0x4c/0x330
[ 7.606817] handle_irq_event_percpu+0x32/0xa0
[ 7.607670] handle_irq_event+0x3a/0x60
[ 7.608416] handle_edge_irq+0x9b/0x1f0
[ 7.609154] generic_handle_irq+0x4f/0x60
[ 7.609918] __evtchn_fifo_handle_events+0x195/0x3a0
[ 7.610864] __xen_evtchn_do_upcall+0x66/0xb0
[ 7.611693] __xen_pv_evtchn_do_upcall+0x1d/0x30
[ 7.612582] xen_pv_evtchn_do_upcall+0x9d/0xc0
[ 7.613439]
[ 7.613882] exc_xen_hypervisor_callback+0x8/0x10
This is quite similar to the problem I reported a few months ago (see
[1]) but this time this is happening with fifo rather than 2L.
I haven't been able to reproduced it reliably so far. But looking at
the code, I think I have found another potential race after commit
commit b6622798bc50b625a1e62f82c7190df40c1f5b21
Author: Juergen Gross
Date: Sat Mar 6 17:18:33 2021 +0100
xen/events: avoid handling the same event on two cpusat the same
time
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled
on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the
per-event data
and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Link:
https://lore.kernel.org/r/20210306161833.4552-4-jgr...@suse.com
Signed-off-by: Boris Ostrovsky
The evtchn driver will use the lateeoi handlers. So the code to ack
looks like:
do_mask(..., EVT_MASK_REASON_EOI_PENDING)
smp_store_release(>is_active, 0);
clear_evtchn(info->evtchn);
The code to handle an interrupts look like:
clear_link(...)
if ( evtchn_fifo_is_pending(port) && !evtchn_fifo_is_mask()) {
if (xchg_acquire(>is_active, 1)
return;
generic_handle_irq();
}
After changing the affinity, an interrupt may be received once on the
previous vCPU. So, I think the following can happen:
vCPU0 | vCPU1
|
Receive event |
| change affinity to vCPU1
clear_link() |
|
/* The interrupt is re-raised */
| receive event
|
| /* The interrupt is not masked */
info->is_active = 1 |
do_mask(...) |
info->is_active = 0 |
| info->is_active = 1
clear_evtchn(...) |
| do_mask(...)
| info->is_active = 0
| clear_evtchn(...)
Does this look plausible to you?
Yes, it does.
Thanks for the analysis.
So I guess for lateeoi events we need to clear is_active only in
xen_irq_lateeoi()? At a first glance this should fix the issue.
It should work and would be quite neat. But, I believe clear_evtchn()
would have to stick in the ack helper to avoid losing interrupts.
Could you try the attached patch, please? Only compile tested.
Juergen
From
[PATCH v2] dma-mapping: use vmalloc_to_page for vmalloc addresses
This commit is dedicated to fix incorrect conversion from
cpu_addr to page address in cases when we get virtual
address which allocated in the vmalloc range.
As the result, virt_to_page() cannot convert this address
properly and return incorrect page address.
Need to detect such cases and obtains the page address using
vmalloc_to_page() instead.
Signed-off-by: Roman Skakun
Reviewed-by: Andrii Anisov
---
Hey!
Thanks for suggestions, Christoph!
I updated the patch according to your advice.
But, I'm so surprised because nobody catches this problem
in the common code before. It looks a bit strange as for me.
kernel/dma/ops_helpers.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
index 910ae69cae77..782728d8a393 100644
--- a/kernel/dma/ops_helpers.c
+++ b/kernel/dma/ops_helpers.c
@@ -5,6 +5,14 @@
*/
#include
+static struct page *cpu_addr_to_page(void *cpu_addr)
+{
+ if (is_vmalloc_addr(cpu_addr))
+ return vmalloc_to_page(cpu_addr);
+ else
+ return virt_to_page(cpu_addr);
+}
+
/*
* Create scatter-list for the already allocated DMA buffer.
*/
@@ -12,7 +20,7 @@ int dma_common_get_sgtable(struct device *dev, struct
sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- struct page *page = virt_to_page(cpu_addr);
+ struct page *page = cpu_addr_to_page(cpu_addr);
int ret;
ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
@@ -43,7 +51,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct
*vma,
return -ENXIO;
return remap_pfn_range(vma, vma->vm_start,
- page_to_pfn(virt_to_page(cpu_addr)) + vma->vm_pgoff,
+ page_to_pfn(cpu_addr_to_page(cpu_addr)) + vma->vm_pgoff,
user_count << PAGE_SHIFT, vma->vm_page_prot);
#else
return -ENXIO;
--
2.25.1
Re: Interrupt for port 19, but apparently not enabled; per-user 000000004af23acc
On 22.06.21 14:21, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut here ]
[ 7.581899] Interrupt for port 19, but apparently not
enabled;
per-user 4af23acc
[ 7.583401] WARNING: CPU: 0 PID: 467 at
/home/ANT.AMAZON.COM/jgrall/works/oss/linux/drivers/xen/evtchn.c:169
evtchn_interrupt+0xd5/0x100
[ 7.585583] Modules linked in:
[ 7.586188] CPU: 0 PID: 467 Comm: xenstore-read Not
tainted
5.13.0-rc6 #240
[ 7.587462] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 7.589462] RIP: e030:evtchn_interrupt+0xd5/0x100
[ 7.590361] Code: 48 8d bb d8 01 00 00 ba 01 00 00 00
be 1d 00 00 00
e8 5f 72 c4 ff eb b2 8b 75 20 48 89 da 48 c7 c7 a8 03 5f 82 e8 6b 2d 96
ff <0f> 0b e9 4d ff ff ff 41 0f b6 f4 48 c7 c7 80 da a2 82 e8 f0
[ 7.593662] RSP: e02b:c90040003e60 EFLAGS: 00010082
[ 7.594636] RAX: RBX: 888102328c00 RCX:
0027
[ 7.595924] RDX: RSI: 88817fe18ad0 RDI:
88817fe18ad8
[ 7.597216] RBP: 888108ef8140 R08: R09:
0001
[ 7.598522] R10: R11: 7075727265746e49 R12:
[ 7.599810] R13: c90040003ec4 R14: 8881001b8000 R15:
888109b36f80
[ 7.601113] FS: () GS:88817fe0()
knlGS:
[ 7.602570] CS: 1e030 DS: ES: CR0:80050033
[ 7.603700] CR2: 7f15b390e368 CR3: 00010bb04000 CR4:
00050660
[ 7.604993] Call Trace:
[ 7.605501]
[ 7.605929] __handle_irq_event_percpu+0x4c/0x330
[ 7.606817] handle_irq_event_percpu+0x32/0xa0
[ 7.607670] handle_irq_event+0x3a/0x60
[ 7.608416] handle_edge_irq+0x9b/0x1f0
[ 7.609154] generic_handle_irq+0x4f/0x60
[ 7.609918] __evtchn_fifo_handle_events+0x195/0x3a0
[ 7.610864] __xen_evtchn_do_upcall+0x66/0xb0
[ 7.611693] __xen_pv_evtchn_do_upcall+0x1d/0x30
[ 7.612582] xen_pv_evtchn_do_upcall+0x9d/0xc0
[ 7.613439]
[ 7.613882] exc_xen_hypervisor_callback+0x8/0x10
This is quite similar to the problem I reported a few months ago (see
[1]) but this time this is happening with fifo rather than 2L.
I haven't been able to reproduced it reliably so far. But looking at
the code, I think I have found another potential race after commit
commit b6622798bc50b625a1e62f82c7190df40c1f5b21
Author: Juergen Gross
Date: Sat Mar 6 17:18:33 2021 +0100
xen/events: avoid handling the same event on two cpusat the same
time
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled
on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the
per-event data
and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Link:
https://lore.kernel.org/r/20210306161833.4552-4-jgr...@suse.com
Signed-off-by: Boris Ostrovsky
The evtchn driver will use the lateeoi handlers. So the code to ack
looks like:
do_mask(..., EVT_MASK_REASON_EOI_PENDING)
smp_store_release(>is_active, 0);
clear_evtchn(info->evtchn);
The code to handle an interrupts look like:
clear_link(...)
if ( evtchn_fifo_is_pending(port) && !evtchn_fifo_is_mask()) {
if (xchg_acquire(>is_active, 1)
return;
generic_handle_irq();
}
After changing the affinity, an interrupt may be received once on the
previous vCPU. So, I think the following can happen:
vCPU0 | vCPU1
|
Receive event |
| change affinity to vCPU1
clear_link() |
|
/* The interrupt is re-raised */
| receive event
|
| /* The interrupt is not masked */
info->is_active = 1 |
do_mask(...) |
info->is_active = 0 |
| info->is_active = 1
clear_evtchn(...) |
| do_mask(...)
| info->is_active = 0
| clear_evtchn(...)
Does this look plausible to you?
Yes, it does.
Thanks for the analysis.
So I guess for lateeoi events we need to clear is_active only in
xen_irq_lateeoi()? At a first glance this should fix the issue.
It should work and would be quite neat. But, I believe clear_evtchn()
would have to stick in the ack helper to avoid losing interrupts.
I agree.
Preparing a patch ...
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public
Re: Interrupt for port 19, but apparently not enabled; per-user 000000004af23acc
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut here ]
[ 7.581899] Interrupt for port 19, but apparently not
enabled;
per-user 4af23acc
[ 7.583401] WARNING: CPU: 0 PID: 467 at
/home/ANT.AMAZON.COM/jgrall/works/oss/linux/drivers/xen/evtchn.c:169
evtchn_interrupt+0xd5/0x100
[ 7.585583] Modules linked in:
[ 7.586188] CPU: 0 PID: 467 Comm: xenstore-read Not tainted
5.13.0-rc6 #240
[ 7.587462] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 7.589462] RIP: e030:evtchn_interrupt+0xd5/0x100
[ 7.590361] Code: 48 8d bb d8 01 00 00 ba 01 00 00 00
be 1d 00 00 00
e8 5f 72 c4 ff eb b2 8b 75 20 48 89 da 48 c7 c7 a8 03 5f 82 e8 6b 2d 96
ff <0f> 0b e9 4d ff ff ff 41 0f b6 f4 48 c7 c7 80 da a2 82 e8 f0
[ 7.593662] RSP: e02b:c90040003e60 EFLAGS: 00010082
[ 7.594636] RAX: RBX: 888102328c00 RCX:
0027
[ 7.595924] RDX: RSI: 88817fe18ad0 RDI:
88817fe18ad8
[ 7.597216] RBP: 888108ef8140 R08: R09:
0001
[ 7.598522] R10: R11: 7075727265746e49 R12:
[ 7.599810] R13: c90040003ec4 R14: 8881001b8000 R15:
888109b36f80
[ 7.601113] FS: () GS:88817fe0()
knlGS:
[ 7.602570] CS: 1e030 DS: ES: CR0: 80050033
[ 7.603700] CR2: 7f15b390e368 CR3: 00010bb04000 CR4:
00050660
[ 7.604993] Call Trace:
[ 7.605501]
[ 7.605929] __handle_irq_event_percpu+0x4c/0x330
[ 7.606817] handle_irq_event_percpu+0x32/0xa0
[ 7.607670] handle_irq_event+0x3a/0x60
[ 7.608416] handle_edge_irq+0x9b/0x1f0
[ 7.609154] generic_handle_irq+0x4f/0x60
[ 7.609918] __evtchn_fifo_handle_events+0x195/0x3a0
[ 7.610864] __xen_evtchn_do_upcall+0x66/0xb0
[ 7.611693] __xen_pv_evtchn_do_upcall+0x1d/0x30
[ 7.612582] xen_pv_evtchn_do_upcall+0x9d/0xc0
[ 7.613439]
[ 7.613882] exc_xen_hypervisor_callback+0x8/0x10
This is quite similar to the problem I reported a few months ago (see
[1]) but this time this is happening with fifo rather than 2L.
I haven't been able to reproduced it reliably so far. But looking at
the code, I think I have found another potential race after commit
commit b6622798bc50b625a1e62f82c7190df40c1f5b21
Author: Juergen Gross
Date: Sat Mar 6 17:18:33 2021 +0100
xen/events: avoid handling the same event on two cpus at the same
time
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled
on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Link: https://lore.kernel.org/r/20210306161833.4552-4-jgr...@suse.com
Signed-off-by: Boris Ostrovsky
The evtchn driver will use the lateeoi handlers. So the code to ack
looks like:
do_mask(..., EVT_MASK_REASON_EOI_PENDING)
smp_store_release(>is_active, 0);
clear_evtchn(info->evtchn);
The code to handle an interrupts look like:
clear_link(...)
if ( evtchn_fifo_is_pending(port) && !evtchn_fifo_is_mask()) {
if (xchg_acquire(>is_active, 1)
return;
generic_handle_irq();
}
After changing the affinity, an interrupt may be received once on the
previous vCPU. So, I think the following can happen:
vCPU0 | vCPU1
|
Receive event |
| change affinity to vCPU1
clear_link() |
|
/* The interrupt is re-raised */
| receive event
|
| /* The interrupt is not masked */
info->is_active = 1 |
do_mask(...) |
info->is_active = 0 |
| info->is_active = 1
clear_evtchn(...) |
| do_mask(...)
| info->is_active = 0
| clear_evtchn(...)
Does this look plausible to you?
Yes, it does.
Thanks for the analysis.
So I guess for lateeoi events we need to clear is_active only in
xen_irq_lateeoi()? At a first glance this should fix the issue.
It should work and would be quite neat. But, I believe clear_evtchn()
would have to stick in the ack helper to avoid losing interrupts.
Cheers,
--
Julien Grall
Re: [PATCH 3/5] libxencall: introduce variant of xencall2() returning long
Jan Beulich writes ("[PATCH 3/5] libxencall: introduce variant of xencall2()
returning long"):
> Some hypercalls, memory-op in particular, can return values requiring
> more than 31 bits to represent. Hence the underlying layers need to make
> sure they won't truncate such values.
Thanks for this.
All 5 patches:
Acked-by: Ian Jackson
Nit:
> While adding the new function to the map file, I noticed the stray
> xencall6 there. I'm taking the liberty to remove it at this occasion. If
> such a function would ever appear, it shouldn't lane in version 1.0.
Typo for "land", I think.
Ian.
[ovmf test] 162956: trouble: blocked/broken/preparing/queued
flight 162956 ovmf running [real] http://logs.test-lab.xenproject.org/osstest/logs/162956/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-i3864 host-install(4)broken REGR. vs. 162359 build-i386-pvops 4 host-install(4)broken REGR. vs. 162359 build-i386-xsm4 host-install(4)broken REGR. vs. 162359 build-amd64-pvops 4 host-install(4)broken REGR. vs. 162359 build-amd64-libvirt queued test-amd64-amd64-xl-qemuu-ovmf-amd64 queued test-amd64-i386-xl-qemuu-ovmf-amd64 queued build-amd64-xsm 2 hosts-allocate running build-amd64 2 hosts-allocate running Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf 6cfeeb71c43173d657d86d4a38ed655b0fc5f277 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 18 days Failing since162368 2021-06-04 15:42:59 Z 17 days 38 attempts Testing same since 162938 2021-06-21 11:33:16 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Daoxiang Li gaoliming Hao A Wu Jian J Wang Kaaira Gupta Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Maurice Ma Ni, Ray Patrick Rudolph Ray Ni Rebecca Cran Scottie Kuo Sean Brogan Sean Brogan Sumana Venur Zhiguang Liu jobs: build-amd64-xsm preparing build-i386-xsm broken build-amd64 preparing build-i386 broken build-amd64-libvirt queued build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 queued test-amd64-i386-xl-qemuu-ovmf-amd64 queued sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-amd64-libvirt queued broken-job build-amd64-pvops broken broken-job build-i386 broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken broken-job test-amd64-amd64-xl-qemuu-ovmf-amd64 queued broken-job test-amd64-i386-xl-qemuu-ovmf-amd64 queued broken-step build-i386 host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-i386-xsm host-install(4) broken-step build-amd64-pvops host-install(4) Not pushing. (No revision log; it would be 2193 lines long.)
[libvirt test] 162958: regressions - trouble: blocked/broken/fail/pass/preparing/queued
flight 162958 libvirt running [real] http://logs.test-lab.xenproject.org/osstest/logs/162958/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-i386-pvops 4 host-install(4)broken REGR. vs. 151777 build-arm64 4 host-install(4)broken REGR. vs. 151777 build-i3864 host-install(4)broken REGR. vs. 151777 build-arm64-pvops 4 host-install(4)broken REGR. vs. 151777 build-arm64-xsm 4 host-install(4)broken REGR. vs. 151777 build-i386-xsm4 host-install(4)broken REGR. vs. 151777 build-armhf-pvops 4 host-install(4)broken REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt queued test-amd64-amd64-libvirt queued test-amd64-amd64-libvirt-pair queued test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm queued test-amd64-amd64-libvirt-vhd queued test-amd64-amd64-libvirt-xsm queued test-amd64-i386-libvirt queued test-amd64-i386-libvirt-pair queued test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmqueued test-amd64-i386-libvirt-xsm queued build-amd64-pvops 2 hosts-allocate running build-amd64-xsm 2 hosts-allocate running build-amd64 2 hosts-allocate running Tests which did not succeed, but are not blocking: build-arm64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt b1112f6c0f4bd1244cd2913bfa5f1e0b6548049a baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 347 days Failing since151818 2020-07-11 04:18:52 Z 346 days 338 attempts Testing same since (not found) 0 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Andika Triwidada Andrea Bolognani Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brian Turek Bruno Haible Chris Mayo Christian Ehrhardt Christian Schoenebeck Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dmytro Linkin Eiichi Tsukata Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Hela Basa Helmut Grohne Ian Wienand Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark John Ferlan Jonathan Watt Jonathon Jongsma Julio Faracco Ján Tomko Kashyap Chamarthy Kevin Locke Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Liao Pingfang Lin Ma Lin Ma Lin Ma Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Neal Gompa Nick Shyrokovskiy Nickys Music Group Nico Pache Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Orion Poplawski Pany Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Ricky Tigg Roman Bogorodskiy Roman Bolshakov Ryan Gahagan
[qemu-mainline test] 162952: trouble: blocked/broken/pass/preparing/queued
flight 162952 qemu-mainline running [real] http://logs.test-lab.xenproject.org/osstest/logs/162952/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-arm64 4 host-install(4)broken REGR. vs. 152631 build-arm64-pvops 4 host-install(4)broken REGR. vs. 152631 build-arm64-xsm 4 host-install(4)broken REGR. vs. 152631 build-i386-xsm4 host-install(4)broken REGR. vs. 152631 build-i386-pvops 4 host-install(4)broken REGR. vs. 152631 build-i3864 host-install(4)broken REGR. vs. 152631 test-armhf-armhf-libvirt queued test-armhf-armhf-libvirt-raw queued test-armhf-armhf-xl queued test-armhf-armhf-xl-arndale queued test-armhf-armhf-xl-credit1 queued test-armhf-armhf-xl-multivcpu queued test-armhf-armhf-xl-rtds queued test-armhf-armhf-xl-vhd queued test-amd64-i386-pair queued test-amd64-i386-libvirt-xsm queued test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmqueued test-amd64-i386-libvirt-pair queued test-amd64-i386-libvirt queued test-amd64-i386-freebsd10-i386 queued test-amd64-i386-freebsd10-amd64 queued test-amd64-coresched-i386-xl queued test-amd64-coresched-amd64-xl queued test-amd64-amd64-xl-xsm queued test-amd64-amd64-xl-shadowqueued test-amd64-amd64-xl-rtds queued build-amd64-libvirt queued test-amd64-amd64-xl-qemuu-ws16-amd64 queued test-amd64-amd64-xl-qemuu-win7-amd64 queued test-amd64-amd64-xl-qemuu-ovmf-amd64 queued test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictqueued test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm queued test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow queued test-amd64-amd64-xl-qemuu-debianhvm-amd64queued test-amd64-amd64-amd64-pvgrub queued test-amd64-amd64-xl-qcow2 queued test-amd64-amd64-dom0pvh-xl-amd queued test-amd64-amd64-xl-pvshimqueued test-amd64-amd64-dom0pvh-xl-intel queued test-amd64-amd64-i386-pvgrub queued test-amd64-amd64-libvirt queued test-amd64-amd64-xl-pvhv2-intel queued test-amd64-amd64-libvirt-pair queued test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm queued test-amd64-amd64-xl-pvhv2-amd queued test-amd64-amd64-libvirt-vhd queued test-amd64-amd64-libvirt-xsm queued test-amd64-amd64-xl-multivcpu queued test-amd64-amd64-pair queued test-amd64-amd64-pygrub queued test-amd64-amd64-xl-credit2 queued test-amd64-amd64-qemuu-freebsd11-amd64 queued test-amd64-amd64-qemuu-freebsd12-amd64 queued test-amd64-amd64-xl-credit1 queued test-amd64-amd64-qemuu-nested-amd queued test-amd64-amd64-qemuu-nested-intel queued test-amd64-amd64-xl queued test-armhf-armhf-xl-credit2 queued test-armhf-armhf-xl-cubietruck queued test-amd64-i386-qemuu-rhel6hvm-amd queued test-amd64-i386-qemuu-rhel6hvm-intel queued test-amd64-i386-xlqueued test-amd64-i386-xl-pvshim queued test-amd64-i386-xl-qemuu-debianhvm-amd64 queued test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow queued test-amd64-i386-xl-qemuu-debianhvm-i386-xsm queued test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict queued test-amd64-i386-xl-qemuu-ovmf-amd64 queued test-amd64-i386-xl-qemuu-win7-amd64 queued test-amd64-i386-xl-qemuu-ws16-amd64 queued test-amd64-i386-xl-rawqueued test-amd64-i386-xl-shadow queued test-amd64-i386-xl-xsmqueued build-amd64 2 hosts-allocate running build-amd64-pvops 2
[linux-linus test] 162948: trouble: blocked/broken/pass/queued/running
flight 162948 linux-linus running [real] http://logs.test-lab.xenproject.org/osstest/logs/162948/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-i386-xsm4 host-install(4)broken REGR. vs. 152332 build-arm64-pvops 4 host-install(4)broken REGR. vs. 152332 build-arm64-xsm 4 host-install(4)broken REGR. vs. 152332 build-arm64 4 host-install(4)broken REGR. vs. 152332 build-i386-pvops 4 host-install(4)broken REGR. vs. 152332 build-i3864 host-install(4)broken REGR. vs. 152332 build-amd64-pvops 4 host-install(4)broken REGR. vs. 152332 build-amd64 4 host-install(4)broken REGR. vs. 152332 build-armhf-pvops 4 host-install(4)broken REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm queued test-amd64-i386-xl-qemuu-debianhvm-i386-xsm queued test-amd64-amd64-xl-xsm queued test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm queued test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmqueued test-amd64-amd64-xl-qemut-debianhvm-i386-xsm queued test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm queued test-amd64-amd64-libvirt-xsm queued test-amd64-i386-xl-xsmqueued test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmqueued test-amd64-i386-libvirt-xsm queued test-amd64-i386-xl-qemut-debianhvm-i386-xsm queued build-amd64-xsm 4 host-install(4) running build-amd64-xsm 3 syslog-serverrunning Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a
[xen-unstable test] 162963: trouble: blocked/broken/pass/preparing/queued/running
flight 162963 xen-unstable running [real] http://logs.test-lab.xenproject.org/osstest/logs/162963/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xtf broken build-arm64 broken build-arm64-pvopsbroken build-i386-prev broken build-i386-xsm broken build-arm64-pvops 4 host-install(4)broken REGR. vs. 162533 build-arm64 4 host-install(4)broken REGR. vs. 162533 build-i386-xsm4 host-install(4)broken REGR. vs. 162533 build-i386-prev 4 host-install(4)broken REGR. vs. 162533 build-amd64-xtf 4 host-install(4)broken REGR. vs. 162533 test-amd64-i386-qemuu-rhel6hvm-amd queued test-amd64-i386-qemuu-rhel6hvm-intel queued test-amd64-i386-xlqueued test-amd64-i386-xl-pvshim queued test-amd64-i386-xl-qemut-debianhvm-amd64 queued test-amd64-i386-xl-qemut-debianhvm-i386-xsm queued test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm queued test-amd64-i386-xl-qemut-win7-amd64 queued test-amd64-i386-xl-qemut-ws16-amd64 queued test-amd64-i386-xl-qemuu-debianhvm-amd64 queued test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict queued test-amd64-i386-xl-qemuu-ovmf-amd64 queued test-amd64-i386-xl-qemuu-win7-amd64 queued test-amd64-i386-xl-qemuu-ws16-amd64 queued test-amd64-i386-xl-rawqueued test-amd64-i386-xl-shadow queued test-amd64-i386-xl-xsmqueued test-arm64-arm64-libvirt-xsm queued test-arm64-arm64-xl-xsm queued test-armhf-armhf-examine queued test-armhf-armhf-libvirt queued test-armhf-armhf-libvirt-raw queued test-armhf-armhf-xl queued test-amd64-amd64-xl-rtds queued test-amd64-amd64-xl-qemuu-ws16-amd64 queued test-amd64-amd64-xl-qemuu-win7-amd64 queued test-amd64-amd64-xl-qemuu-ovmf-amd64 queued test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictqueued test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm queued test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow queued test-amd64-amd64-xl-qemuu-debianhvm-amd64queued test-amd64-amd64-xl-qemut-ws16-amd64 queued test-amd64-amd64-xl-qemut-win7-amd64 queued test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmqueued test-amd64-amd64-xl-qemut-debianhvm-i386-xsm queued build-amd64-libvirt queued test-amd64-amd64-xl-qemut-debianhvm-amd64queued test-amd64-amd64-xl-qcow2 queued test-amd64-amd64-xl-pvshimqueued test-amd64-amd64-xl-pvhv2-intel queued test-amd64-amd64-xl-pvhv2-amd queued test-amd64-amd64-xl-multivcpu queued test-amd64-amd64-xl-credit2 queued build-i386-libvirtqueued test-amd64-amd64-xl-credit1 queued test-amd64-amd64-xl queued test-amd64-amd64-amd64-pvgrub queued test-amd64-amd64-dom0pvh-xl-amd queued test-amd64-amd64-qemuu-nested-intel queued test-amd64-amd64-dom0pvh-xl-intel queued test-amd64-amd64-examine queued test-amd64-amd64-qemuu-nested-amd queued test-amd64-amd64-i386-pvgrub queued test-amd64-amd64-libvirt queued test-amd64-amd64-qemuu-freebsd12-amd64 queued test-amd64-amd64-libvirt-pair queued test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm queued test-amd64-amd64-qemuu-freebsd11-amd64 queued test-amd64-amd64-libvirt-vhd queued test-amd64-amd64-libvirt-xsm queued test-amd64-amd64-pygrub queued test-amd64-amd64-livepatchqueued test-amd64-amd64-migrupgrade queued test-amd64-amd64-pair queued test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow queued test-amd64-i386-xl-qemuu-debianhvm-i386-xsm queued test-amd64-amd64-xl-shadowqueued test-amd64-amd64-xl-xsm queued test-amd64-coresched-amd64-xl queued test-amd64-coresched-i386-xl queued
[OSSTEST PATCH] di-version update
Signed-off-by: Ian Jackson --- production-config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/production-config b/production-config index bc658006..9a405444 100644 --- a/production-config +++ b/production-config @@ -91,7 +91,7 @@ TftpNetbootGroup osstest TftpDiVersion_wheezy 2016-06-08 TftpDiVersion_jessie 2018-06-26 TftpDiVersion_stretch 2020-09-24 -TftpDiVersion_buster 2021-02-10 +TftpDiVersion_buster 2021-06-22 DebianMirror_buster_armhf http://snapshot.debian.org/archive/debian/20210124T203726Z/ -- 2.20.1
Re: Interrupt for port 19, but apparently not enabled; per-user 000000004af23acc
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut here ]
[ 7.581899] Interrupt for port 19, but apparently not
enabled;
per-user 4af23acc
[ 7.583401] WARNING: CPU: 0 PID: 467 at
/home/ANT.AMAZON.COM/jgrall/works/oss/linux/drivers/xen/evtchn.c:169
evtchn_interrupt+0xd5/0x100
[ 7.585583] Modules linked in:
[ 7.586188] CPU: 0 PID: 467 Comm: xenstore-read Not tainted
5.13.0-rc6 #240
[ 7.587462] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 7.589462] RIP: e030:evtchn_interrupt+0xd5/0x100
[ 7.590361] Code: 48 8d bb d8 01 00 00 ba 01 00 00 00
be 1d 00 00 00
e8 5f 72 c4 ff eb b2 8b 75 20 48 89 da 48 c7 c7 a8 03 5f 82 e8 6b 2d 96
ff <0f> 0b e9 4d ff ff ff 41 0f b6 f4 48 c7 c7 80 da a2 82 e8 f0
[ 7.593662] RSP: e02b:c90040003e60 EFLAGS: 00010082
[ 7.594636] RAX: RBX: 888102328c00 RCX:
0027
[ 7.595924] RDX: RSI: 88817fe18ad0 RDI:
88817fe18ad8
[ 7.597216] RBP: 888108ef8140 R08: R09:
0001
[ 7.598522] R10: R11: 7075727265746e49 R12:
[ 7.599810] R13: c90040003ec4 R14: 8881001b8000 R15:
888109b36f80
[ 7.601113] FS: () GS:88817fe0()
knlGS:
[ 7.602570] CS: 1e030 DS: ES: CR0: 80050033
[ 7.603700] CR2: 7f15b390e368 CR3: 00010bb04000 CR4:
00050660
[ 7.604993] Call Trace:
[ 7.605501]
[ 7.605929] __handle_irq_event_percpu+0x4c/0x330
[ 7.606817] handle_irq_event_percpu+0x32/0xa0
[ 7.607670] handle_irq_event+0x3a/0x60
[ 7.608416] handle_edge_irq+0x9b/0x1f0
[ 7.609154] generic_handle_irq+0x4f/0x60
[ 7.609918] __evtchn_fifo_handle_events+0x195/0x3a0
[ 7.610864] __xen_evtchn_do_upcall+0x66/0xb0
[ 7.611693] __xen_pv_evtchn_do_upcall+0x1d/0x30
[ 7.612582] xen_pv_evtchn_do_upcall+0x9d/0xc0
[ 7.613439]
[ 7.613882] exc_xen_hypervisor_callback+0x8/0x10
This is quite similar to the problem I reported a few months ago (see
[1]) but this time this is happening with fifo rather than 2L.
I haven't been able to reproduced it reliably so far. But looking at the
code, I think I have found another potential race after commit
commit b6622798bc50b625a1e62f82c7190df40c1f5b21
Author: Juergen Gross
Date: Sat Mar 6 17:18:33 2021 +0100
xen/events: avoid handling the same event on two cpus at the same time
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled
on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Link: https://lore.kernel.org/r/20210306161833.4552-4-jgr...@suse.com
Signed-off-by: Boris Ostrovsky
The evtchn driver will use the lateeoi handlers. So the code to ack
looks like:
do_mask(..., EVT_MASK_REASON_EOI_PENDING)
smp_store_release(>is_active, 0);
clear_evtchn(info->evtchn);
The code to handle an interrupts look like:
clear_link(...)
if ( evtchn_fifo_is_pending(port) && !evtchn_fifo_is_mask()) {
if (xchg_acquire(>is_active, 1)
return;
generic_handle_irq();
}
After changing the affinity, an interrupt may be received once on the
previous vCPU. So, I think the following can happen:
vCPU0 | vCPU1
|
Receive event |
| change affinity to vCPU1
clear_link() |
|
/* The interrupt is re-raised */
| receive event
|
| /* The interrupt is not masked */
info->is_active = 1 |
do_mask(...) |
info->is_active = 0 |
| info->is_active = 1
clear_evtchn(...) |
| do_mask(...)
| info->is_active = 0
| clear_evtchn(...)
Does this look plausible to you?
Yes, it does.
Thanks for the analysis.
So I guess for lateeoi events we need to clear is_active only in
xen_irq_lateeoi()? At a first glance this should fix the issue.
What do you think?
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Interrupt for port 19, but apparently not enabled; per-user 000000004af23acc
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[7.581000] [ cut here ]
[7.581899] Interrupt for port 19, but apparently not enabled;
per-user 4af23acc
[7.583401] WARNING: CPU: 0 PID: 467 at
/home/ANT.AMAZON.COM/jgrall/works/oss/linux/drivers/xen/evtchn.c:169
evtchn_interrupt+0xd5/0x100
[7.585583] Modules linked in:
[7.586188] CPU: 0 PID: 467 Comm: xenstore-read Not tainted
5.13.0-rc6 #240
[7.587462] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[7.589462] RIP: e030:evtchn_interrupt+0xd5/0x100
[7.590361] Code: 48 8d bb d8 01 00 00 ba 01 00 00 00 be 1d 00 00 00
e8 5f 72 c4 ff eb b2 8b 75 20 48 89 da 48 c7 c7 a8 03 5f 82 e8 6b 2d 96
ff <0f> 0b e9 4d ff ff ff 41 0f b6 f4 48 c7 c7 80 da a2 82 e8 f0
[7.593662] RSP: e02b:c90040003e60 EFLAGS: 00010082
[7.594636] RAX: RBX: 888102328c00 RCX:
0027
[7.595924] RDX: RSI: 88817fe18ad0 RDI:
88817fe18ad8
[7.597216] RBP: 888108ef8140 R08: R09:
0001
[7.598522] R10: R11: 7075727265746e49 R12:
[7.599810] R13: c90040003ec4 R14: 8881001b8000 R15:
888109b36f80
[7.601113] FS: () GS:88817fe0()
knlGS:
[7.602570] CS: 1e030 DS: ES: CR0: 80050033
[7.603700] CR2: 7f15b390e368 CR3: 00010bb04000 CR4:
00050660
[7.604993] Call Trace:
[7.605501]
[7.605929] __handle_irq_event_percpu+0x4c/0x330
[7.606817] handle_irq_event_percpu+0x32/0xa0
[7.607670] handle_irq_event+0x3a/0x60
[7.608416] handle_edge_irq+0x9b/0x1f0
[7.609154] generic_handle_irq+0x4f/0x60
[7.609918] __evtchn_fifo_handle_events+0x195/0x3a0
[7.610864] __xen_evtchn_do_upcall+0x66/0xb0
[7.611693] __xen_pv_evtchn_do_upcall+0x1d/0x30
[7.612582] xen_pv_evtchn_do_upcall+0x9d/0xc0
[7.613439]
[7.613882] exc_xen_hypervisor_callback+0x8/0x10
This is quite similar to the problem I reported a few months ago (see
[1]) but this time this is happening with fifo rather than 2L.
I haven't been able to reproduced it reliably so far. But looking at the
code, I think I have found another potential race after commit
commit b6622798bc50b625a1e62f82c7190df40c1f5b21
Author: Juergen Gross
Date: Sat Mar 6 17:18:33 2021 +0100
xen/events: avoid handling the same event on two cpus at the same time
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Link: https://lore.kernel.org/r/20210306161833.4552-4-jgr...@suse.com
Signed-off-by: Boris Ostrovsky
The evtchn driver will use the lateeoi handlers. So the code to ack
looks like:
do_mask(..., EVT_MASK_REASON_EOI_PENDING)
smp_store_release(>is_active, 0);
clear_evtchn(info->evtchn);
The code to handle an interrupts look like:
clear_link(...)
if ( evtchn_fifo_is_pending(port) && !evtchn_fifo_is_mask()) {
if (xchg_acquire(>is_active, 1)
return;
generic_handle_irq();
}
After changing the affinity, an interrupt may be received once on the
previous vCPU. So, I think the following can happen:
vCPU0 | vCPU1
|
Receive event |
| change affinity to vCPU1
clear_link()|
|
/* The interrupt is re-raised */
| receive event
|
| /* The interrupt is not masked */
info->is_active = 1 |
do_mask(...)|
info->is_active = 0 |
| info->is_active = 1
clear_evtchn(...) |
| do_mask(...)
| info->is_active = 0
| clear_evtchn(...)
Does this look plausible to you?
Cheers,
[1] https://www.spinics.net/lists/kernel/msg3771782.html
--
Julien Grall
[PATCH V7 01/18] perf/core: Use static_call to optimize perf_guest_info_callbacks
From: Like Xu
For "struct perf_guest_info_callbacks", the two fields "is_in_guest"
and "is_user_mode" are replaced with a new multiplexed member named
"state", and the "get_guest_ip" field will be renamed to "get_ip".
For arm64, xen and kvm/x86, the application of DEFINE_STATIC_CALL_RET0
could make all that perf_guest_cbs stuff suck less. For arm, csky, nds32,
and riscv, just applied some renamed refactoring.
Cc: Will Deacon
Cc: Marc Zyngier
Cc: Guo Ren
Cc: Nick Hu
Cc: Paul Walmsley
Cc: Boris Ostrovsky
Cc: linux-arm-ker...@lists.infradead.org
Cc: kvm...@lists.cs.columbia.edu
Cc: linux-c...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: xen-devel@lists.xenproject.org
Suggested-by: Peter Zijlstra (Intel)
Original-by: Peter Zijlstra (Intel)
Signed-off-by: Like Xu
Signed-off-by: Zhu Lingshan
---
arch/arm/kernel/perf_callchain.c | 16 -
arch/arm64/kernel/perf_callchain.c | 29 ++-
arch/arm64/kvm/perf.c | 22 -
arch/csky/kernel/perf_callchain.c | 4 ++--
arch/nds32/kernel/perf_event_cpu.c | 16 -
arch/riscv/kernel/perf_callchain.c | 4 ++--
arch/x86/events/core.c | 38 --
arch/x86/events/intel/core.c | 7 +++---
arch/x86/include/asm/kvm_host.h| 2 +-
arch/x86/kvm/pmu.c | 2 +-
arch/x86/kvm/x86.c | 37 -
arch/x86/xen/pmu.c | 33 +++---
include/linux/perf_event.h | 12 ++
kernel/events/core.c | 9 +++
14 files changed, 144 insertions(+), 87 deletions(-)
diff --git a/arch/arm/kernel/perf_callchain.c b/arch/arm/kernel/perf_callchain.c
index 3b69a76d341e..1ce30f86d6c7 100644
--- a/arch/arm/kernel/perf_callchain.c
+++ b/arch/arm/kernel/perf_callchain.c
@@ -64,7 +64,7 @@ perf_callchain_user(struct perf_callchain_entry_ctx *entry,
struct pt_regs *regs
{
struct frame_tail __user *tail;
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
+ if (perf_guest_cbs && perf_guest_cbs->state()) {
/* We don't support guest os callchain now */
return;
}
@@ -100,7 +100,7 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx
*entry, struct pt_regs *re
{
struct stackframe fr;
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
+ if (perf_guest_cbs && perf_guest_cbs->state()) {
/* We don't support guest os callchain now */
return;
}
@@ -111,8 +111,8 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx
*entry, struct pt_regs *re
unsigned long perf_instruction_pointer(struct pt_regs *regs)
{
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest())
- return perf_guest_cbs->get_guest_ip();
+ if (perf_guest_cbs && perf_guest_cbs->state())
+ return perf_guest_cbs->get_ip();
return instruction_pointer(regs);
}
@@ -120,9 +120,13 @@ unsigned long perf_instruction_pointer(struct pt_regs
*regs)
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+ unsigned int state = 0;
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
- if (perf_guest_cbs->is_user_mode())
+ if (perf_guest_cbs)
+ state = perf_guest_cbs->state();
+
+ if (perf_guest_cbs && state) {
+ if (state & PERF_GUEST_USER)
misc |= PERF_RECORD_MISC_GUEST_USER;
else
misc |= PERF_RECORD_MISC_GUEST_KERNEL;
diff --git a/arch/arm64/kernel/perf_callchain.c
b/arch/arm64/kernel/perf_callchain.c
index 88ff471b0bce..5df2bd5d12ba 100644
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@ -5,6 +5,7 @@
* Copyright (C) 2015 ARM Limited
*/
#include
+#include
#include
#include
@@ -99,10 +100,25 @@ compat_user_backtrace(struct compat_frame_tail __user
*tail,
}
#endif /* CONFIG_COMPAT */
+DEFINE_STATIC_CALL_RET0(arm64_guest_state, *(perf_guest_cbs->state));
+DEFINE_STATIC_CALL_RET0(arm64_guest_get_ip, *(perf_guest_cbs->get_ip));
+
+void arch_perf_update_guest_cbs(void)
+{
+ static_call_update(arm64_guest_state, (void *)&__static_call_return0);
+ static_call_update(arm64_guest_get_ip, (void *)&__static_call_return0);
+
+ if (perf_guest_cbs && perf_guest_cbs->state)
+ static_call_update(arm64_guest_state, perf_guest_cbs->state);
+
+ if (perf_guest_cbs && perf_guest_cbs->get_ip)
+ static_call_update(arm64_guest_get_ip, perf_guest_cbs->get_ip);
+}
+
void perf_callchain_user(struct perf_callchain_entry_ctx *entry,
struct pt_regs *regs)
{
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
+ if (static_call(arm64_guest_state)()) {
/* We don't support guest os callchain now */
return;
}
@@
[PATCH V7 01/18] perf/core: Use static_call to optimize perf_guest_info_callbacks
From: Like Xu
For "struct perf_guest_info_callbacks", the two fields "is_in_guest"
and "is_user_mode" are replaced with a new multiplexed member named
"state", and the "get_guest_ip" field will be renamed to "get_ip".
For arm64, xen and kvm/x86, the application of DEFINE_STATIC_CALL_RET0
could make all that perf_guest_cbs stuff suck less. For arm, csky, nds32,
and riscv, just applied some renamed refactoring.
Cc: Will Deacon
Cc: Marc Zyngier
Cc: Guo Ren
Cc: Nick Hu
Cc: Paul Walmsley
Cc: Boris Ostrovsky
Cc: linux-arm-ker...@lists.infradead.org
Cc: kvm...@lists.cs.columbia.edu
Cc: linux-c...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: xen-devel@lists.xenproject.org
Suggested-by: Peter Zijlstra (Intel)
Original-by: Peter Zijlstra (Intel)
Signed-off-by: Like Xu
Signed-off-by: Zhu Lingshan
---
arch/arm/kernel/perf_callchain.c | 16 -
arch/arm64/kernel/perf_callchain.c | 29 ++-
arch/arm64/kvm/perf.c | 22 -
arch/csky/kernel/perf_callchain.c | 4 ++--
arch/nds32/kernel/perf_event_cpu.c | 16 -
arch/riscv/kernel/perf_callchain.c | 4 ++--
arch/x86/events/core.c | 38 --
arch/x86/events/intel/core.c | 7 +++---
arch/x86/include/asm/kvm_host.h| 2 +-
arch/x86/kvm/pmu.c | 2 +-
arch/x86/kvm/x86.c | 37 -
arch/x86/xen/pmu.c | 33 +++---
include/linux/perf_event.h | 12 ++
kernel/events/core.c | 9 +++
14 files changed, 144 insertions(+), 87 deletions(-)
diff --git a/arch/arm/kernel/perf_callchain.c b/arch/arm/kernel/perf_callchain.c
index 3b69a76d341e..1ce30f86d6c7 100644
--- a/arch/arm/kernel/perf_callchain.c
+++ b/arch/arm/kernel/perf_callchain.c
@@ -64,7 +64,7 @@ perf_callchain_user(struct perf_callchain_entry_ctx *entry,
struct pt_regs *regs
{
struct frame_tail __user *tail;
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
+ if (perf_guest_cbs && perf_guest_cbs->state()) {
/* We don't support guest os callchain now */
return;
}
@@ -100,7 +100,7 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx
*entry, struct pt_regs *re
{
struct stackframe fr;
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
+ if (perf_guest_cbs && perf_guest_cbs->state()) {
/* We don't support guest os callchain now */
return;
}
@@ -111,8 +111,8 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx
*entry, struct pt_regs *re
unsigned long perf_instruction_pointer(struct pt_regs *regs)
{
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest())
- return perf_guest_cbs->get_guest_ip();
+ if (perf_guest_cbs && perf_guest_cbs->state())
+ return perf_guest_cbs->get_ip();
return instruction_pointer(regs);
}
@@ -120,9 +120,13 @@ unsigned long perf_instruction_pointer(struct pt_regs
*regs)
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+ unsigned int state = 0;
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
- if (perf_guest_cbs->is_user_mode())
+ if (perf_guest_cbs)
+ state = perf_guest_cbs->state();
+
+ if (perf_guest_cbs && state) {
+ if (state & PERF_GUEST_USER)
misc |= PERF_RECORD_MISC_GUEST_USER;
else
misc |= PERF_RECORD_MISC_GUEST_KERNEL;
diff --git a/arch/arm64/kernel/perf_callchain.c
b/arch/arm64/kernel/perf_callchain.c
index 88ff471b0bce..5df2bd5d12ba 100644
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@ -5,6 +5,7 @@
* Copyright (C) 2015 ARM Limited
*/
#include
+#include
#include
#include
@@ -99,10 +100,25 @@ compat_user_backtrace(struct compat_frame_tail __user
*tail,
}
#endif /* CONFIG_COMPAT */
+DEFINE_STATIC_CALL_RET0(arm64_guest_state, *(perf_guest_cbs->state));
+DEFINE_STATIC_CALL_RET0(arm64_guest_get_ip, *(perf_guest_cbs->get_ip));
+
+void arch_perf_update_guest_cbs(void)
+{
+ static_call_update(arm64_guest_state, (void *)&__static_call_return0);
+ static_call_update(arm64_guest_get_ip, (void *)&__static_call_return0);
+
+ if (perf_guest_cbs && perf_guest_cbs->state)
+ static_call_update(arm64_guest_state, perf_guest_cbs->state);
+
+ if (perf_guest_cbs && perf_guest_cbs->get_ip)
+ static_call_update(arm64_guest_get_ip, perf_guest_cbs->get_ip);
+}
+
void perf_callchain_user(struct perf_callchain_entry_ctx *entry,
struct pt_regs *regs)
{
- if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
+ if (static_call(arm64_guest_state)()) {
/* We don't support guest os callchain now */
return;
}
@@
Re: [PATCH] tools/xenstored: Don't crash xenstored when Live-Update is cancelled
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Currently, this will crash xenstored because do_lu_start() assumes
lu_status will be valid. This is not the case when Live-Update has been
cancelled. This will result to dereference a NULL pointer and
crash Xenstored.
Rework do_lu_start() to check if lu_status is NULL and return an
error in this case.
Fixes: af216a99fb ("tools/xenstore: add the basic framework for doing the live
update")
Signed-off-by: Julien Grall
This is currently based on top of:
https://lore.kernel.org/xen-devel/20210616144324.31652-1-jul...@xen.org
This can be re-ordered if necessary.
---
tools/xenstore/xenstored_control.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/xenstore/xenstored_control.c
b/tools/xenstore/xenstored_control.c
index a045f102a420..37a3d39f20b5 100644
--- a/tools/xenstore/xenstored_control.c
+++ b/tools/xenstore/xenstored_control.c
@@ -696,7 +696,18 @@ static bool do_lu_start(struct delayed_request *req)
time_t now = time(NULL);
const char *ret;
struct buffered_data *saved_in;
- struct connection *conn = lu_status->conn;
+ struct connection *conn = req->data;
+
+ /*
+* Cancellation may have been requested asynchronously. In this
+* case, lu_status will be NULL.
+*/
+ if (!lu_status) {
+ ret = "Cancellation was requested";
+ conn = req->data;
This will set conn to the same value it already has.
Other than that:
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] tools/xenstored: Don't crash xenstored when Live-Update is cancelled
On 22.06.21 10:53, Julien Grall wrote: Hi Juergen, On 22/06/2021 10:46, Juergen Gross wrote: On 17.06.21 19:38, Julien Grall wrote: From: Julien GralL As Live-Update is asynchronous, it is possible to receive a request to cancel it (either on the same connection or from a different one). Currently, this will crash xenstored because do_lu_start() assumes lu_status will be valid. This is not the case when Live-Update has been cancelled. This will result to dereference a NULL pointer and crash Xenstored. Umm, you introduced that bug in "[PATCH 03/10] tools/xenstore: Don't assume conn->in points to the LU request". No. I did reproduced this one without my series. If there are in-flight transaction this will crash in lu_check_lu_allowed() otherwise, it will crash when calling lu_dump_state(). Oh, right, I missed the indirection via delay_request(). Sorry. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] tools/xenstored: Don't crash xenstored when Live-Update is cancelled
Hi Juergen, On 22/06/2021 10:46, Juergen Gross wrote: On 17.06.21 19:38, Julien Grall wrote: From: Julien GralL As Live-Update is asynchronous, it is possible to receive a request to cancel it (either on the same connection or from a different one). Currently, this will crash xenstored because do_lu_start() assumes lu_status will be valid. This is not the case when Live-Update has been cancelled. This will result to dereference a NULL pointer and crash Xenstored. Umm, you introduced that bug in "[PATCH 03/10] tools/xenstore: Don't assume conn->in points to the LU request". No. I did reproduced this one without my series. If there are in-flight transaction this will crash in lu_check_lu_allowed() otherwise, it will crash when calling lu_dump_state(). The easiest way to reproduce is requesting live-update when there are long transactions and from a different connection (still in dom0) requesting to abort the connection. In this case, lu_abort() will free lu_status and the destructor will set it to NULL. But the actual request is still in the delayed request queue for the other connection. Cheers, -- Julien Grall
Re: [PATCH] tools/xenstored: Don't crash xenstored when Live-Update is cancelled
On 17.06.21 19:38, Julien Grall wrote: From: Julien GralL As Live-Update is asynchronous, it is possible to receive a request to cancel it (either on the same connection or from a different one). Currently, this will crash xenstored because do_lu_start() assumes lu_status will be valid. This is not the case when Live-Update has been cancelled. This will result to dereference a NULL pointer and crash Xenstored. Umm, you introduced that bug in "[PATCH 03/10] tools/xenstore: Don't assume conn->in points to the LU request". So I think you should fold your fix into that series. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[xen-unstable test] 162943: trouble: blocked/broken/pass
flight 162943 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/162943/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev broken build-amd64-pvopsbroken build-amd64-xsm broken build-amd64-xtf broken build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-pvops 4 host-install(4)broken REGR. vs. 162533 build-arm64-pvops 4 host-install(4)broken REGR. vs. 162533 build-i386-pvops 4 host-install(4)broken REGR. vs. 162533 build-arm64-xsm 4 host-install(4)broken REGR. vs. 162533 build-arm64 4 host-install(4)broken REGR. vs. 162533 build-i3864 host-install(4)broken REGR. vs. 162533 build-i386-xsm4 host-install(4)broken REGR. vs. 162533 build-i386-prev 4 host-install(4)broken REGR. vs. 162533 build-amd64 4 host-install(4)broken REGR. vs. 162533 build-amd64-prev 4 host-install(4)broken REGR. vs. 162533 build-amd64-xsm 4 host-install(4)broken REGR. vs. 162533 build-amd64-xtf 4 host-install(4)broken REGR. vs. 162533 build-armhf-pvops 4 host-install(4)broken REGR. vs. 162533 Tests which did not succeed, but are not blocking: test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)
[xen-unstable-smoke test] 162960: trouble: blocked/broken/pass
flight 162960 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/162960/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-arm64-xsm broken build-arm64-xsm 4 host-install(4)broken REGR. vs. 162880 build-amd64 4 host-install(4)broken REGR. vs. 162880 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen c9b59f9032d41be8bade8a25d9148cf6ed203704 baseline version: xen 8af4b47f061edf6450f2b0a0a8134fdf1c13b3e5 Last test of basis 162880 2021-06-17 17:00:36 Z4 days Testing same since 162942 2021-06-21 16:00:26 Z0 days5 attempts People who touched revisions under test: George Dunlap Nick Rosbrook Nick Rosbrook jobs: build-arm64-xsm broken build-amd64 broken build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-amd64 broken broken-job build-arm64-xsm broken broken-step build-arm64-xsm host-install(4) broken-step build-amd64 host-install(4) Not pushing. commit c9b59f9032d41be8bade8a25d9148cf6ed203704 Author: Nick Rosbrook Date: Mon May 24 16:36:52 2021 -0400 golang/xenlight: do not negate ret when converting to Error Commit 871e51d2d4 changed the sign on the xenlight error types (making the values negative, same as the C-generated constants), but failed to remove the code changing the sign before casting to Error(). This results in error strings like "libxl error: ", rather than the correct message. Fix all occurrances of this by running: gofmt -w -r 'Error(-ret) -> Error(ret)' xenlight.go from tools/golang/xenlight. Signed-off-by: Nick Rosbrook Acked-by: George Dunlap commit 1d95fd75df18bf25cb445feb47caf62da25c00e8 Author: Nick Rosbrook Date: Mon May 24 16:36:51 2021 -0400 golang/xenlight: add SendTrigger wrapper Add a warpper around libxl_send_trigger. Signed-off-by: Nick Rosbrook Reviewed-by: George Dunlap commit 9b6d865e0af56e376740ba03b1ccdf316362a71e Author: Nick Rosbrook Date: Mon May 24 16:36:50 2021 -0400 golang/xenlight: add DomainDestroy wrapper Add a wrapper around libxl_domain_destroy. Signed-off-by: Nick Rosbrook Reviewed-by: George Dunlap commit c089de0e2fa56d846cfb658b7b5efc3426895973 Author: Nick Rosbrook Date: Mon May 24 16:36:47 2021 -0400 golang/xenlight: rename Ctx receivers to ctx As a matter of style, it is strange to see capitalized receiver names, due to the significance of capitalized symbols in Go (although there is in fact nothing special about a capitalized receiver name). Fix this in xenlight.go by running: gofmt -w -r 'Ctx -> ctx' xenlight.go from tools/golang/xenlight. There is no functional change. Signed-off-by: Nick Rosbrook Reviewed-by: George Dunlap commit 1997940ad25e3566d1ab38496b8c7b07a086695a Author: Nick Rosbrook Date: Mon May 24 16:36:46 2021 -0400 golang/xenlight: use struct pointers in keyed union fields Currently, when marshalig Go types with keyed union fields, we assign the value of the
