|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 168591: regressions - FAIL
flight 168591 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/168591/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-build fail REGR. vs. 168580 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 168580 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 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass version targeted for testing: xen fef5531fd8f311b347970568d77e7bf4feffd7fb baseline version: xen dedb0aa42c6d1ee31805dfc61630db2c41117330 Last test of basis 168580 2022-03-14 10:01:40 Z 0 days Testing same since 168589 2022-03-14 19:00:27 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> Ayan Kumar Halder <ayankuma@xxxxxxxxxx> Julien Grall <jgrall@xxxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked 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 Not pushing. ------------------------------------------------------------ commit fef5531fd8f311b347970568d77e7bf4feffd7fb Author: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> Date: Thu Mar 10 17:45:00 2022 +0000 xen/arm64: io: Handle the abort due to access to stage1 translation table If the abort was caused due to access to stage1 translation table, Xen will try to set the p2m entry (assuming that the Stage 1 translation table is in the non MMIO region). If there is no such entry found, then Xen will try to map the address as a MMIO region (assuming that the Stage 1 translation table is in the direct MMIO region). If that fails as well, then there are the two following scenarios:- 1. Stage 1 translation table being in an emulated MMIO region - Xen can read the region, but it has no way to return the value read to the CPU page table walker (which tries to go through the stage1 tables to resolve the translation fault). 2. Stage 1 translation table address is invalid. In both the above scenarios, Xen will forward the abort to the guest. Signed-off-by: Ayan Kumar Halder <ayankuma@xxxxxxxxxx> Reviewed-by: Julien Grall <jgrall@xxxxxxxxxx> commit 9e5a68a6652cc54ce3cb3b0ce208eeed79d5aeb5 Author: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> Date: Thu Mar 10 17:44:59 2022 +0000 xen/arm64: io: Support instructions (for which ISS is not valid) on emulated MMIO region using MMIO/ioreq handler When an instruction is trapped in Xen due to translation fault, Xen checks if the ISS is invalid (for data abort) or it is an instruction abort. If so, Xen tries to resolve the translation fault using p2m page tables. In case of data abort, Xen will try to map the mmio region to the guest (ie tries to emulate the mmio region). If the ISS is not valid and it is a data abort, then Xen tries to decode the instruction. In case of ioreq, Xen saves the decoding state, rn and imm9 to vcpu_io. Whenever the vcpu handles the ioreq successfully, it will read the decoding state to determine if the instruction decoded was a ldr/str post indexing (ie INSTR_LDR_STR_POSTINDEXING). If so, it uses these details to post increment rn. In case of mmio handler, if the mmio operation was successful, then Xen retrives the decoding state, rn and imm9. For state == INSTR_LDR_STR_POSTINDEXING, Xen will update rn. If there is an error encountered while decoding/executing the instruction, Xen will forward the abort to the guest. Also, the logic to infer the type of instruction has been moved from try_handle_mmio() to try_decode_instruction() which is called before. try_handle_mmio() is solely responsible for handling the mmio operation. Signed-off-by: Ayan Kumar Halder <ayankuma@xxxxxxxxxx> Acked-by: Julien Grall <jgrall@xxxxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> commit f9dd8436e3b826e4ca2284effa4c0285527ea763 Author: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> Date: Thu Mar 10 17:44:58 2022 +0000 xen/arm64: Decode ldr/str post increment operations At the moment, Xen does not decode any of the arm64 instructions. This means that when hsr_dabt.isv == 0, Xen cannot handle those instructions. This will lead to Xen to abort the guests (from which those instructions originate). With this patch, Xen is able to decode ldr/str post indexing instructions. These are a subset of instructions for which hsr_dabt.isv == 0. The following instructions are now supported by Xen :- 1. ldr x2, [x1], #8 2. ldr w2, [x1], #-4 3. ldr x2, [x1], #-8 4. ldr w2, [x1], #4 5. ldrh w2, [x1], #2 6. ldrb w2, [x1], #1 7. str x2, [x1], #8 8. str w2, [x1], #-4 9. strh w2, [x1], #2 10. strb w2, [x1], #1 In the subsequent patch, decode_arm64() will get invoked when hsr_dabt.isv == 0. Signed-off-by: Ayan Kumar Halder <ayankuma@xxxxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |