Re: [Xen-devel] [PATCH v1] docs: substitute XEN_CONFIG_DIR in xl.conf.5
Am Sun, 18 Aug 2019 18:20:26 +0100 schrieb Wei Liu : > This doesn't apply. There is no such file. My changes need to be applied in this order, some of them may apply in any order: 20190619120633.27466-1-o...@aepfle.de 20190619121715.28532-1-o...@aepfle.de 20190619123818.30747-1-o...@aepfle.de 20190619130335.3458-1-o...@aepfle.de 20190621092944.29241-1-o...@aepfle.de 20190621093005.29329-1-o...@aepfle.de Olaf pgpihQJ_IPwMM.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] docs: substitute XEN_CONFIG_DIR in xl.conf.5
On Sun, Aug 18, 2019 at 06:27:26PM +0100, Andrew Cooper wrote:
> On 18/08/2019 18:20, Wei Liu wrote:
> > On Fri, Jun 21, 2019 at 11:30:05AM +0200, Olaf Hering wrote:
> >> xl(1) opens xl.conf in XEN_CONFIG_DIR.
> >> Substitute this variable also in the man page.
> >>
> >> Signed-off-by: Olaf Hering
> >> ---
> >> docs/man/xl.1.pod.in | 2 +-
> >> docs/man/xl.conf.5.pod.in | 2 +-
> >> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
> >> index 3d64eaa5b2..fb17153635 100644
> >> --- a/docs/man/xl.1.pod.in
> >> +++ b/docs/man/xl.1.pod.in
> >> @@ -50,7 +50,7 @@ setup the bridge.
> >>
> >> If you specify the amount of memory dom0 has, passing B to
> >> Xen, it is highly recommended to disable B. Edit
> >> -B and set it to 0.
> >> +B<@XEN_CONFIG_DIR@/xl.conf> and set it to 0.
> >>
> >> =item run xl as B
> >>
> >> diff --git a/docs/man/xl.conf.5.pod.in b/docs/man/xl.conf.5.pod.in
> >> index 2beb2119a8..b16036aaeb 100644
> >> --- a/docs/man/xl.conf.5.pod.in
> >> +++ b/docs/man/xl.conf.5.pod.in
> > Sorry for the late reply.
> >
> > This doesn't apply. There is no such file.
>
> Hmm. We have a xl.conf.5.pod which has no substitutions in, and I don't
> recall this changing. Perhaps a logical dependency earlier in the SUSE
> patch queue?
>
> I think this patch needs a {pod=>pod.in} rename as well, for it to apply
> to staging and work as intended.
I figured that as well.
Perhaps I missed the patch that did the renaming from Olaf.
Unfortunately I don't have the full xen-devel archive in my mailbox now.
Wei.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] docs: substitute XEN_CONFIG_DIR in xl.conf.5
On Mon, Aug 19, 2019 at 09:57:17AM +0200, Olaf Hering wrote: > Am Sun, 18 Aug 2019 18:20:26 +0100 > schrieb Wei Liu : > > > This doesn't apply. There is no such file. > > My changes need to be applied in this order, some of them may apply in any > order: > > 20190619120633.27466-1-o...@aepfle.de > 20190619121715.28532-1-o...@aepfle.de > 20190619123818.30747-1-o...@aepfle.de > 20190619130335.3458-1-o...@aepfle.de > 20190621092944.29241-1-o...@aepfle.de > 20190621093005.29329-1-o...@aepfle.de Thanks. I will take a look. Wei. > > > Olaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 11/11] arm64: use asm-generic/dma-mapping.h
On Fri, Aug 16, 2019 at 03:00:13PM +0200, Christoph Hellwig wrote: > Now that the Xen special cases are gone nothing worth mentioning is > left in the arm64 file, so switch to use the > asm-generic version instead. > > Signed-off-by: Christoph Hellwig > --- > arch/arm64/include/asm/Kbuild| 1 + > arch/arm64/include/asm/dma-mapping.h | 22 -- > arch/arm64/mm/dma-mapping.c | 1 + > 3 files changed, 2 insertions(+), 22 deletions(-) > delete mode 100644 arch/arm64/include/asm/dma-mapping.h Acked-by: Will Deacon Thanks for cleaning this up. Will ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 140301: regressions - FAIL
flight 140301 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140301/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140072 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 140238 pass in 140072 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail in 140238 pass in 140301 test-armhf-armhf-xl-vhd 10 debian-di-install fail in 140238 pass in 140301 test-amd64-amd64-xl-pvshim 12 guest-startfail pass in 140238 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail pass in 140238 test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail pass in 140238 test-armhf-armhf-libvirt-raw 10 debian-di-install fail pass in 140238 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 140238 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 140238 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
On Sun, Aug 18, 2019 at 10:00:17PM -0700, Roman Shaposhnik wrote: > Hi Roger! > > Some good news, some bad news ;-) > > Good news is that on the newer BIOS, your original patch seems to work fine. > > IOW, with newer BIOS: > 1. without your original patch I see garbled screen > 2. with your original patch everything boots normally. That would be my expectation. > Bad news is that with older BIOS, your original patch seems to either > work or not depending on the BIOS some of the BIOS settings. > > IOW, with older BIOS: > 1. without your original patch I see garbled screen (regardless of > BIOS settings) > 2. with your original patch AND resetting to a factory defaults of > BIOS settings -- everything boots normally > 3. when I load up our custom settings -- the only thing that can > boot normally is the latest patch > > So, would it make sense and commit your original patch for now? This > will unlock me with newer BIOSes on these boxes. I think so, can you please provide a tested-by to the patch: https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg01547.html Feel free to also note the weird behaviour you are seeing with this box and firmware version. > As for the older BIOSes, I still feel that it would be great for Xen > to boot more reliably -- especially since Xen 4.10 seems to be doing > fine regardless of BIOS version and settings. > > What do you think? We could add a quirk for this fimrware version and hardware if we know exactly what the issue is. Have you figured out if it's related to the flush? ie: iommu_iotlb_flush vs iommu_iotlb_flush_all vs iommu_flush_all? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 0/2] More typesafe conversion of common interface
Hi all, The first patch was originally send as part of the series "xen/arm: Add xentrace support" [1]. As all the work but this patch was merged the series is now renamed. There are an additional patch for switching map_vcpu_info to use typesafe gfn. Cheers, [1] https://lists.xen.org/archives/html/xen-devel/2018-12/msg02133.html Julien Grall (2): xen: Switch parameter in get_page_from_gfn to use typesafe gfn xen/domain: Use typesafe gfn in map_vcpu_info xen/arch/arm/guestcopy.c | 2 +- xen/arch/arm/mm.c| 2 +- xen/arch/x86/cpu/vpmu.c | 2 +- xen/arch/x86/domctl.c| 6 +++--- xen/arch/x86/hvm/dm.c| 2 +- xen/arch/x86/hvm/domain.c| 6 -- xen/arch/x86/hvm/hvm.c | 9 + xen/arch/x86/hvm/svm/svm.c | 8 xen/arch/x86/hvm/viridian/viridian.c | 16 xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- xen/arch/x86/hvm/vmx/vvmx.c | 12 ++-- xen/arch/x86/mm.c| 24 ++-- xen/arch/x86/mm/p2m.c| 2 +- xen/arch/x86/mm/shadow/hvm.c | 6 +++--- xen/arch/x86/physdev.c | 3 ++- xen/arch/x86/pv/descriptor-tables.c | 4 ++-- xen/arch/x86/pv/emul-priv-op.c | 6 +++--- xen/arch/x86/pv/mm.c | 2 +- xen/arch/x86/traps.c | 11 ++- xen/common/domain.c | 4 ++-- xen/common/event_fifo.c | 12 ++-- xen/common/memory.c | 4 ++-- xen/include/asm-arm/p2m.h| 6 +++--- xen/include/asm-x86/p2m.h| 16 xen/include/public/vcpu.h| 2 +- xen/include/xen/domain.h | 2 +- 26 files changed, 95 insertions(+), 78 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 13/15] x86/microcode: Synchronize late microcode loading
On Mon, Aug 19, 2019 at 11:27:36AM +0100, Sergey Dyasli wrote:
>> +static int master_thread_fn(const struct microcode_patch *patch)
>> +{
>> +unsigned int cpu = smp_processor_id();
>> +int ret = 0;
>> +
>> +while ( loading_state != LOADING_CALLIN )
>> +cpu_relax();
>> +
>> +cpumask_set_cpu(cpu, _callin_map);
>> +
>> +while ( loading_state != LOADING_ENTER )
>> +cpu_relax();
>
>If I'm reading it right, this will wait forever in case when...
>
>> +
>> +/*
>> + * If an error happened, control thread would set 'loading_state'
>> + * to LOADING_EXIT. Don't perform ucode loading for this case
>> + */
>> +if ( loading_state == LOADING_EXIT )
>> +return ret;
I tried to check whether there was an error here. But as you said, we
cannot reach here if 'control thread' set loading_state from LOADING_CALLIN
to LOADING_EXIT. I will do this check in the while-loop right above.
>> +
>> +ret = microcode_ops->apply_microcode(patch);
>> +if ( !ret )
>> +atomic_inc(_updated);
>> +atomic_inc(_out);
>> +
>> +while ( loading_state != LOADING_EXIT )
>> +cpu_relax();
>> +
>> +return ret;
>> +}
>> +
>> +static int control_thread_fn(const struct microcode_patch *patch)
>> {
>> -unsigned int cpu;
>> +unsigned int cpu = smp_processor_id(), done;
>> +unsigned long tick;
>> +int ret;
>>
>> -/* Store the patch after a successful loading */
>> -if ( !microcode_update_cpu(patch) && patch )
>> +/* Allow threads to call in */
>> +loading_state = LOADING_CALLIN;
>> +smp_mb();
>> +
>> +cpumask_set_cpu(cpu, _callin_map);
>> +
>> +/* Waiting for all threads calling in */
>> +ret = wait_for_condition(wait_cpu_callin,
>> + (void *)(unsigned long)num_online_cpus(),
>> + MICROCODE_CALLIN_TIMEOUT_US);
>> +if ( ret ) {
>> +loading_state = LOADING_EXIT;
>> +return ret;
>> +}
>
>...this condition holds. Have you actually tested this case?
I didn't craft a case to verify the error-handling path. And I believe
that you are right.
Thanks
Chao
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 140332: regressions - FAIL
flight 140332 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/140332/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 140200 version targeted for testing: ovmf 5726bdd9a2dfd188a96129e8c00721f34cf3906e baseline version: ovmf 501de8146d4fda1d423cd935316661746bdb750b Last test of basis 140200 2019-08-16 11:39:55 Z3 days Testing same since 140332 2019-08-19 01:11:08 Z0 days1 attempts People who touched revisions under test: Shenglei Zhang jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 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 Not pushing. commit 5726bdd9a2dfd188a96129e8c00721f34cf3906e Author: Shenglei Zhang Date: Thu Aug 15 15:32:59 2019 +0800 ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left Replace the operation to shift logical left with the function LShiftU64, which has the same functionality. The original code causes ShellPkg build failure with build target"-b NOOPT". Cc: Jaben Carsey Cc: Ray Ni Cc: Zhichao Gao Signed-off-by: Shenglei Zhang Reviewed-by: Zhichao Gao commit 944bd5cf1d69741f3705983f650f6adad696a7d1 Author: Shenglei Zhang Date: Fri Aug 16 14:50:35 2019 +0800 CryptoPkg: Fix coding style Update attribute "Out" to "out". The original "Out" can not pass ECC check. Cc: Jian Wang Cc: Ting Ye Signed-off-by: Shenglei Zhang Reviewed-by: Jian J Wang ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [qemu-s390x] [Qemu-devel] [PATCH v7 33/42] exec: Replace device_endian with MemOp
On 16/08/19 12:12, Thomas Huth wrote:
> This patch is *huge*, more than 800kB. It keeps being stuck in the the
> filter of the qemu-s390x list each time you send it. Please:
>
> 1) Try to break it up in more digestible pieces, e.g. change only one
> subsystem at a time (this is also better reviewable by people who are
> interested in one area)
This is not really possible, since the patch is basically a
search-and-replace. You could perhaps use some magic
("DEVICE_MEMOP_ENDIAN" or something like that) to allow a split, but it
would introduce more complication than anything else.
Agreed on the HTML though. :)
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 140321: regressions - trouble: blocked/broken/fail/pass
flight 140321 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/140321/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel broken test-amd64-i386-qemuu-rhel6hvm-intel 4 host-install(4) broken REGR. vs. 133580 test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail REGR. vs. 133580 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580 test-arm64-arm64-libvirt-xsm 17 guest-start.2fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-check
Re: [Xen-devel] [PATCH v6 04/10] domain: remove the 'is_xenstore' flag
On 8/16/19 1:19 PM, Paul Durrant wrote: This patch introduces a convenience macro, is_xenstore_domain(), which tests the domain 'options' directly and then uses that in place of the 'is_xenstore' flag. Signed-off-by: Paul Durrant Reviewed-by: "Roger Pau Monné" Acked-by: George Dunlap Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v7 25/42] hw/misc: Declare device little or big endian
On 16/08/19 12:04, Philippe Mathieu-Daudé wrote:
>> diff --git a/hw/misc/a9scu.c b/hw/misc/a9scu.c
>> index 4307f00..3de8cd3 100644
>> --- a/hw/misc/a9scu.c
>> +++ b/hw/misc/a9scu.c
>> @@ -94,7 +94,7 @@ static void a9_scu_write(void *opaque, hwaddr offset,
>> static const MemoryRegionOps a9_scu_ops = {
>> .read = a9_scu_read,
>> .write = a9_scu_write,
>> - .endianness = DEVICE_NATIVE_ENDIAN,
>> + .endianness = DEVICE_LITTLE_ENDIAN,
> Uh, I doubt that.
>
... why? :)
Remember that BE32 and BE8 ARM OSes still are "natively" little-endian.
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware
AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
leak, CVE-2006-1056, and worked around by several OSes, including Xen. AMD
Fam17h CPUs no longer have this leak, and advertise so in a CPUID bit.
Introduce the RSTR_FP_ERR_PTRS feature, as specified by AMD, and expose to all
guests by default. While adjusting libxl's cpuid table, add CLZERO which
looks to have been omitted previously.
Also introduce an X86_BUG bit to trigger the (F)XRSTOR workaround, and set it
on AMD hardware where RSTR_FP_ERR_PTRS is not advertised. Optimise the
workaround path by dropping the data-dependent unpredictable conditions which
will evalute to true for all 64bit OSes and most 32bit ones.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* Use the AMD naming, not that I am convinced this is a sensible name to use.
* Adjust the i387 codepaths as well as the xstate ones.
* Add xen-cpuid/libxl data for the CPUID bit.
---
tools/libxl/libxl_cpuid.c | 3 +++
tools/misc/xen-cpuid.c | 1 +
xen/arch/x86/cpu/amd.c | 7 +++
xen/arch/x86/i387.c | 14 +-
xen/arch/x86/xstate.c | 6 ++
xen/include/asm-x86/cpufeature.h| 3 +++
xen/include/asm-x86/cpufeatures.h | 2 ++
xen/include/public/arch-x86/cpufeatureset.h | 1 +
8 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index a8d07fac50..acc92fd46c 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -256,7 +256,10 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
*cpuid, const char* str)
{"invtsc", 0x8007, NA, CPUID_REG_EDX, 8, 1},
+{"clzero", 0x8008, NA, CPUID_REG_EBX, 0, 1},
+{"rstr-fp-err-ptrs", 0x8008, NA, CPUID_REG_EBX, 2, 1},
{"ibpb", 0x8008, NA, CPUID_REG_EBX, 12, 1},
+
{"nc", 0x8008, NA, CPUID_REG_ECX, 0, 8},
{"apicidsize", 0x8008, NA, CPUID_REG_ECX, 12, 4},
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index b0db0525a9..04cdd9aa95 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -145,6 +145,7 @@ static const char *const str_e7d[32] =
static const char *const str_e8b[32] =
{
[ 0] = "clzero",
+[ 2] = "rstr-fp-err-ptrs",
[12] = "ibpb",
};
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index a2f83c79a5..463f9776c7 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -580,6 +580,13 @@ static void init_amd(struct cpuinfo_x86 *c)
}
/*
+* Older AMD CPUs don't save/load FOP/FIP/FDP unless an FPU exception
+* is pending. Xen works around this at (F)XRSTOR time.
+*/
+ if ( !cpu_has(c, X86_FEATURE_RSTR_FP_ERR_PTRS) )
+ setup_force_cpu_cap(X86_BUG_FPU_PTR_LEAK);
+
+ /*
* Attempt to set lfence to be Dispatch Serialising. This MSR almost
* certainly isn't virtualised (and Xen at least will leak the real
* value in but silently discard writes), as well as being per-core
diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 88178485cb..82dbc461c3 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -43,20 +43,17 @@ static inline void fpu_fxrstor(struct vcpu *v)
const typeof(v->arch.xsave_area->fpu_sse) *fpu_ctxt = v->arch.fpu_ctxt;
/*
- * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
+ * Some CPUs don't save/restore FDP/FIP/FOP unless an exception
* is pending. Clear the x87 state here by setting it to fixed
* values. The hypervisor data segment can be sometimes 0 and
* sometimes new user value. Both should be ok. Use the FPU saved
* data block as a safe address because it should be in L1.
*/
-if ( !(fpu_ctxt->fsw & ~fpu_ctxt->fcw & 0x003f) &&
- boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
-{
+if ( cpu_bug_fpu_ptr_leak )
asm volatile ( "fnclex\n\t"
"ffree %%st(7)\n\t" /* clear stack tag */
"fildl %0" /* load to clear state */
: : "m" (*fpu_ctxt) );
-}
/*
* FXRSTOR can fault if passed a corrupted data block. We handle this
@@ -169,11 +166,10 @@ static inline void fpu_fxsave(struct vcpu *v)
: "=m" (*fpu_ctxt) : "R" (fpu_ctxt) );
/*
- * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
- * is pending.
+ * Some CPUs don't save/restore FDP/FIP/FOP unless an exception is
+ * pending. The restore code fills in suitable defaults.
*/
-if ( !(fpu_ctxt->fsw & 0x0080) &&
- boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+
[Xen-devel] [PATCH 1/2] x86/feature: Generalise synth and introduce a bug word
Future changes are going to want to use cpu_bug_* in a mannor similar to Linux. Introduce one bug word, and generalise the calculation of NCAPINTS. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné v2: * Rebase --- xen/include/asm-x86/cpufeatures.h | 67 ++- 1 file changed, 38 insertions(+), 29 deletions(-) diff --git a/xen/include/asm-x86/cpufeatures.h b/xen/include/asm-x86/cpufeatures.h index 57f3e61fd5..ab3650f73b 100644 --- a/xen/include/asm-x86/cpufeatures.h +++ b/xen/include/asm-x86/cpufeatures.h @@ -4,35 +4,44 @@ #include +/* Number of capability words covered by the featureset words. */ #define FSCAPINTS FEATURESET_NR_ENTRIES -#define NCAPINTS (FSCAPINTS + 1) /* N 32-bit words worth of info */ +/* Synthetic words follow the featureset words. */ +#define X86_NR_SYNTH 1 +#define X86_SYNTH(x) (FSCAPINTS * 32 + (x)) -/* Other features, Xen-defined mapping. */ -/* This range is used for feature bits which conflict or are synthesized */ -XEN_CPUFEATURE(CONSTANT_TSC,(FSCAPINTS+0)*32+ 0) /* TSC ticks at a constant rate */ -XEN_CPUFEATURE(NONSTOP_TSC, (FSCAPINTS+0)*32+ 1) /* TSC does not stop in C states */ -XEN_CPUFEATURE(ARAT,(FSCAPINTS+0)*32+ 2) /* Always running APIC timer */ -XEN_CPUFEATURE(ARCH_PERFMON,(FSCAPINTS+0)*32+ 3) /* Intel Architectural PerfMon */ -XEN_CPUFEATURE(TSC_RELIABLE,(FSCAPINTS+0)*32+ 4) /* TSC is known to be reliable */ -XEN_CPUFEATURE(XTOPOLOGY, (FSCAPINTS+0)*32+ 5) /* cpu topology enum extensions */ -XEN_CPUFEATURE(CPUID_FAULTING, (FSCAPINTS+0)*32+ 6) /* cpuid faulting */ -XEN_CPUFEATURE(CLFLUSH_MONITOR, (FSCAPINTS+0)*32+ 7) /* clflush reqd with monitor */ -XEN_CPUFEATURE(APERFMPERF, (FSCAPINTS+0)*32+ 8) /* APERFMPERF */ -XEN_CPUFEATURE(MFENCE_RDTSC,(FSCAPINTS+0)*32+ 9) /* MFENCE synchronizes RDTSC */ -XEN_CPUFEATURE(XEN_SMEP,(FSCAPINTS+0)*32+10) /* SMEP gets used by Xen itself */ -XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /* SMAP gets used by Xen itself */ -XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as Dispatch Serialising */ -XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use IND_THUNK_LFENCE */ -XEN_CPUFEATURE(IND_THUNK_JMP, (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP */ -XEN_CPUFEATURE(SC_L1TF_VULN,(FSCAPINTS+0)*32+15) /* L1TF protection required */ -XEN_CPUFEATURE(SC_MSR_PV, (FSCAPINTS+0)*32+16) /* MSR_SPEC_CTRL used by Xen for PV */ -XEN_CPUFEATURE(SC_MSR_HVM, (FSCAPINTS+0)*32+17) /* MSR_SPEC_CTRL used by Xen for HVM */ -XEN_CPUFEATURE(SC_RSB_PV, (FSCAPINTS+0)*32+18) /* RSB overwrite needed for PV */ -XEN_CPUFEATURE(SC_RSB_HVM, (FSCAPINTS+0)*32+19) /* RSB overwrite needed for HVM */ -XEN_CPUFEATURE(XEN_SELFSNOOP, (FSCAPINTS+0)*32+20) /* SELFSNOOP gets used by Xen itself */ -XEN_CPUFEATURE(SC_MSR_IDLE, (FSCAPINTS+0)*32+21) /* (SC_MSR_PV || SC_MSR_HVM) && default_xen_spec_ctrl */ -XEN_CPUFEATURE(XEN_LBR, (FSCAPINTS+0)*32+22) /* Xen uses MSR_DEBUGCTL.LBR */ -XEN_CPUFEATURE(SC_VERW_PV, (FSCAPINTS+0)*32+23) /* VERW used by Xen for PV */ -XEN_CPUFEATURE(SC_VERW_HVM, (FSCAPINTS+0)*32+24) /* VERW used by Xen for HVM */ -XEN_CPUFEATURE(SC_VERW_IDLE,(FSCAPINTS+0)*32+25) /* VERW used by Xen for idle */ +/* Synthetic features */ +XEN_CPUFEATURE(CONSTANT_TSC, X86_SYNTH( 0)) /* TSC ticks at a constant rate */ +XEN_CPUFEATURE(NONSTOP_TSC, X86_SYNTH( 1)) /* TSC does not stop in C states */ +XEN_CPUFEATURE(ARAT, X86_SYNTH( 2)) /* Always running APIC timer */ +XEN_CPUFEATURE(ARCH_PERFMON, X86_SYNTH( 3)) /* Intel Architectural PerfMon */ +XEN_CPUFEATURE(TSC_RELIABLE, X86_SYNTH( 4)) /* TSC is known to be reliable */ +XEN_CPUFEATURE(XTOPOLOGY, X86_SYNTH( 5)) /* cpu topology enum extensions */ +XEN_CPUFEATURE(CPUID_FAULTING,X86_SYNTH( 6)) /* cpuid faulting */ +XEN_CPUFEATURE(CLFLUSH_MONITOR, X86_SYNTH( 7)) /* clflush reqd with monitor */ +XEN_CPUFEATURE(APERFMPERF,X86_SYNTH( 8)) /* APERFMPERF */ +XEN_CPUFEATURE(MFENCE_RDTSC, X86_SYNTH( 9)) /* MFENCE synchronizes RDTSC */ +XEN_CPUFEATURE(XEN_SMEP, X86_SYNTH(10)) /* SMEP gets used by Xen itself */ +XEN_CPUFEATURE(XEN_SMAP, X86_SYNTH(11)) /* SMAP gets used by Xen itself */ +XEN_CPUFEATURE(LFENCE_DISPATCH, X86_SYNTH(12)) /* lfence set as Dispatch Serialising */ +XEN_CPUFEATURE(IND_THUNK_LFENCE, X86_SYNTH(13)) /* Use IND_THUNK_LFENCE */ +XEN_CPUFEATURE(IND_THUNK_JMP, X86_SYNTH(14)) /* Use IND_THUNK_JMP */ +XEN_CPUFEATURE(SC_L1TF_VULN, X86_SYNTH(15)) /* L1TF protection required */ +XEN_CPUFEATURE(SC_MSR_PV, X86_SYNTH(16)) /* MSR_SPEC_CTRL used by Xen for PV */ +XEN_CPUFEATURE(SC_MSR_HVM,X86_SYNTH(17)) /* MSR_SPEC_CTRL used by Xen for HVM */ +XEN_CPUFEATURE(SC_RSB_PV, X86_SYNTH(18)) /* RSB overwrite needed for PV */ +XEN_CPUFEATURE(SC_RSB_HVM,X86_SYNTH(19)) /*
Re: [Xen-devel] [PATCH] xen/console: Fix build when CONFIG_DEBUG_TRACE=y
Hi Andrew, On 8/19/19 7:04 PM, Andrew Cooper wrote: On 19/08/2019 19:01, Julien Grall wrote: Commit b5e6e1ee8da "xen/console: Don't treat NUL character as the end of the buffer" extended sercon_puts to take the number of character to print in argument. Sadly, a couple of couple of the callers in debugtrace_dump_worker() were not converted. This result to a build failure when enabling CONFIG_DEBUG_TRACE. Spotted by Travis using randconfig Signed-off-by: Julien Grall --- xen/drivers/char/console.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2c14c2ca73..924d4971ca 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -1185,11 +1185,12 @@ static void debugtrace_dump_worker(void) /* Print oldest portion of the ring. */ ASSERT(debugtrace_buf[debugtrace_bytes - 1] == 0); -sercon_puts(_buf[debugtrace_prd]); +sercon_puts(_buf[debugtrace_prd], +strlen(_buf[debugtrace_prd])); Isn't this just debugtrace_bytes - debugtrace_prd - 1 ? I tried and it resulted to print a lot of @^ on the console. This is because the ring may not be full. So the portion between debugtrace_prd and debugtrace_bytes will be full of zero. Looking at the code again, I think this portion and either be full of zero character or full of non-zero character. In other word, a mix would not be possible. So how about: if ( debugtrace_buf[debugtrace_prd] != '\0' ) sercon_puts(_buf[debugtrace_prd], debugtrace_bytes - debugtrace_prd - 1); Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 140333: regressions - FAIL
flight 140333 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140333/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 139910 build-amd64-xsm 6 xen-buildfail REGR. vs. 139910 test-amd64-i386-xl-xsm7 xen-boot fail in 140223 REGR. vs. 139910 test-amd64-i386-xl7 xen-boot fail in 140269 REGR. vs. 139910 test-amd64-i386-xl-raw7 xen-boot fail in 140269 REGR. vs. 139910 Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-xsm 7 xen-boot fail in 140193 pass in 140223 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 140193 pass in 140223 test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail in 140193 pass in 140269 test-amd64-i386-examine 8 reboot fail in 140223 pass in 140269 test-amd64-i386-libvirt 7 xen-boot fail in 140223 pass in 140269 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail in 140269 pass in 140193 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail in 140269 pass in 140193 test-amd64-i386-libvirt-pair 10 xen-boot/src_host fail in 140269 pass in 140193 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host fail in 140269 pass in 140193 test-amd64-i386-xl-pvshim 7 xen-boot fail in 140269 pass in 140223 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail in 140269 pass in 140223 test-amd64-i386-freebsd10-amd64 7 xen-boot fail in 140269 pass in 140223 test-amd64-i386-freebsd10-i386 7 xen-boot fail in 140269 pass in 140223 test-armhf-armhf-xl-vhd 7 xen-boot fail pass in 140269 test-armhf-armhf-libvirt 19 leak-check/check fail pass in 140269 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl 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-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-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-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a
[Xen-devel] [freebsd-master test] 140355: all pass - PUSHED
flight 140355 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/140355/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 41a4c010326cd697d92141076bab53c424edb56f baseline version: freebsd f39a1bd1426e0e5a462522b7a1de56e8233591e7 Last test of basis 140195 2019-08-16 09:21:38 Z3 days Testing same since 140355 2019-08-19 09:20:16 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> asomers avg bdrewery brooks cem delphij emaste Eric Joyner erj eugen hselasky imp Jacob Keller jeff kevans kib manu mav mjg mmel ray rmacklem thj vangyzen wulf jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd 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/freebsd.git f39a1bd1426..41a4c010326 41a4c010326cd697d92141076bab53c424edb56f -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [qemu-s390x] [PATCH v7 33/42] exec: Replace device_endian with MemOp
On 8/19/19 11:29 AM, Paolo Bonzini wrote:
> On 19/08/19 20:28, Paolo Bonzini wrote:
>> On 16/08/19 12:12, Thomas Huth wrote:
>>> This patch is *huge*, more than 800kB. It keeps being stuck in the the
>>> filter of the qemu-s390x list each time you send it. Please:
>>>
>>> 1) Try to break it up in more digestible pieces, e.g. change only one
>>> subsystem at a time (this is also better reviewable by people who are
>>> interested in one area)
>>
>> This is not really possible, since the patch is basically a
>> search-and-replace. You could perhaps use some magic
>> ("DEVICE_MEMOP_ENDIAN" or something like that) to allow a split, but it
>> would introduce more complication than anything else.
>
> I'm stupid, at this point of the series it _would_ be possible to split
> the patch by subsystem. Still not sure it would be actually an advantage.
It might be easier to review if we split by symbol, one rename per patch over
the entire code base.
r~
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware
This is a subset of a previously posted series, because support for this workaround has been outstanding for far too long. Andrew Cooper (2): x86/feature: Generalise synth and introduce a bug word x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware tools/libxl/libxl_cpuid.c | 3 ++ tools/misc/xen-cpuid.c | 1 + xen/arch/x86/cpu/amd.c | 7 +++ xen/arch/x86/i387.c | 14 +++--- xen/arch/x86/xstate.c | 6 +-- xen/include/asm-x86/cpufeature.h| 3 ++ xen/include/asm-x86/cpufeatures.h | 69 + xen/include/public/arch-x86/cpufeatureset.h | 1 + 8 files changed, 62 insertions(+), 42 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [qemu-s390x] [Qemu-devel] [PATCH v7 33/42] exec: Replace device_endian with MemOp
On 19/08/19 20:28, Paolo Bonzini wrote:
> On 16/08/19 12:12, Thomas Huth wrote:
>> This patch is *huge*, more than 800kB. It keeps being stuck in the the
>> filter of the qemu-s390x list each time you send it. Please:
>>
>> 1) Try to break it up in more digestible pieces, e.g. change only one
>> subsystem at a time (this is also better reviewable by people who are
>> interested in one area)
>
> This is not really possible, since the patch is basically a
> search-and-replace. You could perhaps use some magic
> ("DEVICE_MEMOP_ENDIAN" or something like that) to allow a split, but it
> would introduce more complication than anything else.
I'm stupid, at this point of the series it _would_ be possible to split
the patch by subsystem. Still not sure it would be actually an advantage.
Paolo
> Agreed on the HTML though. :)
>
> Paolo
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 7/8] xen/arm: don't iomem_permit_access for reserved-memory regions
Hi Stefano, On 8/19/19 6:43 PM, Stefano Stabellini wrote: Don't allow reserved-memory regions to be remapped into any unprivileged guests, until reserved-memory regions are properly supported in Xen. For now, do not call iomem_permit_access on them, because giving iomem_permit_access to dom0 means that the toolstack will be able to assign the region to a domU. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch: independ. modules 3/3] python: Add XC binding for Xen build ID
On Thu, Aug 15, 2019 at 09:44:00AM +, Pawel Wieczorkiewicz wrote:
> Extend the list of xc() object methods with additional one to display
> Xen's buildid. The implementation follows the libxl implementation
> (e.g. max buildid size assumption being XC_PAGE_SIZE).
>
> Signed-off-by: Pawel Wieczorkiewicz
> Reviewed-by: Martin Mazein
> Reviewed-by: Andra-Irina Paraschiv
> Reviewed-by: Norbert Manthey
> ---
> v2:
> * No code change
> * Adding maintainers
> ---
> tools/python/xen/lowlevel/xc/xc.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/tools/python/xen/lowlevel/xc/xc.c
> b/tools/python/xen/lowlevel/xc/xc.c
> index 522cbe3b9c..5459d6834d 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1211,6 +1211,26 @@ out:
> return ret_obj ? ret_obj : pyxc_error_to_exception(self->xc_handle);
> }
>
> +static PyObject *pyxc_xenbuildid(XcObject *self)
> +{
> +xen_build_id_t *buildid;
> +int i, r;
> +char *str;
> +
> +buildid = alloca(sizeof(buildid->len) + XC_PAGE_SIZE);
> +buildid->len = XC_PAGE_SIZE - sizeof(*buildid);
Those doesn't match. You allocated XC_PAGE_SIZE in addition to
sizeof(buildid->len). I'd change to alloca(XC_PAGE_SIZE) - it is
unlikely that izeof(buildid->len) would be larger than XC_PAGE_SIZE and
we do assume it in other places anyway.
> +
> +r = xc_version(self->xc_handle, XENVER_build_id, buildid);
> +if ( r <= 0 )
> +return pyxc_error_to_exception(self->xc_handle);
> +
> +str = alloca((r * 2) + 1);
> +for ( i = 0; i < r; i++ )
> +snprintf([i * 2], 3, "%02hhx", buildid->buf[i]);
> +
> +return Py_BuildValue("s", str);
> +}
> +
> static PyObject *pyxc_xeninfo(XcObject *self)
> {
> xen_extraversion_t xen_extra;
> @@ -2294,6 +2314,13 @@ static PyMethodDef pyxc_methods[] = {
>"Returns [dict]: information about Xen"
>"[None]: on failure.\n" },
>
> +{ "buildid",
> + (PyCFunction)pyxc_xenbuildid,
> + METH_NOARGS, "\n"
> + "Get Xen buildid\n"
> + "Returns [str]: Xen buildid"
> + "[None]: on failure.\n" },
> +
> { "shadow_control",
>(PyCFunction)pyxc_shadow_control,
>METH_VARARGS | METH_KEYWORDS, "\n"
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored
C version of xenstored had this ability since 61aaed0d5 ("Allow
XS_INTRODUCE to be used for rebinding the xenstore evtchn.") from 2007.
Copy it as is to Ocaml version.
Signed-off-by: Igor Druzhinin
---
tools/ocaml/xenstored/domain.ml | 6 +-
tools/ocaml/xenstored/process.ml | 8 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/xenstored/domain.ml b/tools/ocaml/xenstored/domain.ml
index b0a01b0..aeb185f 100644
--- a/tools/ocaml/xenstored/domain.ml
+++ b/tools/ocaml/xenstored/domain.ml
@@ -23,9 +23,9 @@ type t =
{
id: Xenctrl.domid;
mfn: nativeint;
- remote_port: int;
interface: Xenmmap.mmap_interface;
eventchn: Event.t;
+ mutable remote_port: int;
mutable port: Xeneventchn.t option;
mutable bad_client: bool;
mutable io_credit: int; (* the rounds of ring process left to do,
default is 0,
@@ -71,6 +71,10 @@ let notify dom = match dom.port with
Event.notify dom.eventchn port
let bind_interdomain dom =
+ begin match dom.port with
+ | None -> ()
+ | Some port -> Event.unbind dom.eventchn port
+ end;
dom.port <- Some (Event.bind_interdomain dom.eventchn dom.id
dom.remote_port);
debug "bound domain %d remote port %d to local port %s" dom.id
dom.remote_port (string_of_port dom.port)
diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml
index 8a7e538..ff5c948 100644
--- a/tools/ocaml/xenstored/process.ml
+++ b/tools/ocaml/xenstored/process.ml
@@ -408,7 +408,13 @@ let do_introduce con _t domains cons data =
in
let dom =
if Domains.exist domains domid then
- Domains.find domains domid
+ let edom = Domains.find domains domid in
+ if (Domain.get_mfn edom) = mfn &&
(Connections.find_domain cons domid) != con then begin
+ (* Use XS_INTRODUCE for recreating the xenbus
event-channel. *)
+ edom.remote_port <- port;
+ Domain.bind_interdomain edom;
+ end;
+ edom
else try
let ndom = Domains.create domains domid mfn port in
Connections.add_domain cons ndom;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 140371: tolerable all pass - PUSHED
flight 140371 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/140371/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 427b9c58f50bfbf6be99c0470079a165add18d22 baseline version: xen f7efd9c792738f579e3c7062d8d3e90b21d8a771 Last test of basis 140214 2019-08-16 22:00:55 Z2 days Testing same since 140371 2019-08-19 15:07:44 Z0 days1 attempts People who touched revisions under test: George Dunlap Jan Beulich Julien Grall Michał Kowalczyk Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f7efd9c792..427b9c58f5 427b9c58f50bfbf6be99c0470079a165add18d22 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 1/8] xen/arm: pass node to device_tree_for_each_node
On Mon, 19 Aug 2019, Julien Grall wrote:
> On 8/17/19 1:29 AM, Stefano Stabellini wrote:
> > On Fri, 16 Aug 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 16/08/2019 00:36, Stefano Stabellini wrote:
> > > > Add a new parameter to device_tree_for_each_node: node, the node to
> > > > start the search from. Passing 0 triggers the old behavior.
> > >
> > > Here you say 0 triggers the old behavior but...
> > >
> > > >
> > > > Set min_depth to depth of the current node + 1 to avoid scanning
> > > > siblings of the initial node passed as an argument.
> > > >
> > > > Don't call func() on the parent node passed as an argument. Clarify the
> > > > change in the comment on top of the function.
> > >
> > > ... here you mention that the first node will be skipped. So the behavior
> > > is
> > > now different and should be explained in the commit message why this is
> > > fine
> > > to skip the root node.
> >
> > Yes I'll update
> >
> >
> > > >
> > > > Signed-off-by: Stefano Stabellini
> > > > ---
> > > > Changes in v6:
> > > > - fix code style
> > > > - don't call func() on the first node
> > > >
> > > > Changes in v5:
> > > > - go back to v3
> > > > - code style improvement in acpi/boot.c
> > > > - improve comments and commit message
> > > > - increase min_depth to avoid parsing siblings
> > > > - replace for with do/while loop and increase min_depth to avoid
> > > > scanning siblings of the initial node
> > > > - pass only node, calculate depth
> > > >
> > > > Changes in v3:
> > > > - improve commit message
> > > > - improve in-code comments
> > > > - improve code style
> > > >
> > > > Changes in v2:
> > > > - new
> > > > ---
> > > >xen/arch/arm/acpi/boot.c | 8 +---
> > > >xen/arch/arm/bootfdt.c| 34 --
> > > >xen/include/xen/device_tree.h | 6 +++---
> > > >3 files changed, 28 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> > > > index 9b29769a10..bf9c78b02c 100644
> > > > --- a/xen/arch/arm/acpi/boot.c
> > > > +++ b/xen/arch/arm/acpi/boot.c
> > > > @@ -246,9 +246,11 @@ int __init acpi_boot_table_init(void)
> > > > * - the device tree is not empty (it has more than just a
> > > > /chosen
> > > > node)
> > > > * and ACPI has not been force enabled (acpi=force)
> > > > */
> > > > -if ( param_acpi_off || ( !param_acpi_force
> > > > - &&
> > > > device_tree_for_each_node(device_tree_flattened,
> > > > -
> > > > dt_scan_depth1_nodes,
> > > > NULL)))
> > > > +if ( param_acpi_off)
> > > > +goto disable;
> > > > +if ( !param_acpi_force &&
> > > > + device_tree_for_each_node(device_tree_flattened, 0,
> > > > + dt_scan_depth1_nodes, NULL) )
> > > >goto disable;
> > > > /*
> > > > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > > > index 891b4b66ff..f1614ef7fc 100644
> > > > --- a/xen/arch/arm/bootfdt.c
> > > > +++ b/xen/arch/arm/bootfdt.c
> > > > @@ -75,9 +75,10 @@ static u32 __init device_tree_get_u32(const void
> > > > *fdt,
> > > > int node,
> > > >}
> > > > /**
> > > > - * device_tree_for_each_node - iterate over all device tree nodes
> > > > + * device_tree_for_each_node - iterate over all device tree sub-nodes
> > > > * @fdt: flat device tree.
> > > > - * @func: function to call for each node.
> > > > + * @node: parent node to start the search from
> > > > + * @func: function to call for each sub-node.
> > > > * @data: data to pass to @func.
> > > > *
> > > > * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> > > > @@ -85,20 +86,18 @@ static u32 __init device_tree_get_u32(const void
> > > > *fdt,
> > > > int node,
> > > > * Returns 0 if all nodes were iterated over successfully. If @func
> > > > * returns a value different from 0, that value is returned
> > > > immediately.
> > > > */
> > > > -int __init device_tree_for_each_node(const void *fdt,
> > > > +int __init device_tree_for_each_node(const void *fdt, int node,
> > > > device_tree_node_func func,
> > > > void *data)
> > > >{
> > > > -int node;
> > > > -int depth;
> > > > +int depth = fdt_node_depth(fdt, node);
> > >
> > > Sorry I didn't spot this in the previous version. As I pointed out on v4
> > > (and
> > > you actually agreed!), you don't need the absolute depth...
> > >
> > > You only need the relative depth. So this is a waste of processing as you
> > > have
> > > to go through the FDT to calculate the depth.
> > >
> > > This is not entirely critical so I would be willing to consider a patch on
> > > top
> > > of this series.
> >
> > I tried when I sent this version of the series, but I couldn't quite do
> > it that way. I wanted to get rid of the depth parameter to
> > device_tree_for_each_node, and
Re: [Xen-devel] [PATCH v1] x86: Restore IA32_MISC_ENABLE on wakeup
On 8/19/19 7:28 PM, Andrew Cooper wrote: > On 19/08/2019 14:56, Michał Kowalczyk wrote: >> On 8/19/19 3:52 PM, Andrew Cooper wrote: >>> On 19/08/2019 14:50, Michał Kowalczyk wrote: On 8/19/19 11:04 AM, Andrew Cooper wrote: > On 19/08/2019 03:23, Michał Kowalczyk wrote: >> diff --git a/xen/arch/x86/boot/trampoline.S >> b/xen/arch/x86/boot/trampoline.S >> index 7c6a2328d2..fcaa3eeaf1 100644 >> --- a/xen/arch/x86/boot/trampoline.S >> +++ b/xen/arch/x86/boot/trampoline.S >> @@ -85,7 +85,7 @@ trampoline_gdt: >> .long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . >> .popsection >> >> -GLOBAL(trampoline_misc_enable_off) >> +GLOBAL(misc_enable_off) > The overall change is fine, but why have you renamed this variable? The old name had "trampoline_" prefix because the only place where it was used was trampoline_protmode_entry in arch/x86/boot/trampoline.S. Now it's also used in the wakeup code, so I removed the prefix which could be (IMO) misleading. > Without the rename, the patch would be just the single hunk in wakeup.S > and therefore easier to backport. True. Anyway, the decision is on your side, I can leave the old name if you prefer. >>> The trampoline_ prefix indicates where the data lives, which is in the >>> 16 bit trampoline which contains both the AP boot path, and wakeup path. >> Ah, if this is the convention you use then we should leave the old name. >>> If you're happy with this, I can adjust on commit to avoid you sending a >>> second time. >> Would be great, thanks! > Done. > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c3cfa5b3084d71bccd8360d044bea813688b587c Looks good. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/console: Fix build when CONFIG_DEBUG_TRACE=y
Commit b5e6e1ee8da "xen/console: Don't treat NUL character as the end of the buffer" extended sercon_puts to take the number of character to print in argument. Sadly, a couple of couple of the callers in debugtrace_dump_worker() were not converted. This result to a build failure when enabling CONFIG_DEBUG_TRACE. Spotted by Travis using randconfig Signed-off-by: Julien Grall --- xen/drivers/char/console.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2c14c2ca73..924d4971ca 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -1185,11 +1185,12 @@ static void debugtrace_dump_worker(void) /* Print oldest portion of the ring. */ ASSERT(debugtrace_buf[debugtrace_bytes - 1] == 0); -sercon_puts(_buf[debugtrace_prd]); +sercon_puts(_buf[debugtrace_prd], +strlen(_buf[debugtrace_prd])); /* Print youngest portion of the ring. */ debugtrace_buf[debugtrace_prd] = '\0'; -sercon_puts(_buf[0]); +sercon_puts(_buf[0], debugtrace_prd); memset(debugtrace_buf, '\0', debugtrace_bytes); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-hooks-1 PATCH 2/3] livepatch: Export payload structure via livepatch_payload.h
On 8/14/19 8:57 AM, Pawel Wieczorkiewicz wrote: The payload structure will be used by the new hooks implementation and therefore its definition has to be exported via the livepatch_payload header. The new hooks will make use of the payload structure fields and the hooks' pointers will also be defined in the payload structure, so the structure along with all field definitions needs to be available to the code being patched in. Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Andra-Irina Paraschiv Reviewed-by: Eslam Elnikety Reviewed-by: Leonard Foerster Reviewed-by: Martin Pohlack Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-hooks-1 PATCH 1/3] create-diff-object: Handle extra pre-|post- hooks
On 8/14/19 8:55 AM, Pawel Wieczorkiewicz wrote: Include new sections containing optional pre-, post- action hooks. The following new section names are supported: - .livepatch.hooks.preapply - .livepatch.hooks.postapply - .livepatch.hooks.prerevert - .livepatch.hooks.postrevert Signed-off-by: Pawel Wieczorkiewicz --- Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH livepatch-hooks-4 1/1] livepatch: always print XENLOG_ERR information
On 8/14/19 1:23 PM, Pawel Wieczorkiewicz wrote: A lot of legitimate error messages were hidden behind debug printk only. Most of these messages can be triggered by loading a malformed hotpatch payload and are priceless for understanding issues with such payloads. Thus, always display all relevant XENLOG_ERR messages. Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Amit Shah Reviewed-by: Martin Mazein Reviewed-by: Bjoern Doebel --- Reviewed-by: Ross Lagerwall This changes is much-needed. Thanks, Ross ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 5/8] xen/arm: early_print_info print reserved_mem
Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.
Since we are at it, also switch the existing RESVD print to use unsigned
int.
Signed-off-by: Stefano Stabellini
Reviewed-by: Volodymyr Babchuk
Acked-by: Julien Grall
---
Changes in v6:
- add acked-by and reviewed-by
- fix indentation
Changes in v5:
- switch to unsigned
Changes in v4:
- new patch
---
xen/arch/arm/bootfdt.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index eb3dc13b06..defd793f8f 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -352,9 +352,10 @@ static int __init early_scan_node(const void *fdt,
static void __init early_print_info(void)
{
struct meminfo *mi =
+struct meminfo *mem_resv = _mem;
struct bootmodules *mods =
struct bootcmdlines *cmds =
-int i, nr_rsvd;
+unsigned int i, j, nr_rsvd;
for ( i = 0; i < mi->nr_banks; i++ )
printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
@@ -376,7 +377,13 @@ static void __init early_print_info(void)
continue;
/* fdt_get_mem_rsv returns length */
e += s;
-printk(" RESVD[%d]: %"PRIpaddr" - %"PRIpaddr"\n", i, s, e);
+printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i, s, e);
+}
+for ( j = 0; j < mem_resv->nr_banks; j++, i++ )
+{
+printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i,
+ mem_resv->bank[j].start,
+ mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
}
printk("\n");
for ( i = 0 ; i < cmds->nr_mods; i++ )
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 3/8] xen/arm: keep track of reserved-memory regions
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
bootinfo.reserved_mem array.
Refuse to continue once we reach the max number of reserved memory
regions to avoid accidentally mapping any portions of them into a VM.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v6:
- use dt_node_cmp
- add acked-by
Changes in v5:
- remove unneeded cast
- remove unneeded strlen check
- don't pass address_cells, size_cells, depth to device_tree_for_each_node
Changes in v4:
- depth + 1 in process_reserved_memory_node
- pass address_cells and size_cells to device_tree_for_each_node
- pass struct meminfo * instead of a boolean to process_memory_node
- improve in-code comment
- use a separate process_reserved_memory_node (separate from
process_memory_node) function wrapper to have different error handling
Changes in v3:
- match only /reserved-memory
- put the warning back in place for reg not present on a normal memory
region
- refuse to continue once we reach the max number of reserved memory
regions
Changes in v2:
- call process_memory_node from process_reserved_memory_node to avoid
duplication
---
xen/arch/arm/bootfdt.c | 39 -
xen/include/asm-arm/setup.h | 1 +
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 320c9a16f4..0a01963b0e 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -145,6 +145,7 @@ static int __init process_memory_node(const void *fdt, int
node,
const __be32 *cell;
paddr_t start, size;
u32 reg_cells = address_cells + size_cells;
+struct meminfo *mem = data;
if ( address_cells < 1 || size_cells < 1 )
{
@@ -160,14 +161,14 @@ static int __init process_memory_node(const void *fdt,
int node,
cell = (const __be32 *)prop->data;
banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
-for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
+for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
{
device_tree_get_reg(, address_cells, size_cells, , );
if ( !size )
return -EINVAL;
-bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
-bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
-bootinfo.mem.nr_banks++;
+mem->bank[mem->nr_banks].start = start;
+mem->bank[mem->nr_banks].size = size;
+mem->nr_banks++;
}
if ( i < banks )
@@ -175,6 +176,31 @@ static int __init process_memory_node(const void *fdt, int
node,
return 0;
}
+static int __init process_reserved_memory_node(const void *fdt, int node,
+ const char *name, int depth,
+ u32 address_cells,
+ u32 size_cells,
+ void *data)
+{
+int rc = process_memory_node(fdt, node, name, depth, address_cells,
+ size_cells, data);
+
+if ( rc == -ENOSPC )
+panic("Max number of supported reserved-memory regions reached.");
+else if ( rc != -ENOENT )
+return rc;
+return 0;
+}
+
+static int __init process_reserved_memory(const void *fdt, int node,
+ const char *name, int depth,
+ u32 address_cells, u32 size_cells)
+{
+return device_tree_for_each_node(fdt, node,
+ process_reserved_memory_node,
+ _mem);
+}
+
static void __init process_multiboot_node(const void *fdt, int node,
const char *name,
u32 address_cells, u32 size_cells)
@@ -308,7 +334,10 @@ static int __init early_scan_node(const void *fdt,
if ( device_tree_node_matches(fdt, node, "memory") )
rc = process_memory_node(fdt, node, name, depth,
- address_cells, size_cells, NULL);
+ address_cells, size_cells, );
+else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") )
+rc = process_reserved_memory(fdt, node, name, depth,
+ address_cells, size_cells);
else if ( depth <= 3 && (device_tree_node_compatible(fdt, node,
"xen,multiboot-module" ) ||
device_tree_node_compatible(fdt, node, "multiboot,module" )))
process_multiboot_node(fdt, node, name, address_cells, size_cells);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 8bf3d5910a..efcba545c2 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -66,6
[Xen-devel] [PATCH v7 8/8] xen/arm: add reserved-memory regions to the dom0 memory node
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by the spec. This commit fixes it.
Change make_memory_node to take a struct meminfo * instead of a
kernel_info. Call it twice for dom0, once to create the first regular
memory node, and the second time to create a second memory node with the
ranges covering reserved-memory regions.
Also, make a small code style fix in make_memory_node.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- add acked-by
Changes in v4:
- pass struct meminfo * to make_memory_node
- call make_memory_node twice for dom0, once for normal memory, once for
reserved-memory regions
---
xen/arch/arm/domain_build.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b4260f1fc2..306180d8cb 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -639,11 +639,11 @@ static int __init fdt_property_interrupts(void *fdt,
gic_interrupt_t *intr,
static int __init make_memory_node(const struct domain *d,
void *fdt,
int addrcells, int sizecells,
- const struct kernel_info *kinfo)
+ struct meminfo *mem)
{
int res, i;
int reg_size = addrcells + sizecells;
-int nr_cells = reg_size*kinfo->mem.nr_banks;
+int nr_cells = reg_size * mem->nr_banks;
__be32 reg[NR_MEM_BANKS * 4 /* Worst case addrcells + sizecells */];
__be32 *cells;
@@ -662,10 +662,10 @@ static int __init make_memory_node(const struct domain *d,
return res;
cells = [0];
-for ( i = 0 ; i < kinfo->mem.nr_banks; i++ )
+for ( i = 0 ; i < mem->nr_banks; i++ )
{
-u64 start = kinfo->mem.bank[i].start;
-u64 size = kinfo->mem.bank[i].size;
+u64 start = mem->bank[i].start;
+u64 size = mem->bank[i].size;
dt_dprintk(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
i, start, start + size);
@@ -1486,10 +1486,18 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
if ( res )
return res;
-res = make_memory_node(d, kinfo->fdt, addrcells, sizecells, kinfo);
+res = make_memory_node(d, kinfo->fdt, addrcells, sizecells,
>mem);
if ( res )
return res;
+/*
+ * Create a second memory node to store the ranges covering
+ * reserved-memory regions.
+ */
+res = make_memory_node(d, kinfo->fdt, addrcells, sizecells,
+ _mem);
+if ( res )
+return res;
}
res = fdt_end_node(kinfo->fdt);
@@ -1745,7 +1753,7 @@ static int __init prepare_dtb_domU(struct domain *d,
struct kernel_info *kinfo)
if ( ret )
goto err;
-ret = make_memory_node(d, kinfo->fdt, addrcells, sizecells, kinfo);
+ret = make_memory_node(d, kinfo->fdt, addrcells, sizecells, >mem);
if ( ret )
goto err;
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 2/8] xen/arm: make process_memory_node a device_tree_node_func
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Return error if there is no reg property or if nr_banks is reached. Let
the caller deal with the error.
Add a printk when device tree parsing fails.
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- use -EINVAL as return in case size is 0
Changes in v6:
- fix out of space check
- bring back printk when address_cells or size_cells are not properly set
- return -EINVAL in that case (different from reg missing)
- add printk when parsing fails
- return -ENOENT when memory size is 0
Changes in v5:
- return -ENOENT if address_cells or size_cells are not properly set
Changes in v4:
- return error if there is no reg propery, remove printk
- return error if nr_banks is reached
Changes in v3:
- improve commit message
- check return value of process_memory_node
Changes in v2:
- new
---
xen/arch/arm/bootfdt.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0ca3c20f05..320c9a16f4 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -134,9 +134,10 @@ int __init device_tree_for_each_node(const void *fdt, int
node,
return 0;
}
-static void __init process_memory_node(const void *fdt, int node,
- const char *name,
- u32 address_cells, u32 size_cells)
+static int __init process_memory_node(const void *fdt, int node,
+ const char *name, int depth,
+ u32 address_cells, u32 size_cells,
+ void *data)
{
const struct fdt_property *prop;
int i;
@@ -149,15 +150,12 @@ static void __init process_memory_node(const void *fdt,
int node,
{
printk("fdt: node `%s': invalid #address-cells or #size-cells",
name);
-return;
+return -EINVAL;
}
prop = fdt_get_property(fdt, node, "reg", NULL);
if ( !prop )
-{
-printk("fdt: node `%s': missing `reg' property\n", name);
-return;
-}
+return -ENOENT;
cell = (const __be32 *)prop->data;
banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
@@ -166,11 +164,15 @@ static void __init process_memory_node(const void *fdt,
int node,
{
device_tree_get_reg(, address_cells, size_cells, , );
if ( !size )
-continue;
+return -EINVAL;
bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
bootinfo.mem.nr_banks++;
}
+
+if ( i < banks )
+return -ENOSPC;
+return 0;
}
static void __init process_multiboot_node(const void *fdt, int node,
@@ -302,15 +304,20 @@ static int __init early_scan_node(const void *fdt,
u32 address_cells, u32 size_cells,
void *data)
{
+int rc = 0;
+
if ( device_tree_node_matches(fdt, node, "memory") )
-process_memory_node(fdt, node, name, address_cells, size_cells);
+rc = process_memory_node(fdt, node, name, depth,
+ address_cells, size_cells, NULL);
else if ( depth <= 3 && (device_tree_node_compatible(fdt, node,
"xen,multiboot-module" ) ||
device_tree_node_compatible(fdt, node, "multiboot,module" )))
process_multiboot_node(fdt, node, name, address_cells, size_cells);
else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
process_chosen_node(fdt, node, name, address_cells, size_cells);
-return 0;
+if ( rc < 0 )
+printk("fdt: node `%s': parsing failed\n", name);
+return rc;
}
static void __init early_print_info(void)
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 6/8] xen/arm: handle reserved-memory in consider_modules and dt_unreserved_regions
reserved-memory regions overlap with memory nodes. The overlapping
memory is reserved-memory and should be handled accordingly:
consider_modules and dt_unreserved_regions should skip these regions the
same way they are already skipping mem-reserve regions.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v4:
- code style
- add acked-by
Changes in v3:
- coding style
- in-code comments
Changes in v2:
- fix commit message: full overlap
- remove check_reserved_memory
- extend consider_modules and dt_unreserved_regions
---
xen/arch/arm/setup.c | 53 +---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 215746a5c3..bc4082296e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -206,6 +206,28 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
}
}
+/*
+ * i is the current bootmodule we are evaluating across all possible
+ * kinds.
+ *
+ * When retrieving the corresponding reserved-memory addresses
+ * below, we need to index the bootinfo.reserved_mem bank starting
+ * from 0, and only counting the reserved-memory modules. Hence,
+ * we need to use i - nr.
+ */
+for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ )
+{
+paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start;
+paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size;
+
+if ( s < r_e && r_s < e )
+{
+dt_unreserved_regions(r_e, e, cb, i + 1);
+dt_unreserved_regions(s, r_s, cb, i + 1);
+return;
+}
+}
+
cb(s, e);
}
@@ -392,7 +414,7 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
{
const struct bootmodules *mi =
int i;
-int nr_rsvd;
+int nr;
s = (s+align-1) & ~(align-1);
e = e & ~(align-1);
@@ -418,9 +440,9 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
/* Now check any fdt reserved areas. */
-nr_rsvd = fdt_num_mem_rsv(device_tree_flattened);
+nr = fdt_num_mem_rsv(device_tree_flattened);
-for ( ; i < mi->nr_mods + nr_rsvd; i++ )
+for ( ; i < mi->nr_mods + nr; i++ )
{
paddr_t mod_s, mod_e;
@@ -442,6 +464,31 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t
e,
return consider_modules(s, mod_s, size, align, i+1);
}
}
+
+/*
+ * i is the current bootmodule we are evaluating, across all
+ * possible kinds of bootmodules.
+ *
+ * When retrieving the corresponding reserved-memory addresses, we
+ * need to index the bootinfo.reserved_mem bank starting from 0, and
+ * only counting the reserved-memory modules. Hence, we need to use
+ * i - nr.
+ */
+nr += mi->nr_mods;
+for ( ; i - nr < bootinfo.reserved_mem.nr_banks; i++ )
+{
+paddr_t r_s = bootinfo.reserved_mem.bank[i - nr].start;
+paddr_t r_e = r_s + bootinfo.reserved_mem.bank[i - nr].size;
+
+if ( s < r_e && r_s < e )
+{
+r_e = consider_modules(r_e, e, size, align, i + 1);
+if ( r_e )
+return r_e;
+
+return consider_modules(s, r_s, size, align, i + 1);
+}
+}
return e;
}
#endif
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 7/8] xen/arm: don't iomem_permit_access for reserved-memory regions
Don't allow reserved-memory regions to be remapped into any unprivileged
guests, until reserved-memory regions are properly supported in Xen. For
now, do not call iomem_permit_access on them, because giving
iomem_permit_access to dom0 means that the toolstack will be able to
assign the region to a domU.
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- update in-code comment
Changes in v6:
- compare against "/reserved-memory/"
Changes in v5:
- fix check condition
- use strnicmp
- return error
- improve commit message
Changes in v4:
- compare the parent name with reserved-memory
- use dt_node_cmp
Changes in v3:
- new patch
---
xen/arch/arm/domain_build.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4c8404155a..b4260f1fc2 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1155,15 +1155,24 @@ static int __init map_range_to_domain(const struct
dt_device_node *dev,
bool need_mapping = !dt_device_for_passthrough(dev);
int res;
-res = iomem_permit_access(d, paddr_to_pfn(addr),
- paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
-if ( res )
+/*
+ * reserved-memory regions are RAM carved out for a special purpose.
+ * They are not MMIO and therefore a domain should not be able to
+ * manage them via the IOMEM interface.
+ */
+if ( strnicmp(dt_node_full_name(dev), "/reserved-memory/",
+ strlen("/reserved-memory/")) != 0 )
{
-printk(XENLOG_ERR "Unable to permit to dom%d access to"
- " 0x%"PRIx64" - 0x%"PRIx64"\n",
- d->domain_id,
- addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
-return res;
+res = iomem_permit_access(d, paddr_to_pfn(addr),
+paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to dom%d access to"
+" 0x%"PRIx64" - 0x%"PRIx64"\n",
+d->domain_id,
+addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
+return res;
+}
}
if ( need_mapping )
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 0/8] reserved-memory in dom0
Hi all, This patch series introduces partial reserved-memory support for dom0 only (no domU support for reserved-memory yet.) The following changes since commit 762b9a2d990bba1f3aefe660cff0c37ad2e375bc: xen/page_alloc: Keep away MFN 0 from the buddy allocator (2019-08-09 11:12:55 -0700) are available in the Git repository at: http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git reserved-mem-7 for you to fetch changes up to 794790f98d9bba4e34ea689049bf29899c6f1b2b: xen/arm: add reserved-memory regions to the dom0 memory node (2019-08-19 10:08:56 -0700) Stefano Stabellini (8): xen/arm: pass node to device_tree_for_each_node xen/arm: make process_memory_node a device_tree_node_func xen/arm: keep track of reserved-memory regions xen/arm: fix indentation in early_print_info xen/arm: early_print_info print reserved_mem xen/arm: handle reserved-memory in consider_modules and dt_unreserved_regions xen/arm: don't iomem_permit_access for reserved-memory regions xen/arm: add reserved-memory regions to the dom0 memory node xen/arch/arm/acpi/boot.c | 8 ++- xen/arch/arm/bootfdt.c| 128 +- xen/arch/arm/domain_build.c | 47 +++- xen/arch/arm/setup.c | 53 - xen/include/asm-arm/setup.h | 1 + xen/include/xen/device_tree.h | 6 +- 6 files changed, 181 insertions(+), 62 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 4/8] xen/arm: fix indentation in early_print_info
No functional changes.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
xen/arch/arm/bootfdt.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0a01963b0e..eb3dc13b06 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -358,15 +358,15 @@ static void __init early_print_info(void)
for ( i = 0; i < mi->nr_banks; i++ )
printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
- mi->bank[i].start,
- mi->bank[i].start + mi->bank[i].size - 1);
+mi->bank[i].start,
+mi->bank[i].start + mi->bank[i].size - 1);
printk("\n");
for ( i = 0 ; i < mods->nr_mods; i++ )
printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
- i,
- mods->module[i].start,
- mods->module[i].start + mods->module[i].size,
- boot_module_kind_as_string(mods->module[i].kind));
+i,
+mods->module[i].start,
+mods->module[i].start + mods->module[i].size,
+boot_module_kind_as_string(mods->module[i].kind));
nr_rsvd = fdt_num_mem_rsv(device_tree_flattened);
for ( i = 0; i < nr_rsvd; i++ )
@@ -376,8 +376,7 @@ static void __init early_print_info(void)
continue;
/* fdt_get_mem_rsv returns length */
e += s;
-printk(" RESVD[%d]: %"PRIpaddr" - %"PRIpaddr"\n",
- i, s, e);
+printk(" RESVD[%d]: %"PRIpaddr" - %"PRIpaddr"\n", i, s, e);
}
printk("\n");
for ( i = 0 ; i < cmds->nr_mods; i++ )
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 1/8] xen/arm: pass node to device_tree_for_each_node
Add a new parameter to device_tree_for_each_node: node, the node to
start the search from.
To avoid scanning device tree, and given that we only care about
relative increments of depth compared to the depth of the initial node,
we set the initial depth to 0. Then, we call func() for every node with
depth > 0.
Don't call func() on the parent node passed as an argument. Clarify the
change in the comment on top of the function. The current callers pass
the root node as argument: it is OK to skip the root node because no
relevant properties are in it, only subnodes.
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- fix commit message
- use const
- init depth and min_depth to 0
Changes in v6:
- fix code style
- don't call func() on the first node
Changes in v5:
- go back to v3
- code style improvement in acpi/boot.c
- improve comments and commit message
- increase min_depth to avoid parsing siblings
- replace for with do/while loop and increase min_depth to avoid
scanning siblings of the initial node
- pass only node, calculate depth
Changes in v3:
- improve commit message
- improve in-code comments
- improve code style
Changes in v2:
- new
---
xen/arch/arm/acpi/boot.c | 8 +---
xen/arch/arm/bootfdt.c| 38 ++-
xen/include/xen/device_tree.h | 6 +++---
3 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 9b29769a10..bf9c78b02c 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -246,9 +246,11 @@ int __init acpi_boot_table_init(void)
* - the device tree is not empty (it has more than just a /chosen node)
* and ACPI has not been force enabled (acpi=force)
*/
-if ( param_acpi_off || ( !param_acpi_force
- &&
device_tree_for_each_node(device_tree_flattened,
- dt_scan_depth1_nodes,
NULL)))
+if ( param_acpi_off)
+goto disable;
+if ( !param_acpi_force &&
+ device_tree_for_each_node(device_tree_flattened, 0,
+ dt_scan_depth1_nodes, NULL) )
goto disable;
/*
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 891b4b66ff..0ca3c20f05 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -75,9 +75,10 @@ static u32 __init device_tree_get_u32(const void *fdt, int
node,
}
/**
- * device_tree_for_each_node - iterate over all device tree nodes
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
* @fdt: flat device tree.
- * @func: function to call for each node.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
* @data: data to pass to @func.
*
* Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
@@ -85,20 +86,22 @@ static u32 __init device_tree_get_u32(const void *fdt, int
node,
* Returns 0 if all nodes were iterated over successfully. If @func
* returns a value different from 0, that value is returned immediately.
*/
-int __init device_tree_for_each_node(const void *fdt,
+int __init device_tree_for_each_node(const void *fdt, int node,
device_tree_node_func func,
void *data)
{
-int node;
-int depth;
+/*
+ * We only care about relative depth increments, assume depth of
+ * node is 0 for simplicity.
+ */
+int depth = 0;
+const int min_depth = depth;
+const int first_node = node;
u32 address_cells[DEVICE_TREE_MAX_DEPTH];
u32 size_cells[DEVICE_TREE_MAX_DEPTH];
int ret;
-for ( node = 0, depth = 0;
- node >=0 && depth >= 0;
- node = fdt_next_node(fdt, node, ) )
-{
+do {
const char *name = fdt_get_name(fdt, node, NULL);
u32 as, ss;
@@ -117,10 +120,17 @@ int __init device_tree_for_each_node(const void *fdt,
size_cells[depth] = device_tree_get_u32(fdt, node,
"#size-cells", ss);
-ret = func(fdt, node, name, depth, as, ss, data);
-if ( ret != 0 )
-return ret;
-}
+/* skip the first node */
+if ( node != first_node )
+{
+ret = func(fdt, node, name, depth, as, ss, data);
+if ( ret != 0 )
+return ret;
+}
+
+node = fdt_next_node(fdt, node, );
+} while ( node >= 0 && depth > min_depth );
+
return 0;
}
@@ -357,7 +367,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
-device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
+device_tree_for_each_node((void *)fdt, 0, early_scan_node, NULL);
early_print_info();
return fdt_totalsize(fdt);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index
Re: [Xen-devel] [PATCH v7 1/8] xen/arm: pass node to device_tree_for_each_node
On 8/19/19 6:43 PM, Stefano Stabellini wrote:
@@ -85,20 +86,22 @@ static u32 __init device_tree_get_u32(const void *fdt, int
node,
* Returns 0 if all nodes were iterated over successfully. If @func
* returns a value different from 0, that value is returned immediately.
*/
-int __init device_tree_for_each_node(const void *fdt,
+int __init device_tree_for_each_node(const void *fdt, int node,
device_tree_node_func func,
void *data)
{
-int node;
-int depth;
+/*
+ * We only care about relative depth increments, assume depth of
+ * node is 0 for simplicity.
+ */
+int depth = 0;
+const int min_depth = depth;
There is no need to define min_depth here. With min_depth dropped:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 2/8] xen/arm: make process_memory_node a device_tree_node_func
Hi Stefano, On 8/19/19 6:43 PM, Stefano Stabellini wrote: Change the signature of process_memory_node to match device_tree_node_func. Thanks to this change, the next patch will be able to use device_tree_for_each_node to call process_memory_node on all the children of a provided node. Return error if there is no reg property or if nr_banks is reached. Let the caller deal with the error. Add a printk when device tree parsing fails. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/boot: Reposition trampoline data
On Mon, 2019-08-19 at 14:42 +0100, Andrew Cooper wrote: > ... to separate code from data. In particular, > trampoline_realmode_entry's > write to trampoline_cpu_started clobbers the I-cache line containing > trampoline_protmode_entry, which won't be great for AP startup. > > Reformat the comments for trampoline_gdt to reduce their volume. > > No functional change. Please, let's not do this one until my other boot cleanups have landed. It just hurts. I have also reordered some of these for functional reasons, because they are used in different contexts (and end up in completely different trampolines). > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > --- > xen/arch/x86/boot/trampoline.S | 67 ++ > > 1 file changed, 28 insertions(+), 39 deletions(-) > > diff --git a/xen/arch/x86/boot/trampoline.S > b/xen/arch/x86/boot/trampoline.S > index 1761fc1213..1b11b4757a 100644 > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -59,45 +59,6 @@ GLOBAL(trampoline_realmode_entry) > lmsw%ax # CR0.PE = 1 (enter > protected mode) > ljmpl $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6) > > -trampoline_gdt: > -/* 0x: unused */ > -.quad 0x > -/* 0x0008: ring 0 code, 32-bit mode */ > -.quad 0x00cf9b00 > -/* 0x0010: ring 0 code, 64-bit mode */ > -.quad 0x00af9b00 > -/* 0x0018: ring 0 data */ > -.quad 0x00cf9300 > -/* 0x0020: real-mode code @ BOOT_TRAMPOLINE */ > -.long 0x > -.long 0x9b00 > -/* 0x0028: real-mode data @ BOOT_TRAMPOLINE */ > -.long 0x > -.long 0x9300 > -/* > - * 0x0030: ring 0 Xen data, 16 MiB size, base > - * address is computed at runtime. > - */ > -.quad 0x00c093000fff > -.Ltramopline_gdt_end: > - > -.pushsection .trampoline_rel, "a" > -.long trampoline_gdt + BOOT_PSEUDORM_CS + 2 - . > -.long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . > -.popsection > - > -GLOBAL(trampoline_misc_enable_off) > -.quad 0 > - > -GLOBAL(cpuid_ext_features) > -.long 0 > - > -GLOBAL(trampoline_xen_phys_start) > -.long 0 > - > -GLOBAL(trampoline_cpu_started) > -.byte 0 > - > .code32 > trampoline_protmode_entry: > /* Set up a few descriptors: on entry only CS is guaranteed > good. */ > @@ -186,6 +147,34 @@ idt_48: .word 0, 0, 0 # base = limit = 0 > gdt_48: .word .Ltramopline_gdt_end - trampoline_gdt - 1 > .long bootsym_rel(trampoline_gdt,4) > > +trampoline_gdt: > +.quad 0x /* 0x: unused */ > +.quad 0x00cf9b00 /* 0x0008: ring 0 code, 32-bit > mode */ > +.quad 0x00af9b00 /* 0x0010: ring 0 code, 64-bit > mode */ > +.quad 0x00cf9300 /* 0x0018: ring 0 data */ > +.quad 0x9b00 /* 0x0020: real-mode code @ > BOOT_TRAMPOLINE */ > +.quad 0x9300 /* 0x0028: real-mode data @ > BOOT_TRAMPOLINE */ > +.quad 0x00c093000fff /* 0x0030: ring 0 Xen data, 16M @ > XEN */ > +.Ltramopline_gdt_end: > + > +/* Relocations for trampoline Real Mode segments. */ > +.pushsection .trampoline_rel, "a" > +.long trampoline_gdt + BOOT_PSEUDORM_CS + 2 - . > +.long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . > +.popsection > + > +GLOBAL(trampoline_misc_enable_off) > +.quad 0 > + > +GLOBAL(cpuid_ext_features) > +.long 0 > + > +GLOBAL(trampoline_xen_phys_start) > +.long 0 > + > +GLOBAL(trampoline_cpu_started) > +.byte 0 > + > /* The first page of trampoline is permanent, the rest boot-time > only. */ > /* Reuse the boot trampoline on the 1st trampoline page as stack for > wakeup. */ > .equwakeup_stack, trampoline_start + PAGE_SIZE smime.p7s Description: S/MIME cryptographic signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/6] x86/boot: Rename trampoline_{start, end} to boot_trampoline_{start, end}
On Mon, 2019-08-12 at 11:55 +0200, Jan Beulich wrote: > On 09.08.2019 17:02, David Woodhouse wrote: > > From: David Woodhouse > > > > In preparation for splitting the boot and permanent trampolines from > > each other. Some of these will change back, but most are boot so do the > > plain search/replace that way first, then a subsequent patch will extract > > the permanent trampoline code. > > To be honest I don't view it as helpful to do things in this order. > If you first re-arranged the ordering of items within the trampoline, > we'd then not end up with an intermediate state where the labels are > misleading. Is there a reason things can't sensibly be done the other > way around? Obviously I did all this in a working tree first, swore at it a lot and finally got it working, then attempted to split it up into separate meaningful commits which individually made sense. There is plenty of room for subjectivity in the choices I made in that last step. I'm not sure I quite see why you say the labels are misleading. My intent was to apply labels based on what each object is *used* for, despite the fact that to start with they're all actually in the same place. And then to actually move each different type of symbol into its separate section/location to clean things up. Is it just the code comments at the start of trampoline.S that you find misleading in the interim stage? Because those *don't* purely talk about what bootsym/bootdatasym/trampsym/tramp32sym are used for; they do say how they are (eventually) relocated. I suppose I could rip that code comment out of patch #3 completely and add it again in a later commit... or just just add it again. I write code comments in an attempt to be helpful to those who come after me (especially when that's actually myself) but if they're going to cause problems, then maybe they're more hassle than they're worth? smime.p7s Description: S/MIME cryptographic signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH livepatch-hooks-4 1/1] livepatch: always print XENLOG_ERR information
On 19/08/2019 15:42, Ross Lagerwall wrote: > On 8/14/19 1:23 PM, Pawel Wieczorkiewicz wrote: >> A lot of legitimate error messages were hidden behind debug printk >> only. Most of these messages can be triggered by loading a malformed >> hotpatch payload and are priceless for understanding issues with such >> payloads. >> Thus, always display all relevant XENLOG_ERR messages. >> >> Signed-off-by: Pawel Wieczorkiewicz >> Reviewed-by: Amit Shah >> Reviewed-by: Martin Mazein >> Reviewed-by: Bjoern Doebel >> --- > Reviewed-by: Ross Lagerwall > > This changes is much-needed. In an effort get some of this livepatch content moving, I've committed this. I did however fix up some indentation errors, and the final three hunks which ended up with double "livepatch:" prefixes. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86: Restore IA32_MISC_ENABLE on wakeup
On 19/08/2019 14:56, Michał Kowalczyk wrote: > On 8/19/19 3:52 PM, Andrew Cooper wrote: >> On 19/08/2019 14:50, Michał Kowalczyk wrote: >>> On 8/19/19 11:04 AM, Andrew Cooper wrote: On 19/08/2019 03:23, Michał Kowalczyk wrote: > diff --git a/xen/arch/x86/boot/trampoline.S > b/xen/arch/x86/boot/trampoline.S > index 7c6a2328d2..fcaa3eeaf1 100644 > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -85,7 +85,7 @@ trampoline_gdt: > .long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . > .popsection > > -GLOBAL(trampoline_misc_enable_off) > +GLOBAL(misc_enable_off) The overall change is fine, but why have you renamed this variable? >>> The old name had "trampoline_" prefix because the only place where it >>> was used was trampoline_protmode_entry in arch/x86/boot/trampoline.S. >>> Now it's also used in the wakeup code, so I removed the prefix which >>> could be (IMO) misleading. Without the rename, the patch would be just the single hunk in wakeup.S and therefore easier to backport. >>> True. Anyway, the decision is on your side, I can leave the old name if >>> you prefer. >> The trampoline_ prefix indicates where the data lives, which is in the >> 16 bit trampoline which contains both the AP boot path, and wakeup path. > Ah, if this is the convention you use then we should leave the old name. >> If you're happy with this, I can adjust on commit to avoid you sending a >> second time. > Would be great, thanks! Done. https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c3cfa5b3084d71bccd8360d044bea813688b587c ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/console: Fix build when CONFIG_DEBUG_TRACE=y
On 19/08/2019 19:01, Julien Grall wrote: > Commit b5e6e1ee8da "xen/console: Don't treat NUL character as the end > of the buffer" extended sercon_puts to take the number of character > to print in argument. > > Sadly, a couple of couple of the callers in debugtrace_dump_worker() > were not converted. This result to a build failure when enabling > CONFIG_DEBUG_TRACE. > > Spotted by Travis using randconfig > Signed-off-by: Julien Grall > --- > xen/drivers/char/console.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > index 2c14c2ca73..924d4971ca 100644 > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -1185,11 +1185,12 @@ static void debugtrace_dump_worker(void) > > /* Print oldest portion of the ring. */ > ASSERT(debugtrace_buf[debugtrace_bytes - 1] == 0); > -sercon_puts(_buf[debugtrace_prd]); > +sercon_puts(_buf[debugtrace_prd], > +strlen(_buf[debugtrace_prd])); Isn't this just debugtrace_bytes - debugtrace_prd - 1 ? ~Andrew > > /* Print youngest portion of the ring. */ > debugtrace_buf[debugtrace_prd] = '\0'; > -sercon_puts(_buf[0]); > +sercon_puts(_buf[0], debugtrace_prd); > > memset(debugtrace_buf, '\0', debugtrace_bytes); > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 1/2] xen: Switch parameter in get_page_from_gfn to use typesafe gfn
No functional change intended.
Only reasonable clean-ups are done in this patch. The rest will use _gfn
for the time being.
The code in get_page_from_gfn is slightly reworked to also handle a bad
behavior because it is not safe to use mfn_to_page(...) because
mfn_valid(...) succeeds.
Signed-off-by: Julien Grall
---
Changes in v4:
- Drop all the reviewed-by/acked-by as the last version was
sent nearly 9 months ago.
- Rework the change in x86 version get_page_from_gfn
- s/%#PRI_/%PRI_/
Changes in v3:
- Add Jan's acked-by
Changes in v2:
- Remove >> PAGE_SHIFT in svm code
- Fix typo in the e-mail address
- Small NITs
---
xen/arch/arm/guestcopy.c | 2 +-
xen/arch/arm/mm.c| 2 +-
xen/arch/x86/cpu/vpmu.c | 2 +-
xen/arch/x86/domctl.c| 6 +++---
xen/arch/x86/hvm/dm.c| 2 +-
xen/arch/x86/hvm/domain.c| 6 --
xen/arch/x86/hvm/hvm.c | 9 +
xen/arch/x86/hvm/svm/svm.c | 8
xen/arch/x86/hvm/viridian/viridian.c | 16
xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
xen/arch/x86/hvm/vmx/vvmx.c | 12 ++--
xen/arch/x86/mm.c| 24 ++--
xen/arch/x86/mm/p2m.c| 2 +-
xen/arch/x86/mm/shadow/hvm.c | 6 +++---
xen/arch/x86/physdev.c | 3 ++-
xen/arch/x86/pv/descriptor-tables.c | 4 ++--
xen/arch/x86/pv/emul-priv-op.c | 6 +++---
xen/arch/x86/pv/mm.c | 2 +-
xen/arch/x86/traps.c | 11 ++-
xen/common/domain.c | 2 +-
xen/common/event_fifo.c | 12 ++--
xen/common/memory.c | 4 ++--
xen/include/asm-arm/p2m.h| 6 +++---
xen/include/asm-x86/p2m.h| 16
24 files changed, 92 insertions(+), 75 deletions(-)
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 7a0f3e9d5f..55892062bb 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -37,7 +37,7 @@ static struct page_info *translate_get_page(copy_info_t info,
uint64_t addr,
return get_page_from_gva(info.gva.v, addr,
write ? GV2M_WRITE : GV2M_READ);
-page = get_page_from_gfn(info.gpa.d, paddr_to_pfn(addr), , P2M_ALLOC);
+page = get_page_from_gfn(info.gpa.d, gaddr_to_gfn(addr), , P2M_ALLOC);
if ( !page )
return NULL;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index e1cdeaaf2f..e9afd53e69 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1405,7 +1405,7 @@ int xenmem_add_to_physmap_one(
/* Take reference to the foreign domain page.
* Reference will be released in XENMEM_remove_from_physmap */
-page = get_page_from_gfn(od, idx, , P2M_ALLOC);
+page = get_page_from_gfn(od, _gfn(idx), , P2M_ALLOC);
if ( !page )
{
put_pg_owner(od);
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 375599aca5..c5a4c9a603 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -590,7 +590,7 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t
*params)
struct vcpu *v;
struct vpmu_struct *vpmu;
struct page_info *page;
-uint64_t gfn = params->val;
+gfn_t gfn = _gfn(params->val);
if ( (params->vcpu >= d->max_vcpus) || (d->vcpu[params->vcpu] == NULL) )
return -EINVAL;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 2d45e5b8a8..3ce2dd1463 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -453,7 +453,7 @@ long arch_do_domctl(
break;
}
-page = get_page_from_gfn(d, gfn, , P2M_ALLOC);
+page = get_page_from_gfn(d, _gfn(gfn), , P2M_ALLOC);
if ( unlikely(!page) ||
unlikely(is_xen_heap_page(page)) )
@@ -503,11 +503,11 @@ long arch_do_domctl(
case XEN_DOMCTL_hypercall_init:
{
-unsigned long gmfn = domctl->u.hypercall_init.gmfn;
+gfn_t gfn = _gfn(domctl->u.hypercall_init.gmfn);
struct page_info *page;
void *hypercall_page;
-page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
if ( !page || !get_page_type(page, PGT_writable_page) )
{
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d6d0e8be89..3b3ad27938 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -186,7 +186,7 @@ static int modified_memory(struct domain *d,
{
struct page_info *page;
-page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
+page = get_page_from_gfn(d, _gfn(pfn), NULL, P2M_UNSHARE);
if ( page )
{
paging_mark_pfn_dirty(d, _pfn(pfn));
diff --git
[Xen-devel] [PATCH v4 2/2] xen/domain: Use typesafe gfn in map_vcpu_info
At the same time, modify the documentation of the hypercall to reflect
the real meaning of the field mfn.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/common/domain.c | 6 +++---
xen/include/public/vcpu.h | 2 +-
xen/include/xen/domain.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e8f6dfbdf1..915ebca190 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1282,7 +1282,7 @@ int vcpu_reset(struct vcpu *v)
* of memory, and it sets a pending event to make sure that a pending
* event doesn't get missed.
*/
-int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset)
+int map_vcpu_info(struct vcpu *v, gfn_t gfn, unsigned offset)
{
struct domain *d = v->domain;
void *mapping;
@@ -1299,7 +1299,7 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn,
unsigned offset)
if ( (v != current) && !(v->pause_flags & VPF_down) )
return -EINVAL;
-page = get_page_from_gfn(d, _gfn(gfn), NULL, P2M_ALLOC);
+page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
if ( !page )
return -EINVAL;
@@ -1538,7 +1538,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
domain_lock(d);
-rc = map_vcpu_info(v, info.mfn, info.offset);
+rc = map_vcpu_info(v, _gfn(info.mfn), info.offset);
domain_unlock(d);
break;
diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h
index 3623af932f..dc4c6a72a0 100644
--- a/xen/include/public/vcpu.h
+++ b/xen/include/public/vcpu.h
@@ -182,7 +182,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_set_singleshot_timer_t);
*/
#define VCPUOP_register_vcpu_info 10 /* arg == vcpu_register_vcpu_info_t */
struct vcpu_register_vcpu_info {
-uint64_t mfn;/* mfn of page to place vcpu_info */
+uint64_t mfn;/* gfn of page to place vcpu_info */
uint32_t offset; /* offset within page */
uint32_t rsvd; /* unused */
};
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 3f09cb66c0..7e754f7cc0 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -58,7 +58,7 @@ void free_pirq_struct(void *);
int arch_vcpu_create(struct vcpu *v);
void arch_vcpu_destroy(struct vcpu *v);
-int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
+int map_vcpu_info(struct vcpu *v, gfn_t gfn, unsigned offset);
void unmap_vcpu_info(struct vcpu *v);
int arch_domain_create(struct domain *d,
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/6] x86/boot: Split bootsym() into four types of relocations
Apologies for delayed response; I was away last week and was frowned at every time I so much as looked towards the laptop. On Mon, 2019-08-12 at 11:41 +0200, Jan Beulich wrote: > On 09.08.2019 17:01, David Woodhouse wrote: > > --- a/xen/arch/x86/boot/trampoline.S > > +++ b/xen/arch/x86/boot/trampoline.S > > @@ -16,21 +16,62 @@ > >* not guaranteed to persist. > >*/ > > > > -/* NB. bootsym() is only usable in real mode, or via BOOT_PSEUDORM_DS. */ > > +/* > > + * There are four sets of relocations: > > + * > > + * bootsym(): Boot-time code relocated to low memory and run only once. > > + *Only usable at boot, in real mode or via > > BOOT_PSEUDORM_DS. > > I'm not a native speaker, so my viewing this as ambiguous may be wrong, > but to me it reads as "Only usable at boot or in real mode or via > BOOT_PSEUDORM_DS" when aiui it ought to be "Only usable at boot AND (in > real mode OR via BOOT_PSEUDORM_DS)". In which case how about "Only usable > at boot from real mode or via BOOT_PSEUDORM_DS"? Yes, I suppose I see that ambiguity. But ultimately I file it under the category of "don't hack boot code while drunk". I agree that to the reader of English (native or otherwise), that sentence may have either meaning. But this isn't documentation; it's code comments in an assembler file. Anyone who is actually going to make a meaningful contribution to the boot code, might reasonably be expected to understand that "real mode or using the pseudo-realmode segment selector" are grouped together, and that they must use one or the other of those. At boot time. This is not an attempt at a two-line tutorial on all the pitfalls of touching the boot code/data; via bootsym() or otherwise. It's just a pointer in the right direction. But sure, I'll have a look at fixing it — if I don't feel that what I come up with is too clumsy. > > + * bootdatasym(): Boot-time BIOS-discovered data, relocated back up to Xen > > + *image after discovery. > > + * trampsym():Trampoline code relocated into low memory for AP startup > > + *and wakeup. > > + * tramp32sym(): 32-bit trampoline code which at boot can be used directly > > + *from the Xen image in memory, but which will need to be > > + *relocated into low (well, into *mapped*) memory in order > > + *to be used for AP startup. > > + */ > > #undef bootsym > > #define bootsym(s) ((s)-trampoline_start) > > > > #define bootsym_rel(sym, off, opnd...) \ > > bootsym(sym),##opnd; \ > > 111:; \ > > -.pushsection .trampoline_rel, "a"; \ > > +.pushsection .bootsym_rel, "a";\ > > .long 111b - (off) - .;\ > > .popsection > > > > #define bootsym_segrel(sym, off) \ > > $0,$bootsym(sym); \ > > 111:; \ > > -.pushsection .trampoline_seg, "a"; \ > > +.pushsection .bootsym_seg, "a";\ > > +.long 111b - (off) - .;\ > > +.popsection > > + > > +#define bootdatasym(s) ((s)-trampoline_start) > > +#define bootdatasym_rel(sym, off, opnd...) \ > > +bootdatasym(sym),##opnd; \ > > +111:; \ > > +.pushsection .bootdatasym_rel, "a";\ > > +.long 111b - (off) - .;\ > > +.popsection > > + > > +#undef trampsym > > +#define trampsym(s) ((s)-trampoline_start) > > + > > +#define trampsym_rel(sym, off, opnd...)\ > > +trampsym(sym),##opnd; \ > > +111:; \ > > +.pushsection .trampsym_rel, "a"; \ > > +.long 111b - (off) - .;\ > > +.popsection > > + > > +#undef tramp32sym > > +#define tramp32sym(s) ((s)-trampoline_start) > > + > > +#define tramp32sym_rel(sym, off, opnd...) \ > > +tramp32sym(sym),##opnd;\ > > +111:; \ > > +.pushsection .tramp32sym_rel, "a"; \ > > .long 111b - (off) - .;\ > > .popsection > > This repeats the basically same sequence of things several times. > I've not peeked ahead yet to see in how far more differences would > appear later on, but I don't really expect much of a further > change. In which case it might be nice to reduce the redundancy > here (by introducing a single "base" macro from which the four > similar ones would be derived). They end up being more different than this. It was my judgement that attempting to create a more generic building block from which they could all be derived would end up being less readable than just a little bit of partial duplication. If you feel strongly otherwise, I would welcome a follow-on patch to attempt to remedy that, if you choose to send one. > Furthermore, with the intended isolation, wouldn't it be better to > limit
Re: [Xen-devel] [PATCH v2 5/6] x86/boot: Copy 16-bit boot variables back up to Xen image
On Mon, 2019-08-12 at 12:24 +0200, Jan Beulich wrote:
> On 09.08.2019 17:02, David Woodhouse wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -733,6 +733,17 @@ trampoline_setup:
> > cmp $sym_offs(__bootsym_seg_stop),%edi
> > jb 1b
> >
> > +/* Relocations for the boot data section. */
> > +mov sym_fs(trampoline_phys),%edx
> > +add $(boot_trampoline_end - boot_trampoline_start),%edx
> > +mov $sym_offs(__bootdatasym_rel_start),%edi
> > +1:
> > +mov %fs:(%edi),%eax
> > +add %edx,%fs:(%edi,%eax)
> > +add $4,%edi
> > +cmp $sym_offs(__bootdatasym_rel_stop),%edi
> > +jb 1b
> > +
> > /* Do not parse command line on EFI platform here. */
> > cmpb$0,sym_fs(efi_platform)
> > jnz 1f
> > @@ -770,6 +781,11 @@ trampoline_setup:
> > mov $((boot_trampoline_end - boot_trampoline_start) / 4),%ecx
> > rep movsl %fs:(%esi),%es:(%edi)
> >
> > +/* Copy boot data template to low memory. */
> > +mov $sym_offs(bootdata_start),%esi
> > +mov $((bootdata_end - bootdata_start + 3) / 4),%ecx
> > +rep movsl %fs:(%esi),%es:(%edi)
>
> The new data arrangement should be described in the commit message.
> Also just like for the trampoline copying I think it would be better
> if you suitable aligned bootdata_start and bootdata_end, such that
> you wouldn't need to add 3 here before dividing by 4.
Ack.
> > @@ -227,7 +231,7 @@ start64:
> > .word 0
> > idt_48: .word 0, 0, 0 # base = limit = 0
> > .word 0
> > -gdt_48: .word 6*8-1
> > +gdt_48: .word 7*8-1
> > .long tramp32sym_rel(trampoline_gdt,4)
>
> You don't grow trampoline_gdt here, so I think this change is
> wrong. And if a change was needed at all (perhaps in the next
> patch), then I think it would be better to replace the use of
> literal numbers, using the difference of two labels instead
> (the "end" lable preferably being a .L-prefixed one).
I don't grow it but... count it ☺.
I do start using sym_fs() here in places that it wasn't before, so the
incorrect size started to *matter* because the BOOT_FS selector wasn't
included in the limit.
I will make sure I explicitly comment on that in the commit message; no
need for a code comment to explain why the limit actually *does* match
the size of the table.
> > --- a/xen/arch/x86/boot/video.S
> > +++ b/xen/arch/x86/boot/video.S
> > @@ -15,10 +15,10 @@
> >
> > #include "video.h"
> >
> > -/* Scratch space layout: boot_trampoline_end to
> > boot_trampoline_end+0x1000. */
> > -#define modelist bootsym(boot_trampoline_end) /* 2kB (256 entries)
> > */
> > -#define vesa_glob_info (modelist + 0x800)/* 1kB */
> > -#define vesa_mode_info (vesa_glob_info + 0x400) /* 1kB */
> > +/* Scratch space layout: bootdata_end to bootdata_end+0x1000. */
> > +#define modelist(t) bootdatasym_rel(bootdata_end,2,t) /*
> > 2KiB (256 entries) */
> > +#define vesa_glob_info(t) bootdatasym_rel((bootdata_end+0x800),2,t) /*
> > 1KiB */
> > +#define vesa_mode_info(t) bootdatasym_rel((bootdata_end+0xc00),2,t) /*
> > 1KiB */
> >
> > /* Retrieve Extended Display Identification Data. */
> > #define CONFIG_FIRMWARE_EDID
> > @@ -113,7 +113,7 @@ mopar2: movb%al, _param(PARAM_VIDEO_LINES)
> >
> > # Fetching of VESA frame buffer parameters
> > mopar_gr:
> > -leawvesa_mode_info, %di
> > +leawvesa_mode_info(%di)
>
> Just as a note, as I can't really see how to improve the situation:
> The embedding of the relocation offset (2) in the macros is making
> this code even more fragile, as they're now not usable anymore in
> an arbitrary way (consider e.g. their use for the memory operand if
> an insn which also requires an immediate). I think you want to at
> least warn about this restriction in the comment above.
Yeah. I file that one under "don't touch the VESA code unless you want
your brain to dribble out of your ears". Which was basically true
before I touched it too, in my defence ☺.
> > @@ -291,6 +293,10 @@ SECTIONS
> > DECL_SECTION(.data) {
> > *(.data.page_aligned)
> > *(.data)
> > + . = ALIGN(16);
> > + __bootdata_start = .;
> > + *(.data.boot16)
> > + __bootdata_end = .;
>
> Why 16-byte alignment?
Er... not sure. I think this (and the end) can be 4 as you suggest
elsewhere. Will make that change and retest.
> Having reached the end of the patch without seeing the C-level
> bootsym() go away (and as a result noticing that you didn't remove
> all uses) - could you please explain in the commit message what
> the replacement (or not) criteria are?
In the subsequent patch (6/6), bootsym() is indeed gone from C code,
and only trampsym() is left. The latter is for the permanent (not boot
time) trampoline used wakeup and for AP startup. As
Re: [Xen-devel] [PATCH v2 6/6] x86/boot: Do not use trampoline for no-real-mode boot paths
On Mon, 2019-08-12 at 12:55 +0200, Jan Beulich wrote:
> On 09.08.2019 17:02, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Where booted from EFI or with no-real-mode, there is no need to stomp
> > on low memory with the 16-boot code. Instead, just go straight to
> > trampoline_protmode_entry() at its physical location within the Xen
> > image.
> >
> > For now, the boot code (including the EFI loader path) still determines
> > what the trampoline_phys address should be. The trampoline is actually
> > relocated for that address and copied into low memory, from a
> > relocate_trampoline() call made from __start_xen().
>
> I assume this talks about the real mode part of the trampoline, as
> opposed to the next paragraph? Would be nice if you made this
> explicit.
This is the permanent real-mode trampoline used for AP startup and
wakeup, not the real-mode boot code (which the boot code has to have
put there for itself it it wanted it).
I will try to make the commit message clearer; thanks for pointing it
out.
> > For subsequent AP startup and wakeup, the 32-bit trampoline can't
> > trivially be used in-place as that region isn't mapped. So copy it
> > down to low memory too, having relocated it (again) to work from
> > there.
>
> trampoline_protmode_entry gets entered with CR0.PG=0, i.e. at
> that point there's not even the question yet of there being a
> mapping. Subsequently idle_pg_table gets loaded into CR3. I wonder
> if, rather than relocating the 32-bit part of the trampoline, it
> wouldn't be better to install a 1:1 mapping into idle_pg_table.
> Such a mapping would need to have the G bits clear in order to
> not conflict with PV guest mappings of the same linear addresses.
Yeah, I tried making that happen. It made me sad. This seemed to be
simpler and less fragile.
> > --- a/xen/arch/x86/acpi/power.c
> > +++ b/xen/arch/x86/acpi/power.c
> > @@ -152,9 +152,9 @@ static void acpi_sleep_prepare(u32 state)
> > return;
> >
> > if ( acpi_sinfo.vector_width == 32 )
> > -*(uint32_t *)wakeup_vector_va = bootsym_phys(wakeup_start);
> > +*(uint32_t *)wakeup_vector_va = trampsym_phys(wakeup_start);
> > else
> > -*(uint64_t *)wakeup_vector_va = bootsym_phys(wakeup_start);
> > +*(uint64_t *)wakeup_vector_va = trampsym_phys(wakeup_start);
> > }
> >
> > static void acpi_sleep_post(u32 state) {}
> > @@ -388,7 +388,7 @@ static void tboot_sleep(u8 sleep_state)
> > g_tboot_shared->acpi_sinfo.wakeup_vector = acpi_sinfo.wakeup_vector;
> > g_tboot_shared->acpi_sinfo.vector_width = acpi_sinfo.vector_width;
> > g_tboot_shared->acpi_sinfo.kernel_s3_resume_vector =
> > - bootsym_phys(wakeup_start);
> > + trampsym_phys(wakeup_start);
>
> Shouldn't changes like these have happened earlier, when you
> introduce the (logical only at that point) distinction between
> trampoline pieces?
That was in assembler code. This is C, which never had to be that
involved with the distinction. But now that all the dust has settled,
I'm making it consistent, using 'trampsym' for stuff in the permanent
trampoline just like the asm code does.
> > @@ -97,7 +100,7 @@ GLOBAL(trampoline_realmode_entry)
> > cld
> > cli
> > lidttrampsym(idt_48)
> > -lgdttrampsym(gdt_48)
> > +lgdtl trampsym(gdt_48)
>
> Stray / unrelated change (and if needed, then also for lidt)?
The difference between 16bit l.dt and 32-bit l.dtl is that the former
only loads 24 bits of the actual table address (trampoline_gdt in this
case).
Thus, when trampoline_gdt is being used in-place, as it is during early
boot, and *if* the Xen image is loaded higher than 16MiB, lgdt doesn't
work. That's half a day of my life I want back.
It doesn't matter for lidt because we're just loading an empty limit
and pointer there, and we don't care about bits 24-31 of a zero value.
> > @@ -236,11 +239,23 @@ gdt_48: .word 7*8-1
> >
> > /* The first page of trampoline is permanent, the rest boot-time only. */
> > /* Reuse the boot trampoline on the 1st trampoline page as stack for
> > wakeup. */
> > -.equwakeup_stack, boot_trampoline_start + PAGE_SIZE
> > +.equwakeup_stack, perm_trampoline_start + PAGE_SIZE
> > .global wakeup_stack
> >
> > +ENTRY(perm_trampoline_end)
> > +
> > /* From here on early boot only. */
> >
> > +ENTRY(boot_trampoline_start)
> > +
> > +.word 0
> > +boot16_idt:
> > +.word 0, 0, 0 # base = limit = 0
> > +.word 0
> > +boot16_gdt:
> > +.word 7*8-1
> > +.long tramp32sym_rel(trampoline_gdt,4)
>
> Can we really not get away without a second copy of these?
Probably, but my judgement was that the complexity and the pain of
doing so would exceed the benefit. I'll take another look at doing so.
> > @@ -304,8 +319,8 @@
Re: [Xen-devel] [PATCH v6 07/10] use is_iommu_enabled() where appropriate...
On 8/16/19 1:19 PM, Paul Durrant wrote: ...rather than testing the global iommu_enabled flag and ops pointer. Now that there is a per-domain flag indicating whether the domain is permitted to use the IOMMU (which determines whether the ops pointer will be set), many tests of the global iommu_enabled flag and ops pointer can be translated into tests of the per-domain flag. Some of the other tests of purely the global iommu_enabled flag can also be translated into tests of the per-domain flag. NOTE: The comment in iommu_share_p2m_table() is also fixed; need_iommu() disappeared some time ago. Also, whilst the style of the 'if' in flask_iommu_resource_use_perm() is fixed, I have not translated any instances of u32 into uint32_t to keep consistency. IMO such a translation would be better done globally for the source module in a separate patch. The change in the initialization of the 'hd' variable in iommu_map() and iommu_unmap() is done to keep the PV shim build happy. Without this change it will fail to compile with errors of the form: iommu.c:361:32: error: unused variable ‘hd’ [-Werror=unused-variable] const struct domain_iommu *hd = dom_iommu(d); ^~ Signed-off-by: Paul Durrant Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/6] xen/arm: introduce handle_interrupts
On Fri, 9 Aug 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 09/08/2019 00:12, Stefano Stabellini wrote:
> > Move the interrupt handling code out of handle_device to a new function
> > so that it can be reused for dom0less VMs later.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - add patch
> >
> > The diff is hard to read but I just moved the interrupts related code
> > from handle_devices to a new function handle_interrupts, and very little
> > else.
> > ---
> > xen/arch/arm/domain_build.c | 79 +++--
> > 1 file changed, 49 insertions(+), 30 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 4c8404155a..00ddb3b05d 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1220,41 +1220,19 @@ static int __init map_device_children(struct domain
> > *d,
> > }
> > /*
> > - * For a given device node:
> > - * - Give permission to the guest to manage IRQ and MMIO range
> > - * - Retrieve the IRQ configuration (i.e edge/level) from device tree
> > - * When the device is not marked for guest passthrough:
> > - * - Assign the device to the guest if it's protected by an IOMMU
> > - * - Map the IRQs and iomem regions to DOM0
> > + * Return:
> > + * < 0 on error
> > + * 0 on no mapping required
> > + * 1 IRQ mapping done
>
> This feels a bit odd to describe the return value and not what the function
> does.
Fair enough, I'll add a few words.
> But I don't understand why you need to tell the caller whether mapping were
> done or not. This is already conveyed by "need_mapping" provided by the
> caller.
>
> Looking at the only place where you make the distinction between 0 and 1
> (patch #3), you have
>
> +r = handle_interrupts(d, node, true);
> +if ( r < 0 )
> +return r;
> +if ( r > 0 )
> +{
>/* do something */
> +}
>
>
> Not looking at the code below (which looks wrong), as you always pass true
> here, r can either be an error or 1.
Yes, the return statement of handle_interrupts, the way I wrote it:
return !!(need_mapping && res == 0);
is wrong. I'll fix it (also see below).
Stepping back from this specific error, the reason to distinguish
whether a mapping was done or not is to figure out whether we need to
add an interrupt property to the guest device tree. The idea is the
following:
- call handle_interrupts to do any required interrupt mappings
- if any mappings are done, copy over the interrupts property to the guest
device tree
> >*/
> > -static int __init handle_device(struct domain *d, struct dt_device_node
> > *dev,
> > -p2m_type_t p2mt)
> > +static int __init handle_interrupts(struct domain *d,
>
> How about handle_device_interrupts? Or map_device_interrupts?
OK
> > +struct dt_device_node *dev,
> > +bool need_mapping)
> > {
> > -unsigned int nirq;
> > -unsigned int naddr;
> > -unsigned int i;
> > -int res;
> > +int i, nirq, res;
>
> res will be used unitialized if the device has no interrupts.
Well spotted!
> > struct dt_raw_irq rirq;
> > -u64 addr, size;
> > -bool need_mapping = !dt_device_for_passthrough(dev);
> > nirq = dt_number_of_irq(dev);
> > -naddr = dt_number_of_address(dev);
> > -
> > -dt_dprintk("%s passthrough = %d nirq = %d naddr = %u\n",
> > - dt_node_full_name(dev), need_mapping, nirq, naddr);
> > -
> > -if ( dt_device_is_protected(dev) && need_mapping )
> > -{
> > -dt_dprintk("%s setup iommu\n", dt_node_full_name(dev));
> > -res = iommu_assign_dt_device(d, dev);
> > -if ( res )
> > -{
> > -printk(XENLOG_ERR "Failed to setup the IOMMU for %s\n",
> > - dt_node_full_name(dev));
> > -return res;
> > -}
> > -}
> > /* Give permission and map IRQs */
> > for ( i = 0; i < nirq; i++ )
> > @@ -1291,6 +1269,47 @@ static int __init handle_device(struct domain *d,
> > struct dt_device_node *dev,
> > return res;
> > }
> > +return !!(need_mapping && res == 0);
>
> Why do you need the !! here? (a && b) is already a boolean.
Yes, I'll remove it
> But this looks
> pretty wrong as you would return 0 when res is non-zero (i.e an error) and
> need_mapping is true.
>
> But looking at the code, res cannot be 0 here... So why are you checking "res"
> here?
That is a mistake: it should return 1 only when mappings are actually
done.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 140380: tolerable all pass - PUSHED
flight 140380 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/140380/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 4470efeae44fc1fe9ae4004408e175f8271fcda3 baseline version: xen 427b9c58f50bfbf6be99c0470079a165add18d22 Last test of basis 140371 2019-08-19 15:07:44 Z0 days Testing same since 140380 2019-08-19 18:10:24 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Pawel Wieczorkiewicz jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 427b9c58f5..4470efeae4 4470efeae44fc1fe9ae4004408e175f8271fcda3 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 140331: regressions - trouble: broken/fail/pass
flight 140331 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/140331/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair broken test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140221 REGR. vs. 139876 build-amd64-xsm 6 xen-build fail in 140255 REGR. vs. 139876 Tests which are failing intermittently (not blocking): test-amd64-i386-pair 5 host-install/dst_host(5) broken pass in 140255 test-amd64-amd64-xl-xsm 7 xen-boot fail in 140221 pass in 140331 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 140255 pass in 140221 test-amd64-i386-freebsd10-i386 7 xen-boot fail pass in 140255 test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail pass in 140255 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-i386-xl-xsm1 build-check(1) blocked in 140255 n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 140255 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 140255 n/a test-arm64-arm64-examine 11 examine-serial/bootloader fail in 140255 like 139876 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139876 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139876 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139876 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139876 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139876 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139876 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 05c525326957b504561d271f669d3b315930422f Bug not present: 223cea6a4f0552b86fb25e3b8bbd00469816cd7a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/140385/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl.xen-boot --summary-out=tmp/140385.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-amd64-i386-xl xen-boot Searching for failure / basis pass: 140251 fail [host=fiano0] / 138849 ok. Failure / basis pass flights: 140251 / 138849 (tree with no url: minios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 05c525326957b504561d271f669d3b315930422f c530a75c1e6a472b0eb9558310b518f0dfcd8860 501de8146d4fda1d423cd935316661746bdb750b d0d8ad39ecb51cd7497cd524484fe09f50876798 dbf360567a7da50db4d2f9bde4649aba21aa8106 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 6c9639a72f0ca3a9430ef75f375877182281fdef Basis pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a c530a75c1e6a472b0eb9558310b518f0dfcd8860 d031fc07eb83c9d13bff3ebac25da458d5a47917 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 843cec0de800a5f925f8071a7f58f3fb1c6b6eb6 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#223cea6a4f0552b86fb25e3b8bbd00469816cd7a-05c525326957b504561d271f669d3b315930422f git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#d031fc07eb83c9d13bff3ebac25da458d5a47917-501de8146d4fda1d423cd935316661746bdb750b git://xenbits.xen.org/qemu-xen-traditional.\ git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-dbf360567a7da50db4d2f9bde4649aba21aa8106 git://xenbits.xen.org/osstest/seabios.git#30f1e41f04fb4c715d27f987f003cfc31c9ff4f3-30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 git://xenbits.xen.org/xen.git#843cec0de800a5f925f8071a7f58f3fb1c6b6eb6-6c9639a72f0ca3a9430ef75f375877182281fdef adhoc-revtuple-generator: tree discontiguous: linux-2.6 Loaded 3006 nodes in revision graph Searching for test results: 138780 [host=italia0] 138813 [host=albana0] 138849 pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a c530a75c1e6a472b0eb9558310b518f0dfcd8860 d031fc07eb83c9d13bff3ebac25da458d5a47917 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 843cec0de800a5f925f8071a7f58f3fb1c6b6eb6 138878 fail irrelevant 138902 fail irrelevant 138962 fail irrelevant 139003 fail irrelevant 139068 fail irrelevant 139134 fail irrelevant 139237 fail irrelevant 139223 fail irrelevant 139257 fail irrelevant 139324 fail irrelevant 139306 fail irrelevant 139286 fail irrelevant 139338 fail irrelevant 139361 fail irrelevant 139383 fail irrelevant 139408 fail irrelevant 139478 fail irrelevant 139532 fail irrelevant 139584 fail irrelevant 139555 fail irrelevant 139687 fail irrelevant 139616 fail irrelevant 139669 fail irrelevant 139711 fail irrelevant 139735 fail irrelevant 139792 fail irrelevant 139832 fail irrelevant 139942 fail irrelevant 139866 fail irrelevant 139907 fail irrelevant 139996 fail irrelevant 140038 fail irrelevant 140128 fail irrelevant 140163 fail irrelevant 140251 fail 05c525326957b504561d271f669d3b315930422f c530a75c1e6a472b0eb9558310b518f0dfcd8860 501de8146d4fda1d423cd935316661746bdb750b d0d8ad39ecb51cd7497cd524484fe09f50876798 dbf360567a7da50db4d2f9bde4649aba21aa8106
Re: [Xen-devel] [PATCH livepatch-python 1/1] livepatch: Add python bindings for livepatch operations
On Thu, Aug 15, 2019 at 11:36:46AM +, Pawel Wieczorkiewicz wrote:
> Extend the XC python bindings library to support also all common
> livepatch operations and actions.
>
> Add the python bindings for the following operations:
> - status (pyxc_livepatch_status):
> Requires a payload name as an input.
> Returns a status dict containing a state string and a return code
> integer.
> - action (pyxc_livepatch_action):
> Requires a payload name and an action id as an input. Timeout and
> flags are optional parameters.
> Returns a return code integer.
> - upload (pyxc_livepatch_upload):
> Requires a payload name and a module's filename as an input.
> Returns a return code integer.
> - list (pyxc_livepatch_list):
> Takes no parameters.
> Returns a list of dicts containing each payload's:
> * name as a string
> * state as a string
> * return code as an integer
> * list of metadata key=value strings
>
> Each functions throws an exception error based on the errno value
> received from its corresponding libxc function call.
>
> Signed-off-by: Pawel Wieczorkiewicz
> Reviewed-by: Martin Mazein
> Reviewed-by: Andra-Irina Paraschiv
> Reviewed-by: Leonard Foerster
> Reviewed-by: Norbert Manthey
> ---
> tools/python/xen/lowlevel/xc/xc.c | 273
> ++
> 1 file changed, 273 insertions(+)
>
> diff --git a/tools/python/xen/lowlevel/xc/xc.c
> b/tools/python/xen/lowlevel/xc/xc.c
> index 5459d6834d..87e3b8cacc 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -2008,6 +2008,230 @@ static PyObject *pyflask_access(PyObject *self,
> PyObject *args,
> return Py_BuildValue("i",ret);
> }
>
> +static PyObject *pyxc_livepatch_status(XcObject *self,
> + PyObject *args,
> + PyObject *kwds)
> +{
> +xen_livepatch_status_t status;
> +PyObject *info_dict = NULL;
> +char *name;
> +int rc;
> +
> +static char *kwd_list[] = { "name", NULL };
> +
> +if ( !PyArg_ParseTupleAndKeywords(args, kwds, "s", kwd_list, ) )
> +goto error;
> +
> +rc = xc_livepatch_get(self->xc_handle, name, );
> +if ( rc )
> +goto error;
> +
> +info_dict = Py_BuildValue(
> +"{s:i,s:i}",
> +"state",status.state,
> +"rc", status.rc);
> +
> +error:
> +return info_dict ?: pyxc_error_to_exception(self->xc_handle);
> +}
> +
> +static PyObject *pyxc_livepatch_action(XcObject *self,
> + PyObject *args,
> + PyObject *kwds)
> +{
> +int (*action_func)(xc_interface *xch, char *name, uint32_t timeout,
> uint64_t flags);
This makes it dependent on "livepatch: Allow to override inter-modules
buildid dependency" patch. Since it's part of a different series, if
there is going to be v2, please name the dependency explicitly in the
commit message or at least after ---.
> +char *name;
> +unsigned int action;
> +uint32_t timeout;
> +uint64_t flags;
> +int rc;
> +
> +static char *kwd_list[] = { "name", "action", "timeout", "flags", NULL };
> +
> +if ( !PyArg_ParseTupleAndKeywords(args, kwds, "sI|Ik", kwd_list,
> + , , , ) )
> +goto error;
> +
> +switch (action)
> +{
> +case LIVEPATCH_ACTION_UNLOAD:
> +action_func = xc_livepatch_unload;
> +break;
> +case LIVEPATCH_ACTION_REVERT:
> +action_func = xc_livepatch_revert;
> +break;
> +case LIVEPATCH_ACTION_APPLY:
> +action_func = xc_livepatch_apply;
> +break;
> +case LIVEPATCH_ACTION_REPLACE:
> +action_func = xc_livepatch_replace;
> +break;
> +default:
> +goto error;
> +}
> +
> +rc = action_func(self->xc_handle, name, timeout, flags);
> +if ( rc )
> +goto error;
> +
> +return Py_BuildValue("i", rc);
> +error:
> +return pyxc_error_to_exception(self->xc_handle);
> +}
> +
> +static PyObject *pyxc_livepatch_upload(XcObject *self,
> + PyObject *args,
> + PyObject *kwds)
> +{
> +unsigned char *fbuf = MAP_FAILED;
> +char *name, *filename;
> +struct stat buf;
> +int fd = 0, rc;
> +ssize_t len;
> +
> +static char *kwd_list[] = { "name", "filename", NULL };
> +
> +if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ss", kwd_list,
> + , ))
It would be nice to support Path-like objects on python >= 3.6. See
note about "s" format here:
https://docs.python.org/3/c-api/arg.html#strings-and-buffers
But since it's python 3 only, that would need to be under #if
PY_MAJOR_VERSION >= 3.
> +goto error;
> +
> +fd = open(filename, O_RDONLY);
> +if ( fd < 0 )
> +goto error;
> +
> +if ( stat(filename, ) != 0 )
> +goto error;
>
Re: [Xen-devel] [PATCH v3 6/6] xen/arm: add dom0less device assignment info to docs
On Fri, 9 Aug 2019, Julien Grall wrote:
> Hi Stefano,
>
> I figured out I may want to read the docs before looking at the code :).
>
> On 09/08/2019 00:12, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v3:
> > - add nr_spis
> > - change description of interrupts and interrupt-parent
> >
> > Changes in v2:
> > - device tree fragment loaded in cacheable memory
> > - rename multiboot,dtb to multiboot,device-tree
> > - rename "path" to "xen,path"
> > - add a note about device memory mapping
> > - introduce xen,reg
> > - specify only the GIC is supported
> > ---
> > docs/misc/arm/device-tree/booting.txt | 117 ++
> > 1 file changed, 117 insertions(+)
> >
> > diff --git a/docs/misc/arm/device-tree/booting.txt
> > b/docs/misc/arm/device-tree/booting.txt
> > index 317a9e962a..ec2f7ba605 100644
> > --- a/docs/misc/arm/device-tree/booting.txt
> > +++ b/docs/misc/arm/device-tree/booting.txt
> > @@ -148,6 +148,12 @@ with the following properties:
> > An empty property to enable/disable a virtual pl011 for the guest to
> > use.
> > +- nr_spis
> > +Optional. A 32-bit integer specifying the number of SPIs (shared
> > +perhiperal interrupts) to allocate for the domain. If nr_spis is
>
> s/perhiperal/peripheral/. Also can you uppercase the first letter of each
> wording as you are spelling out an acronym?
OK
> > +missing, the max number of SPIs supported by the physical GIC is
> > +used.
> > +
> > - #address-cells and #size-cells
> > Both #address-cells and #size-cells need to be specified because
> > @@ -226,3 +232,114 @@ chosen {
> > };
> > };
> > };
> > +
> > +
> > +Device Assignment
> > +=
>
> Couldn't we just extend the file misc/arm/passthrough.txt? After all there
> should be no major difference between the two.
Do you mean instead of introducing this sub-chapter, or in addition? I
think it would be best if we avoid any duplication of information with
docs/misc/arm/passthrough.txt by referencing
docs/misc/arm/passthrough.txt as much as possible. But I would keep the
dom0less device assignment details here. I tried to do that in this
patch by only providing examples and details about the differences
compared to docs/misc/arm/passthrough.txt (xen,path, xen,reg, interrupt
mapping) here in booting.txt.
> > +
> > +Device Assignment (Passthrough) is supported by adding another module,
> > +alongside the kernel and ramdisk, with the device tree fragment
> > +corresponding to the device node to assign to the guest.
> > +
> > +The dtb sub-node should have the following properties:
> > +
> > +- compatible
> > +
> > +"multiboot,device-tree"
>
> Can we follow the convention for dom0? I.e you always have to pass
> "multiboot,module"? And probably suggest an order if the compatible
> "multiboot,device-tree" is not specified.
>
> This would help to keep everything similar between dom0 and domU. Longer term,
> I would love to see Dom0 described exactly the same way as domU.
Yes, I think it is a good idea.
> You would need to do the same update for multiboot,{kernel, ramdisk}.
OK, I'll do it in this patch
> > +
> > +- reg
> > +
> > +Specifies the physical address of the device tree binary fragment
> > +RAM and its length.
> > +
> > +As an example:
> > +
> > +module@0xc00 {
> > +compatible = "multiboot,device-tree", "multiboot,module";
> > +reg = <0x0 0xc00 0xff>;
> > +};
> > +
> > +The DTB fragment is loaded in cacheable memory, at 0xc00 in the
> > +example above. It should follow the convention explained in
>
> This is a bit confusing, how does the user know that 0xc000 is cachable
> memory? Also why you do mention it for device-tree and not kernel and
> initramfs?
That is a mistake, sorry. I'll remove it as it doesn't add useful
information and it is confusing.
> > +docs/misc/arm/passthrough.txt. The DTB fragment will be added to the
> > +guest device tree, so that the guest kernel will be able to discover the
> > +device.
> > +
> > +In addition, the following properties for each device node in the device
> > +tree fragment will be used for the device assignment setup:
> > +
> > +- xen,reg
> > +
> > + The xen,reg property is an array of:
> > +
> > +
> > +
> > + They specify the physical address and size of the device memory
> > + ranges together with the corresponding guest address to map them to.
> > + The size of `phys_addr' and `guest_addr' is determined by
> > + #address_cells; the size of `size' is determined by #size_cells.
> > + The memory will be mapped as device memory in the guest
> > + (p2m_mmio_direct_dev).
> > +
> > +- xen,path
> > +
> > + A new string property named "xen,path" holds the path in the host device
> > + tree to the corresponding device node.
> > +
> > +Please note that for GIC interrupts, the interrupts and interrupt-parent
> > +device tree properties
Re: [Xen-devel] [PATCH v3 5/6] xen/arm: introduce nr_spis
On Fri, 9 Aug 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 8/9/19 12:12 AM, Stefano Stabellini wrote:
> > We don't have a clear way to know how many virtual SPIs we need for the
> > boot domains. Introduce a new option under xen,domain to specify the
> > number of SPIs to allocate for the domain.
> >
> > The property is optional, when absent, we'll use the physical number of
> > gic lines for dom0less domains, just like for dom0. Given that dom0less
> > VMs are meant for static partitioning scenarios where the number of VMs
> > is very low, increased memory overhead should not be a problem, and it
> > is possible to minimizing it by using "nr_spis".
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - improve commit message
> > - introduce nr_spis
> > ---
> > xen/arch/arm/domain_build.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 0057a509d1..fc4e5bc4ca 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2270,7 +2270,6 @@ void __init create_domUs(void)
> > struct domain *d;
> > struct xen_domctl_createdomain d_cfg = {
> > .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
> > -.arch.nr_spis = 0,
> > .flags = XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap,
> > .max_evtchn_port = -1,
> > .max_grant_frames = 64,
> > @@ -2280,13 +2279,13 @@ void __init create_domUs(void)
> > if ( !dt_device_is_compatible(node, "xen,domain") )
> > continue;
> > -if ( dt_property_read_bool(node, "vpl011") )
> > -d_cfg.arch.nr_spis = GUEST_VPL011_SPI - 32 + 1;
> > -
>
> This change is not specified in the commit message nor the documentation.
I'll add a reference in the commit message.
> This will likely lead to some issues if the number of SPIs programmed (either
> from the DT or the Hardware) is smaller than the the SPI here.
>
> Furthemore, it is important to write down in the documentation that the SPI
> used by vpl011 may clash with a device interrupt routed to the guest.
Good points, I'll add those info to the docs.
> > if ( !dt_property_read_u32(node, "cpus", _cfg.max_vcpus) )
> > panic("Missing property 'cpus' for domain %s\n",
> > dt_node_name(node));
> > +if ( !dt_property_read_u32(node, "nr_spis", _cfg.arch.nr_spis)
> > )
> > +d_cfg.arch.nr_spis = gic_number_lines() - 32;
> > +
> > d = domain_create(++max_init_domid, _cfg, false);
> > if ( IS_ERR(d) )
> > panic("Error creating domain %s\n", dt_node_name(node));
> >
>
> Cheers,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 140340: regressions - FAIL
flight 140340 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/140340/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 139829 Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-pair 26 leak-check/check/src_host fail pass in 140277 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139829 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139829 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt b437b50bbcb063076906932dd782b1360709bdc9 baseline version: libvirt 086764748e1a6b9aaf968db68145e05837eae3bd Last test of basis 139829 2019-08-08 04:19:02 Z 11 days Failing since139853 2019-08-09 04:24:11 Z 10 days 11 attempts Testing same since 140277 2019-08-18 04:19:40 Z1 days2 attempts People who touched revisions under test: Andrea Bolognani Daniel Henrique Barboza Daniel P. Berrangé Eric Blake Han Han He Xin hexin Ilias Stamatis Jiri Denemark Ján Tomko Laine Stump Liu Qi Marc-André Lureau Maxiwell S. Garcia Menno Lageman Michal Privoznik Paolo Bonzini Peter Krempa Roman Bolshakov Wim ten Have Zhang Yu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair fail test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd 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
Re: [Xen-devel] [PATCH v3 2/6] xen/arm: copy dtb fragment to guest dtb
On Fri, 9 Aug 2019, Julien Grall wrote:
> On 8/9/19 12:12 AM, Stefano Stabellini wrote:
> > Read the dtb fragment corresponding to a passthrough device from memory
> > at the location referred to by the "multiboot,dtb" compatible node.
> >
> > Copy the fragment to the guest dtb.
> >
> > Add a dtb_bootmodule field to struct kernel_info to find the dtb
> > fragment for a guest.
> >
> > Some of the code below is taken from tools/libxl/libxl_arm.c. Note that
> > it is OK to take LGPL 2.1 code and including it into a GPLv2 code base.
> > The result is GPLv2 code.
> >
> > Signed-off-by: Stefano Stabellini
> >
> >
> > Changes in v3:
> > - switch to using device_tree_for_each_node for the copy
> >
> > Changes in v2:
> > - add a note about the code coming from libxl in the commit message
> > - copy /aliases
> > - code style
> > ---
> > xen/arch/arm/domain_build.c | 103 +++
> > xen/include/asm-arm/kernel.h | 2 +-
> > 2 files changed, 104 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 00ddb3b05d..70bcdc449d 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1706,6 +1707,102 @@ static int __init make_vpl011_uart_node(const struct
> > domain *d, void *fdt)
> > }
> > #endif
> > +static int __init handle_properties(struct domain *d, void *fdt, const
> > void *pfdt, int nodeoff,
> > +u32 address_cells, u32 size_cells)
>
> So in this file we already have a function call write_properties. How a user
> will know which one to use?
I have renamed handle_properties to handle_prop_pfdt, to make it clear
that this one is specific to partial device tree fragments.
> It is also not entirely clear from there variable name what is the difference
> between fdt and pfdt.
I have clarified and reduced the list of parameters by passing a kinfo
instead of domain and fdt separately.
> Also, no more u32 in the code please. This is now part of the CODING_STYLE.
Interesting, I haven't been following. Should I use uint32_t? What's the
recommended practice for fixed sized integers now?
> > +{
> > +int propoff, nameoff, r;
>
> Please no single letter variable unless this is obvious to understand (such as
> i, j for iteration). This should be ret, rc or res.
>
> Note that somehow you are using the 3 of them in the same patches... I am not
> going to ask for consistency thought.
OK
> > +const struct fdt_property *prop;
> > +
> > +for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
> > + propoff >= 0;
> > + propoff = fdt_next_property_offset(pfdt, propoff) )
> > +{
> > +
> > +if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
> > +return -FDT_ERR_INTERNAL;
> > +
> > +nameoff = fdt32_to_cpu(prop->nameoff);
> > +r = fdt_property(fdt, fdt_string(pfdt, nameoff),
> > + prop->data, fdt32_to_cpu(prop->len));
> > +if ( r )
> > +return r;
> > +}
> > +
> > +/* FDT_ERR_NOTFOUND => There is no more properties for this node */
> > +return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
> > +}
> > +
> > +static int __init scan_pt_node(const void *pfdt,
> > + int nodeoff, const char *name, int depth,
> > + u32 address_cells, u32 size_cells,
>
> Same here.
>
> > + void *data)
> > +{
> > +int rc;
> > +int i, num;
>
> Anything that can't be negative, should be unsigned.
OK
> > +struct kernel_info *kinfo = data;
> > +void *fdt = kinfo->fdt;
> > +int depth_next = depth;
> > +int node_next;
> > +
> > +/* no need to parse initial node */
> > +if ( !depth )
> > +return 0;
>
> So this is going to copy what ever is in the partial device-tree. In other
> word, the users can override pretty much anything that Xen created. I don't
> think this is what we want.
>
> Instead, we should only copy nodes under /passthrough and also the /aliases.
Very good point! I'll fix it.
> > +
> > +rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
>
> fdt_begin_node assume the second parameter will be non-NULL. What if
> fdt_get_name() returns NULL?
I'll add a check.
> > +if ( rc )
> > +return rc;
> > +
> > +rc = handle_properties(kinfo->d, fdt, pfdt, nodeoff,
> > + address_cells, size_cells);
> > +if ( rc )
> > +return rc;
> > +
> > +node_next = fdt_next_node(pfdt, nodeoff, _next);
>
> What if node_next is invalid (i.e because it is negative)?
This goes away with the change described below.
> > +
> > +/*
> > + * If the next node is a sibling, then we need to call
> > + *
Re: [Xen-devel] [PATCH v3 4/6] xen/arm: handle "multiboot, device-tree" compatible nodes
On Fri, 9 Aug 2019, Volodymyr Babchuk wrote:
> Stefano Stabellini writes:
>
> > Detect "multiboot,device-tree" compatible nodes. Add them to the bootmod
> > array as BOOTMOD_GUEST_DTB. In kernel_probe, find the right
> > BOOTMOD_GUEST_DTB and store a pointer to it in dtb_bootmodule.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v2:
> > - rename BOOTMOD_DTB to BOOTMOD_GUEST_DTB
> > - rename multiboot,dtb to multiboot,device-tree
> > ---
> > xen/arch/arm/bootfdt.c | 2 ++
> > xen/arch/arm/kernel.c | 12 +++-
> > xen/arch/arm/setup.c| 1 +
> > xen/include/asm-arm/setup.h | 1 +
> > 4 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index 891b4b66ff..4ee1bc314e 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -205,6 +205,8 @@ static void __init process_multiboot_node(const void
> > *fdt, int node,
> > kind = BOOTMOD_RAMDISK;
> > else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
> > kind = BOOTMOD_XSM;
> > +else if ( fdt_node_check_compatible(fdt, node,
> > "multiboot,device-tree") == 0 )
> > +kind = BOOTMOD_GUEST_DTB;
> > else
> > kind = BOOTMOD_UNKNOWN;
> >
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index 389bef2afa..997a871f62 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -425,7 +425,7 @@ int __init kernel_probe(struct kernel_info *info,
> > struct bootmodule *mod = NULL;
> > struct bootcmdline *cmd = NULL;
> > struct dt_device_node *node;
> > -u64 kernel_addr, initrd_addr, size;
> > +u64 kernel_addr = 0, initrd_addr = 0, dtb_addr = 0, size;
> It is unclear for my why are you initialize those variables with 0
Good point, they are unnecessary
> > int rc;
> >
> > /* domain is NULL only for the hardware domain */
> > @@ -469,6 +469,16 @@ int __init kernel_probe(struct kernel_info *info,
> > info->initrd_bootmodule =
> > boot_module_find_by_addr_and_kind(
> > BOOTMOD_RAMDISK, initrd_addr);
> > }
> > +else if ( dt_device_is_compatible(node,
> > "multiboot,device-tree") )
> > +{
> > +u32 len;
> > +const __be32 *val;
> > +
> > +val = dt_get_property(node, "reg", );
> Do you need to check return value there?
I'll add a check
> > +dt_get_range(, node, _addr, );
> > +info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
> > +BOOTMOD_GUEST_DTB, dtb_addr);
> > +}
> > else
> > continue;
> > }
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 215746a5c3..f93a8bed04 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -347,6 +347,7 @@ const char * __init
> > boot_module_kind_as_string(bootmodule_kind kind)
> > case BOOTMOD_KERNEL: return "Kernel";
> > case BOOTMOD_RAMDISK: return "Ramdisk";
> > case BOOTMOD_XSM: return "XSM";
> > +case BOOTMOD_GUEST_DTB: return "DTB";
> > case BOOTMOD_UNKNOWN: return "Unknown";
> > default: BUG();
> > }
> > diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> > index 8bf3d5910a..5aaf07bf97 100644
> > --- a/xen/include/asm-arm/setup.h
> > +++ b/xen/include/asm-arm/setup.h
> > @@ -16,6 +16,7 @@ typedef enum {
> > BOOTMOD_KERNEL,
> > BOOTMOD_RAMDISK,
> > BOOTMOD_XSM,
> > +BOOTMOD_GUEST_DTB,
> > BOOTMOD_UNKNOWN
> > } bootmodule_kind;
>
>
> --
> Volodymyr Babchuk at EPAM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] xen/arm: copy dtb fragment to guest dtb
On Fri, 9 Aug 2019, Volodymyr Babchuk wrote:
> Stefano Stabellini writes:
>
> > Read the dtb fragment corresponding to a passthrough device from memory
> > at the location referred to by the "multiboot,dtb" compatible node.
> >
> > Copy the fragment to the guest dtb.
> >
> > Add a dtb_bootmodule field to struct kernel_info to find the dtb
> > fragment for a guest.
> >
> > Some of the code below is taken from tools/libxl/libxl_arm.c. Note that
> > it is OK to take LGPL 2.1 code and including it into a GPLv2 code base.
> > The result is GPLv2 code.
> >
> > Signed-off-by: Stefano Stabellini
> >
> >
> > Changes in v3:
> > - switch to using device_tree_for_each_node for the copy
> >
> > Changes in v2:
> > - add a note about the code coming from libxl in the commit message
> > - copy /aliases
> > - code style
> > ---
> > xen/arch/arm/domain_build.c | 103 +++
> > xen/include/asm-arm/kernel.h | 2 +-
> > 2 files changed, 104 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 00ddb3b05d..70bcdc449d 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1706,6 +1707,102 @@ static int __init make_vpl011_uart_node(const
> > struct domain *d, void *fdt)
> > }
> > #endif
> >
> > +static int __init handle_properties(struct domain *d, void *fdt, const
> > void *pfdt, int nodeoff,
> > +u32 address_cells, u32 size_cells)
> nitpicking: "handle_properties" is somewhat non-descriptive in context
> of this file. From this name it is hard to tell that this function
> copies properties of FDT node.
I'll rename it to handle_prop_pfdt: the important message to convey is
that it is a function to handle the properties of the partial device
tree.
> > +{
> > +int propoff, nameoff, r;
> > +const struct fdt_property *prop;
> > +
> > +for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
> > + propoff >= 0;
> > + propoff = fdt_next_property_offset(pfdt, propoff) )
> > +{
> > +
> Do you really need this empty line?
I'll remove it
> > +if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
> > +return -FDT_ERR_INTERNAL;
> > +
> > +nameoff = fdt32_to_cpu(prop->nameoff);
> > +r = fdt_property(fdt, fdt_string(pfdt, nameoff),
> > + prop->data, fdt32_to_cpu(prop->len));
> > +if ( r )
> > +return r;
> > +}
> > +
> > +/* FDT_ERR_NOTFOUND => There is no more properties for this node */
> > +return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
> > +}
> > +
> > +static int __init scan_pt_node(const void *pfdt,
> > + int nodeoff, const char *name, int depth,
> > + u32 address_cells, u32 size_cells,
> > + void *data)
> > +{
> > +int rc;
> > +int i, num;
> > +struct kernel_info *kinfo = data;
> > +void *fdt = kinfo->fdt;
> > +int depth_next = depth;
> > +int node_next;
> > +
> > +/* no need to parse initial node */
> > +if ( !depth )
> > +return 0;
> > +
> > +rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
> > +if ( rc )
> > +return rc;
> > +
> > +rc = handle_properties(kinfo->d, fdt, pfdt, nodeoff,
> > + address_cells, size_cells);
> > +if ( rc )
> > +return rc;
> > +
> > +node_next = fdt_next_node(pfdt, nodeoff, _next);
> > +
> > +/*
> > + * If the next node is a sibling, then we need to call
> > + * fdt_end_node once. If the next node is one level up, we need to
> > + * call it twice: once for us and the second time for our parent.
> > + * Both these two conditions are expressed together by depth -
> > + * depth_next + 1.
> > + *
> > + * If we reached the end of the device tree fragment, then it is
> > + * easy: we need to call fdt_end_node once for every level of depth
> > + * to close all open nodes.
> > + */
> > +if ( depth_next < 0 )
> > +num = depth;
> > +else
> > +num = depth - depth_next + 1;
> > +
> > +for ( i = 0; i < num; i++ )
> > +{
> > +rc = fdt_end_node(fdt);
> > +if ( rc )
> > +return rc;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +static int __init domain_handle_dtb_bootmodule(struct domain *d,
> > + struct kernel_info *kinfo)
> > +{
> > +void *pfdt;
> > +int res;
> > +
> > +pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
> > +kinfo->dtb_bootmodule->size);
> > +if ( pfdt == NULL )
> > +return -EFAULT;
> > +
> > +res = device_tree_for_each_node(pfdt, scan_pt_node, kinfo);
> > +
> >
Re: [Xen-devel] [PATCH v3 3/6] xen/arm: assign devices to boot domains
On Fri, 9 Aug 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 8/9/19 12:12 AM, Stefano Stabellini wrote:
> > Scan the user provided dtb fragment at boot. For each device node, map
> > memory to guests, and route interrupts and setup the iommu.
> >
> > The iommu is setup by passing the node of the device to assign on the
> > host device tree. The path is specified in the device tree fragment as
> > the "xen,path" string property.
> >
> > The memory region to remap is specified by the "xen,reg" property.
> > (Perhaps it might be possible to use "range" instead of "xen,regs". This
>
> s/xen,regs/xen,reg/
>
> But I don't see how you could use range here... This is for translation
> address between two address-space.
I'll remove the comment
> > is something to investigate.)
> >
> > The interrupts are taken from the host device tree corresponding node.
> > To map the interrupt call handle_interrupts, which is shared with the
> > existing dom0 path.
> >
> > Add a interrupt-parent property automatically to the guest device tree
> > when the interrupt-parent should be the GIC. Copy over the interrupt
> > property from the host device tree node.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - improve commit message
> > - remove superfluous cast
> > - merge code with the copy code
> > - add interrup-parent
> > - demove depth > 2 check
> > - reuse code from handle_interrupts
> > - copy interrupts from host dt
> >
> > Changes in v2:
> > - rename "path" to "xen,path"
> > - grammar fix
> > - use gaddr_to_gfn and maddr_to_mfn
> > - remove depth <= 2 limitation in scanning the dtb fragment
> > - introduce and parse xen,reg
> > - code style
> > - support more than one interrupt per device
> > - specify only the GIC is supported
> > ---
> > xen/arch/arm/domain_build.c | 66 +
> > 1 file changed, 66 insertions(+)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 70bcdc449d..0057a509d1 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1712,6 +1712,9 @@ static int __init handle_properties(struct domain *d,
> > void *fdt, const void *pfd
> > {
> > int propoff, nameoff, r;
> > const struct fdt_property *prop;
> > +struct dt_device_node *node;
> > +const __be32 *cell;
> > +int i, len;
>
> Again any variable that can't be negative should be unsigned.
OK
> > for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
> > propoff >= 0;
> > @@ -1726,6 +1729,69 @@ static int __init handle_properties(struct domain *d,
> > void *fdt, const void *pfd
> >prop->data, fdt32_to_cpu(prop->len));
> > if ( r )
> > return r;
> > +
> > +if ( strcmp("xen,reg", fdt_string(pfdt, nameoff)) == 0 )
>
> This should be dt_prop_cmp. But this property should not be part of the guest
> DTB afterwards.
Good point!
> Lastly, a bit of documentation would be nice.
Do you mean an in-code comment, or a document somewhere?
> > +{
> > +paddr_t mstart, size, gstart;
> > +cell = (const __be32 *)prop->data;
> > +len = fdt32_to_cpu(prop->len) /
> > +((address_cells*2 + size_cells) * sizeof (u32));
> > +
> > +for ( i = 0; i < len; i++ )
> > +{
> > +mstart = dt_next_cell(address_cells, );
> > +size = dt_next_cell(size_cells, );
>
> Please use device_get_reg here.
OK (device_tree_get_reg)
> > +gstart = dt_next_cell(address_cells, );
> > +
> > +r = guest_physmap_add_entry(d, gaddr_to_gfn(gstart),
> > +maddr_to_mfn(mstart),
> > +get_order_from_bytes(size),
> > +p2m_mmio_direct_dev);
>
> The indentation is wrong.
I'll fix
> > +if ( r < 0 )
> > +{
> > +dprintk(XENLOG_ERR,
> > +"Failed to map %"PRIpaddr" to the guest
> > at%"PRIpaddr"\n",
> > +mstart, gstart);
> > +return -EFAULT;
> > +}
> > +}
> > +}
> > +
> > +if ( strcmp("xen,path", fdt_string(pfdt, nameoff)) == 0 )
>
> Same remark as for "xen,reg".
OK
> > +{
> > +node = dt_find_node_by_path(prop->data);
> > +if ( node != NULL )
> > +r = iommu_assign_dt_device(d, node);
> > +else
> > +{
> > +dprintk(XENLOG_ERR, "Couldn't find node %s in host_dt!\n",
> > +(char *)prop->data);
> > +return -EINVAL;
> > +}
> > +
> > +r = handle_interrupts(d, node, true);
> > +if ( r < 0 )
> > +return r;
> > +if ( r > 0 )
> > +{
> > +unsigned int intlen;
> > +
Re: [Xen-devel] [PATCH v3 4/6] xen/arm: handle "multiboot, device-tree" compatible nodes
On Fri, 9 Aug 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 8/9/19 12:12 AM, Stefano Stabellini wrote:
> > Detect "multiboot,device-tree" compatible nodes. Add them to the bootmod
> > array as BOOTMOD_GUEST_DTB. In kernel_probe, find the right
> > BOOTMOD_GUEST_DTB and store a pointer to it in dtb_bootmodule.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v2:
> > - rename BOOTMOD_DTB to BOOTMOD_GUEST_DTB
> > - rename multiboot,dtb to multiboot,device-tree
> > ---
> > xen/arch/arm/bootfdt.c | 2 ++
> > xen/arch/arm/kernel.c | 12 +++-
> > xen/arch/arm/setup.c| 1 +
> > xen/include/asm-arm/setup.h | 1 +
> > 4 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index 891b4b66ff..4ee1bc314e 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -205,6 +205,8 @@ static void __init process_multiboot_node(const void
> > *fdt, int node,
> > kind = BOOTMOD_RAMDISK;
> > else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0
> > )
> > kind = BOOTMOD_XSM;
> > +else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree")
> > == 0 )
> > +kind = BOOTMOD_GUEST_DTB;
>
> AFAICT, this function will only be executed if the compatible multiboot,module
> or xen,multiboot-module is also present. But this is not documented in
> booting.txt.
That's a good point, I added it to the doc
> > else
> > kind = BOOTMOD_UNKNOWN;
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index 389bef2afa..997a871f62 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -425,7 +425,7 @@ int __init kernel_probe(struct kernel_info *info,
> > struct bootmodule *mod = NULL;
> > struct bootcmdline *cmd = NULL;
> > struct dt_device_node *node;
> > -u64 kernel_addr, initrd_addr, size;
> > +u64 kernel_addr = 0, initrd_addr = 0, dtb_addr = 0, size;
> > int rc;
> > /* domain is NULL only for the hardware domain */
> > @@ -469,6 +469,16 @@ int __init kernel_probe(struct kernel_info *info,
> > info->initrd_bootmodule =
> > boot_module_find_by_addr_and_kind(
> > BOOTMOD_RAMDISK, initrd_addr);
> > }
> > +else if ( dt_device_is_compatible(node,
> > "multiboot,device-tree") )
> > +{
> > +u32 len;
>
> No more u32. Please use uint32_t instead.
Ok, got it
> > +const __be32 *val;
> > +
> > +val = dt_get_property(node, "reg", );
> > +dt_get_range(, node, _addr, );
> > +info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
> > +BOOTMOD_GUEST_DTB, dtb_addr);
> > +}
> > else
> > continue;
> > }
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 215746a5c3..f93a8bed04 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -347,6 +347,7 @@ const char * __init
> > boot_module_kind_as_string(bootmodule_kind kind)
> > case BOOTMOD_KERNEL: return "Kernel";
> > case BOOTMOD_RAMDISK: return "Ramdisk";
> > case BOOTMOD_XSM: return "XSM";
> > +case BOOTMOD_GUEST_DTB: return "DTB";
> > case BOOTMOD_UNKNOWN: return "Unknown";
> > default: BUG();
> > }
> > diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> > index 8bf3d5910a..5aaf07bf97 100644
> > --- a/xen/include/asm-arm/setup.h
> > +++ b/xen/include/asm-arm/setup.h
> > @@ -16,6 +16,7 @@ typedef enum {
> > BOOTMOD_KERNEL,
> > BOOTMOD_RAMDISK,
> > BOOTMOD_XSM,
> > +BOOTMOD_GUEST_DTB,
> > BOOTMOD_UNKNOWN
> > } bootmodule_kind;
> >
>
> Cheers,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [qemu-s390x] [PATCH v7 33/42] exec: Replace device_endian with MemOp
On Mon, 19 Aug. 2019, 23:01 Richard Henderson,
wrote:
> On 8/19/19 11:29 AM, Paolo Bonzini wrote:
> > On 19/08/19 20:28, Paolo Bonzini wrote:
> >> On 16/08/19 12:12, Thomas Huth wrote:
> >>> This patch is *huge*, more than 800kB. It keeps being stuck in the the
> >>> filter of the qemu-s390x list each time you send it. Please:
> >>>
> >>> 1) Try to break it up in more digestible pieces, e.g. change only one
> >>> subsystem at a time (this is also better reviewable by people who are
> >>> interested in one area)
> >>
> >> This is not really possible, since the patch is basically a
> >> search-and-replace. You could perhaps use some magic
> >> ("DEVICE_MEMOP_ENDIAN" or something like that) to allow a split, but it
> >> would introduce more complication than anything else.
> >
> > I'm stupid, at this point of the series it _would_ be possible to split
> > the patch by subsystem. Still not sure it would be actually an
> advantage.
>
> It might be easier to review if we split by symbol, one rename per patch
> over
> the entire code base.
>
>
> r~
>
Or if we review your script (I assume this wasn't a manual change). I'm not
sure it's realistic to have review on the entire patch or patches.
Best regards,
Edgar
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] python: do not report handled EAGAIN error
match_watch_by_token() when returns an error, sets also exception within
python. This is generally the right thing to do, but when
xspy_read_watch() handle EAGAIN error internally, the exception needs to
be cleared. Otherwise it will fail like this:
xen.lowlevel.xs.Error: (11, 'Resource temporarily unavailable')
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
(...)
result = self.handle.read_watch()
SystemError: returned
a result with an error set
Fixes f6e1023412 "python: Extract registered watch search logic from
xspy_read_watch()"
Signed-off-by: Marek Marczykowski-Górecki
---
tools/python/xen/lowlevel/xs/xs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/python/xen/lowlevel/xs/xs.c
b/tools/python/xen/lowlevel/xs/xs.c
index ea50f86bc3..621039d7a7 100644
--- a/tools/python/xen/lowlevel/xs/xs.c
+++ b/tools/python/xen/lowlevel/xs/xs.c
@@ -531,6 +531,7 @@ again:
free(xsval);
if (!val && errno == EAGAIN) {
+PyErr_Clear();
goto again;
}
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 140351: regressions - FAIL
flight 140351 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140351/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140072 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 140238 pass in 140072 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail in 140238 pass in 140351 test-armhf-armhf-xl-vhd 10 debian-di-install fail in 140238 pass in 140351 test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail in 140301 pass in 140351 test-amd64-amd64-xl-pvshim 12 guest-startfail pass in 140238 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail pass in 140238 test-armhf-armhf-libvirt-raw 10 debian-di-install fail pass in 140238 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail pass in 140301 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 140238 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 140238 never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail in 140238 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
Re: [Xen-devel] [PATCH] x86/p2m: fix non-translated handling of iommu mappings
On Mon, Jul 22, 2019 at 8:33 AM Roger Pau Monne wrote:
>
> The current usage of need_iommu_pt_sync in p2m for non-translated
> guests is wrong because it doesn't correctly handle a relaxed PV
> hardware domain, that has need_sync set to false, but still need
> entries to be added from calls to {set/clear}_identity_p2m_entry.
>
> Adjust the code in guest_physmap_add_page to also check whether the
> domain has an iommu instead of whether it needs syncing or not in
> order to take a reference to a page to be mapped.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
> Cc: Paul Durrant
Tested-by: Roman Shaposhnik
> ---
> xen/arch/x86/mm/p2m.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index fef97c82f6..88a2430c8c 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -836,7 +836,7 @@ guest_physmap_add_page(struct domain *d, gfn_t gfn, mfn_t
> mfn,
> */
> for ( i = 0; i < (1UL << page_order); ++i, ++page )
> {
> -if ( !need_iommu_pt_sync(d) )
> +if ( !has_iommu_pt(d) )
> /* nothing */;
> else if ( get_page_and_type(page, d, PGT_writable_page) )
> put_page_and_type(page);
> @@ -1341,7 +1341,7 @@ int set_identity_p2m_entry(struct domain *d, unsigned
> long gfn_l,
>
> if ( !paging_mode_translate(p2m->domain) )
> {
> -if ( !need_iommu_pt_sync(d) )
> +if ( !has_iommu_pt(d) )
> return 0;
> return iommu_legacy_map(d, _dfn(gfn_l), _mfn(gfn_l), PAGE_ORDER_4K,
> IOMMUF_readable | IOMMUF_writable);
> @@ -1432,7 +1432,7 @@ int clear_identity_p2m_entry(struct domain *d, unsigned
> long gfn_l)
>
> if ( !paging_mode_translate(d) )
> {
> -if ( !need_iommu_pt_sync(d) )
> +if ( !has_iommu_pt(d) )
> return 0;
> return iommu_legacy_unmap(d, _dfn(gfn_l), PAGE_ORDER_4K);
> }
> --
> 2.20.1 (Apple Git-117)
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
On Mon, Aug 19, 2019 at 1:16 AM Roger Pau Monné wrote: > > On Sun, Aug 18, 2019 at 10:00:17PM -0700, Roman Shaposhnik wrote: > > Hi Roger! > > > > Some good news, some bad news ;-) > > > > Good news is that on the newer BIOS, your original patch seems to work fine. > > > > IOW, with newer BIOS: > > 1. without your original patch I see garbled screen > > 2. with your original patch everything boots normally. > > That would be my expectation. > > > Bad news is that with older BIOS, your original patch seems to either > > work or not depending on the BIOS some of the BIOS settings. > > > > IOW, with older BIOS: > > 1. without your original patch I see garbled screen (regardless of > > BIOS settings) > > 2. with your original patch AND resetting to a factory defaults of > > BIOS settings -- everything boots normally > > 3. when I load up our custom settings -- the only thing that can > > boot normally is the latest patch > > > > So, would it make sense and commit your original patch for now? This > > will unlock me with newer BIOSes on these boxes. > > I think so, can you please provide a tested-by to the patch: > > https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg01547.html Done. > Feel free to also note the weird behaviour you are seeing with this > box and firmware version. > > > As for the older BIOSes, I still feel that it would be great for Xen > > to boot more reliably -- especially since Xen 4.10 seems to be doing > > fine regardless of BIOS version and settings. > > > > What do you think? > > We could add a quirk for this fimrware version and hardware if we know > exactly what the issue is. Have you figured out if it's related to the > flush? ie: iommu_iotlb_flush vs iommu_iotlb_flush_all vs iommu_flush_all? I am actually at Open Source Summit in San Diego right now -- away from my lab. I'll try to capture as much data on Fri as possible when I come back. Please stay tuned. Thanks, Roman. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 140354: regressions - FAIL
flight 140354 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/140354/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 140251 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-examine 8 reboot fail like 140251 test-amd64-i386-xl-raw7 xen-boot fail like 140251 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail like 140251 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 140251 test-amd64-i386-xl-xsm7 xen-boot fail like 140251 test-amd64-i386-libvirt 7 xen-boot fail like 140251 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail like 140251 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail like 140251 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail like 140251 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail like 140251 test-amd64-i386-pair 10 xen-boot/src_hostfail like 140251 test-amd64-i386-pair 11 xen-boot/dst_hostfail like 140251 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-bootfail like 140251 test-amd64-i386-xl7 xen-boot fail like 140251 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail like 140251 test-amd64-i386-xl-shadow 7 xen-boot fail like 140251 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-bootfail like 140251 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail like 140251 test-amd64-i386-freebsd10-i386 7 xen-bootfail like 140251 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail like 140251 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail like 140251 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail like 140251 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail like 140251 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail like 140251 test-amd64-i386-libvirt-xsm 7 xen-boot fail like 140251 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail like 140251 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 140251 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail like 140251 test-amd64-i386-xl-pvshim 7 xen-boot fail like 140251 test-amd64-i386-freebsd10-amd64 7 xen-boot fail like 140251 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail like 140251 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail like 140251 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail like 140251 build-armhf-pvops 6 kernel-build fail like 140251 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 140251 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140251 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140251 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 140251 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check
Re: [Xen-devel] [PATCH 02/11] xen/arm: use dev_is_dma_coherent
Hi Christoph, On 8/16/19 2:00 PM, Christoph Hellwig wrote: Use the dma-noncoherent dev_is_dma_coherent helper instead of the home grown variant. It took me a bit of time to understand that dev->archdata.dma_coherent and dev->dma_coherent will always contain the same value. Would you mind it mention it in the commit message? Other than that: Reviewed-by: Julien Grall Signed-off-by: Christoph Hellwig Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 140307: regressions - FAIL
flight 140307 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140307/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which did not succeed, but are not blocking: test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linuxa5aa80588fcd5520ece36121c41b7d8e72245e33 baseline version: linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d Last test of basis 129313 2018-11-02 05:39:08 Z 290 days Failing since129412 2018-11-04 14:10:15 Z 287 days 203 attempts Testing same since 140202 2019-08-16 12:59:29 Z2 days3 attempts 2457 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf
Re: [Xen-devel] [PATCH 04/11] xen/arm: remove xen_dma_ops
Hi Christoph, On 8/16/19 2:00 PM, Christoph Hellwig wrote: arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no need for a pointer indirection. Signed-off-by: Christoph Hellwig Reviewed-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 1/8] xen/arm: pass node to device_tree_for_each_node
Hi,
On 8/17/19 1:29 AM, Stefano Stabellini wrote:
On Fri, 16 Aug 2019, Julien Grall wrote:
Hi,
On 16/08/2019 00:36, Stefano Stabellini wrote:
Add a new parameter to device_tree_for_each_node: node, the node to
start the search from. Passing 0 triggers the old behavior.
Here you say 0 triggers the old behavior but...
Set min_depth to depth of the current node + 1 to avoid scanning
siblings of the initial node passed as an argument.
Don't call func() on the parent node passed as an argument. Clarify the
change in the comment on top of the function.
... here you mention that the first node will be skipped. So the behavior is
now different and should be explained in the commit message why this is fine
to skip the root node.
Yes I'll update
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- fix code style
- don't call func() on the first node
Changes in v5:
- go back to v3
- code style improvement in acpi/boot.c
- improve comments and commit message
- increase min_depth to avoid parsing siblings
- replace for with do/while loop and increase min_depth to avoid
scanning siblings of the initial node
- pass only node, calculate depth
Changes in v3:
- improve commit message
- improve in-code comments
- improve code style
Changes in v2:
- new
---
xen/arch/arm/acpi/boot.c | 8 +---
xen/arch/arm/bootfdt.c| 34 --
xen/include/xen/device_tree.h | 6 +++---
3 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 9b29769a10..bf9c78b02c 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -246,9 +246,11 @@ int __init acpi_boot_table_init(void)
* - the device tree is not empty (it has more than just a /chosen
node)
* and ACPI has not been force enabled (acpi=force)
*/
-if ( param_acpi_off || ( !param_acpi_force
- &&
device_tree_for_each_node(device_tree_flattened,
- dt_scan_depth1_nodes,
NULL)))
+if ( param_acpi_off)
+goto disable;
+if ( !param_acpi_force &&
+ device_tree_for_each_node(device_tree_flattened, 0,
+ dt_scan_depth1_nodes, NULL) )
goto disable;
/*
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 891b4b66ff..f1614ef7fc 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -75,9 +75,10 @@ static u32 __init device_tree_get_u32(const void *fdt,
int node,
}
/**
- * device_tree_for_each_node - iterate over all device tree nodes
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
* @fdt: flat device tree.
- * @func: function to call for each node.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
* @data: data to pass to @func.
*
* Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
@@ -85,20 +86,18 @@ static u32 __init device_tree_get_u32(const void *fdt,
int node,
* Returns 0 if all nodes were iterated over successfully. If @func
* returns a value different from 0, that value is returned immediately.
*/
-int __init device_tree_for_each_node(const void *fdt,
+int __init device_tree_for_each_node(const void *fdt, int node,
device_tree_node_func func,
void *data)
{
-int node;
-int depth;
+int depth = fdt_node_depth(fdt, node);
Sorry I didn't spot this in the previous version. As I pointed out on v4 (and
you actually agreed!), you don't need the absolute depth...
You only need the relative depth. So this is a waste of processing as you have
to go through the FDT to calculate the depth.
This is not entirely critical so I would be willing to consider a patch on top
of this series.
I tried when I sent this version of the series, but I couldn't quite do
it that way. I wanted to get rid of the depth parameter to
device_tree_for_each_node, and we need to know the depth of the first
node passed as an argument to compare it with the depth of the next node
and figure out if it is at the same level or one level deeper.
fdt_next_node() will increment/decrement whichever depth you pass in
argument.
So if you pass 0, then any child of the node will be at depth 1. Any
node at the same level as the parent node will also be depth 0...
Therefore initializing depth to 0 and checking it is strictly positive
(i.e depth > 0) is enough for our use case.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform
On 8/6/19 10:14 PM, Amit Tomer wrote: Hi Hi, What are the consequences to change the interrupt parent? I am not entirely sure about it at the moment but looks like it controllers power domain for various devices like GPU, VPU and OTG etc. So, we may not be able to support these devices for XEN domains ? I haven't used the platform so I can't for sure know what can happen here. The risk is if all the power domains are turned off at boot, then Dom0 would not be able to turn them on. Therefore all the devices you listed may be unusable. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
Hi Christoph,
On 8/16/19 2:00 PM, Christoph Hellwig wrote:
+static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
+dma_addr_t dev_addr, unsigned long offset, size_t size,
+enum dma_data_direction dir, unsigned long attrs)
+{
+ unsigned long page_pfn = page_to_xen_pfn(page);
+ unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
+ unsigned long compound_pages =
+ (1<
The Arm version as a comment here. Could we retain it?
+ if (local)
+ dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
+ else
+ __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir,
attrs);
+}
+
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable
On 14.08.19 15:02, Andrew Cooper wrote: On 14/08/2019 13:51, George Dunlap wrote: On 8/7/19 5:03 PM, Jan Beulich wrote: Whatever we do in Xen, it'll only allow to work around that issue. An actual fix belongs in the kernel(s). For this reason I suppose what we're talking about here is a feature (from Xen's pov), not a bug fix. And it being a feature, it should preferably be coded in a way that's usable also going forward. FWIW, I agree with what I understand Jan to be saying: 1. It would be good to be able to disable FIFO event channels, but 2. Disabling them in Xen isn't really the right way to fix Amazon's issue. Rather, probably the soft reboot should reset the event channel state. Depends what you mean about "fix the issue". Amazon have real customer VMs in this situation which will break on a Xen old => new upgrade. Modifying Xen is the only rational option. They are also doing this in an upstream compatible manner (which is great). One way or another, Xen needs to gain this ability to work around broken-linux which is already in the field. As for the ideal way to fix this, this bug has existed in Linux longer than soft-reset has been a thing, and frankly, its still a gruesome hack. We need some interfaces which don't suck so terribly. ~Andrew Thanks, Andrew. I second those points. I have just sent v3 of this patch, mostly addressing comments from Jan. Have a look, and let me know if there are further tweaks you would rather see. Thanks. Cheers, Eslam ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 08/11] swiotlb-xen: use the same foreign page check everywhere
Hi Christoph, On 8/16/19 2:00 PM, Christoph Hellwig wrote: xen_dma_map_page uses a different and more complicated check for foreign pages than the other three cache maintainance helpers. Switch it to the simpler pfn_vali method a well. NIT: s/pfn_vali/pfn_valid/ Signed-off-by: Christoph Hellwig Reviewed-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 2/8] xen/arm: make process_memory_node a device_tree_node_func
On 8/17/19 1:48 AM, Stefano Stabellini wrote:
On Fri, 16 Aug 2019, Julien Grall wrote:
I think you are right, and honestly I was thinking about it while I
updated this patch. If I use -EINVAL, it would be the same return error
as the "invalid #address-cells or #size-cells". I just wanted to
double-check that it is OK for you.
We don't need to differentiate "invalid #{address, size}-cells" from
"zero size", so using the same errno is fine.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3] evtchn: Introduce a per-guest knob to control FIFO ABI
Support for FIFO event channel ABI was first introduced in Xen 4.4
(see 88910061ec6). Make this support tunable, since the choice of which
event channel ABI has implications for hibernation. Consider resuming a
pre Xen 4.4 hibernated Linux guest. During resume from hibernation, there
are two kernels involved: the "boot" kernel and the "resume" kernel. The
guest boot kernel may default to FIFO ABI and instruct Xen via an
EVTCHNOP_init_control to switch from 2L to FIFO. On the other hand, the
resume kernel keeps assuming 2L. This, in turn, results in Xen and the
resumed kernel talking past each other (due to different protocols FIFO
vs 2L). A knob to control the support level for event channel ABIs per
guest would allow an administrator to work around this issue. This patch
introduces this knob.
In order to announce to guests that the event channel ABI does not support
FIFO, the hypervisor returns EPERM on init_control operation. When this
operation fails, the guest should continue to use the 2L event channel ABI.
For example, in Linux drivers/xen/events/events_base.c:
if (fifo_events)
ret = xen_evtchn_fifo_init();
if (ret < 0)
xen_evtchn_2l_init();
and xen_evtchn_fifo_init fails when EVTCHNOP_init_control fails. This commit
does not change the current default behaviour: announce FIFO event channels
ABI support for guests unless explicitly stated otherwise at domaincreate.
Signed-off-by: Eslam Elnikety
---
Changes in v2:
- Reworded the commit message
- Return EPERM instead of ENOSYS when forcing 2L ABI
- Use d->options instead of replicating the flag
Changes in v3:
- Reworded the commit subject
- Check at evtchn_fifo_init_control, rather than EVTCHNOP_init_control
---
docs/man/xl.cfg.5.pod.in| 5 +
tools/libxl/libxl.h | 8
tools/libxl/libxl_create.c | 5 +
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_parse.c | 2 ++
tools/xl/xl_sxp.c | 2 ++
xen/common/event_channel.c | 1 +
xen/common/event_fifo.c | 4
xen/include/public/domctl.h | 3 +++
9 files changed, 31 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c99d40307e..f204d8b4f0 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1262,6 +1262,11 @@ FIFO-based event channel ABI support up to 131,071 event
channels.
Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
x86).
+=item B
+
+Indicates if support for FIFO event channel ABI is disabled. The default
+is false (0).
+
=item B
Specifies the virtual display devices to be provided to the guest.
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 9bacfb97f0..9ee80d74a6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -169,6 +169,14 @@
*/
#define LIBXL_HAVE_BUILDINFO_EVENT_CHANNELS 1
+/*
+ * LIBXL_HAVE_BUILDINFO_DISABLE_EVTCHN_FIFO indicates that the
+ * libxl_domain_build_info structure contains a boolean
+ * disable_evtchn_fifo which instructs libxl to enable/disable
+ * support for FIFO event channel ABI at create time.
+ */
+#define LIBXL_HAVE_BUILDINFO_DISABLE_EVTCHN_FIFO 1
+
/*
* libxl_domain_build_info has the u.hvm.ms_vm_genid field.
*/
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 03ce166f4f..aa87e45643 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -217,6 +217,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
if (!b_info->event_channels)
b_info->event_channels = 1023;
+libxl_defbool_setdefault(_info->disable_evtchn_fifo, false);
+
libxl__arch_domain_build_info_setdefault(gc, b_info);
libxl_defbool_setdefault(_info->dm_restrict, false);
@@ -564,6 +566,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config
*d_config,
libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
}
+if (libxl_defbool_val(b_info->disable_evtchn_fifo))
+create.flags |= XEN_DOMCTL_CDF_disable_fifo;
+
/* Ultimately, handle is an array of 16 uint8_t, same as uuid */
libxl_uuid_copy(ctx, (libxl_uuid *), >uuid);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b61399ce36..5f30570443 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -521,6 +521,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("iomem",Array(libxl_iomem_range, "num_iomem")),
("claim_mode", libxl_defbool),
("event_channels", uint32),
+("disable_evtchn_fifo", libxl_defbool),
("kernel", string),
("cmdline", string),
("ramdisk", string),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index e105bda2bb..bcf16c31d4 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1496,6 +1496,8 @@ void parse_config_data(const char *config_source,
if (!xlu_cfg_get_long(config,
Re: [Xen-devel] [PATCH] x86/pv: Clean up cr3 handling in arch_set_info_guest()
Hi Andrew, On 8/13/19 7:04 PM, Andrew Cooper wrote: On 24/01/2019 22:10, Andrew Cooper wrote: On 24/01/2019 21:42, Julien Grall wrote: Hi Andrew, On 12/21/18 1:46 PM, Andrew Cooper wrote: All of this code lives inside CONFIG_PV which means gfn == mfn, and the fill_ro_mpt() calls clearly show that the value is used untranslated. Change cr3_gfn to a suitably typed cr3_mfn, and replace get_page_from_gfn() with a straight mfn_to_page/get_page sequence, to avoid the implication that translation is going on. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Stefano Stabellini CC: Julien Grall Julien: This should simplify your "xen: Switch parameter in get_page_from_gfn to use typesafe gfn" patch. In particular, I did a doubletake at fill_ro_mpt(_mfn(gfn_x(cr3_gfn))); when reviewing it. I was looking at updating my patch and remembered you suggested to rebase on top of this. Do you have any plan to resend the patch? I'll see if I can find some time tomorrow. So maybe I was a little off ;) Better late than never I suppose. I nearly forgot that work :). Can you CC me on the patch when you send it? I will rebase my work on top of it. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86: Restore IA32_MISC_ENABLE on wakeup
On 19/08/2019 03:23, Michał Kowalczyk wrote: > diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S > index 7c6a2328d2..fcaa3eeaf1 100644 > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -85,7 +85,7 @@ trampoline_gdt: > .long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . > .popsection > > -GLOBAL(trampoline_misc_enable_off) > +GLOBAL(misc_enable_off) The overall change is fine, but why have you renamed this variable? Without the rename, the patch would be just the single hunk in wakeup.S and therefore easier to backport. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 13/15] x86/microcode: Synchronize late microcode loading
On 19/08/2019 02:25, Chao Gao wrote:
> This patch ports microcode improvement patches from linux kernel.
>
> Before you read any further: the early loading method is still the
> preferred one and you should always do that. The following patch is
> improving the late loading mechanism for long running jobs and cloud use
> cases.
>
> Gather all cores and serialize the microcode update on them by doing it
> one-by-one to make the late update process as reliable as possible and
> avoid potential issues caused by the microcode update.
>
> Signed-off-by: Chao Gao
> Tested-by: Chao Gao
> [linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
> [linux commit: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7]
> Cc: Kevin Tian
> Cc: Jun Nakajima
> Cc: Ashok Raj
> Cc: Borislav Petkov
> Cc: Thomas Gleixner
> Cc: Andrew Cooper
> Cc: Jan Beulich
> ---
> Changes in v9:
> - log __buildin_return_address(0) when timeout
> - divide CPUs into three logical sets and they will call different
> functions during ucode loading. The 'control thread' is chosen to
> coordinate ucode loading on all CPUs. Since only control thread would
> set 'loading_state', we can get rid of 'cmpxchg' stuff in v8.
> - s/rep_nop/cpu_relax
> - each thread updates its revision number itself
> - add XENLOG_ERR prefix for each line of multi-line log messages
>
> Changes in v8:
> - to support blocking #NMI handling during loading ucode
>* introduce a flag, 'loading_state', to mark the start or end of
> ucode loading.
>* use a bitmap for cpu callin since if cpu may stay in #NMI handling,
> there are two places for a cpu to call in. bitmap won't be counted
> twice.
>* don't wait for all CPUs callout, just wait for CPUs that perform the
> update. We have to do this because some threads may be stuck in NMI
> handling (where cannot reach the rendezvous).
> - emit a warning if the system stays in stop_machine context for more
> than 1s
> - comment that rdtsc is fine while loading an update
> - use cmpxchg() to avoid panic being called on multiple CPUs
> - Propagate revision number to other threads
> - refine comments and prompt messages
>
> Changes in v7:
> - Check whether 'timeout' is 0 rather than "<=0" since it is unsigned int.
> - reword the comment above microcode_update_cpu() to clearly state that
> one thread per core should do the update.
> ---
> xen/arch/x86/microcode.c | 289
> +++
> 1 file changed, 267 insertions(+), 22 deletions(-)
>
> diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
> index bdd9c9f..91f9e81 100644
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -30,18 +30,52 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
>
> +#include
> #include
> #include
> #include
> #include
>
> +/*
> + * Before performing a late microcode update on any thread, we
> + * rendezvous all cpus in stop_machine context. The timeout for
> + * waiting for cpu rendezvous is 30ms. It is the timeout used by
> + * live patching
> + */
> +#define MICROCODE_CALLIN_TIMEOUT_US 3
> +
> +/*
> + * Timeout for each thread to complete update is set to 1s. It is a
> + * conservative choice considering all possible interference.
> + */
> +#define MICROCODE_UPDATE_TIMEOUT_US 100
> +
> static module_t __initdata ucode_mod;
> static signed int __initdata ucode_mod_idx;
> static bool_t __initdata ucode_mod_forced;
> +static unsigned int nr_cores;
> +
> +/*
> + * These states help to coordinate CPUs during loading an update.
> + *
> + * The semantics of each state is as follow:
> + * - LOADING_PREPARE: initial state of 'loading_state'.
> + * - LOADING_CALLIN: CPUs are allowed to callin.
> + * - LOADING_ENTER: all CPUs have called in. Initiate ucode loading.
> + * - LOADING_EXIT: ucode loading is done or aborted.
> + */
> +static enum {
> +LOADING_PREPARE,
> +LOADING_CALLIN,
> +LOADING_ENTER,
> +LOADING_EXIT,
> +} loading_state;
>
> /*
> * If we scan the initramfs.cpio for the early microcode code
> @@ -190,6 +224,16 @@ static DEFINE_SPINLOCK(microcode_mutex);
> DEFINE_PER_CPU(struct cpu_signature, cpu_sig);
>
> /*
> + * Count the CPUs that have entered, exited the rendezvous and succeeded in
> + * microcode update during late microcode update respectively.
> + *
> + * Note that a bitmap is used for callin to allow cpu to set a bit multiple
> + * times. It is required to do busy-loop in #NMI handling.
> + */
> +static cpumask_t cpu_callin_map;
> +static atomic_t cpu_out, cpu_updated;
> +
> +/*
> * Return a patch that covers current CPU. If there are multiple patches,
> * return the one with the highest revision number. Return error If no
> * patch is found and an error occurs during the parsing process. Otherwise
> @@ -232,6 +276,34 @@ bool microcode_update_cache(struct microcode_patch
> *patch)
> return true;
> }
>
>
Re: [Xen-devel] [livepatch-build-tools part3 v2 3/3] create-diff-object: Strip all undefined entires of known size
On 16. Aug 2019, at 17:02, Ross Lagerwall mailto:ross.lagerw...@citrix.com>> wrote: On 8/8/19 1:51 PM, Pawel Wieczorkiewicz wrote: The patched ELF object file contains all sections and symbols as resulted from the compilation. However, certain symbols may not be copied over to the resulting object file, due to being unchanged or not included for other reasons. In such situation the resulting object file has the entire sections copied along (with all their entries unchanged), while some of the corresponding symbols are not copied along at all. This leads to having incorrect undefined (STN_UNDEF) entries in the final hotpatch ELF file. The newly added function livepatch_strip_undefined_elements() detects and removes all undefined RELA entries as well as their corresponding PROGBITS section entries. Since the sections may contain elements of unknown size (sh.sh_entsize == 0), perform the strip only on sections with well defined entry sizes. After replacing the stripped rela list, it is assumed that the next invocation of the kpatch_rebuild_rela_section_data() will adjust all section header parameters according to the current state. The code in this patch seems to be very similar (i.e. somewhat copy-and-pasted) to kpatch_regenerate_special_section() which prunes the rela list and rebuilds the corresponding text section according to the predicate should_keep_rela_group(). The intent of the function also seems to be the same (only keep elements that are needed). In what situations does the existing function not do the right thing? Can should_keep_rela_group() be updated instead? Yes, the code is largely based on the kpatch_regenerate_special_section(). However, the livepatch_strip_undefined_elements() and kpatch_regenerate_special_section() have different "granularity" and different scope. 1. Scope - livepatch_strip_undefined_elements(): all RELA sections - kpatch_regenerate_special_section(): special RELA sections 2. "granularity" - livepatch_strip_undefined_elements(): all relas to be checked - kpatch_regenerate_special_section(): all relas in a group are copied I think it should be possible to create a common function with the base functionality that could take most of the common code in and then be used from within both of the functions. However, I did not want to touch existing functionality and I am afraid the changes may result in a pretty convoluted code. If you think it is still worth it, I can give it a shot. Thanks, -- Ross Lagerwall Best Regards, Pawel Wieczorkiewicz Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86: Restore IA32_MISC_ENABLE on wakeup
On 8/19/19 11:04 AM, Andrew Cooper wrote: > On 19/08/2019 03:23, Michał Kowalczyk wrote: >> diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S >> index 7c6a2328d2..fcaa3eeaf1 100644 >> --- a/xen/arch/x86/boot/trampoline.S >> +++ b/xen/arch/x86/boot/trampoline.S >> @@ -85,7 +85,7 @@ trampoline_gdt: >> .long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . >> .popsection >> >> -GLOBAL(trampoline_misc_enable_off) >> +GLOBAL(misc_enable_off) > The overall change is fine, but why have you renamed this variable? The old name had "trampoline_" prefix because the only place where it was used was trampoline_protmode_entry in arch/x86/boot/trampoline.S. Now it's also used in the wakeup code, so I removed the prefix which could be (IMO) misleading. > Without the rename, the patch would be just the single hunk in wakeup.S > and therefore easier to backport. True. Anyway, the decision is on your side, I can leave the old name if you prefer. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86: Restore IA32_MISC_ENABLE on wakeup
On 8/19/19 3:52 PM, Andrew Cooper wrote: > On 19/08/2019 14:50, Michał Kowalczyk wrote: >> On 8/19/19 11:04 AM, Andrew Cooper wrote: >>> On 19/08/2019 03:23, Michał Kowalczyk wrote: diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S index 7c6a2328d2..fcaa3eeaf1 100644 --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -85,7 +85,7 @@ trampoline_gdt: .long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . .popsection -GLOBAL(trampoline_misc_enable_off) +GLOBAL(misc_enable_off) >>> The overall change is fine, but why have you renamed this variable? >> The old name had "trampoline_" prefix because the only place where it >> was used was trampoline_protmode_entry in arch/x86/boot/trampoline.S. >> Now it's also used in the wakeup code, so I removed the prefix which >> could be (IMO) misleading. >>> Without the rename, the patch would be just the single hunk in wakeup.S >>> and therefore easier to backport. >> True. Anyway, the decision is on your side, I can leave the old name if >> you prefer. > The trampoline_ prefix indicates where the data lives, which is in the > 16 bit trampoline which contains both the AP boot path, and wakeup path. Ah, if this is the convention you use then we should leave the old name. > If you're happy with this, I can adjust on commit to avoid you sending a > second time. Would be great, thanks! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pv: Clean up cr3 handling in arch_set_info_guest()
On 19/08/2019 11:08, Julien Grall wrote: > Hi Andrew, > > On 8/13/19 7:04 PM, Andrew Cooper wrote: >> On 24/01/2019 22:10, Andrew Cooper wrote: >>> On 24/01/2019 21:42, Julien Grall wrote: Hi Andrew, On 12/21/18 1:46 PM, Andrew Cooper wrote: > All of this code lives inside CONFIG_PV which means gfn == mfn, > and the > fill_ro_mpt() calls clearly show that the value is used untranslated. > > Change cr3_gfn to a suitably typed cr3_mfn, and replace > get_page_from_gfn() > with a straight mfn_to_page/get_page sequence, to avoid the > implication that > translation is going on. > > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > CC: Stefano Stabellini > CC: Julien Grall > > Julien: This should simplify your "xen: Switch parameter in > get_page_from_gfn > to use typesafe gfn" patch. In particular, I did a doubletake at > fill_ro_mpt(_mfn(gfn_x(cr3_gfn))); when reviewing it. I was looking at updating my patch and remembered you suggested to rebase on top of this. Do you have any plan to resend the patch? >>> I'll see if I can find some time tomorrow. >> >> So maybe I was a little off ;) Better late than never I suppose. > > I nearly forgot that work :). Can you CC me on the patch when you send > it? I will rebase my work on top of it. I committed it when I sent this email. Rebase on staging and you're good. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/boot: Various bits of trampoline cleanup
Andrew Cooper (3): x86/boot: Further minor GDT corrections x86/boot: Reposition trampoline data x86/boot: Drop all use of lmsw xen/arch/x86/boot/head.S | 2 +- xen/arch/x86/boot/trampoline.S| 78 +-- xen/arch/x86/boot/wakeup.S| 5 ++- xen/arch/x86/x86_64/kexec_reloc.S | 4 +- 4 files changed, 40 insertions(+), 49 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/boot: Drop all use of lmsw
lmsw is an obsolete relic of the 286 processor - so much so that it even lacks intercept assistance on AMD processors. Use a plain mov to %cr0 which is easier to follow, certainly faster to virtualise on AMD hardware, and almost certainly a faster microcode path in real hardware. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/boot/trampoline.S | 12 ++-- xen/arch/x86/boot/wakeup.S | 5 +++-- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S index 1b11b4757a..89f841331d 100644 --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -54,9 +54,10 @@ GLOBAL(trampoline_realmode_entry) lidtbootsym(idt_48) lgdtbootsym(gdt_48) mov $1,%bl# EBX != 0 indicates we are an AP -xor %ax, %ax -inc %ax -lmsw%ax # CR0.PE = 1 (enter protected mode) + +mov $X86_CR0_PE, %eax +mov %eax, %cr0 + ljmpl $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6) .code32 @@ -252,9 +253,8 @@ trampoline_boot_cpu_entry: lgdtbootsym(gdt_48) /* Enter protected mode, and flush insn queue. */ -xor %ax,%ax -inc %ax -lmsw%ax # CR0.PE = 1 (enter protected mode) +mov $X86_CR0_PE, %eax +mov %eax, %cr0 /* Load proper protected-mode values into all segment registers. */ ljmpl $BOOT_CS32,$bootsym_rel(1f,6) diff --git a/xen/arch/x86/boot/wakeup.S b/xen/arch/x86/boot/wakeup.S index e3cb9e033a..2af6c6017c 100644 --- a/xen/arch/x86/boot/wakeup.S +++ b/xen/arch/x86/boot/wakeup.S @@ -51,8 +51,9 @@ ENTRY(wakeup_start) lidtwakesym(idt_48) lgdtwakesym(gdt_48) -movw$1, %ax -lmsw%ax # Turn on CR0.PE +mov $X86_CR0_PE, %eax +mov %eax, %cr0 + ljmpl $BOOT_CS32, $bootsym_rel(wakeup_32, 6) /* This code uses an extended set of video mode numbers. These include: -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/boot: Reposition trampoline data
... to separate code from data. In particular, trampoline_realmode_entry's write to trampoline_cpu_started clobbers the I-cache line containing trampoline_protmode_entry, which won't be great for AP startup. Reformat the comments for trampoline_gdt to reduce their volume. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/boot/trampoline.S | 67 ++ 1 file changed, 28 insertions(+), 39 deletions(-) diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S index 1761fc1213..1b11b4757a 100644 --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -59,45 +59,6 @@ GLOBAL(trampoline_realmode_entry) lmsw%ax # CR0.PE = 1 (enter protected mode) ljmpl $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6) -trampoline_gdt: -/* 0x: unused */ -.quad 0x -/* 0x0008: ring 0 code, 32-bit mode */ -.quad 0x00cf9b00 -/* 0x0010: ring 0 code, 64-bit mode */ -.quad 0x00af9b00 -/* 0x0018: ring 0 data */ -.quad 0x00cf9300 -/* 0x0020: real-mode code @ BOOT_TRAMPOLINE */ -.long 0x -.long 0x9b00 -/* 0x0028: real-mode data @ BOOT_TRAMPOLINE */ -.long 0x -.long 0x9300 -/* - * 0x0030: ring 0 Xen data, 16 MiB size, base - * address is computed at runtime. - */ -.quad 0x00c093000fff -.Ltramopline_gdt_end: - -.pushsection .trampoline_rel, "a" -.long trampoline_gdt + BOOT_PSEUDORM_CS + 2 - . -.long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . -.popsection - -GLOBAL(trampoline_misc_enable_off) -.quad 0 - -GLOBAL(cpuid_ext_features) -.long 0 - -GLOBAL(trampoline_xen_phys_start) -.long 0 - -GLOBAL(trampoline_cpu_started) -.byte 0 - .code32 trampoline_protmode_entry: /* Set up a few descriptors: on entry only CS is guaranteed good. */ @@ -186,6 +147,34 @@ idt_48: .word 0, 0, 0 # base = limit = 0 gdt_48: .word .Ltramopline_gdt_end - trampoline_gdt - 1 .long bootsym_rel(trampoline_gdt,4) +trampoline_gdt: +.quad 0x /* 0x: unused */ +.quad 0x00cf9b00 /* 0x0008: ring 0 code, 32-bit mode */ +.quad 0x00af9b00 /* 0x0010: ring 0 code, 64-bit mode */ +.quad 0x00cf9300 /* 0x0018: ring 0 data */ +.quad 0x9b00 /* 0x0020: real-mode code @ BOOT_TRAMPOLINE */ +.quad 0x9300 /* 0x0028: real-mode data @ BOOT_TRAMPOLINE */ +.quad 0x00c093000fff /* 0x0030: ring 0 Xen data, 16M @ XEN */ +.Ltramopline_gdt_end: + +/* Relocations for trampoline Real Mode segments. */ +.pushsection .trampoline_rel, "a" +.long trampoline_gdt + BOOT_PSEUDORM_CS + 2 - . +.long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . +.popsection + +GLOBAL(trampoline_misc_enable_off) +.quad 0 + +GLOBAL(cpuid_ext_features) +.long 0 + +GLOBAL(trampoline_xen_phys_start) +.long 0 + +GLOBAL(trampoline_cpu_started) +.byte 0 + /* The first page of trampoline is permanent, the rest boot-time only. */ /* Reuse the boot trampoline on the 1st trampoline page as stack for wakeup. */ .equwakeup_stack, trampoline_start + PAGE_SIZE -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/boot: Further minor GDT corrections
gdt_boot_descr and gdt_48 disagree on how long trampoline_gdt is. Introduce an end label and have the linker calculate the size, rather than hard coding it. Also, just as with c/s af292b41e9, there is no point forcing the CPU to set Access bits. Fix all remaining GDTs in Xen. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné The trampoline GDT access bits were actually noticed when trying to clean up our boot time pagetables and map the trampoline read-only. --- xen/arch/x86/boot/head.S | 2 +- xen/arch/x86/boot/trampoline.S| 15 --- xen/arch/x86/x86_64/kexec_reloc.S | 4 ++-- 3 files changed, 11 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 26b680521d..9fdb9b3954 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -129,7 +129,7 @@ multiboot2_header: .word 0 gdt_boot_descr: -.word 7*8-1 +.word .Ltramopline_gdt_end - trampoline_gdt - 1 gdt_boot_base: .long sym_offs(trampoline_gdt) .long 0 /* Needed for 64-bit lgdt */ diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S index 7c6a2328d2..1761fc1213 100644 --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -63,22 +63,23 @@ trampoline_gdt: /* 0x: unused */ .quad 0x /* 0x0008: ring 0 code, 32-bit mode */ -.quad 0x00cf9a00 +.quad 0x00cf9b00 /* 0x0010: ring 0 code, 64-bit mode */ -.quad 0x00af9a00 +.quad 0x00af9b00 /* 0x0018: ring 0 data */ -.quad 0x00cf9200 +.quad 0x00cf9300 /* 0x0020: real-mode code @ BOOT_TRAMPOLINE */ .long 0x -.long 0x9a00 +.long 0x9b00 /* 0x0028: real-mode data @ BOOT_TRAMPOLINE */ .long 0x -.long 0x9200 +.long 0x9300 /* * 0x0030: ring 0 Xen data, 16 MiB size, base * address is computed at runtime. */ -.quad 0x00c092000fff +.quad 0x00c093000fff +.Ltramopline_gdt_end: .pushsection .trampoline_rel, "a" .long trampoline_gdt + BOOT_PSEUDORM_CS + 2 - . @@ -182,7 +183,7 @@ start64: .word 0 idt_48: .word 0, 0, 0 # base = limit = 0 .word 0 -gdt_48: .word 6*8-1 +gdt_48: .word .Ltramopline_gdt_end - trampoline_gdt - 1 .long bootsym_rel(trampoline_gdt,4) /* The first page of trampoline is permanent, the rest boot-time only. */ diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S index 5bf61d5c2d..9e5b7a6ba1 100644 --- a/xen/arch/x86/x86_64/kexec_reloc.S +++ b/xen/arch/x86/x86_64/kexec_reloc.S @@ -182,8 +182,8 @@ compat_mode_gdt_desc: .align 8 compat_mode_gdt: .quad 0x /* null */ -.quad 0x00cf9200 /* 0x0008 ring 0 data*/ -.quad 0x00cf9a00 /* 0x0010 ring 0 code, compatibility */ +.quad 0x00cf9300 /* 0x0008 ring 0 data*/ +.quad 0x00cf9b00 /* 0x0010 ring 0 code, compatibility */ compat_mode_idt: .word 0 /* limit */ -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 01/14] xen/x86: Make mfn_to_gfn typesafe
> On Jul 29, 2019, at 1:13 PM, Julien Grall wrote: > > Hi, > > @George can I get an ack for this patch? > > Cheers, > > On 6/3/19 5:03 PM, Julien Grall wrote: >> No functional changes intended. >> Signed-off-by: Julien Grall Acked-by: George Dunlap Sorry for the delay. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86: Restore IA32_MISC_ENABLE on wakeup
On 19/08/2019 14:50, Michał Kowalczyk wrote: > On 8/19/19 11:04 AM, Andrew Cooper wrote: >> On 19/08/2019 03:23, Michał Kowalczyk wrote: >>> diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S >>> index 7c6a2328d2..fcaa3eeaf1 100644 >>> --- a/xen/arch/x86/boot/trampoline.S >>> +++ b/xen/arch/x86/boot/trampoline.S >>> @@ -85,7 +85,7 @@ trampoline_gdt: >>> .long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . >>> .popsection >>> >>> -GLOBAL(trampoline_misc_enable_off) >>> +GLOBAL(misc_enable_off) >> The overall change is fine, but why have you renamed this variable? > The old name had "trampoline_" prefix because the only place where it > was used was trampoline_protmode_entry in arch/x86/boot/trampoline.S. > Now it's also used in the wakeup code, so I removed the prefix which > could be (IMO) misleading. >> Without the rename, the patch would be just the single hunk in wakeup.S >> and therefore easier to backport. > True. Anyway, the decision is on your side, I can leave the old name if > you prefer. The trampoline_ prefix indicates where the data lives, which is in the 16 bit trampoline which contains both the AP boot path, and wakeup path. If you're happy with this, I can adjust on commit to avoid you sending a second time. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
