[seabios test] 185623: tolerable FAIL - PUSHED
flight 185623 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/185623/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 185287 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 185287 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 185287 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass version targeted for testing: seabios e5f2e4c69643bc3cd385306a9e5d29e11578148c baseline version: seabios c5a361c09a19e3b1a83557b01f11f04b27181a11 Last test of basis 185287 2024-04-09 15:42:58 Z6 days Testing same since 185604 2024-04-15 13:42:35 Z0 days3 attempts People who touched revisions under test: Daniil Tatianin Kevin O'Connor 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictpass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 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/osstest/seabios.git c5a361c..e5f2e4c e5f2e4c69643bc3cd385306a9e5d29e11578148c -> xen-tested-master
[xen-unstable test] 185622: regressions - FAIL
flight 185622 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/185622/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-vhd 12 debian-di-installfail REGR. vs. 185281 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail REGR. vs. 185281 build-arm64-pvops 6 kernel-build fail REGR. vs. 185281 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 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-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail blocked in 185281 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185281 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185281 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 185281 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 185281 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 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-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-qcow214 migrate-support-checkfail never pass test-armhf-armhf-xl-qcow215 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-raw 15 saverestore-support-checkfail never pass version targeted for testing: xen c0f890cd9d5fd2c17a1e3110cb26f98c90ce8429 baseline version: xen 672b26b66ebb5ff3d28c573a6545a08020b27495 Last test of basis 185281 2024-04-09 11:10:22 Z6 days Failing since185294 2024-04-10 04:20:17 Z5 days9 attempts Testing same since 185457 2024-04-13 21:33:46 Z2 days6 attempts People who touched revisions under test: Andrew Cooper Bertrand Marquis Bjoern Doebel Daniel P. Smith Jan Beulich Jason Andryuk Jason Andryuk John Ernberg Juergen Gross Julien Grall Konrad Rzeszutek Wilk Leigh Brown Luca Fancellu Michal Orzel Nicola Vetrini Peng Fan Roger Pau Monne Roger Pau Monné Ross Lagerwall Shawn Anastasio Stefano Stabellini Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
[ovmf test] 185624: all pass - PUSHED
flight 185624 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/185624/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5ba3602e4580d6b65dacf4292a031627f93e1167 baseline version: ovmf 98f150a954b35cc74bd87ae355cf35d8c9e1580d Last test of basis 185309 2024-04-11 08:11:11 Z4 days Failing since185603 2024-04-15 13:42:34 Z0 days3 attempts Testing same since 185624 2024-04-15 20:11:06 Z0 days1 attempts People who touched revisions under test: Gahan Saraiya Jiewen Yao Qingyu Taylor Beebe Wei6 Xu 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 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/osstest/ovmf.git 98f150a954..5ba3602e45 5ba3602e4580d6b65dacf4292a031627f93e1167 -> xen-tested-master
Re: [PATCH 4/4] xen/public: Use -Wpadding for public headers
On Mon, 15 Apr 2024, Andrew Cooper wrote:
> RFC. In theory this is a great way to avoid some of the spiketraps involved
> with C being the official representation.
>
> However, this doesn't build. gnttab_transfer has a layout that requires a
> CONFIG_COMPAT if we want to satisfy -Wpadding for both forms of the structure.
>
> Thoughts on whether this cross-check is worthwhile-enough to warrant the
> ifdefary?
I like this patch and I think we have no choice but going in this
direction and adding all the padding explicitly with any related
necessary ifdefary.
The only question for me is whether to:
1) add -Wpadding
2) add __packed__
3) do both
I think it is important to add __packed__ to the headers to clear out
any misconceptions about possible hidden paddings and get a
correct-by-default behavior for anyone that would import the headers
into their own projects.
The only issue is that __packed__ makes -Wpadding not useful. We could
technically add both if we disable __packed__ for the -Wpadding build.
For instance we could use __packed which is defined by Xen, and change
the definition of __packed to nothing for the -Wpadding build.
That way we get both the nice -Wpadding checks and also the nice
obvious-by-default __packed__.
> ~Andrew
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/common/Makefile | 1 +
> xen/common/hdr-chk.c | 13 +
> xen/include/public/grant_table.h | 7 +++
> 3 files changed, 21 insertions(+)
> create mode 100644 xen/common/hdr-chk.c
>
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index d512cad5243f..dbbda70829f1 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -15,6 +15,7 @@ obj-y += event_fifo.o
> obj-$(CONFIG_GRANT_TABLE) += grant_table.o
> obj-y += guestcopy.o
> obj-y += gzip/
> +obj-y += hdr-chk.o
> obj-$(CONFIG_HYPFS) += hypfs.o
> obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
> obj-y += irq.o
> diff --git a/xen/common/hdr-chk.c b/xen/common/hdr-chk.c
> new file mode 100644
> index ..1c7a509dcd06
> --- /dev/null
> +++ b/xen/common/hdr-chk.c
> @@ -0,0 +1,13 @@
> +#include
> +
> +#include
> +
> +#pragma GCC diagnostic error "-Wpadded"
> +
> +#include
> +
> +#ifdef CONFIG_COMPAT
> +
> +#include
> +
> +#endif /* CONFIG_COMPAT */
> diff --git a/xen/include/public/grant_table.h
> b/xen/include/public/grant_table.h
> index 1dfa17a6d02a..a66c77d0166c 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -355,6 +355,7 @@ struct gnttab_unmap_grant_ref {
> grant_handle_t handle;
> /* OUT parameters. */
> int16_t status; /* => enum grant_status */
> +uint16_t _pad0;
> };
> typedef struct gnttab_unmap_grant_ref gnttab_unmap_grant_ref_t;
> DEFINE_XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t);
> @@ -371,6 +372,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t);
> struct gnttab_setup_table {
> /* IN parameters. */
> domid_t dom;
> +uint16_t _pad0;
> uint32_t nr_frames;
> /* OUT parameters. */
> int16_t status; /* => enum grant_status */
> @@ -409,9 +411,12 @@ struct gnttab_transfer {
> /* IN parameters. */
> xen_pfn_t mfn;
> domid_t domid;
> +uint16_t _pad0;
> grant_ref_t ref;
> /* OUT parameters. */
> int16_t status;
> +uint16_t _pad1;
> +/* XXX compat-dependent padding. */
> };
> typedef struct gnttab_transfer gnttab_transfer_t;
> DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_t);
> @@ -468,10 +473,12 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_copy_t);
> struct gnttab_query_size {
> /* IN parameters. */
> domid_t dom;
> +uint16_t _ign1;
> /* OUT parameters. */
> uint32_t nr_frames;
> uint32_t max_nr_frames;
> int16_t status; /* => enum grant_status */
> +uint16_t _ign2;
> };
> typedef struct gnttab_query_size gnttab_query_size_t;
> DEFINE_XEN_GUEST_HANDLE(gnttab_query_size_t);
> --
> 2.30.2
>
Re: [PATCH 3/4] xen/gnttab: Perform compat/native gnttab_query_size check
On Mon, 15 Apr 2024, Andrew Cooper wrote: > This subop appears to have been missed from the compat checks. > > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Jan Beulich > CC: Stefano Stabellini > CC: Julien Grall > --- > xen/common/compat/grant_table.c | 4 > xen/include/xlat.lst| 1 + > 2 files changed, 5 insertions(+) > > diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c > index af98eade17c9..8a754055576b 100644 > --- a/xen/common/compat/grant_table.c > +++ b/xen/common/compat/grant_table.c > @@ -30,6 +30,10 @@ CHECK_gnttab_unmap_grant_ref; > CHECK_gnttab_unmap_and_replace; > #undef xen_gnttab_unmap_and_replace > > +#define xen_gnttab_query_size gnttab_query_size > +CHECK_gnttab_query_size; > +#undef xen_gnttab_query_size > + > DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_compat_t); > DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_compat_t); > DEFINE_XEN_GUEST_HANDLE(gnttab_copy_compat_t); > diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst > index b3befd9cc113..53a1bdfc533f 100644 > --- a/xen/include/xlat.lst > +++ b/xen/include/xlat.lst > @@ -88,6 +88,7 @@ > !gnttab_get_status_framesgrant_table.h > ?gnttab_get_version grant_table.h > ?gnttab_map_grant_refgrant_table.h > +?gnttab_query_size grant_table.h > ?gnttab_set_version grant_table.h > !gnttab_setup_table grant_table.h > ?gnttab_swap_grant_ref grant_table.h I am no compat layer expert, but shouldn't there be something like: #ifndef CHECK_gnttab_map_grant_ref CASE(map_grant_ref); #endif somewhere under compat_grant_table_op ?
Re: [PATCH 2/4] xen/xlat: Sort structs per file
On Mon, 15 Apr 2024, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Reviewed-by: Stefano Stabellini
Re: [PATCH 1/4] xen/xlat: Sort out whitespace
On Mon, 15 Apr 2024, Andrew Cooper wrote: > * Fix tabs/spaces mismatch for certain rows > * Insert lines between header files to improve legibility > > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Jan Beulich > CC: Stefano Stabellini > CC: Julien Grall > --- > xen/include/xlat.lst | 31 +++ > 1 file changed, 27 insertions(+), 4 deletions(-) > > diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst > index 9c41948514bf..e811342bb096 100644 > --- a/xen/include/xlat.lst > +++ b/xen/include/xlat.lst > @@ -20,19 +20,24 @@ > # First column indicator: > # ! - needs translation > # ? - needs checking > + > ?dom0_vga_console_info xen.h > ?xenctl_bitmap xen.h > ?mmu_update xen.h > !mmuext_op xen.h > !start_info xen.h > ?vcpu_time_info xen.h > + > ?pmu_amd_ctxtarch-x86/pmu.h > ?pmu_archarch-x86/pmu.h > ?pmu_cntr_pair arch-x86/pmu.h > ?pmu_intel_ctxt arch-x86/pmu.h > ?pmu_regsarch-x86/pmu.h > + > !cpu_user_regs arch-x86/xen-@arch@.h > + > !trap_info arch-x86/xen.h > + > ?cpu_offline_action arch-x86/xen-mca.h > ?mc arch-x86/xen-mca.h > ?mcinfo_bank arch-x86/xen-mca.h > @@ -50,6 +55,7 @@ > ?mc_notifydomain arch-x86/xen-mca.h > !mc_physcpuinfo arch-x86/xen-mca.h > ?page_offline_action arch-x86/xen-mca.h > + > ?argo_addr argo.h > !argo_iovargo.h > ?argo_register_ring argo.h > @@ -59,6 +65,7 @@ > ?argo_ring_message_headerargo.h > ?argo_send_addr argo.h > ?argo_unregister_ringargo.h > + > ?evtchn_alloc_unboundevent_channel.h > ?evtchn_bind_interdomain event_channel.h > ?evtchn_bind_ipi event_channel.h > @@ -74,6 +81,7 @@ > ?evtchn_set_priority event_channel.h > ?evtchn_status event_channel.h > ?evtchn_unmask event_channel.h > + > ?gnttab_cache_flush grant_table.h > !gnttab_copy grant_table.h > ?gnttab_dump_table grant_table.h > @@ -86,9 +94,10 @@ > ?gnttab_get_version grant_table.h > !gnttab_get_status_framesgrant_table.h > ?grant_entry_v1 grant_table.h > -? grant_entry_header grant_table.h > +?grant_entry_header grant_table.h > ?grant_entry_v2 grant_table.h > ?gnttab_swap_grant_ref grant_table.h > + > !dm_op_buf hvm/dm_op.h > ?dm_op_create_ioreq_server hvm/dm_op.h > ?dm_op_destroy_ioreq_server hvm/dm_op.h > @@ -108,15 +117,20 @@ > ?dm_op_set_pci_intx_levelhvm/dm_op.h > ?dm_op_set_pci_link_routehvm/dm_op.h > ?dm_op_track_dirty_vram hvm/dm_op.h > + > !hvm_altp2m_set_mem_access_multi hvm/hvm_op.h > + > ?vcpu_hvm_contexthvm/hvm_vcpu.h > ?vcpu_hvm_x86_32 hvm/hvm_vcpu.h > ?vcpu_hvm_x86_64 hvm/hvm_vcpu.h > + > ?hypfs_direntry hypfs.h > ?hypfs_dirlistentry hypfs.h > + > ?kexec_exec kexec.h > !kexec_image kexec.h > !kexec_range kexec.h > + > !add_to_physmap memory.h > !add_to_physmap_batchmemory.h > !foreign_memory_map memory.h > @@ -130,6 +144,7 @@ > !reserved_device_memory_map memory.h > ?vmemrange memory.h > !vnuma_topology_info memory.h > + > ?physdev_eoi physdev.h > ?physdev_get_free_pirq physdev.h > ?physdev_irq physdev.h > @@ -143,6 +158,7 @@ > ?physdev_restore_msi physdev.h > ?physdev_set_ioplphysdev.h > ?physdev_setup_gsi physdev.h > + > !pct_registerplatform.h > !power_register platform.h > ?processor_csd platform.h > @@ -158,23 +174,30 @@ > ?xenpf_pcpu_version platform.h > ?xenpf_resource_entryplatform.h > ?xenpf_ucode_revisionplatform.h > + > ?pmu_datapmu.h > ?pmu_params pmu.h > + > !sched_poll sched.h > ?sched_pin_override sched.h > ?sched_remote_shutdown sched.h > ?
[ovmf test] 185617: regressions - trouble: blocked/broken
flight 185617 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/185617/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64-pvops 5 host-build-prep fail REGR. vs. 185309 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185309 build-i3865 host-build-prep fail REGR. vs. 185309 build-amd64 5 host-build-prep fail REGR. vs. 185309 build-i386-xsm5 host-build-prep fail REGR. vs. 185309 build-i386-pvops 5 host-build-prep fail REGR. vs. 185309 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 0707d9296d7536c5baf43b23d70eafce10b1ab03 baseline version: ovmf 98f150a954b35cc74bd87ae355cf35d8c9e1580d Last test of basis 185309 2024-04-11 08:11:11 Z4 days Failing since185603 2024-04-15 13:42:34 Z0 days2 attempts Testing same since 185617 2024-04-15 17:41:09 Z0 days1 attempts People who touched revisions under test: Gahan Saraiya Jiewen Yao Qingyu Wei6 Xu jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 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-amd64-pvops broken broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken Not pushing. commit 0707d9296d7536c5baf43b23d70eafce10b1ab03 Author: Wei6 Xu Date: Fri Apr 12 15:14:40 2024 +0800 SecurityPkg/Tcg2Config: Hide BIOS unsupported hash algorithm from UI REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4731 TCG2 configuration UI shows all the hash algorithms that TPM hardware supports in the checkbox. If user only selects one algorithm that is supported by TPM hardware but not supported by BIOS and uncheck the others, the SyncPcrAllocationsAndPcrMask in Tcg2Pei will not be able to decide a viable PCR to activate, then an assert occurs. Add check against PcdTcg2HashAlgorithmBitmap when deciding whether to suppress the hash algorithm checkbox to avoid user to select the hash algorithm which may cause an assert. Cc: Rahul Kumar Cc: Jiewen Yao Signed-off-by: Wei6 Xu Reviewed-by: Rahul Kumar Acked-by: Jiewen Yao commit e25808f5018ea601d0adf1d6d10c1cb3cb6a050b Author: Qingyu Date: Mon Apr 8 16:56:47 2024 +0800 MdePkg: Update the comments of GetInformation function Refer to Uefi spec 2.10 section 11.11.2, add a new retval EFI_NOT_FOUND to EFI_ADAPTER_INFORMATION_PROTOCOL.GetInformation(). Reference: [mantis #1866] - GetInfo() of Adapter Information Protocol should have a provision for IHV to return no data. Cc: Liming Gao Cc: Michael D Kinney Cc: Zhiguang Liu Signed-off-by: Qingyu Signed-off-by: Gahan Saraiya
[xen-4.18-testing test] 185527: regressions - trouble: blocked/broken
flight 185527 xen-4.18-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/185527/ Regressions :-( 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 broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-i386-xsm5 host-build-prep fail REGR. vs. 185285 build-i386-pvops 5 host-build-prep fail REGR. vs. 185285 build-amd64-prev 5 host-build-prep fail REGR. vs. 185285 build-amd64 5 host-build-prep fail REGR. vs. 185285 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185285 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185285 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185285 build-i386-prev 5 host-build-prep fail REGR. vs. 185285 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185285 build-arm64 5 host-build-prep fail REGR. vs. 185285 build-i3865 host-build-prep fail REGR. vs. 185285 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185285 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185285 build-armhf 5 host-build-prep fail REGR. vs. 185285 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a
[seabios test] 185616: regressions - trouble: blocked/broken
flight 185616 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/185616/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64 5 host-build-prep fail REGR. vs. 185287 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185287 build-i386-xsm5 host-build-prep fail REGR. vs. 185287 build-i3865 host-build-prep fail REGR. vs. 185287 build-i386-pvops 5 host-build-prep fail REGR. vs. 185287 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185287 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-i386-xsm 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-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a version targeted for testing: seabios e5f2e4c69643bc3cd385306a9e5d29e11578148c baseline version: seabios c5a361c09a19e3b1a83557b01f11f04b27181a11 Last test of basis 185287 2024-04-09 15:42:58 Z6 days Testing same since 185604 2024-04-15 13:42:35 Z0 days2 attempts People who touched revisions under test: Daniil Tatianin Kevin O'Connor jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-qemuu-freebsd11-amd64 blocked test-amd64-amd64-qemuu-freebsd12-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictblocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 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-amd64-pvops broken broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken Not pushing. commit e5f2e4c69643bc3cd385306a9e5d29e11578148c Author: Daniil Tatianin Date: Thu Apr 11 22:51:35 2024 +0300 pciinit: don't misalign large BARs Previously we would unconditionally lower the alignment for large BARs in
Re: [PATCH v2 13/13] xen/arm: List static shared memory regions as /memory nodes
Hi Luca, On 09/04/2024 12:45, Luca Fancellu wrote: Currently Xen is not exporting the static shared memory regions to the device tree as /memory node, this commit is fixing this issue. The static shared memory banks can be part of the memory range available for the domain, so if they are overlapping with the normal memory banks, they need to be merged together in order to produce a /memory node with non overlapping ranges in 'reg'. Before reviewing the code in more details, I would like to understand a bit more the use case and whether it should be valid. From my understanding, the case you are trying to prevent is the following setup: 1. The Guest Physical region 0x to 0x8000 is used for RAM 2. The Guest Physical region 0x to 0x4000 is used for static memory The underlying Host Physical regions may be different. Xen doesn't guarantee in which order the regions will be mapped, So whether the overlapped region will point to the memory or the shared region is unknown (we don't guarantee the order of the mapping). So nothing good will happen to the guest. Did I understand correctly? If so, shouldn't this be a configuration we should forbid? Cheers, -- Julien Grall
[ovmf test] 185603: regressions - trouble: blocked/broken
flight 185603 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/185603/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64-xsm 5 host-build-prep fail REGR. vs. 185309 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185309 build-i3865 host-build-prep fail REGR. vs. 185309 build-amd64 5 host-build-prep fail REGR. vs. 185309 build-i386-xsm5 host-build-prep fail REGR. vs. 185309 build-i386-pvops 5 host-build-prep fail REGR. vs. 185309 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf e25808f5018ea601d0adf1d6d10c1cb3cb6a050b baseline version: ovmf 98f150a954b35cc74bd87ae355cf35d8c9e1580d Last test of basis 185309 2024-04-11 08:11:11 Z4 days Testing same since 185603 2024-04-15 13:42:34 Z0 days1 attempts People who touched revisions under test: Gahan Saraiya Qingyu jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 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-amd64-pvops broken broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken Not pushing. commit e25808f5018ea601d0adf1d6d10c1cb3cb6a050b Author: Qingyu Date: Mon Apr 8 16:56:47 2024 +0800 MdePkg: Update the comments of GetInformation function Refer to Uefi spec 2.10 section 11.11.2, add a new retval EFI_NOT_FOUND to EFI_ADAPTER_INFORMATION_PROTOCOL.GetInformation(). Reference: [mantis #1866] - GetInfo() of Adapter Information Protocol should have a provision for IHV to return no data. Cc: Liming Gao Cc: Michael D Kinney Cc: Zhiguang Liu Signed-off-by: Qingyu Signed-off-by: Gahan Saraiya
[seabios test] 185604: regressions - trouble: blocked/broken
flight 185604 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/185604/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64 5 host-build-prep fail REGR. vs. 185287 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185287 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185287 build-i386-xsm5 host-build-prep fail REGR. vs. 185287 build-i3865 host-build-prep fail REGR. vs. 185287 build-i386-pvops 5 host-build-prep fail REGR. vs. 185287 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-i386-xsm 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-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a version targeted for testing: seabios e5f2e4c69643bc3cd385306a9e5d29e11578148c baseline version: seabios c5a361c09a19e3b1a83557b01f11f04b27181a11 Last test of basis 185287 2024-04-09 15:42:58 Z6 days Testing same since 185604 2024-04-15 13:42:35 Z0 days1 attempts People who touched revisions under test: Daniil Tatianin Kevin O'Connor jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-qemuu-freebsd11-amd64 blocked test-amd64-amd64-qemuu-freebsd12-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictblocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 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-amd64-pvops broken broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken Not pushing. commit e5f2e4c69643bc3cd385306a9e5d29e11578148c Author: Daniil Tatianin Date: Thu Apr 11 22:51:35 2024 +0300 pciinit: don't misalign large BARs Previously we would unconditionally lower the alignment for large BARs in
[xen-unstable test] 185597: regressions - trouble: blocked/broken
flight 185597 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/185597/ Regressions :-( 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 broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-prev 5 host-build-prep fail REGR. vs. 185281 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185281 build-i386-prev 5 host-build-prep fail REGR. vs. 185281 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185281 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185281 build-i386-xsm5 host-build-prep fail REGR. vs. 185281 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185281 build-i3865 host-build-prep fail REGR. vs. 185281 build-i386-pvops 5 host-build-prep fail REGR. vs. 185281 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185281 build-arm64 5 host-build-prep fail REGR. vs. 185281 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185281 build-armhf 5 host-build-prep fail REGR. vs. 185281 build-amd64 5 host-build-prep fail REGR. vs. 185281 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-xtf-amd64-amd64-31 build-check(1) blocked n/a test-xtf-amd64-amd64-41 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pygrub
Re: [XEN PATCH] docs/misra: mark the gzip folder as adopted code
On 15/04/2024 10:56 am, Federico Serafini wrote: > Mark the whole gzip folder as adopted code and remove the redundant > deviation of file inflate. > > Signed-off-by: Federico Serafini Acked-by: Andrew Cooper I hadn't realised that we had a special case like this. Definitely better to get rid of it. I've pulled this into my `for-next` branch, and will get it committed properly when OSSTest (our non-gitlab CI) is in a happier state.
[PATCH 2/4] xen/xlat: Sort structs per file
Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall --- xen/include/xlat.lst | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst index e811342bb096..b3befd9cc113 100644 --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -22,11 +22,11 @@ # ? - needs checking ? dom0_vga_console_info xen.h -? xenctl_bitmap xen.h ? mmu_update xen.h ! mmuext_op xen.h ! start_info xen.h ? vcpu_time_info xen.h +? xenctl_bitmap xen.h ? pmu_amd_ctxtarch-x86/pmu.h ? pmu_archarch-x86/pmu.h @@ -40,13 +40,6 @@ ? cpu_offline_action arch-x86/xen-mca.h ? mc arch-x86/xen-mca.h -? mcinfo_bank arch-x86/xen-mca.h -? mcinfo_common arch-x86/xen-mca.h -? mcinfo_extended arch-x86/xen-mca.h -? mcinfo_global arch-x86/xen-mca.h -? mcinfo_logical_cpu arch-x86/xen-mca.h -? mcinfo_msr arch-x86/xen-mca.h -? mcinfo_recovery arch-x86/xen-mca.h ! mc_fetcharch-x86/xen-mca.h ? mc_info arch-x86/xen-mca.h ? mc_inject_v2arch-x86/xen-mca.h @@ -54,6 +47,13 @@ ? mc_msrinjectarch-x86/xen-mca.h ? mc_notifydomain arch-x86/xen-mca.h ! mc_physcpuinfo arch-x86/xen-mca.h +? mcinfo_bank arch-x86/xen-mca.h +? mcinfo_common arch-x86/xen-mca.h +? mcinfo_extended arch-x86/xen-mca.h +? mcinfo_global arch-x86/xen-mca.h +? mcinfo_logical_cpu arch-x86/xen-mca.h +? mcinfo_msr arch-x86/xen-mca.h +? mcinfo_recovery arch-x86/xen-mca.h ? page_offline_action arch-x86/xen-mca.h ? argo_addr argo.h @@ -85,18 +85,18 @@ ? gnttab_cache_flush grant_table.h ! gnttab_copy grant_table.h ? gnttab_dump_table grant_table.h +! gnttab_get_status_framesgrant_table.h +? gnttab_get_version grant_table.h ? gnttab_map_grant_refgrant_table.h +? gnttab_set_version grant_table.h ! gnttab_setup_table grant_table.h +? gnttab_swap_grant_ref grant_table.h ! gnttab_transfer grant_table.h -? gnttab_unmap_grant_ref grant_table.h ? gnttab_unmap_and_replacegrant_table.h -? gnttab_set_version grant_table.h -? gnttab_get_version grant_table.h -! gnttab_get_status_framesgrant_table.h -? grant_entry_v1 grant_table.h +? gnttab_unmap_grant_ref grant_table.h ? grant_entry_header grant_table.h +? grant_entry_v1 grant_table.h ? grant_entry_v2 grant_table.h -? gnttab_swap_grant_ref grant_table.h ! dm_op_buf hvm/dm_op.h ? dm_op_create_ioreq_server hvm/dm_op.h @@ -134,11 +134,11 @@ ! add_to_physmap memory.h ! add_to_physmap_batchmemory.h ! foreign_memory_map memory.h +! mem_access_op memory.h +! mem_acquire_resourcememory.h ! memory_exchange memory.h ! memory_map memory.h ! memory_reservation memory.h -! mem_access_op memory.h -! mem_acquire_resourcememory.h ! pod_target memory.h ! remove_from_physmap memory.h ! reserved_device_memory_map memory.h @@ -154,10 +154,10 @@ ? physdev_pci_device physdev.h ? physdev_pci_device_add physdev.h ? physdev_pci_mmcfg_reserved physdev.h -? physdev_unmap_pirq physdev.h ? physdev_restore_msi physdev.h ? physdev_set_ioplphysdev.h ? physdev_setup_gsi physdev.h +? physdev_unmap_pirq physdev.h ! pct_registerplatform.h ! power_register platform.h @@ -169,17 +169,17 @@ ? processor_pxplatform.h ! psd_package platform.h ? xenpf_enter_acpi_sleep platform.h -! xenpf_symdata platform.h -?
[PATCH 0/4] xen/xlat: Improvements to compat hypercall checking
This started off as patch 3, and grew somewhat. Patches 1-3 are simple and hopefully non-controversial. Patch 4 is an attempt to make the headers less fragile, but came with an unexpected complication. Details in the patch. Andrew Cooper (4): xen/xlat: Sort out whitespace xen/xlat: Sort structs per file xen/gnttab: Perform compat/native gnttab_query_size check xen/public: Use -Wpadding for public headers xen/common/Makefile | 1 + xen/common/compat/grant_table.c | 4 ++ xen/common/hdr-chk.c | 13 ++ xen/include/public/grant_table.h | 7 xen/include/xlat.lst | 70 +--- 5 files changed, 72 insertions(+), 23 deletions(-) create mode 100644 xen/common/hdr-chk.c base-commit: c0f890cd9d5fd2c17a1e3110cb26f98c90ce8429 -- 2.30.2
[PATCH 3/4] xen/gnttab: Perform compat/native gnttab_query_size check
This subop appears to have been missed from the compat checks. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall --- xen/common/compat/grant_table.c | 4 xen/include/xlat.lst| 1 + 2 files changed, 5 insertions(+) diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c index af98eade17c9..8a754055576b 100644 --- a/xen/common/compat/grant_table.c +++ b/xen/common/compat/grant_table.c @@ -30,6 +30,10 @@ CHECK_gnttab_unmap_grant_ref; CHECK_gnttab_unmap_and_replace; #undef xen_gnttab_unmap_and_replace +#define xen_gnttab_query_size gnttab_query_size +CHECK_gnttab_query_size; +#undef xen_gnttab_query_size + DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_compat_t); DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_compat_t); DEFINE_XEN_GUEST_HANDLE(gnttab_copy_compat_t); diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst index b3befd9cc113..53a1bdfc533f 100644 --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -88,6 +88,7 @@ ! gnttab_get_status_framesgrant_table.h ? gnttab_get_version grant_table.h ? gnttab_map_grant_refgrant_table.h +? gnttab_query_size grant_table.h ? gnttab_set_version grant_table.h ! gnttab_setup_table grant_table.h ? gnttab_swap_grant_ref grant_table.h -- 2.30.2
[PATCH 4/4] xen/public: Use -Wpadding for public headers
RFC. In theory this is a great way to avoid some of the spiketraps involved
with C being the official representation.
However, this doesn't build. gnttab_transfer has a layout that requires a
CONFIG_COMPAT if we want to satisfy -Wpadding for both forms of the structure.
Thoughts on whether this cross-check is worthwhile-enough to warrant the
ifdefary?
~Andrew
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/Makefile | 1 +
xen/common/hdr-chk.c | 13 +
xen/include/public/grant_table.h | 7 +++
3 files changed, 21 insertions(+)
create mode 100644 xen/common/hdr-chk.c
diff --git a/xen/common/Makefile b/xen/common/Makefile
index d512cad5243f..dbbda70829f1 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -15,6 +15,7 @@ obj-y += event_fifo.o
obj-$(CONFIG_GRANT_TABLE) += grant_table.o
obj-y += guestcopy.o
obj-y += gzip/
+obj-y += hdr-chk.o
obj-$(CONFIG_HYPFS) += hypfs.o
obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
obj-y += irq.o
diff --git a/xen/common/hdr-chk.c b/xen/common/hdr-chk.c
new file mode 100644
index ..1c7a509dcd06
--- /dev/null
+++ b/xen/common/hdr-chk.c
@@ -0,0 +1,13 @@
+#include
+
+#include
+
+#pragma GCC diagnostic error "-Wpadded"
+
+#include
+
+#ifdef CONFIG_COMPAT
+
+#include
+
+#endif /* CONFIG_COMPAT */
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 1dfa17a6d02a..a66c77d0166c 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -355,6 +355,7 @@ struct gnttab_unmap_grant_ref {
grant_handle_t handle;
/* OUT parameters. */
int16_t status; /* => enum grant_status */
+uint16_t _pad0;
};
typedef struct gnttab_unmap_grant_ref gnttab_unmap_grant_ref_t;
DEFINE_XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t);
@@ -371,6 +372,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t);
struct gnttab_setup_table {
/* IN parameters. */
domid_t dom;
+uint16_t _pad0;
uint32_t nr_frames;
/* OUT parameters. */
int16_t status; /* => enum grant_status */
@@ -409,9 +411,12 @@ struct gnttab_transfer {
/* IN parameters. */
xen_pfn_t mfn;
domid_t domid;
+uint16_t _pad0;
grant_ref_t ref;
/* OUT parameters. */
int16_t status;
+uint16_t _pad1;
+/* XXX compat-dependent padding. */
};
typedef struct gnttab_transfer gnttab_transfer_t;
DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_t);
@@ -468,10 +473,12 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_copy_t);
struct gnttab_query_size {
/* IN parameters. */
domid_t dom;
+uint16_t _ign1;
/* OUT parameters. */
uint32_t nr_frames;
uint32_t max_nr_frames;
int16_t status; /* => enum grant_status */
+uint16_t _ign2;
};
typedef struct gnttab_query_size gnttab_query_size_t;
DEFINE_XEN_GUEST_HANDLE(gnttab_query_size_t);
--
2.30.2
[PATCH 1/4] xen/xlat: Sort out whitespace
* Fix tabs/spaces mismatch for certain rows * Insert lines between header files to improve legibility Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall --- xen/include/xlat.lst | 31 +++ 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst index 9c41948514bf..e811342bb096 100644 --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -20,19 +20,24 @@ # First column indicator: # ! - needs translation # ? - needs checking + ? dom0_vga_console_info xen.h ? xenctl_bitmap xen.h ? mmu_update xen.h ! mmuext_op xen.h ! start_info xen.h ? vcpu_time_info xen.h + ? pmu_amd_ctxtarch-x86/pmu.h ? pmu_archarch-x86/pmu.h ? pmu_cntr_pair arch-x86/pmu.h ? pmu_intel_ctxt arch-x86/pmu.h ? pmu_regsarch-x86/pmu.h + ! cpu_user_regs arch-x86/xen-@arch@.h + ! trap_info arch-x86/xen.h + ? cpu_offline_action arch-x86/xen-mca.h ? mc arch-x86/xen-mca.h ? mcinfo_bank arch-x86/xen-mca.h @@ -50,6 +55,7 @@ ? mc_notifydomain arch-x86/xen-mca.h ! mc_physcpuinfo arch-x86/xen-mca.h ? page_offline_action arch-x86/xen-mca.h + ? argo_addr argo.h ! argo_iovargo.h ? argo_register_ring argo.h @@ -59,6 +65,7 @@ ? argo_ring_message_headerargo.h ? argo_send_addr argo.h ? argo_unregister_ringargo.h + ? evtchn_alloc_unboundevent_channel.h ? evtchn_bind_interdomain event_channel.h ? evtchn_bind_ipi event_channel.h @@ -74,6 +81,7 @@ ? evtchn_set_priority event_channel.h ? evtchn_status event_channel.h ? evtchn_unmask event_channel.h + ? gnttab_cache_flush grant_table.h ! gnttab_copy grant_table.h ? gnttab_dump_table grant_table.h @@ -86,9 +94,10 @@ ? gnttab_get_version grant_table.h ! gnttab_get_status_framesgrant_table.h ? grant_entry_v1 grant_table.h -? grant_entry_header grant_table.h +? grant_entry_header grant_table.h ? grant_entry_v2 grant_table.h ? gnttab_swap_grant_ref grant_table.h + ! dm_op_buf hvm/dm_op.h ? dm_op_create_ioreq_server hvm/dm_op.h ? dm_op_destroy_ioreq_server hvm/dm_op.h @@ -108,15 +117,20 @@ ? dm_op_set_pci_intx_levelhvm/dm_op.h ? dm_op_set_pci_link_routehvm/dm_op.h ? dm_op_track_dirty_vram hvm/dm_op.h + ! hvm_altp2m_set_mem_access_multi hvm/hvm_op.h + ? vcpu_hvm_contexthvm/hvm_vcpu.h ? vcpu_hvm_x86_32 hvm/hvm_vcpu.h ? vcpu_hvm_x86_64 hvm/hvm_vcpu.h + ? hypfs_direntry hypfs.h ? hypfs_dirlistentry hypfs.h + ? kexec_exec kexec.h ! kexec_image kexec.h ! kexec_range kexec.h + ! add_to_physmap memory.h ! add_to_physmap_batchmemory.h ! foreign_memory_map memory.h @@ -130,6 +144,7 @@ ! reserved_device_memory_map memory.h ? vmemrange memory.h ! vnuma_topology_info memory.h + ? physdev_eoi physdev.h ? physdev_get_free_pirq physdev.h ? physdev_irq physdev.h @@ -143,6 +158,7 @@ ? physdev_restore_msi physdev.h ? physdev_set_ioplphysdev.h ? physdev_setup_gsi physdev.h + ! pct_registerplatform.h ! power_register platform.h ? processor_csd platform.h @@ -158,23 +174,30 @@ ? xenpf_pcpu_version platform.h ? xenpf_resource_entryplatform.h ? xenpf_ucode_revisionplatform.h + ? pmu_datapmu.h ? pmu_params pmu.h + ! sched_poll sched.h ? sched_pin_override sched.h ? sched_remote_shutdown sched.h ? sched_shutdown sched.h + ? t_buf trace.h + ? vcpu_get_physid
[xen-4.16-testing test] 185556: regressions - trouble: blocked/broken
flight 185556 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/185556/ Regressions :-( 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 broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-prev 5 host-build-prep fail REGR. vs. 185283 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185283 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185283 build-i3865 host-build-prep fail REGR. vs. 185283 build-i386-pvops 5 host-build-prep fail REGR. vs. 185283 build-amd64 5 host-build-prep fail REGR. vs. 185283 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185283 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185283 build-i386-prev 5 host-build-prep fail REGR. vs. 185283 build-i386-xsm5 host-build-prep fail REGR. vs. 185283 build-arm64 5 host-build-prep fail REGR. vs. 185283 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185283 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185283 build-armhf 5 host-build-prep fail REGR. vs. 185283 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a
[xen-4.17-testing test] 185536: regressions - trouble: blocked/broken
flight 185536 xen-4.17-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/185536/ Regressions :-( 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 broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-prev 5 host-build-prep fail REGR. vs. 185284 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185284 build-amd64 5 host-build-prep fail REGR. vs. 185284 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185284 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185284 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185284 build-i3865 host-build-prep fail REGR. vs. 185284 build-i386-xsm5 host-build-prep fail REGR. vs. 185284 build-i386-prev 5 host-build-prep fail REGR. vs. 185284 build-i386-pvops 5 host-build-prep fail REGR. vs. 185284 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185284 build-arm64 5 host-build-prep fail REGR. vs. 185284 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185284 build-armhf 5 host-build-prep fail REGR. vs. 185284 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a
Re: Rewritten XSA status page, xsa.json
On 15/04/2024 3:14 pm, George Dunlap wrote: > Hey all, > > Some of you may have noticed that xenbis.xenproject.org/xsa/ doesn't > currently list XSA-456. This has prompted me to rewrite the perl code > which generates that area of the webpage into golang, which is much > easier for the current security team to understand and modify. The > draft replacement is here: > > https://xenbits.xenproject.org/people/gdunlap/xsa-draft/ > > In particular, if you use `xsa.json` for any purpose, let me know if > you have any issues. If I don't hear any objections I'll replace the > website generation code on Wednesday. As I said on Friday, LGTM. I'm tempted to say put it live now, announce it on Matrix and ask for people to point out issues that they find. Or post your draft link and ask people to look at that? It's the downstreams who are more likely to notice problems... But a tangent while we're here. How difficult would it be to get some basic info about XSAs 1-25 on this page? We have the primary advisory-*.txt's in xsa.git at least, and going to the wiki isn't great. ~Andrew
[PATCH] x86/spec: fix reporting of BHB clearing usage from guest entry points
Reporting whether the BHB clearing on entry is done for the different domains
types based on cpu_has_bhb_seq is incorrect, as that variable signals whether
there's a BHB clearing sequence selected, but that alone doesn't imply that
such sequence is used from the PV and/or HVM entry points.
Instead use opt_bhb_entry_{pv,hvm} which do signal whether BHB clearing is
performed on entry from PV/HVM.
Fixes: 689ad48ce9cf ('x86/spec-ctrl: Wire up the Native-BHI software sequences')
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/spec_ctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index dd01e30844a1..29f5248d01d1 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -643,7 +643,7 @@ static void __init print_details(enum ind_thunk thunk)
opt_eager_fpu ? " EAGER_FPU" : "",
opt_verw_hvm ? " VERW" : "",
boot_cpu_has(X86_FEATURE_IBPB_ENTRY_HVM) ? " IBPB-entry": "",
- cpu_has_bhb_seq ? " BHB-entry" : "");
+ opt_bhb_entry_hvm ? " BHB-entry" : "");
#endif
#ifdef CONFIG_PV
@@ -658,7 +658,7 @@ static void __init print_details(enum ind_thunk thunk)
opt_eager_fpu ? " EAGER_FPU" : "",
opt_verw_pv ? " VERW" : "",
boot_cpu_has(X86_FEATURE_IBPB_ENTRY_PV) ? " IBPB-entry": "",
- cpu_has_bhb_seq ? " BHB-entry" : "");
+ opt_bhb_entry_pv ? " BHB-entry" : "");
printk(" XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
opt_xpti_hwdom ? "enabled" : "disabled",
--
2.44.0
Rewritten XSA status page, xsa.json
Hey all, Some of you may have noticed that xenbis.xenproject.org/xsa/ doesn't currently list XSA-456. This has prompted me to rewrite the perl code which generates that area of the webpage into golang, which is much easier for the current security team to understand and modify. The draft replacement is here: https://xenbits.xenproject.org/people/gdunlap/xsa-draft/ In particular, if you use `xsa.json` for any purpose, let me know if you have any issues. If I don't hear any objections I'll replace the website generation code on Wednesday. Thanks, -George
Re: [XEN PATCH v4 0/5] x86/iommu: Drop IOMMU support when cx16 isn't supported
Le 15/04/2024 à 14:15, Teddy Astie a écrit : > All hardware that supports VT-d/AMD-Vi that exists also supports cx16 (aside > specifically crafted virtual machines). > > Some IOMMU code paths in Xen consider cases where VT-d/AMD-Vi is supported > while cx16 isn't, those paths may be bugged and are barely tested, dead code > in practice. > > Disable IOMMU in case we have IOMMU hardware but no cx16, then cleanup > no-cx16 handling logic from VT-d and AMD-Vi drivers. Also disable > interrupt remapping that also relies on cx16. > > Teddy Astie (5): >VT-d: Disable IOMMU if cx16 isn't supported >AMD-Vi: Disable IOMMU if cx16 isn't supported >VT-d: Cleanup MAP_SINGLE_DEVICE and related code >VT-d: Disable intrerrupt remapping if cx16 is not supported >AMD-Vi: Disable intrerrupt remapping if cx16 is not supported > > xen/drivers/passthrough/amd/iommu_intr.c| 6 ++ > xen/drivers/passthrough/amd/iommu_map.c | 42 -- > xen/drivers/passthrough/amd/pci_amd_iommu.c | 6 ++ > xen/drivers/passthrough/vtd/intremap.c | 70 +--- > xen/drivers/passthrough/vtd/iommu.c | 92 +++-- > xen/drivers/passthrough/vtd/vtd.h | 5 +- > 6 files changed, 77 insertions(+), 144 deletions(-) > Here is the patch history that got lost for some reason in this cover. Changed in v2: * Added cleanup no-cx16 code for x2APIC * Fixed commit and code formatting * Added missing Suggested-by note Changed in v3: * Use -ENODEV instead of -ENOSYS. Changed in v4: * Reworded "Disable IOMMU if cx16 isn't supported" * Moved interrupt remapping cleanup in separate patches * Check cx16 for interrupt remapping in driver's callbacks rather than in x2apic_bsp_setup Teddy --- Teddy Astie | Vates XCP-ng Intern XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
Re: [PATCH 1/2] swiotlb: Remove alloc_size argument to swiotlb_tbl_map_single()
On Mon, 15 Apr 2024 13:03:30 + Michael Kelley wrote: > From: Petr Tesařík Sent: Monday, April 15, 2024 5:50 AM > > > > On Mon, 15 Apr 2024 12:23:22 + > > Michael Kelley wrote: > > > > > From: Petr Tesařík Sent: Monday, April 15, 2024 4:46 > > > AM > > > > > > > > Hi Michael, > > > > > > > > sorry for taking so long to answer. Yes, there was no agreement on the > > > > removal of the "dir" parameter, but I'm not sure it's because of > > > > symmetry with swiotlb_sync_*(), because the topic was not really > > > > discussed. > > > > > > > > The discussion was about the KUnit test suite and whether direction is > > > > a property of the bounce buffer or of each sync operation. Since DMA API > > > > defines associates each DMA buffer with a direction, the direction > > > > parameter passed to swiotlb_sync_*() should match what was passed to > > > > swiotlb_tbl_map_single(), because that's how it is used by the generic > > > > DMA code. In other words, if the parameter is kept, it should be kept > > > > to match dma_map_*(). > > > > > > > > However, there is also symmetry with swiotlb_tbl_unmap_single(). This > > > > function does use the parameter for the final sync. I believe there > > > > should be a matching initial sync in swiotlb_tbl_map_single(). In > > > > short, the buffer sync for DMA non-coherent devices should be moved from > > > > swiotlb_map() to swiotlb_tbl_map_single(). If this sync is not needed, > > > > then the caller can (and should) include DMA_ATTR_SKIP_CPU_SYNC in > > > > the flags parameter. > > > > > > > > To sum it up: > > > > > > > > * Do *NOT* remove the "dir" parameter. > > > > * Let me send a patch which moves the initial buffer sync. > > > > > > > > > > I'm not seeing the need to move the initial buffer sync. All > > > callers of swiotlb_tbl_map_single() already have a subsequent > > > check for a non-coherent device, and a call to > > > arch_sync_dma_for_device(). And the Xen code has some > > > special handling that probably shouldn't go in > > > swiotlb_tbl_map_single(). Or am I missing something? > > > > Oh, sure, there's nothing broken ATM. It's merely a cleanup. The API is > > asymmetric and thus confusing. You get a final sync by default if you > > call swiotlb_tbl_unmap_single(), > > I don't see that final sync in swiotlb_tbl_unmap_single(). It calls > swiotlb_bounce() to copy the data, but it doesn't deal with > non-coherent devices or call arch_sync_dma_for_cpu(). Ouch. You're right! The buffer gets only bounced but not synced if device DMA is non-coherent. So, how is this supposed to work? Now I'm looking at the code in dma_direct_map_page(), and it calls arch_sync_dma_for_device() explicitly, _except_ when using SWIOTLB. So, maybe I should instead review all callers of swiotlb_map(), make sure that they handle non-coherent devices, and then remove the sync from swiotlb_map()? I mean, the current situation seems somewhat disorganized to me. Petr T
[linux-6.1 test] 185595: regressions - trouble: blocked/broken
flight 185595 linux-6.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/185595/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64-pvops 5 host-build-prep fail REGR. vs. 185299 build-amd64 5 host-build-prep fail REGR. vs. 185299 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185299 build-i3865 host-build-prep fail REGR. vs. 185299 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185299 build-i386-pvops 5 host-build-prep fail REGR. vs. 185299 build-i386-xsm5 host-build-prep fail REGR. vs. 185299 build-arm64 5 host-build-prep fail REGR. vs. 185299 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185299 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185299 build-armhf 5 host-build-prep fail REGR. vs. 185299 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-vhd 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-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1)
RE: [PATCH 1/2] swiotlb: Remove alloc_size argument to swiotlb_tbl_map_single()
From: Petr Tesařík Sent: Monday, April 15, 2024 5:50 AM > > On Mon, 15 Apr 2024 12:23:22 + > Michael Kelley wrote: > > > From: Petr Tesařík Sent: Monday, April 15, 2024 4:46 AM > > > > > > Hi Michael, > > > > > > sorry for taking so long to answer. Yes, there was no agreement on the > > > removal of the "dir" parameter, but I'm not sure it's because of > > > symmetry with swiotlb_sync_*(), because the topic was not really > > > discussed. > > > > > > The discussion was about the KUnit test suite and whether direction is > > > a property of the bounce buffer or of each sync operation. Since DMA API > > > defines associates each DMA buffer with a direction, the direction > > > parameter passed to swiotlb_sync_*() should match what was passed to > > > swiotlb_tbl_map_single(), because that's how it is used by the generic > > > DMA code. In other words, if the parameter is kept, it should be kept > > > to match dma_map_*(). > > > > > > However, there is also symmetry with swiotlb_tbl_unmap_single(). This > > > function does use the parameter for the final sync. I believe there > > > should be a matching initial sync in swiotlb_tbl_map_single(). In > > > short, the buffer sync for DMA non-coherent devices should be moved from > > > swiotlb_map() to swiotlb_tbl_map_single(). If this sync is not needed, > > > then the caller can (and should) include DMA_ATTR_SKIP_CPU_SYNC in > > > the flags parameter. > > > > > > To sum it up: > > > > > > * Do *NOT* remove the "dir" parameter. > > > * Let me send a patch which moves the initial buffer sync. > > > > > > > I'm not seeing the need to move the initial buffer sync. All > > callers of swiotlb_tbl_map_single() already have a subsequent > > check for a non-coherent device, and a call to > > arch_sync_dma_for_device(). And the Xen code has some > > special handling that probably shouldn't go in > > swiotlb_tbl_map_single(). Or am I missing something? > > Oh, sure, there's nothing broken ATM. It's merely a cleanup. The API is > asymmetric and thus confusing. You get a final sync by default if you > call swiotlb_tbl_unmap_single(), I don't see that final sync in swiotlb_tbl_unmap_single(). It calls swiotlb_bounce() to copy the data, but it doesn't deal with non-coherent devices or call arch_sync_dma_for_cpu(). > but you don't get an initial sync by > default if you call swiotlb_tbl_map_single(). This is difficult to > remember, so potential new users of the API may incorrectly assume that > an initial sync is done, or that a final sync is not done. > > And yes, when moving the code, all current users of > swiotlb_tbl_map_single() should specify DMA_ATTR_SKIP_CPU_SYNC. > > Petr T
Re: [PATCH 1/2] swiotlb: Remove alloc_size argument to swiotlb_tbl_map_single()
On Mon, 15 Apr 2024 12:23:22 + Michael Kelley wrote: > From: Petr Tesařík Sent: Monday, April 15, 2024 4:46 AM > > > > Hi Michael, > > > > sorry for taking so long to answer. Yes, there was no agreement on the > > removal of the "dir" parameter, but I'm not sure it's because of > > symmetry with swiotlb_sync_*(), because the topic was not really > > discussed. > > > > The discussion was about the KUnit test suite and whether direction is > > a property of the bounce buffer or of each sync operation. Since DMA API > > defines associates each DMA buffer with a direction, the direction > > parameter passed to swiotlb_sync_*() should match what was passed to > > swiotlb_tbl_map_single(), because that's how it is used by the generic > > DMA code. In other words, if the parameter is kept, it should be kept > > to match dma_map_*(). > > > > However, there is also symmetry with swiotlb_tbl_unmap_single(). This > > function does use the parameter for the final sync. I believe there > > should be a matching initial sync in swiotlb_tbl_map_single(). In > > short, the buffer sync for DMA non-coherent devices should be moved from > > swiotlb_map() to swiotlb_tbl_map_single(). If this sync is not needed, > > then the caller can (and should) include DMA_ATTR_SKIP_CPU_SYNC in > > the flags parameter. > > > > To sum it up: > > > > * Do *NOT* remove the "dir" parameter. > > * Let me send a patch which moves the initial buffer sync. > > > > I'm not seeing the need to move the initial buffer sync. All > callers of swiotlb_tbl_map_single() already have a subsequent > check for a non-coherent device, and a call to > arch_sync_dma_for_device(). And the Xen code has some > special handling that probably shouldn't go in > swiotlb_tbl_map_single(). Or am I missing something? Oh, sure, there's nothing broken ATM. It's merely a cleanup. The API is asymmetric and thus confusing. You get a final sync by default if you call swiotlb_tbl_unmap_single(), but you don't get an initial sync by default if you call swiotlb_tbl_map_single(). This is difficult to remember, so potential new users of the API may incorrectly assume that an initial sync is done, or that a final sync is not done. And yes, when moving the code, all current users of swiotlb_tbl_map_single() should specify DMA_ATTR_SKIP_CPU_SYNC. Petr T
RE: [PATCH 1/2] swiotlb: Remove alloc_size argument to swiotlb_tbl_map_single()
From: Petr Tesařík Sent: Monday, April 15, 2024 4:46 AM > > Hi Michael, > > sorry for taking so long to answer. Yes, there was no agreement on the > removal of the "dir" parameter, but I'm not sure it's because of > symmetry with swiotlb_sync_*(), because the topic was not really > discussed. > > The discussion was about the KUnit test suite and whether direction is > a property of the bounce buffer or of each sync operation. Since DMA API > defines associates each DMA buffer with a direction, the direction > parameter passed to swiotlb_sync_*() should match what was passed to > swiotlb_tbl_map_single(), because that's how it is used by the generic > DMA code. In other words, if the parameter is kept, it should be kept > to match dma_map_*(). > > However, there is also symmetry with swiotlb_tbl_unmap_single(). This > function does use the parameter for the final sync. I believe there > should be a matching initial sync in swiotlb_tbl_map_single(). In > short, the buffer sync for DMA non-coherent devices should be moved from > swiotlb_map() to swiotlb_tbl_map_single(). If this sync is not needed, > then the caller can (and should) include DMA_ATTR_SKIP_CPU_SYNC in > the flags parameter. > > To sum it up: > > * Do *NOT* remove the "dir" parameter. > * Let me send a patch which moves the initial buffer sync. > I'm not seeing the need to move the initial buffer sync. All callers of swiotlb_tbl_map_single() already have a subsequent check for a non-coherent device, and a call to arch_sync_dma_for_device(). And the Xen code has some special handling that probably shouldn't go in swiotlb_tbl_map_single(). Or am I missing something? Michael
[XEN PATCH v4 2/5] AMD-Vi: Disable IOMMU if cx16 isn't supported
All hardware with AMD-Vi has CMPXCHG16 support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/amd/iommu_map.c | 42 +++--
xen/drivers/passthrough/amd/pci_amd_iommu.c | 6 +++
2 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index e0f4fe736a..f67975e700 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -167,15 +167,14 @@ int amd_iommu_set_root_page_table(struct amd_iommu_dte
*dte,
{
bool valid = flags & SET_ROOT_VALID;
-if ( dte->v && dte->tv &&
- (cpu_has_cx16 || (flags & SET_ROOT_WITH_UNITY_MAP)) )
+if ( dte->v && dte->tv )
{
union {
struct amd_iommu_dte dte;
uint64_t raw64[4];
__uint128_t raw128[2];
} ldte = { .dte = *dte };
-__uint128_t old = ldte.raw128[0];
+__uint128_t res, old = ldte.raw128[0];
int ret = 0;
ldte.dte.domain_id = domain_id;
@@ -185,33 +184,20 @@ int amd_iommu_set_root_page_table(struct amd_iommu_dte
*dte,
ldte.dte.paging_mode = paging_mode;
ldte.dte.v = valid;
-if ( cpu_has_cx16 )
-{
-__uint128_t res = cmpxchg16b(dte, , [0]);
+res = cmpxchg16b(dte, , [0]);
-/*
- * Hardware does not update the DTE behind our backs, so the
- * return value should match "old".
- */
-if ( res != old )
-{
-printk(XENLOG_ERR
- "Dom%d: unexpected DTE %016lx_%016lx (expected
%016lx_%016lx)\n",
- domain_id,
- (uint64_t)(res >> 64), (uint64_t)res,
- (uint64_t)(old >> 64), (uint64_t)old);
-ret = -EILSEQ;
-}
-}
-else /* Best effort, updating domain_id last. */
+/*
+ * Hardware does not update the DTE behind our backs, so the
+ * return value should match "old".
+ */
+if ( res != old )
{
-uint64_t *ptr = (void *)dte;
-
-write_atomic(ptr + 0, ldte.raw64[0]);
-/* No barrier should be needed between these two. */
-write_atomic(ptr + 1, ldte.raw64[1]);
-
-ret = 1;
+printk(XENLOG_ERR
+ "Dom%d: unexpected DTE %016lx_%016lx (expected
%016lx_%016lx)\n",
+ domain_id,
+ (uint64_t)(res >> 64), (uint64_t)res,
+ (uint64_t)(old >> 64), (uint64_t)old);
+ret = -EILSEQ;
}
return ret;
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index f6efd88e36..3a6a23f706 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -305,6 +305,12 @@ static int __init cf_check iov_detect(void)
if ( !iommu_enable && !iommu_intremap )
return 0;
+if ( unlikely(!cpu_has_cx16) )
+{
+printk("AMD-Vi: CPU doesn't support CMPXCHG16B, disabling\n");
+return -ENODEV;
+}
+
if ( (init_done ? amd_iommu_init_late()
: amd_iommu_init(false)) != 0 )
{
--
2.44.0
Teddy Astie | Vates XCP-ng Intern
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
[XEN PATCH v4 1/5] VT-d: Disable IOMMU if cx16 isn't supported
All hardware with VT-d has CMPXCHG16B support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/vtd/iommu.c | 73 ++---
1 file changed, 25 insertions(+), 48 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index c7110af7c9..9c787ba9eb 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1482,7 +1482,7 @@ int domain_context_mapping_one(
{
struct domain_iommu *hd = dom_iommu(domain);
struct context_entry *context, *context_entries, lctxt;
-__uint128_t old;
+__uint128_t res, old;
uint64_t maddr;
uint16_t seg = iommu->drhd->segment, prev_did = 0;
struct domain *prev_dom = NULL;
@@ -1580,55 +1580,23 @@ int domain_context_mapping_one(
ASSERT(!context_fault_disable(lctxt));
}
-if ( cpu_has_cx16 )
-{
-__uint128_t res = cmpxchg16b(context, , );
-
-/*
- * Hardware does not update the context entry behind our backs,
- * so the return value should match "old".
- */
-if ( res != old )
-{
-if ( pdev )
-check_cleanup_domid_map(domain, pdev, iommu);
-printk(XENLOG_ERR
- "%pp: unexpected context entry %016lx_%016lx (expected
%016lx_%016lx)\n",
- _SBDF(seg, bus, devfn),
- (uint64_t)(res >> 64), (uint64_t)res,
- (uint64_t)(old >> 64), (uint64_t)old);
-rc = -EILSEQ;
-goto unlock;
-}
-}
-else if ( !prev_dom || !(mode & MAP_WITH_RMRR) )
-{
-context_clear_present(*context);
-iommu_sync_cache(context, sizeof(*context));
+res = cmpxchg16b(context, , );
-write_atomic(>hi, lctxt.hi);
-/* No barrier should be needed between these two. */
-write_atomic(>lo, lctxt.lo);
-}
-else /* Best effort, updating DID last. */
+/*
+ * Hardware does not update the context entry behind our backs,
+ * so the return value should match "old".
+ */
+if ( res != old )
{
- /*
- * By non-atomically updating the context entry's DID field last,
- * during a short window in time TLB entries with the old domain ID
- * but the new page tables may be inserted. This could affect I/O
- * of other devices using this same (old) domain ID. Such updating
- * therefore is not a problem if this was the only device associated
- * with the old domain ID. Diverting I/O of any of a dying domain's
- * devices to the quarantine page tables is intended anyway.
- */
-if ( !(mode & (MAP_OWNER_DYING | MAP_SINGLE_DEVICE)) )
-printk(XENLOG_WARNING VTDPREFIX
- " %pp: reassignment may cause %pd data corruption\n",
- _SBDF(seg, bus, devfn), prev_dom);
-
-write_atomic(>lo, lctxt.lo);
-/* No barrier should be needed between these two. */
-write_atomic(>hi, lctxt.hi);
+if ( pdev )
+check_cleanup_domid_map(domain, pdev, iommu);
+printk(XENLOG_ERR
+"%pp: unexpected context entry %016lx_%016lx (expected
%016lx_%016lx)\n",
+_SBDF(seg, bus, devfn),
+(uint64_t)(res >> 64), (uint64_t)res,
+(uint64_t)(old >> 64), (uint64_t)old);
+rc = -EILSEQ;
+goto unlock;
}
iommu_sync_cache(context, sizeof(struct context_entry));
@@ -2630,6 +2598,15 @@ static int __init cf_check vtd_setup(void)
int ret;
bool reg_inval_supported = true;
+if ( unlikely(!cpu_has_cx16) )
+{
+printk(XENLOG_ERR VTDPREFIX
+ "IOMMU: CPU doesn't support CMPXCHG16B, disabling\n");
+
+ret = -ENODEV;
+goto error;
+}
+
if ( list_empty(_drhd_units) )
{
ret = -ENODEV;
--
2.44.0
Teddy Astie | Vates XCP-ng Intern
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
[XEN PATCH v4 3/5] VT-d: Cleanup MAP_SINGLE_DEVICE and related code
This flag was only used in case cx16 is not available, as those code paths no
longer exist, this flag now does basically nothing.
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/vtd/iommu.c | 12 +++-
xen/drivers/passthrough/vtd/vtd.h | 5 ++---
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 9c787ba9eb..7c6bae0256 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1692,15 +1692,9 @@ static int domain_context_mapping(struct domain *domain,
u8 devfn,
break;
}
-if ( domain != pdev->domain && pdev->domain != dom_io )
-{
-if ( pdev->domain->is_dying )
-mode |= MAP_OWNER_DYING;
-else if ( drhd &&
- !any_pdev_behind_iommu(pdev->domain, pdev, drhd->iommu) &&
- !pdev->phantom_stride )
-mode |= MAP_SINGLE_DEVICE;
-}
+if ( domain != pdev->domain && pdev->domain != dom_io &&
+ pdev->domain->is_dying )
+mode |= MAP_OWNER_DYING;
switch ( pdev->type )
{
diff --git a/xen/drivers/passthrough/vtd/vtd.h
b/xen/drivers/passthrough/vtd/vtd.h
index cb2df76eed..43f06a353d 100644
--- a/xen/drivers/passthrough/vtd/vtd.h
+++ b/xen/drivers/passthrough/vtd/vtd.h
@@ -28,9 +28,8 @@
*/
#define MAP_WITH_RMRR (1u << 0)
#define MAP_OWNER_DYING (1u << 1)
-#define MAP_SINGLE_DEVICE (1u << 2)
-#define MAP_ERROR_RECOVERY(1u << 3)
-#define UNMAP_ME_PHANTOM_FUNC (1u << 4)
+#define MAP_ERROR_RECOVERY(1u << 2)
+#define UNMAP_ME_PHANTOM_FUNC (1u << 3)
/* Allow for both IOAPIC and IOSAPIC. */
#define IO_xAPIC_route_entry IO_APIC_route_entry
--
2.44.0
Teddy Astie | Vates XCP-ng Intern
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
[XEN PATCH v4 5/5] AMD-Vi: Disable intrerrupt remapping if cx16 is not supported
All hardware with AMD-Vi has CMPXCHG16 support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/amd/iommu_intr.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/drivers/passthrough/amd/iommu_intr.c
b/xen/drivers/passthrough/amd/iommu_intr.c
index 7fc796dec2..9ab7c68749 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -649,6 +649,12 @@ bool __init cf_check iov_supports_xt(void)
if ( !iommu_enable || !iommu_intremap )
return false;
+if ( unlikely(!cpu_has_cx16) )
+{
+AMD_IOMMU_WARN("CPU doesn't support CMPXCHG16B, disable interrupt
remapping\n");
+return false;
+}
+
if ( amd_iommu_prepare(true) )
return false;
--
2.44.0
Teddy Astie | Vates XCP-ng Intern
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
[XEN PATCH v4 0/5] x86/iommu: Drop IOMMU support when cx16 isn't supported
All hardware that supports VT-d/AMD-Vi that exists also supports cx16 (aside specifically crafted virtual machines). Some IOMMU code paths in Xen consider cases where VT-d/AMD-Vi is supported while cx16 isn't, those paths may be bugged and are barely tested, dead code in practice. Disable IOMMU in case we have IOMMU hardware but no cx16, then cleanup no-cx16 handling logic from VT-d and AMD-Vi drivers. Also disable interrupt remapping that also relies on cx16. Teddy Astie (5): VT-d: Disable IOMMU if cx16 isn't supported AMD-Vi: Disable IOMMU if cx16 isn't supported VT-d: Cleanup MAP_SINGLE_DEVICE and related code VT-d: Disable intrerrupt remapping if cx16 is not supported AMD-Vi: Disable intrerrupt remapping if cx16 is not supported xen/drivers/passthrough/amd/iommu_intr.c| 6 ++ xen/drivers/passthrough/amd/iommu_map.c | 42 -- xen/drivers/passthrough/amd/pci_amd_iommu.c | 6 ++ xen/drivers/passthrough/vtd/intremap.c | 70 +--- xen/drivers/passthrough/vtd/iommu.c | 92 +++-- xen/drivers/passthrough/vtd/vtd.h | 5 +- 6 files changed, 77 insertions(+), 144 deletions(-) -- 2.44.0 Teddy Astie | Vates XCP-ng Intern XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
[XEN PATCH v4 4/5] VT-d: Disable intrerrupt remapping if cx16 is not supported
All hardware with VT-d has CMPXCHG16B support. Check this at initialisation
time, and remove the effectively-dead logic for the non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/vtd/intremap.c | 70 --
xen/drivers/passthrough/vtd/iommu.c| 7 +--
2 files changed, 21 insertions(+), 56 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/intremap.c
b/xen/drivers/passthrough/vtd/intremap.c
index c504852eb8..7d4d907b4f 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -150,6 +150,13 @@ bool __init cf_check intel_iommu_supports_eim(void)
if ( !iommu_qinval || !iommu_intremap || list_empty(_drhd_units) )
return false;
+if ( unlikely(!cpu_has_cx16) )
+{
+printk(XENLOG_WARNING VTDPREFIX
+ "CPU doesn't support CMPXCHG16B, disable interrupt
remapping\n");
+return false;
+}
+
/* We MUST have a DRHD unit for each IOAPIC. */
for ( apic = 0; apic < nr_ioapics; apic++ )
if ( !ioapic_to_drhd(IO_APIC_ID(apic)) )
@@ -173,47 +180,26 @@ bool __init cf_check intel_iommu_supports_eim(void)
* Assume iremap_lock has been acquired. It is to make sure software will not
* change the same IRTE behind us. With this assumption, if only high qword or
* low qword in IRTE is to be updated, this function's atomic variant can
- * present an atomic update to VT-d hardware even when cmpxchg16b
- * instruction is not supported.
+ * present an atomic update to VT-d hardware.
*/
static void update_irte(struct vtd_iommu *iommu, struct iremap_entry *entry,
const struct iremap_entry *new_ire, bool atomic)
{
-ASSERT(spin_is_locked(>intremap.lock));
+__uint128_t ret;
+struct iremap_entry old_ire;
-if ( cpu_has_cx16 )
-{
-__uint128_t ret;
-struct iremap_entry old_ire;
+ASSERT(spin_is_locked(>intremap.lock));
-old_ire = *entry;
-ret = cmpxchg16b(entry, _ire, new_ire);
+old_ire = *entry;
+ret = cmpxchg16b(entry, _ire, new_ire);
-/*
- * In the above, we use cmpxchg16 to atomically update the 128-bit
- * IRTE, and the hardware cannot update the IRTE behind us, so
- * the return value of cmpxchg16 should be the same as old_ire.
- * This ASSERT validate it.
- */
-ASSERT(ret == old_ire.val);
-}
-else
-{
-/*
- * VT-d hardware doesn't update IRTEs behind us, nor the software
- * since we hold iremap_lock. If the caller wants VT-d hardware to
- * always see a consistent entry, but we can't meet it, a bug will
- * be raised.
- */
-if ( entry->lo == new_ire->lo )
-write_atomic(>hi, new_ire->hi);
-else if ( entry->hi == new_ire->hi )
-write_atomic(>lo, new_ire->lo);
-else if ( !atomic )
-*entry = *new_ire;
-else
-BUG();
-}
+/*
+ * In the above, we use cmpxchg16 to atomically update the 128-bit
+ * IRTE, and the hardware cannot update the IRTE behind us, so
+ * the return value of cmpxchg16 should be the same as old_ire.
+ * This ASSERT validate it.
+ */
+ASSERT(ret == old_ire.val);
}
/* Mark specified intr remap entry as free */
@@ -395,7 +381,6 @@ static int ioapic_rte_to_remap_entry(struct vtd_iommu
*iommu,
/* Indicate remap format. */
remap_rte->format = 1;
-/* If cmpxchg16b is not available the caller must mask the IO-APIC pin. */
update_irte(iommu, iremap_entry, _ire, !init && !masked);
iommu_sync_cache(iremap_entry, sizeof(*iremap_entry));
iommu_flush_iec_index(iommu, 0, index);
@@ -437,21 +422,6 @@ void cf_check io_apic_write_remap_rte(
bool masked = true;
int rc;
-if ( !cpu_has_cx16 )
-{
- /*
-* Cannot atomically update the IRTE entry: mask the IO-APIC pin to
-* avoid interrupts seeing an inconsistent IRTE entry.
-*/
-old_rte = __ioapic_read_entry(apic, pin, true);
-if ( !old_rte.mask )
-{
-masked = false;
-old_rte.mask = 1;
-__ioapic_write_entry(apic, pin, true, old_rte);
-}
-}
-
/* Not the initializer, for old gcc to cope. */
new_rte.raw = rte;
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 7c6bae0256..a1bd3c5ff6 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2663,12 +2663,7 @@ static int __init cf_check vtd_setup(void)
iommu_intremap = iommu_intremap_off;
#ifndef iommu_intpost
-/*
- * We cannot use posted interrupt if X86_FEATURE_CX16 is
- * not supported, since we count on this feature to
- * atomically update 16-byte IRTE in posted format.
- */
-if ( !cap_intr_post(iommu->cap) ||
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
Hi John, On 15/04/2024 12:17, John Ernberg wrote: Hi Julien, On 4/15/24 1:03 PM, Julien Grall wrote: On 15/04/2024 11:50, Andrew Cooper wrote: On 15/04/2024 11:25 am, Julien Grall wrote: Hi John, I saw this patch was committed. I have one question this may require some adjustment. On 08/04/2024 17:11, John Ernberg wrote: --- xen/arch/arm/platforms/Makefile | 1 + xen/arch/arm/platforms/imx8qm.c | 139 2 files changed, 140 insertions(+) create mode 100644 xen/arch/arm/platforms/imx8qm.c diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 8632f4115f..bec6e55d1f 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o obj-$(CONFIG_ALL64_PLAT) += thunderx.o obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c new file mode 100644 index 00..3600a073e8 --- /dev/null +++ b/xen/arch/arm/platforms/imx8qm.c @@ -0,0 +1,139 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ The majority of Xen code is using GPL-2.0-only. In the early days for Xen on Arm we started to use GPLv2+ which I consider it was a mistake. Unfortunately this started to spread as people copied/pasted the same copyright headers. So can you confirm whether you intended to use GPL-2.0+? If not would you be able to send a patch to adjust it? (Better to it before there are more modifications). Julien: I've called you out multiple times before. And there are multiple thread explaining why I am requesting if we can use GPLv2-only. In fact from CONTRIBUTING: The recommended license of a directory will depend on the COPYING file. If the new file is using a different license, this should be highlighted and discussed in the commit message or cover letter introducing the file. Since part of the code was not written by me, but by Peng, I think both of us need to agree to a license change if one is to be made. Ah I didn't realize that Peng also contributed. Let's wait if he is happy with the change. Also, offline, I was pointed out that I could explain a little bit more why I asked if this could be changed. From [1]: "IIRC from past discussion there are two broads concern with GPLv2+: - We are leaving the choice of which license applies to the person copying the code. So if a new version is released that is less favorable to the initial contributor, then we have no leverage. - Some companies are rather cautious to contribute code that may be licensed under GPLv3 (would be allowed with GPLv2+). The later is particularly a problem because not many people realize that a fair part of Xen on Arm is GPLv2+. I never really understood why we chose that (this was before my time) but this got spread as the existing copyright was added to a new file. Admittely, the contributor should be more cautious. But I would not say this is trivial to spot the difference." Cheers, [1] https://lore.kernel.org/xen-devel/f235f6f8-d585-4e24-7fc8-3f2df9240...@xen.org/ -- Julien Grall
Re: [PATCH 1/2] swiotlb: Remove alloc_size argument to swiotlb_tbl_map_single()
On Sun, 7 Apr 2024 21:11:41 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > Currently swiotlb_tbl_map_single() takes alloc_align_mask and > alloc_size arguments to specify an swiotlb allocation that is > larger than mapping_size. This larger allocation is used solely > by iommu_dma_map_single() to handle untrusted devices that should > not have DMA visibility to memory pages that are partially used > for unrelated kernel data. > > Having two arguments to specify the allocation is redundant. While > alloc_align_mask naturally specifies the alignment of the starting > address of the allocation, it can also implicitly specify the size > by rounding up the mapping_size to that alignment. > > Additionally, the current approach has an edge case bug. > iommu_dma_map_page() already does the rounding up to compute the > alloc_size argument. But swiotlb_tbl_map_single() then calculates > the alignment offset based on the DMA min_align_mask, and adds > that offset to alloc_size. If the offset is non-zero, the addition > may result in a value that is larger than the max the swiotlb can > allocate. If the rounding up is done _after_ the alignment offset is > added to the mapping_size (and the original mapping_size conforms to > the value returned by swiotlb_max_mapping_size), then the max that the > swiotlb can allocate will not be exceeded. > > In view of these issues, simplify the swiotlb_tbl_map_single() interface > by removing the alloc_size argument. Most call sites pass the same > value for mapping_size and alloc_size, and they pass alloc_align_mask > as zero. Just remove the redundant argument from these callers, as they > will see no functional change. For iommu_dma_map_page() also remove > the alloc_size argument, and have swiotlb_tbl_map_single() compute > the alloc_size by rounding up mapping_size after adding the offset > based on min_align_mask. This has the side effect of fixing the > edge case bug but with no other functional change. > > Also add a sanity test on the alloc_align_mask. While IOMMU code > currently ensures the granule is not larger than PAGE_SIZE, if > that guarantee were to be removed in the future, the downstream > effect on the swiotlb might go unnoticed until strange allocation > failures occurred. > > Tested on an ARM64 system with 16K page size and some kernel > test-only hackery to allow modifying the DMA min_align_mask and > the granule size that becomes the alloc_align_mask. Tested these > combinations with a variety of original memory addresses and > sizes, including those that reproduce the edge case bug: > > * 4K granule and 0 min_align_mask > * 4K granule and 0xFFF min_align_mask (4K - 1) > * 16K granule and 0xFFF min_align_mask > * 64K granule and 0xFFF min_align_mask > * 64K granule and 0x3FFF min_align_mask (16K - 1) > > With the changes, all combinations pass. > > Signed-off-by: Michael Kelley > --- > I've haven't used any "Fixes:" tags. This patch really should be > backported only if all the other recent swiotlb fixes get backported, > and I'm unclear on whether that will happen. > > I saw the brief discussion about removing the "dir" parameter from > swiotlb_tbl_map_single(). That removal could easily be done as part > of this patch, since it's already changing the swiotlb_tbl_map_single() > parameters. But I think the conclusion of the discussion was to leave > the "dir" parameter for symmetry with the swiotlb_sync_*() functions. > Please correct me if that's wrong, and I'll respin this patch to do > the removal. Hi Michael, sorry for taking so long to answer. Yes, there was no agreement on the removal of the "dir" parameter, but I'm not sure it's because of symmetry with swiotlb_sync_*(), because the topic was not really discussed. The discussion was about the KUnit test suite and whether direction is a property of the bounce buffer or of each sync operation. Since DMA API defines associates each DMA buffer with a direction, the direction parameter passed to swiotlb_sync_*() should match what was passed to swiotlb_tbl_map_single(), because that's how it is used by the generic DMA code. In other words, if the parameter is kept, it should be kept to match dma_map_*(). However, there is also symmetry with swiotlb_tbl_unmap_single(). This function does use the parameter for the final sync. I believe there should be a matching initial sync in swiotlb_tbl_map_single(). In short, the buffer sync for DMA non-coherent devices should be moved from swiotlb_map() to swiotlb_tbl_map_single(). If this sync is not needed, then the caller can (and should) include DMA_ATTR_SKIP_CPU_SYNC in the flags parameter. To sum it up: * Do *NOT* remove the "dir" parameter. * Let me send a patch which moves the initial buffer sync. Petr T > drivers/iommu/dma-iommu.c | 2 +- > drivers/xen/swiotlb-xen.c | 2 +- > include/linux/swiotlb.h | 2 +- > kernel/dma/swiotlb.c | 56 > +-- 4 files changed, 45 > insertions(+), 17
[linux-5.4 test] 185577: regressions - trouble: blocked/broken/queued/running
flight 185577 linux-5.4 running [real] http://logs.test-lab.xenproject.org/osstest/logs/185577/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-arm64 broken build-arm64-xsm broken build-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-i3865 host-build-prep fail REGR. vs. 185168 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185168 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185168 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185168 build-amd64 5 host-build-prep fail REGR. vs. 185168 build-i386-pvops 5 host-build-prep fail REGR. vs. 185168 build-i386-xsm5 host-build-prep fail REGR. vs. 185168 build-arm64 5 host-build-prep fail REGR. vs. 185168 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185168 build-armhf 5 host-build-prep fail REGR. vs. 185168 test-arm64-arm64-examine queued test-arm64-arm64-libvirt-raw queued test-arm64-arm64-libvirt-xsm queued test-arm64-arm64-xl queued test-arm64-arm64-xl-credit1 queued test-arm64-arm64-xl-credit2 queued test-arm64-arm64-xl-thunderx queued test-arm64-arm64-xl-vhd queued test-arm64-arm64-xl-xsm queued build-arm64-pvops 5 host-build-prep running build-arm64-pvops 3 syslog-serverrunning Tests which did not succeed, but are not blocking: 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-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-xsm 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-raw 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a
Re: [PATCH v2 1/4] docs: add xen_ulong_t to the documented integers sizes/alignments
Hi Julien, > On 15 Apr 2024, at 12:08, Julien Grall wrote: > > Hi Bertrand, > > On 15/04/2024 08:48, Bertrand Marquis wrote: >> Hi Julien, >>> On 12 Apr 2024, at 19:01, Julien Grall wrote: >>> >>> >>> >>> On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis >>> wrote: >>> Hi Julien, >>> On 12 Apr 2024, at 15:53, Julien Grall wrote: On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini wrote: On Wed, 10 Apr 2024, Julien Grall wrote: > On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini > wrote: > xen_ulong_t is widely used in public headers. > > Signed-off-by: Stefano Stabellini > --- > > Given that xen_ulong_t is used in public headers there could be a > better > place for documenting it but this was the most straightforward to > add. > --- >docs/misra/C-language-toolchain.rst | 11 +++ >1 file changed, 11 insertions(+) > > diff --git a/docs/misra/C-language-toolchain.rst > b/docs/misra/C-language-toolchain.rst > index 5ddfe7bdbe..7a334260e6 100644 > --- a/docs/misra/C-language-toolchain.rst > +++ b/docs/misra/C-language-toolchain.rst > @@ -531,6 +531,17 @@ A summary table of data types, sizes and > alignment is below: > - 64 bits > - x86_64, ARMv8-A AArch64, RV64, PPC64 > > + * - xen_ulong_t > + - 32 bits > + - 32 bits > + - x86_32 > + > + * - xen_ulong_t > + - 64 bits > + - 64 bits > + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, > ARMv8-R > + AArch32, ARMv7-A > > > We support neither ARMv8-R nor ARMv8-A Aarch32. > > I could possibly accept the latter because it works to. But the former is > so far misleading. Yes I think you are right. Moreover this document (C-language-toolchain.rst) is meant for the Xen build. While this patch is trying to document the types used in the public headers for the external-facing ABI. I'll move the information this patch is adding to a separate document, specific to the public headers. I will only add the architectures currently working: I'll add ARMv8-A Aarch32 because although it is unsupported it is interesting to know the size of xen_ulong_t for aarch32 in the public headers. I will remove ARMv8-R as it is not available upstream. Thinking a bit more. What about Armv9? Rather than listing each version, should we instead use ARMv7-A aarch32 and later, ARMv8-A aarch64 and later? >>> >>> Definitely you are right here but as for Armv8-R, Armv9 is not something >>> that we explicitely support right now (even though it should work). >>> >>> I am confused with the comparison. I thought you can’t boot Xen at all on >>> Armv8-R. But you can on Armv9-A as this just Armv8-A + features the >>> software don’t need to use. >>> >>> Did you intend to draw the comparison with Armv8-A Aarch32? >> Yes in my mind armv9 even if currently working it is not something >> officially supported so it is in the same state as armv8 aarch32. > > AFAICT, Stefano said he will add ARMv8-A AArch32, so we should be consistent > and add Armv9-A in the list. Yes that makes sense, I agree. Cheers Bertrand > > Cheers, > > -- > Julien Grall
[linux-linus test] 185582: regressions - trouble: blocked/broken/preparing/queued
flight 185582 linux-linus running [real] http://logs.test-lab.xenproject.org/osstest/logs/185582/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64-xsm 5 host-build-prep fail REGR. vs. 185347 build-i3865 host-build-prep fail REGR. vs. 185347 build-amd64 5 host-build-prep fail REGR. vs. 185347 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185347 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185347 build-i386-pvops 5 host-build-prep fail REGR. vs. 185347 build-i386-xsm5 host-build-prep fail REGR. vs. 185347 build-armhf 5 host-build-prep fail REGR. vs. 185347 build-arm64-libvirt queued test-arm64-arm64-examine queued test-arm64-arm64-libvirt-raw queued test-arm64-arm64-libvirt-xsm queued test-arm64-arm64-xl queued test-arm64-arm64-xl-credit1 queued test-arm64-arm64-xl-credit2 queued test-arm64-arm64-xl-thunderx queued test-arm64-arm64-xl-vhd queued test-arm64-arm64-xl-xsm queued build-arm64-pvops 2 hosts-allocate running build-arm64-xsm 2 hosts-allocate running build-arm64 2 hosts-allocate running Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-vhd 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-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd
[xen-unstable test] 185585: regressions - trouble: blocked/broken/preparing/queued
flight 185585 xen-unstable running [real] http://logs.test-lab.xenproject.org/osstest/logs/185585/ Regressions :-( 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-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-prev 5 host-build-prep fail REGR. vs. 185281 build-i386-prev 5 host-build-prep fail REGR. vs. 185281 build-amd64 5 host-build-prep fail REGR. vs. 185281 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185281 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185281 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185281 build-i386-xsm5 host-build-prep fail REGR. vs. 185281 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185281 build-i3865 host-build-prep fail REGR. vs. 185281 build-i386-pvops 5 host-build-prep fail REGR. vs. 185281 build-armhf 5 host-build-prep fail REGR. vs. 185281 build-arm64-libvirt queued test-arm64-arm64-examine queued test-arm64-arm64-libvirt-raw queued test-arm64-arm64-libvirt-xsm queued test-arm64-arm64-xl queued test-arm64-arm64-xl-credit1 queued test-arm64-arm64-xl-credit2 queued test-arm64-arm64-xl-thunderx queued test-arm64-arm64-xl-vhd queued test-arm64-arm64-xl-xsm queued build-arm64 2 hosts-allocate running build-arm64-pvops 2 hosts-allocate running build-arm64-xsm 2 hosts-allocate running Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-xtf-amd64-amd64-31 build-check(1) blocked n/a test-xtf-amd64-amd64-41 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1)
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
Hi everyone, We all have a responsibility and pledge to make this community a welcoming environment. As such, I would like to request we keep the Code of Conduct and patch discussions separate. Should there be a need for any Code of Conduct complaints/investigations, this will be treated separately. Thank you John for your contributions. Many thanks, Kelly Choi Community Manager Xen Project On Mon, Apr 15, 2024 at 12:03 PM Julien Grall wrote: > > > On 15/04/2024 11:50, Andrew Cooper wrote: > > On 15/04/2024 11:25 am, Julien Grall wrote: > >> Hi John, > >> > >> I saw this patch was committed. I have one question this may require > >> some adjustment. > >> > >> On 08/04/2024 17:11, John Ernberg wrote: > >>> --- > >>>xen/arch/arm/platforms/Makefile | 1 + > >>>xen/arch/arm/platforms/imx8qm.c | 139 > > >>>2 files changed, 140 insertions(+) > >>>create mode 100644 xen/arch/arm/platforms/imx8qm.c > >>> > >>> diff --git a/xen/arch/arm/platforms/Makefile > >>> b/xen/arch/arm/platforms/Makefile > >>> index 8632f4115f..bec6e55d1f 100644 > >>> --- a/xen/arch/arm/platforms/Makefile > >>> +++ b/xen/arch/arm/platforms/Makefile > >>> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o > >>>obj-$(CONFIG_ALL64_PLAT) += thunderx.o > >>>obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o > >>>obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o > >>> +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o > >>>obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o > >>>obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o > >>> diff --git a/xen/arch/arm/platforms/imx8qm.c > >>> b/xen/arch/arm/platforms/imx8qm.c > >>> new file mode 100644 > >>> index 00..3600a073e8 > >>> --- /dev/null > >>> +++ b/xen/arch/arm/platforms/imx8qm.c > >>> @@ -0,0 +1,139 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0-or-later */ > >> > >> The majority of Xen code is using GPL-2.0-only. In the early days for > >> Xen on Arm we started to use GPLv2+ which I consider it was a mistake. > >> Unfortunately this started to spread as people copied/pasted the same > >> copyright headers. > >> > >> So can you confirm whether you intended to use GPL-2.0+? If not would > >> you be able to send a patch to adjust it? (Better to it before there > >> are more modifications). > > > > Julien: I've called you out multiple times before. > > And there are multiple thread explaining why I am requesting if we can > use GPLv2-only. In fact from CONTRIBUTING: > > The recommended license of a directory will depend on the COPYING file. > If the new file is using a different license, this should be highlighted > and discussed in the commit message or cover letter introducing the > file. > > > Don't ever bully contributors into changing licensing. It is > > unacceptable behaviour, and in most cases - including this one by the > > looks of things - not legal. > > I don't think I have bullied the contributor. I have asked politely > whether it can be done. There is nothing illegal (see above). > > The problematic behavior is you trying to pressure the other people to > accept your point of view by been condescending or insulting them like > you did here. > > I have reported this behavior several times to CoC. And I guess this > need to happen again. > > Cheers, > > -- > Julien Grall >
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
Hi Julien, On 4/15/24 1:03 PM, Julien Grall wrote: > > > On 15/04/2024 11:50, Andrew Cooper wrote: >> On 15/04/2024 11:25 am, Julien Grall wrote: >>> Hi John, >>> >>> I saw this patch was committed. I have one question this may require >>> some adjustment. >>> >>> On 08/04/2024 17:11, John Ernberg wrote: --- xen/arch/arm/platforms/Makefile | 1 + xen/arch/arm/platforms/imx8qm.c | 139 2 files changed, 140 insertions(+) create mode 100644 xen/arch/arm/platforms/imx8qm.c diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 8632f4115f..bec6e55d1f 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o obj-$(CONFIG_ALL64_PLAT) += thunderx.o obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c new file mode 100644 index 00..3600a073e8 --- /dev/null +++ b/xen/arch/arm/platforms/imx8qm.c @@ -0,0 +1,139 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ >>> >>> The majority of Xen code is using GPL-2.0-only. In the early days for >>> Xen on Arm we started to use GPLv2+ which I consider it was a mistake. >>> Unfortunately this started to spread as people copied/pasted the same >>> copyright headers. >>> >>> So can you confirm whether you intended to use GPL-2.0+? If not would >>> you be able to send a patch to adjust it? (Better to it before there >>> are more modifications). >> >> Julien: I've called you out multiple times before. > > And there are multiple thread explaining why I am requesting if we can > use GPLv2-only. In fact from CONTRIBUTING: > > The recommended license of a directory will depend on the COPYING file. > If the new file is using a different license, this should be highlighted > and discussed in the commit message or cover letter introducing the > file. > Since part of the code was not written by me, but by Peng, I think both of us need to agree to a license change if one is to be made. I am personally fine with either license. >> Don't ever bully contributors into changing licensing. It is >> unacceptable behaviour, and in most cases - including this one by the >> looks of things - not legal. > > I don't think I have bullied the contributor. I have asked politely > whether it can be done. There is nothing illegal (see above). Just adding: I did not feel bullied here. > > The problematic behavior is you trying to pressure the other people to > accept your point of view by been condescending or insulting them like > you did here. > > I have reported this behavior several times to CoC. And I guess this > need to happen again. > > Cheers, > Best regards // John Ernberg
[xen-4.15-testing test] 185590: regressions - trouble: blocked/broken/preparing/queued
flight 185590 xen-4.15-testing running [real] http://logs.test-lab.xenproject.org/osstest/logs/185590/ Regressions :-( 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-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-xsm 5 host-build-prep fail REGR. vs. 185282 build-i386-xsm5 host-build-prep fail REGR. vs. 185282 build-i3865 host-build-prep fail REGR. vs. 185282 build-amd64 5 host-build-prep fail REGR. vs. 185282 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185282 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185282 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185282 build-i386-prev 5 host-build-prep fail REGR. vs. 185282 build-amd64-prev 5 host-build-prep fail REGR. vs. 185282 build-i386-pvops 5 host-build-prep fail REGR. vs. 185282 build-armhf 5 host-build-prep fail REGR. vs. 185282 build-arm64-libvirt queued test-arm64-arm64-libvirt-raw queued test-arm64-arm64-libvirt-xsm queued test-arm64-arm64-xl queued test-arm64-arm64-xl-credit1 queued test-arm64-arm64-xl-credit2 queued test-arm64-arm64-xl-thunderx queued test-arm64-arm64-xl-vhd queued test-arm64-arm64-xl-xsm queued build-arm64-xsm 2 hosts-allocate running build-arm64 2 hosts-allocate running build-arm64-pvops 2 hosts-allocate running Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
On 15/04/2024 11:50, Andrew Cooper wrote: On 15/04/2024 11:25 am, Julien Grall wrote: Hi John, I saw this patch was committed. I have one question this may require some adjustment. On 08/04/2024 17:11, John Ernberg wrote: --- xen/arch/arm/platforms/Makefile | 1 + xen/arch/arm/platforms/imx8qm.c | 139 2 files changed, 140 insertions(+) create mode 100644 xen/arch/arm/platforms/imx8qm.c diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 8632f4115f..bec6e55d1f 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o obj-$(CONFIG_ALL64_PLAT) += thunderx.o obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c new file mode 100644 index 00..3600a073e8 --- /dev/null +++ b/xen/arch/arm/platforms/imx8qm.c @@ -0,0 +1,139 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ The majority of Xen code is using GPL-2.0-only. In the early days for Xen on Arm we started to use GPLv2+ which I consider it was a mistake. Unfortunately this started to spread as people copied/pasted the same copyright headers. So can you confirm whether you intended to use GPL-2.0+? If not would you be able to send a patch to adjust it? (Better to it before there are more modifications). Julien: I've called you out multiple times before. And there are multiple thread explaining why I am requesting if we can use GPLv2-only. In fact from CONTRIBUTING: The recommended license of a directory will depend on the COPYING file. If the new file is using a different license, this should be highlighted and discussed in the commit message or cover letter introducing the file. Don't ever bully contributors into changing licensing. It is unacceptable behaviour, and in most cases - including this one by the looks of things - not legal. I don't think I have bullied the contributor. I have asked politely whether it can be done. There is nothing illegal (see above). The problematic behavior is you trying to pressure the other people to accept your point of view by been condescending or insulting them like you did here. I have reported this behavior several times to CoC. And I guess this need to happen again. Cheers, -- Julien Grall
[linux-6.1 test] 185571: regressions - trouble: blocked/broken
flight 185571 linux-6.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/185571/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64-pvops 5 host-build-prep fail REGR. vs. 185299 build-amd64 5 host-build-prep fail REGR. vs. 185299 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185299 build-i3865 host-build-prep fail REGR. vs. 185299 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185299 build-i386-pvops 5 host-build-prep fail REGR. vs. 185299 build-i386-xsm5 host-build-prep fail REGR. vs. 185299 build-arm64 5 host-build-prep fail REGR. vs. 185299 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185299 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185299 build-armhf 5 host-build-prep fail REGR. vs. 185299 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-vhd 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-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1)
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
On 15/04/2024 11:25 am, Julien Grall wrote: > Hi John, > > I saw this patch was committed. I have one question this may require > some adjustment. > > On 08/04/2024 17:11, John Ernberg wrote: >> --- >> xen/arch/arm/platforms/Makefile | 1 + >> xen/arch/arm/platforms/imx8qm.c | 139 >> 2 files changed, 140 insertions(+) >> create mode 100644 xen/arch/arm/platforms/imx8qm.c >> >> diff --git a/xen/arch/arm/platforms/Makefile >> b/xen/arch/arm/platforms/Makefile >> index 8632f4115f..bec6e55d1f 100644 >> --- a/xen/arch/arm/platforms/Makefile >> +++ b/xen/arch/arm/platforms/Makefile >> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o >> obj-$(CONFIG_ALL64_PLAT) += thunderx.o >> obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o >> obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o >> +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o >> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o >> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o >> diff --git a/xen/arch/arm/platforms/imx8qm.c >> b/xen/arch/arm/platforms/imx8qm.c >> new file mode 100644 >> index 00..3600a073e8 >> --- /dev/null >> +++ b/xen/arch/arm/platforms/imx8qm.c >> @@ -0,0 +1,139 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ > > The majority of Xen code is using GPL-2.0-only. In the early days for > Xen on Arm we started to use GPLv2+ which I consider it was a mistake. > Unfortunately this started to spread as people copied/pasted the same > copyright headers. > > So can you confirm whether you intended to use GPL-2.0+? If not would > you be able to send a patch to adjust it? (Better to it before there > are more modifications). Julien: I've called you out multiple times before. Don't ever bully contributors into changing licensing. It is unacceptable behaviour, and in most cases - including this one by the looks of things - not legal. John: Thankyou for your contribution. It has been made under a license compatible with the rest of Xen. There is no need to make any change, and please do not feel pressured into doing so. ~Andrew
Re: [PATCH v2] drivers: char: Enable OMAP UART driver for TI K3 devices
Hi, On 08/04/2024 16:03, Vaishnav Achath wrote: TI K3 devices (J721E, J721S2, AM62X .etc) have the same variant of UART as OMAP4. Add the compatible used in Linux device tree, "ti,am654-uart" to the OMAP UART dt_match so that the driver can be used with these devices. Also, enable the driver for ARM64 platforms. Reviewed-by: Michal Orzel Signed-off-by: Vaishnav Achath In general, the tags are sorted chronologically. I can re-order both when committing: Acked-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH] xen/public: s/int/int32_t
Hi, On 10/04/2024 00:26, Stefano Stabellini wrote: From 28f83c4ec0c0b5c1e7eb2bd8bc5dc3190314a5b7 Mon Sep 17 00:00:00 2001 From: Stefano Stabellini Date: Tue, 9 Apr 2024 16:19:21 -0700 Subject: [PATCH] public: s/int/int32_t Straightforward int -> int32_t and unsigned int -> uint32_t replacements in public headers. No ABI or semantic changes intended. Signed-off-by: Stefano Stabellini Reviewed-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
Hi John, I saw this patch was committed. I have one question this may require some adjustment. On 08/04/2024 17:11, John Ernberg wrote: --- xen/arch/arm/platforms/Makefile | 1 + xen/arch/arm/platforms/imx8qm.c | 139 2 files changed, 140 insertions(+) create mode 100644 xen/arch/arm/platforms/imx8qm.c diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 8632f4115f..bec6e55d1f 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o obj-$(CONFIG_ALL64_PLAT) += thunderx.o obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c new file mode 100644 index 00..3600a073e8 --- /dev/null +++ b/xen/arch/arm/platforms/imx8qm.c @@ -0,0 +1,139 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ The majority of Xen code is using GPL-2.0-only. In the early days for Xen on Arm we started to use GPLv2+ which I consider it was a mistake. Unfortunately this started to spread as people copied/pasted the same copyright headers. So can you confirm whether you intended to use GPL-2.0+? If not would you be able to send a patch to adjust it? (Better to it before there are more modifications). Cheers, -- Julien Grall
Re: [PATCH v2 1/4] docs: add xen_ulong_t to the documented integers sizes/alignments
Hi Bertrand, On 15/04/2024 08:48, Bertrand Marquis wrote: Hi Julien, On 12 Apr 2024, at 19:01, Julien Grall wrote: On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis wrote: Hi Julien, On 12 Apr 2024, at 15:53, Julien Grall wrote: On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini wrote: On Wed, 10 Apr 2024, Julien Grall wrote: On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini wrote: xen_ulong_t is widely used in public headers. Signed-off-by: Stefano Stabellini --- Given that xen_ulong_t is used in public headers there could be a better place for documenting it but this was the most straightforward to add. --- docs/misra/C-language-toolchain.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst index 5ddfe7bdbe..7a334260e6 100644 --- a/docs/misra/C-language-toolchain.rst +++ b/docs/misra/C-language-toolchain.rst @@ -531,6 +531,17 @@ A summary table of data types, sizes and alignment is below: - 64 bits - x86_64, ARMv8-A AArch64, RV64, PPC64 + * - xen_ulong_t + - 32 bits + - 32 bits + - x86_32 + + * - xen_ulong_t + - 64 bits + - 64 bits + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, ARMv8-R + AArch32, ARMv7-A We support neither ARMv8-R nor ARMv8-A Aarch32. I could possibly accept the latter because it works to. But the former is so far misleading. Yes I think you are right. Moreover this document (C-language-toolchain.rst) is meant for the Xen build. While this patch is trying to document the types used in the public headers for the external-facing ABI. I'll move the information this patch is adding to a separate document, specific to the public headers. I will only add the architectures currently working: I'll add ARMv8-A Aarch32 because although it is unsupported it is interesting to know the size of xen_ulong_t for aarch32 in the public headers. I will remove ARMv8-R as it is not available upstream. Thinking a bit more. What about Armv9? Rather than listing each version, should we instead use ARMv7-A aarch32 and later, ARMv8-A aarch64 and later? Definitely you are right here but as for Armv8-R, Armv9 is not something that we explicitely support right now (even though it should work). I am confused with the comparison. I thought you can’t boot Xen at all on Armv8-R. But you can on Armv9-A as this just Armv8-A + features the software don’t need to use. Did you intend to draw the comparison with Armv8-A Aarch32? Yes in my mind armv9 even if currently working it is not something officially supported so it is in the same state as armv8 aarch32. AFAICT, Stefano said he will add ARMv8-A AArch32, so we should be consistent and add Armv9-A in the list. Cheers, -- Julien Grall
[libvirt test] 185570: regressions - trouble: blocked/broken
flight 185570 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/185570/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-i386-pvops 5 host-build-prep fail REGR. vs. 185412 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185412 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185412 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185412 build-i386-xsm5 host-build-prep fail REGR. vs. 185412 build-amd64 5 host-build-prep fail REGR. vs. 185412 build-i3865 host-build-prep fail REGR. vs. 185412 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185412 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185412 build-arm64 5 host-build-prep fail REGR. vs. 185412 build-armhf 5 host-build-prep fail REGR. vs. 185412 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 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-raw 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-vhd 1 build-check(1) blocked n/a version targeted for testing: libvirt a4972778f97ae667a02bbbecdeabb912506fa2cf baseline version: libvirt 812a146dfe784315edece43d09f8d9e432f8230e Last test of basis 185412 2024-04-13 04:19:07 Z2 days Testing same since 185482 2024-04-14 04:19:08 Z1 days2 attempts People who touched revisions under test: Michal Privoznik jobs: build-amd64-xsm broken build-arm64-xsm broken build-i386-xsm broken build-amd64 broken build-arm64 broken build-armhf broken build-i386 broken build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-arm64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked
[XEN PATCH] docs/misra: mark the gzip folder as adopted code
Mark the whole gzip folder as adopted code and remove the redundant
deviation of file inflate.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 5 -
docs/misra/exclude-list.json | 2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 0230b41c6d..4287805819 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -148,11 +148,6 @@ const-qualified."
# Series 8.
#
--doc_begin="The following file is imported from Linux: ignore for now."
--file_tag+={adopted_r8_2,"^xen/common/inflate\\.c$"}
--config=MC3R1.R8.2,reports+={deliberate,"any_area(any_loc(file(adopted_r8_2)))"}
--doc_end
-
-doc_begin="The type ret_t is deliberately used and defined as int or long
depending on the architecture."
-config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"}
-doc_end
diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json
index 0956364158..cd69765427 100644
--- a/docs/misra/exclude-list.json
+++ b/docs/misra/exclude-list.json
@@ -118,7 +118,7 @@
"comment": "Imported from Linux, ignore for now"
},
{
-"rel_path": "common/gzip/inflate.c",
+"rel_path": "common/gzip/*",
"comment": "Imported from Linux, ignore for now"
},
{
--
2.34.1
[xen-4.15-testing test] 185567: regressions - trouble: blocked/broken
flight 185567 xen-4.15-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/185567/ Regressions :-( 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 broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-xsm 5 host-build-prep fail REGR. vs. 185282 build-i386-xsm5 host-build-prep fail REGR. vs. 185282 build-i3865 host-build-prep fail REGR. vs. 185282 build-amd64 5 host-build-prep fail REGR. vs. 185282 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185282 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185282 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185282 build-i386-prev 5 host-build-prep fail REGR. vs. 185282 build-amd64-prev 5 host-build-prep fail REGR. vs. 185282 build-i386-pvops 5 host-build-prep fail REGR. vs. 185282 build-arm64 5 host-build-prep fail REGR. vs. 185282 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185282 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185282 build-armhf 5 host-build-prep fail REGR. vs. 185282 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a
Re: [PATCH] osstest: increase boot timeout for Debian PV guests
On Mon, Apr 15, 2024 at 10:33:19AM +0200, Roger Pau Monné wrote: > On Mon, Apr 15, 2024 at 09:15:51AM +0100, Anthony PERARD wrote: > > On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote: > > > The current timeout of 40s seems to be too low for AMD boxes (pinots and > > > rimavas) in the lab after XSA-455, see: > > > > There's something else we can tweak if only some machine need extra > > time, it is an host property "TimeoutFactor", which can increase all > > timeout for a single machine. (It's use on the cubietruck for example.) > > > > Or is it better to just increase boot time for all (or at least those) > > pv guest? > > I did consider that, but given the timeout is just limited to PV guest > startup I considered the "TimeoutFactor" too broad. I think > increasing the Debian PV boot timeout from 40s to 60s is a minor > adjustment, and shouldn't affect other tests. > > Let me know if you still prefer to use "TimeoutFactor" and I will look > into it. Acked-by: Anthony PERARD Thanks, -- Anthony PERARD
Re: [OSSTEST PATCH] production-config: override mirror url for buster, use archive
On Mon, Apr 15, 2024 at 09:17:08AM +0100, Anthony PERARD wrote: > buster-backport isn't available on the main mirror anymore. > > Signed-off-by: Anthony PERARD Acked-by: Roger Pau Monné Please push ASAP. Thanks, Roger.
Re: [PATCH] osstest: increase boot timeout for Debian PV guests
On Mon, Apr 15, 2024 at 09:15:51AM +0100, Anthony PERARD wrote: > On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote: > > The current timeout of 40s seems to be too low for AMD boxes (pinots and > > rimavas) in the lab after XSA-455, see: > > There's something else we can tweak if only some machine need extra > time, it is an host property "TimeoutFactor", which can increase all > timeout for a single machine. (It's use on the cubietruck for example.) > > Or is it better to just increase boot time for all (or at least those) > pv guest? I did consider that, but given the timeout is just limited to PV guest startup I considered the "TimeoutFactor" too broad. I think increasing the Debian PV boot timeout from 40s to 60s is a minor adjustment, and shouldn't affect other tests. Let me know if you still prefer to use "TimeoutFactor" and I will look into it. Thanks, Roger.
[xen-unstable test] 185564: regressions - trouble: blocked/broken
flight 185564 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/185564/ Regressions :-( 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 broken build-armhf-pvopsbroken build-i386 broken build-i386-prev broken build-i386-pvops broken build-i386-xsm broken build-amd64-prev 5 host-build-prep fail REGR. vs. 185281 build-i386-prev 5 host-build-prep fail REGR. vs. 185281 build-amd64 5 host-build-prep fail REGR. vs. 185281 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185281 build-amd64-xtf 5 host-build-prep fail REGR. vs. 185281 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185281 build-i386-xsm5 host-build-prep fail REGR. vs. 185281 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185281 build-i3865 host-build-prep fail REGR. vs. 185281 build-i386-pvops 5 host-build-prep fail REGR. vs. 185281 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185281 build-arm64 5 host-build-prep fail REGR. vs. 185281 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185281 build-armhf 5 host-build-prep fail REGR. vs. 185281 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-xtf-amd64-amd64-31 build-check(1) blocked n/a test-xtf-amd64-amd64-41 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pygrub
[OSSTEST PATCH] production-config: override mirror url for buster, use archive
buster-backport isn't available on the main mirror anymore. Signed-off-by: Anthony PERARD --- Notes: I've tested the patch already, so I'll push that soon. production-config | 2 ++ 1 file changed, 2 insertions(+) diff --git a/production-config b/production-config index 6345c40c..5b0c640d 100644 --- a/production-config +++ b/production-config @@ -95,6 +95,8 @@ TftpDiVersion_buster 2023-06-20 DebianSnapshotBackports_jessie http://snapshot.debian.org/archive/debian/20190206T211314Z/ +DebianMirror_buster http://archive.debian.org/debian/ + # For ISO installs DebianImageVersion_wheezy 7.2.0 DebianImageVersion_jessie 8.2.0 -- Anthony PERARD
Re: [PATCH] osstest: increase boot timeout for Debian PV guests
On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote: > The current timeout of 40s seems to be too low for AMD boxes (pinots and > rimavas) in the lab after XSA-455, see: There's something else we can tweak if only some machine need extra time, it is an host property "TimeoutFactor", which can increase all timeout for a single machine. (It's use on the cubietruck for example.) Or is it better to just increase boot time for all (or at least those) pv guest? Cheers, -- Anthony PERARD
[linux-linus test] 185560: regressions - trouble: blocked/broken
flight 185560 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/185560/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-amd64-xsm 5 host-build-prep fail REGR. vs. 185347 build-i3865 host-build-prep fail REGR. vs. 185347 build-amd64 5 host-build-prep fail REGR. vs. 185347 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185347 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185347 build-i386-pvops 5 host-build-prep fail REGR. vs. 185347 build-i386-xsm5 host-build-prep fail REGR. vs. 185347 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185347 build-arm64 5 host-build-prep fail REGR. vs. 185347 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185347 build-armhf 5 host-build-prep fail REGR. vs. 185347 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-vhd 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-raw 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)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1)
Re: [PATCH v2 1/4] docs: add xen_ulong_t to the documented integers sizes/alignments
Hi Julien, > On 12 Apr 2024, at 19:01, Julien Grall wrote: > > > > On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis > wrote: > Hi Julien, > > > On 12 Apr 2024, at 15:53, Julien Grall wrote: > > > > > > > > On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini > > wrote: > > On Wed, 10 Apr 2024, Julien Grall wrote: > > > On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini > > > wrote: > > > xen_ulong_t is widely used in public headers. > > > > > > Signed-off-by: Stefano Stabellini > > > --- > > > > > > Given that xen_ulong_t is used in public headers there could be a > > > better > > > place for documenting it but this was the most straightforward to > > > add. > > > --- > > >docs/misra/C-language-toolchain.rst | 11 +++ > > >1 file changed, 11 insertions(+) > > > > > > diff --git a/docs/misra/C-language-toolchain.rst > > > b/docs/misra/C-language-toolchain.rst > > > index 5ddfe7bdbe..7a334260e6 100644 > > > --- a/docs/misra/C-language-toolchain.rst > > > +++ b/docs/misra/C-language-toolchain.rst > > > @@ -531,6 +531,17 @@ A summary table of data types, sizes and > > > alignment is below: > > > - 64 bits > > > - x86_64, ARMv8-A AArch64, RV64, PPC64 > > > > > > + * - xen_ulong_t > > > + - 32 bits > > > + - 32 bits > > > + - x86_32 > > > + > > > + * - xen_ulong_t > > > + - 64 bits > > > + - 64 bits > > > + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, > > > ARMv8-R > > > + AArch32, ARMv7-A > > > > > > > > > We support neither ARMv8-R nor ARMv8-A Aarch32. > > > > > > I could possibly accept the latter because it works to. But the former is > > > so far misleading. > > > > Yes I think you are right. Moreover this document > > (C-language-toolchain.rst) is meant for the Xen build. While this patch > > is trying to document the types used in the public headers for the > > external-facing ABI. > > > > I'll move the information this patch is adding to a separate document, > > specific to the public headers. I will only add the architectures > > currently working: I'll add ARMv8-A Aarch32 because although it is > > unsupported it is interesting to know the size of xen_ulong_t for > > aarch32 in the public headers. I will remove ARMv8-R as it is not > > available upstream. > > > > Thinking a bit more. What about Armv9? Rather than listing each version, > > should we instead use ARMv7-A aarch32 and later, ARMv8-A aarch64 and later? > > Definitely you are right here but as for Armv8-R, Armv9 is not something that > we explicitely support right now (even though it should work). > > I am confused with the comparison. I thought you can’t boot Xen at all on > Armv8-R. But you can on Armv9-A as this just Armv8-A + features the software > don’t need to use. > > Did you intend to draw the comparison with Armv8-A Aarch32? Yes in my mind armv9 even if currently working it is not something officially supported so it is in the same state as armv8 aarch32. Armv8-R currently cannot work at all so it is a different state. Cheers Bertrand > > Cheers, > > > > Cheers > Bertrand
[linux-5.4 test] 185540: regressions - trouble: blocked/broken
flight 185540 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/185540/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvopsbroken build-amd64-xsm broken build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf broken build-armhf-pvopsbroken build-i386 broken build-i386-pvops broken build-i386-xsm broken build-i3865 host-build-prep fail REGR. vs. 185168 build-armhf-pvops 5 host-build-prep fail REGR. vs. 185168 build-amd64-pvops 5 host-build-prep fail REGR. vs. 185168 build-amd64-xsm 5 host-build-prep fail REGR. vs. 185168 build-amd64 5 host-build-prep fail REGR. vs. 185168 build-i386-pvops 5 host-build-prep fail REGR. vs. 185168 build-i386-xsm5 host-build-prep fail REGR. vs. 185168 build-arm64-pvops 5 host-build-prep fail REGR. vs. 185168 build-arm64 5 host-build-prep fail REGR. vs. 185168 build-arm64-xsm 5 host-build-prep fail REGR. vs. 185168 build-armhf 5 host-build-prep fail REGR. vs. 185168 Tests which did not succeed, but are not blocking: 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-shadow 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-xsm 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-raw 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1)
