[Xen-devel] [linux-4.4 test] 142736: regressions - FAIL
flight 142736 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/142736/ 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 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142648 pass in 142736 test-amd64-amd64-xl-pvshim 12 guest-start fail in 142711 pass in 142736 test-armhf-armhf-libvirt-raw 7 xen-boot fail in 142711 pass in 142736 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142648 test-armhf-armhf-libvirt 7 xen-boot fail pass in 142711 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt13 migrate-support-check fail in 142648 never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail in 142648 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start 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-arm64-arm64-libvirt-xsm 7 xen-boot 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-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail 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-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-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-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-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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 test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail 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-arm64-arm64-xl 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-amd64-i386-xl-qemuu-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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-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
Re: [Xen-devel] [PATCH] xen/arm: remove special dom0 case in dump_hyp_walk
On 15.10.19 05:49, Stefano Stabellini wrote:
There is no need to have a special dom0 case to convert the pgtable
virtual address into a physical address. The virt_to_maddr function can
work both in the dom0 case and the domU case.
This is more than a cleanup: when Xen is loaded at addresses lower than
2MB on arm32 phys_offset might not hold the right value and be unable to
perform a virt to phys conversion properly. Reducing the unnecessary
usage of phys_offset is a good idea.
Link: https://marc.info/?l=xen-devel=157081398022401
Signed-off-by: Stefano Stabellini
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a6637ce347..b7883cfbab 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -284,10 +284,7 @@ void dump_hyp_walk(vaddr_t addr)
"on CPU%d via TTBR 0x%016"PRIx64"\n",
addr, smp_processor_id(), ttbr);
-if ( smp_processor_id() == 0 )
-BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != pgtable );
-else
-BUG_ON( virt_to_maddr(pgtable) != ttbr );
+BUG_ON( virt_to_maddr(pgtable) != ttbr );
dump_pt_walk(ttbr, addr, HYP_PT_ROOT_LEVEL, 1);
}
I can't make a connection between commit message ("special dom0 case")
and the code modification. The special case removed is about cpu 0, not
dom0.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/arm: remove special dom0 case in dump_hyp_walk
There is no need to have a special dom0 case to convert the pgtable virtual address into a physical address. The virt_to_maddr function can work both in the dom0 case and the domU case. This is more than a cleanup: when Xen is loaded at addresses lower than 2MB on arm32 phys_offset might not hold the right value and be unable to perform a virt to phys conversion properly. Reducing the unnecessary usage of phys_offset is a good idea. Link: https://marc.info/?l=xen-devel=157081398022401 Signed-off-by: Stefano Stabellini diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index a6637ce347..b7883cfbab 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -284,10 +284,7 @@ void dump_hyp_walk(vaddr_t addr) "on CPU%d via TTBR 0x%016"PRIx64"\n", addr, smp_processor_id(), ttbr); -if ( smp_processor_id() == 0 ) -BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != pgtable ); -else -BUG_ON( virt_to_maddr(pgtable) != ttbr ); +BUG_ON( virt_to_maddr(pgtable) != ttbr ); dump_pt_walk(ttbr, addr, HYP_PT_ROOT_LEVEL, 1); } ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure
> On Oct 11, 2019, at 07:11, Lars Kurth wrote: > > On 11/10/2019, 02:24, "Stefano Stabellini" wrote: > >>On Thu, 10 Oct 2019, Lars Kurth wrote: >> * Would we ever include API docs generated from GPLv2 code? E.g. for safety >> use-cases? >> @Stefano, @Artem: I guess this one is for you. >> I suppose if we would have a similar issue for a safety manual >> I am also assuming we would want to use sphinx docs and rst to generate a >> future safety manual > >Hi Lars, > >Thanks for putting this email together. > >In terms of formats, I don't have a preference between rst and pandoc, >but if we are going to use rst going forward, I'd say to try to use rst >for everything, including converting all the old stuff. The fewer >different formats, the better. > > I think the proposal that needs to follow on from this (which would at some > point need to be voted on) would then be to go for rst. > >As I mentioned during the FuSa call, I agree with you, Andrew, and >others that it would be best to have the docs under a CC license. I do >expect that we'll end up copy/pasting snippets of in-code comments into >the docs, so I think it is important that we are allowed to do that from >a license perspective. It is great that GPLv2 allows it (we need to be >sure about this). > > The GPL does *not* allow this, but (c) law and fair use clauses do. So > typically > stuff such as > * Referring to function names, signatures, etc. tend to be all fine > * Copying large portions of in-line comments would not be fine, but > If they are large, they would in most cases be re-written in a more suitable > language. > > So, I think overall, we should be fine. It's a bit of a grey area though. > > And as you point out below, most of the code in question is typically BSD > >Yes, I expect that some docs might be automatically generated, but from >header files, not from source code. Especailly public/ header files, >which are typically BSD, not GPLv2. I cannot come up with examples of >docs we need to generated from GPLv2-only code at the moment, hopefully >there won't be any. > > That makes things a lot easier. > >>I wasn't planning on reusing any of the markup, and wasn't expecting to >>use much of the text either. I'm still considering the option of >>defining that xen/public/* isn't the canonical description of the ABI, >>because C is the wrong tool for the job. >> >>Its fine to provide a C set of headers implementing an ABI, but there is >>a very deliberate reason why the canonical migration v2 spec is in a >>text document. >> >> @Stefano: as you and I believe Brian will be spending time on improving the >> ABI docs, I think we need to build some agreement here on what/how >> to do it. I was assuming that generally the consensus was to have >> docs close to the code in source, but this does not seem to be the case. >> >> But if we do have stuff separately, ideally we would have a tool that helps >> point people editing headers to also look at the relevant docs. Otherwise it >> will >> be hard to keep them in sync. > >In general, it is a good idea to keep the docs close to the code to make >it easier to keep them up to date. But there is no one-size-fits-all >here. For public ABI descriptions, I agree with Andrew that ideally they >should not be defined as C header files. > >But it is not an issue: any work that we do here won't be wasted. For >instance, we could start by adding more comments to the current header >files. Then, as a second step, take all the comments and turn them into >a proper ABI description document without any C function declarations. >It is easy to move English text around, as long as the license allows it >-- that is the only potential blocker I can see. > > This is likely to be problematic. First of all, we are talking about > BSD-3-Clause > or BSD-2-Clause code (the latter is more dominant in headers I believe) in > all known cases. > > The main properties of the BSD are > 1: Can be pretty much used anywhere for any purpose > 2: Can be modified for any purpose > 3: But the original license header must be retained in derivates This is equivalent to attribution of the copyright owner of the originally created file. > Does *not* have requirements around attribution as CC-BY-4: however, > as we store everything in git attribution is handled by us by default See above, the license header attributes copyright, since BSD was created for "software" and people who work on "software" would typically be looking at source code, hence the primary attribution takes place there, with secondary attribution in EULAs, "About" panels, etc. > CC-BY-4 also has properties 1-3 > In addition: it does require that > 4: Derived works are giving appropriate credit to authors >We could clarify in a COPYING how we prefer to do this >4.1: We could say
Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure
On Oct 11, 2019, at 07:11, Lars Kurth wrote: > > On 11/10/2019, 02:24, "Stefano Stabellini" wrote: > >>On Thu, 10 Oct 2019, Lars Kurth wrote: >> * Would we ever include API docs generated from GPLv2 code? E.g. for safety >> use-cases? >> @Stefano, @Artem: I guess this one is for you. >> I suppose if we would have a similar issue for a safety manual >> I am also assuming we would want to use sphinx docs and rst to generate a >> future safety manual > >Hi Lars, > >Thanks for putting this email together. > >In terms of formats, I don't have a preference between rst and pandoc, >but if we are going to use rst going forward, I'd say to try to use rst >for everything, including converting all the old stuff. The fewer >different formats, the better. > > I think the proposal that needs to follow on from this (which would at some > point need to be voted on) would then be to go for rst. > >As I mentioned during the FuSa call, I agree with you, Andrew, and >others that it would be best to have the docs under a CC license. I do >expect that we'll end up copy/pasting snippets of in-code comments into >the docs, so I think it is important that we are allowed to do that from >a license perspective. It is great that GPLv2 allows it (we need to be >sure about this). > > The GPL does *not* allow this, but (c) law and fair use clauses do. So > typically > stuff such as > * Referring to function names, signatures, etc. tend to be all fine > * Copying large portions of in-line comments would not be fine, but > If they are large, they would in most cases be re-written in a more suitable > language. > > So, I think overall, we should be fine. It's a bit of a grey area though. > > And as you point out below, most of the code in question is typically BSD > >Yes, I expect that some docs might be automatically generated, but from >header files, not from source code. Especailly public/ header files, >which are typically BSD, not GPLv2. I cannot come up with examples of >docs we need to generated from GPLv2-only code at the moment, hopefully >there won't be any. > > That makes things a lot easier. > >>I wasn't planning on reusing any of the markup, and wasn't expecting to >>use much of the text either. I'm still considering the option of >>defining that xen/public/* isn't the canonical description of the ABI, >>because C is the wrong tool for the job. >> >>Its fine to provide a C set of headers implementing an ABI, but there is >>a very deliberate reason why the canonical migration v2 spec is in a >>text document. >> >> @Stefano: as you and I believe Brian will be spending time on improving the >> ABI docs, I think we need to build some agreement here on what/how >> to do it. I was assuming that generally the consensus was to have >> docs close to the code in source, but this does not seem to be the case. >> >> But if we do have stuff separately, ideally we would have a tool that helps >> point people editing headers to also look at the relevant docs. Otherwise it >> will >> be hard to keep them in sync. > >In general, it is a good idea to keep the docs close to the code to make >it easier to keep them up to date. But there is no one-size-fits-all >here. For public ABI descriptions, I agree with Andrew that ideally they >should not be defined as C header files. > >But it is not an issue: any work that we do here won't be wasted. For >instance, we could start by adding more comments to the current header >files. Then, as a second step, take all the comments and turn them into >a proper ABI description document without any C function declarations. >It is easy to move English text around, as long as the license allows it >-- that is the only potential blocker I can see. > > This is likely to be problematic. First of all, we are talking about > BSD-3-Clause > or BSD-2-Clause code (the latter is more dominant in headers I believe) in > all known cases. > > The main properties of the BSD are > 1: Can be pretty much used anywhere for any purpose > 2: Can be modified for any purpose > 3: But the original license header must be retained in derivates This is equivalent to attribution of the copyright owner of the originally created file. > Does *not* have requirements around attribution as CC-BY-4: however, > as we store everything in git attribution is handled by us by default See above, the license header attributes copyright, since BSD was created for "software" and people who work on "software" would typically be looking at source code, hence the primary attribution takes place there, with secondary attribution in EULAs, "About" panels, etc. > CC-BY-4 also has properties 1-3 > In addition: it does require that > 4: Derived works are giving appropriate credit to authors >We could clarify in a COPYING how we prefer to do this >4.1: We could say
[Xen-devel] [linux-linus test] 142735: regressions - trouble: broken/fail/pass
flight 142735 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/142735/ 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-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-i386-qemuu-rhel6hvm-intel 4 host-install(4) broken REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 4 host-install(4) broken REGR. vs. 133580 test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 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-xl-qemut-stubdom-debianhvm-amd64-xsm 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-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 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-xl-qemuu-win10-i386 7 xen-boot fail 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-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-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-xl-qemut-ws16-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-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 17 guest-start.2fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: 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-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133580 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail 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 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-xsm 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-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-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 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
Re: [Xen-devel] [XEN PATCH v4 for-4.13 10/10] libxl/xl: Overhaul passthrough setting logic passthrough setting logic
On Mon, Oct 14, 2019 at 05:51:04PM +0100, Ian Jackson wrote: > --- > v4: Fix trailing whitespace > No longer change "unknown" to "unspecified". > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index 64bed30bce..7e220d0c20 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -660,6 +660,12 @@ in preference. However, the availability of this option > is hardware > specific. If B reports B containing > B then this option may be used. > > +=item B Don't forget to change the man page as well ;-). -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 00/20] hw: Clean up hw/i386 headers (and few alpha/hppa)
On 10/14/19 10:22 AM, Philippe Mathieu-Daudé wrote: > This is a follow-up of Markus's cleanup series: > Tame a few "touch this, recompile the world" > https://www.mail-archive.com/qemu-devel@nongnu.org/msg635748.html > > This part is mostly restricted to X86, but since some file from the > Alpha/PA-RISC machines include "hw/i386/pc.h" I had to fix them > too. > > Eventually I'll succeed at removing hw/i386/ dependency on non-X86 > platforms (Quest I started 2 years ago...). > > Regards, > > Phil. > > Philippe Mathieu-Daudé (20): > vl: Add missing "hw/boards.h" include > hw/southbridge/ich9: Removed unused headers > hw/input/pckbd: Remove unused "hw/i386/pc.h" header > hw/i386/ioapic_internal: Remove unused "hw/i386/ioapic.h" header > hw/timer: Remove unused "ui/console.h" header > hw/usb/dev-storage: Remove unused "ui/console.h" header > hw/i386/intel_iommu: Remove unused includes > hw/xen/xen_pt_load_rom: Remove unused includes > hw/alpha/alpha_sys: Remove unused "hw/ide.h" header > hw/alpha/dp264: Include "net/net.h" > hw/hppa/machine: Include "net/net.h" > hw/acpi/cpu_hotplug: Include "hw/pci/pci.h" > hw/timer/hpet: Include "exec/address-spaces.h" > hw/pci-host/q35: Include "qemu/range.h" > hw/i2c/smbus_ich9: Include "qemu/range.h" > hw/pci-host/piix: Include "qemu/range.h" > hw/acpi: Include "hw/mem/nvdimm.h" > hw/i386: Include "hw/mem/nvdimm.h" > hw/pci-host/q35: Remove unused includes > hw/i386/pc: Clean up includes > > hw/acpi/cpu_hotplug.c | 1 + > hw/acpi/ich9.c| 2 +- > hw/acpi/piix4.c | 1 + > hw/alpha/alpha_sys.h | 1 - > hw/alpha/dp264.c | 1 + > hw/hppa/machine.c | 1 + > hw/i2c/smbus_ich9.c | 1 + > hw/i386/acpi-build.c | 1 + > hw/i386/pc.c | 1 + > hw/i386/pc_piix.c | 1 + > hw/i386/pc_q35.c | 1 + > hw/input/pckbd.c | 1 - > hw/isa/lpc_ich9.c | 2 -- > hw/pci-host/piix.c| 1 + > hw/pci-host/q35.c | 1 + > hw/timer/hpet.c | 2 +- > hw/timer/twl92230.c | 1 - > hw/usb/dev-storage.c | 1 - > hw/xen/xen_pt_load_rom.c | 4 > include/hw/i386/ich9.h| 1 - > include/hw/i386/intel_iommu.h | 4 > include/hw/i386/ioapic_internal.h | 1 - > include/hw/i386/pc.h | 12 +++- > include/hw/pci-host/q35.h | 8 +--- > vl.c | 1 + > 25 files changed, 18 insertions(+), 34 deletions(-) > Acked-by: John Snow ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 02/20] hw/southbridge/ich9: Removed unused headers
On 10/14/19 10:22 AM, Philippe Mathieu-Daudé wrote: > The ICH9 chipset is not X86/PC specific. > > These files don't use anything declared by the "hw/i386/pc.h" > or "hw/i386/ioapic.h" headers. Remove them. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: John Snow > --- > hw/acpi/ich9.c | 1 - > hw/isa/lpc_ich9.c | 2 -- > include/hw/i386/ich9.h | 1 - > 3 files changed, 4 deletions(-) > > diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c > index 2034dd749e..fdd0a6c79e 100644 > --- a/hw/acpi/ich9.c > +++ b/hw/acpi/ich9.c > @@ -27,7 +27,6 @@ > #include "qemu/osdep.h" > #include "qapi/error.h" > #include "qapi/visitor.h" > -#include "hw/i386/pc.h" > #include "hw/pci/pci.h" > #include "migration/vmstate.h" > #include "qemu/timer.h" > diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c > index 17c292e306..61cee2ae3a 100644 > --- a/hw/isa/lpc_ich9.c > +++ b/hw/isa/lpc_ich9.c > @@ -35,10 +35,8 @@ > #include "hw/isa/isa.h" > #include "hw/sysbus.h" > #include "migration/vmstate.h" > -#include "hw/i386/pc.h" > #include "hw/irq.h" > #include "hw/isa/apm.h" > -#include "hw/i386/ioapic.h" > #include "hw/pci/pci.h" > #include "hw/pci/pci_bridge.h" > #include "hw/i386/ich9.h" > diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h > index 72e803f6e2..a98d10b252 100644 > --- a/include/hw/i386/ich9.h > +++ b/include/hw/i386/ich9.h > @@ -5,7 +5,6 @@ > #include "hw/sysbus.h" > #include "hw/i386/pc.h" > #include "hw/isa/apm.h" > -#include "hw/i386/ioapic.h" > #include "hw/pci/pci.h" > #include "hw/pci/pcie_host.h" > #include "hw/pci/pci_bridge.h" > -- —js ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl: Move shadow_memkb and iommu_memkb defaulting into libxl
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl:
Move shadow_memkb and iommu_memkb defaulting into libxl"):
> So maybe libxl__domain_build_info_setdefault() should also set a value
> to iommu_memkb as it does for shadow_memkb? At least, set iommu_memkb=0
> if still the default.
I think, this.
Ian.
From 379d8eb69f713cccf7eacb4c2a63f4f5fe944255 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Mon, 14 Oct 2019 17:59:00 +0100
Subject: [PATCH] squash! libxl: Move shadow_memkb and iommu_memkb defaulting
into libxl
---
v4: Provide a fallback default for iommu_memkb too, for old callers.
---
tools/libxl/libxl_create.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7423bedf7d..b3951a2423 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -229,6 +229,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl__arch_domain_build_info_setdefault(gc, b_info);
libxl_defbool_setdefault(_info->dm_restrict, false);
+if (b_info->iommu_memkb == LIBXL_MEMKB_DEFAULT)
+/* Normally defaulted in libxl__domain_create_info_setdefault */
+b_info->iommu_memkb = 0;
+
switch (b_info->type) {
case LIBXL_DOMAIN_TYPE_HVM:
if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic
On Mon, Oct 14, 2019 at 05:09:24PM +0100, Ian Jackson wrote:
> Paul Durrant writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> Overhaul passthrough setting logic"):
> > On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
> > >
> > > Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9]
> > > libxl/xl: Overhaul passthrough setting logic"):
> > > > On 11.10.19 15:31, Ian Jackson wrote:
> > > > > I do not have a strong opinion about this. I would be happy with
> > > > > "auto" (or "default" maybe).
> > > >
> > > > "unspecified"?
> > >
> > > That is IMO the best suggestion so far so I will go with that in my
> > > v3.
> >
> > Seems odd to specify a parameter with a value of 'unspecified' ;-)
>
> I have tried to infer +1/-1/0 numbers from the mail thread. I have
> also looked at libxl_types.idl to see how many times we are using
> what name to represent roughly this concept:
>
> Bikeshed colour Paul Juergen George Ian Anthony Wei #already
>
> unknown ? ? -1+2? ?17
> default ? ? ? 0? ? 2
> auto -1 ? +1 0? ? 1
> unspecified -1 +1? 0? ? 0
>
>
> libxl maintainers
Maybe "unknown" is more used in the API, but when I look at the manpage
"unknown" value as never been used before. On the other hand "default"
as been used twice in the man page. (and one "defaults" and two other
"default" that I'm not sure if they can be in the config file.)
So I would say +2 for default and +1 for unknown.
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl: Move shadow_memkb and iommu_memkb defaulting into libxl
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl:
Move shadow_memkb and iommu_memkb defaulting into libxl"):
> There's probably something else that is needed to be done for user of
> the pre-4.13 API. If they call libxl_domain_need_memory_0x041200, there
> is nothing that set iommu_memkb, so the default value stays at -1 and
> libxl_domain_need_memory_0x041200 returns a value that is lower that
> "target_memkb + shadow_memkb". Then, when libxl create the domain, it
> still keep iommu_memkb==-1, because the old API as been used.
>
> I tried to have xl call the 4.12 API and create a guest without
> passthrough, and QEMU crashed (assert() failure).
>
> So maybe libxl__domain_build_info_setdefault() should also set a value
> to iommu_memkb as it does for shadow_memkb? At least, set iommu_memkb=0
> if still the default.
I think you are right. Not sure how I missed that.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [XEN PATCH v4 for-4.13 10/10] libxl/xl: Overhaul passthrough setting logic passthrough setting logic
Here's what I hope is the final version...
From b60195e857d3699eaa55d9174a69bf91902cddb5 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Mon, 7 Oct 2019 17:59:15 +0100
Subject: [XEN PATCH v4 for-4.13 10/10] libxl/xl: Overhaul passthrough setting
logic
LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code) is doing double duty. We actually need all of
the following to be specificable:
* default ("unknown"): enable PT iff we have devices to
pass through specified in the initial config file.
* "enabled" (and fail if the platform doesn't support it).
* "disabled" (and reject future PT hotplug).
* "share_pt"/"sync_pt": enable PT and set a specific PT mode.
Defaulting and error checking should be done in libxl. So, we make
several changes here.
We introduce "enabled". (And we document "unknown".)
We move all of the error checking and defaulting code from xl into
libxl. Now, libxl__domain_config_setdefault has all of the necessary
information to get this right. So we can do it all there. Choosing
the specific mode is arch-specific.
We can also arrange to have only one place each which calculates
(i) whether passthrough needs to be enabled because pt devices were
specified (ii) whether pt_share can be used (for each arch).
xl now only has to parse the enum in the same way as it parses all
other enums.
This change fixes a regression from earlier 4.13-pre: until recent
changes, passthrough was only enabled by default if passthrough
devices were specified. We restore this behaviour.
Signed-off-by: Ian Jackson
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Andrew Cooper
CC: Paul Durrant
CC: Jan Beulich
---
v4: Fix trailing whitespace
No longer change "unknown" to "unspecified".
v3: Drop paragraph about masking another osstest regression,
as that's now fixed.
Drop redundant "ERROR:" in two log messages.
Add a comment about the way "enabled" gets changed to a specific value.
Split passthrough mode defaulting into arch specific functions.
On ARM, always choose (and insist on) share_pt.
Reject share_pt for non-HAP guests.
Reject passthrough for PVH guests.
Actually document "unspecified" option in xl.cfg(5)
Rename "unknown" to "unspecified"
v2: New patch in this version of the series.
---
docs/man/xl.cfg.5.pod.in| 6
tools/libxl/libxl_arch.h| 6
tools/libxl/libxl_arm.c | 24
tools/libxl/libxl_create.c | 41 +++
tools/libxl/libxl_types.idl | 5 ++--
tools/libxl/libxl_x86.c | 41 +++
tools/xl/xl_parse.c | 67 -
7 files changed, 114 insertions(+), 76 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 64bed30bce..7e220d0c20 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -660,6 +660,12 @@ in preference. However, the availability of this option is
hardware
specific. If B reports B containing
B then this option may be used.
+=item B
+
+The default, which chooses between B and B
+according to whether passthrough devices are enabled in the config
+file.
+
=back
=back
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index d624159e53..ee6641b3e6 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -73,6 +73,12 @@ void libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
libxl_domain_build_info *b_info);
_hidden
+int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
+uint32_t domid,
+libxl_domain_config *d_config,
+const libxl_physinfo *physinfo);
+
+_hidden
int libxl__arch_extra_memory(libxl__gc *gc,
const libxl_domain_build_info *info,
uint64_t *out);
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index bf31b9b3ca..2f1ca69431 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1191,6 +1191,30 @@ void libxl__arch_domain_build_info_setdefault(libxl__gc
*gc,
libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_PVH);
}
+int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
+uint32_t domid,
+libxl_domain_config *d_config,
+const libxl_physinfo *physinfo)
+{
+int rc;
+libxl_domain_create_info *const c_info = _config->c_info;
+
+if (c_info->passthrough == LIBXL_PASSTHROUGH_ENABLED) {
+c_info->passthrough = LIBXL_PASSTHROUGH_SHARE_PT;
+}
+
+if (c_info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT) {
+LOGD(ERROR, domid,
+ "passthrough=\"sync_pt\" not supported on ARM\n");
+rc =
Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl: Move shadow_memkb and iommu_memkb defaulting into libxl
On Fri, Oct 11, 2019 at 05:55:44PM +0100, Ian Jackson wrote: > For callers which call libxl_domain_need_memory, and request an old > pre-4.13 libxl API, and which leave one of these memkb settings unset, > we take special measures to preserve the old behaviour. > > This means that they don't get the additional iommu memory and are at > risk of the domain running out of memory as a result of f89f555827a6 > "remove late (on-demand) construction of IOMMU page tables". But this > is no worse than the state just after f89f555827a6, which already > broke such callers in that way. This is perhaps justifiable because > of the API stability warning next to libxl_domain_need_memory. There's probably something else that is needed to be done for user of the pre-4.13 API. If they call libxl_domain_need_memory_0x041200, there is nothing that set iommu_memkb, so the default value stays at -1 and libxl_domain_need_memory_0x041200 returns a value that is lower that "target_memkb + shadow_memkb". Then, when libxl create the domain, it still keep iommu_memkb==-1, because the old API as been used. I tried to have xl call the 4.12 API and create a guest without passthrough, and QEMU crashed (assert() failure). So maybe libxl__domain_build_info_setdefault() should also set a value to iommu_memkb as it does for shadow_memkb? At least, set iommu_memkb=0 if still the default. iommu_memkb is new in 4.13, user of the pre-4.13 API will not set it. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic
Wei Liu writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul
passthrough setting logic"):
> On Mon, Oct 14, 2019 at 05:09:24PM +0100, Ian Jackson wrote:
> > Bikeshed colour Paul Juergen George Ian Anthony Wei #already
> >
> > unknown ? ? -1+2? ?17
> > default ? ? ? 0? ? 2
> > auto -1 ? +1 0? ? 1
> > unspecified -1 +1? 0? ? 0
> >
> >
> > libxl maintainers
>
> +1 to "unknown". I prefer consistency.
>
> 0 to all others.
Thanks.
> > On this basis IMO clearly this should go back to "unknown".
> > I will do that in a respin (or maybe on commit) but right now I think
> > I am still awaiting a review for this patch.
>
> I think a respin is required -- in one of the mails your said you would
> need to put some logic into arch-specific function.
Yes. Already done.
This is confusing because we are in the thread re v2, which is where
this bikeshed conversation is happening.
But there is also a v3, see:
Subject: Re: [Xen-devel] [XEN PATCH for-4.13 v3 10/10] libxl/xl: Overhaul
passthrough setting logic
That's been R-B Anthony but I have now changed "unspecified" back to
"unknown"...
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 142748: tolerable all pass - PUSHED
flight 142748 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/142748/ 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 55ab292c42db41b05cfdba012680bf1e0ea02f7a baseline version: xen 518c935fac4d30b3ec35d4b6add82b17b7d7aca3 Last test of basis 142742 2019-10-14 11:01:21 Z0 days Testing same since 142748 2019-10-14 14:14:24 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Jan Beulich Olaf Hering 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 518c935fac..55ab292c42 55ab292c42db41b05cfdba012680bf1e0ea02f7a -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic
On Mon, Oct 14, 2019 at 05:09:24PM +0100, Ian Jackson wrote:
> Paul Durrant writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> Overhaul passthrough setting logic"):
> > On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
> > >
> > > Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9]
> > > libxl/xl: Overhaul passthrough setting logic"):
> > > > On 11.10.19 15:31, Ian Jackson wrote:
> > > > > I do not have a strong opinion about this. I would be happy with
> > > > > "auto" (or "default" maybe).
> > > >
> > > > "unspecified"?
> > >
> > > That is IMO the best suggestion so far so I will go with that in my
> > > v3.
> >
> > Seems odd to specify a parameter with a value of 'unspecified' ;-)
>
> I have tried to infer +1/-1/0 numbers from the mail thread. I have
> also looked at libxl_types.idl to see how many times we are using
> what name to represent roughly this concept:
>
> Bikeshed colour Paul Juergen George Ian Anthony Wei #already
>
> unknown ? ? -1+2? ?17
> default ? ? ? 0? ? 2
> auto -1 ? +1 0? ? 1
> unspecified -1 +1? 0? ? 0
>
>
> libxl maintainers
+1 to "unknown". I prefer consistency.
0 to all others.
>
> On this basis IMO clearly this should go back to "unknown".
> I will do that in a respin (or maybe on commit) but right now I think
> I am still awaiting a review for this patch.
>
I think a respin is required -- in one of the mails your said you would
need to put some logic into arch-specific function.
Wei.
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v3 10/10] libxl/xl: Overhaul passthrough setting logic
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v3 10/10] libxl/xl:
Overhaul passthrough setting logic"):
> On Fri, Oct 11, 2019 at 05:55:49PM +0100, Ian Jackson wrote:
> > LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
>
> I guess that's now LIBXL_PASSTHROUGH_UNSPECIFIED.
Heh, see my other mail, just crossed with yours.
> > +int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
> > +uint32_t domid,
> > +libxl_domain_config *d_config,
> > +const libxl_physinfo *physinfo)
> > +{
>
> [...]
>
> > +}
> > +
>
> There are 40 trailing white space here, any reason? :-).
No. I will get rid of them. My editor doesn't complain about them
and my personal view is that this is pointless bureaucracy but it's
not just up to me, so I'll fix it.
> Beside a few typos, the patch looks fine to me:
> Reviewed-by: Anthony PERARD
Thanks.
If I change "unspecified" back to "unknown", and fix the spaces (and
I'll have a look for typos), should I retain your ack ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic
Paul Durrant writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
Overhaul passthrough setting logic"):
> On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
> >
> > Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> > Overhaul passthrough setting logic"):
> > > On 11.10.19 15:31, Ian Jackson wrote:
> > > > I do not have a strong opinion about this. I would be happy with
> > > > "auto" (or "default" maybe).
> > >
> > > "unspecified"?
> >
> > That is IMO the best suggestion so far so I will go with that in my
> > v3.
>
> Seems odd to specify a parameter with a value of 'unspecified' ;-)
I have tried to infer +1/-1/0 numbers from the mail thread. I have
also looked at libxl_types.idl to see how many times we are using
what name to represent roughly this concept:
Bikeshed colour Paul Juergen George Ian Anthony Wei #already
unknown ? ? -1+2? ?17
default ? ? ? 0? ? 2
auto -1 ? +1 0? ? 1
unspecified -1 +1? 0? ? 0
libxl maintainers
On this basis IMO clearly this should go back to "unknown".
I will do that in a respin (or maybe on commit) but right now I think
I am still awaiting a review for this patch.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v3 10/10] libxl/xl: Overhaul passthrough setting logic
On Fri, Oct 11, 2019 at 05:55:49PM +0100, Ian Jackson wrote:
> LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
I guess that's now LIBXL_PASSTHROUGH_UNSPECIFIED.
> version of this code) is doing double duty. We actually need all of
> the following to be specificable:
> * default ("unspecified"): enable PT iff we have devices to
^if
> pass through specified in the initial config file.
> * "enabled" (and fail if the platform doesn't support it).
> * "disabled" (and reject future PT hotplug).
> * "share_pt"/"sync_pt": enable PT and set a specific PT mode.
>
> Defaulting and error checking should be done in libxl. So, we make
> several changes here.
>
> We introduce "enabled". (And we document "unspecified".)
>
> We move all of the error checking and defaulting code from xl into
> libxl. Now, libxl__domain_config_setdefault has all of the necessary
> information to get this right. So we can do it all there. Choosing
> the specific mode is arch-specific.
>
> We can also arrange to have only one place each which calculates
> (i) whether passthrough needs to be enabled because pt devices were
> specified (ii) whether pt_share can be used (for each arch).
>
> xl now only has to parse the enum in the same way as it parses all
> other enums.
>
> This change fixes a regression from earlier 4.13-pre: until recent
> changes, passthrough was only enabled by default if passthrough
> devices were specified. We restore this behaviour.
>
> Signed-off-by: Ian Jackson
>
> ---
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index c0f88a7eaa..226b712cbd 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -631,6 +631,47 @@ void libxl__arch_domain_build_info_setdefault(libxl__gc
> *gc,
> libxl_defbool_setdefault(_info->acpi, true);
> }
>
> +int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
> +uint32_t domid,
> +libxl_domain_config *d_config,
> +const libxl_physinfo *physinfo)
> +{
[...]
> +}
> +
There are 40 trailing white space here, any reason? :-).
Beside a few typos, the patch looks fine to me:
Reviewed-by: Anthony PERARD
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 142723: regressions - FAIL
flight 142723 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/142723/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 140282 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 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-xsm 13 migrate-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-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-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-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14
Re: [Xen-devel] [PATCH 2/2] libxl_pci: Fix guest shutdown with PCI PT attached
On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote: >On 01/10/2019 12:35, Anthony PERARD wrote: >> Rewrite of the commit message: >> >> Before the problematic commit, libxl used to ignore error when >> destroying (force == true) a passthrough device, especially error that >> happens when dealing with the DM. >> >> Since fae4880c45fe, if the DM failed to detach the pci device within >> the allowed time, the timed out error raised skip part of >> pci_remove_*, but also raise the error up to the caller of >> libxl__device_pci_destroy_all, libxl__destroy_domid, and thus the >> destruction of the domain fails. >> >> In this patch, if the DM didn't confirmed that the device is removed, >> we will print a warning and keep going if force=true. The patch >> reorder the functions so that pci_remove_timeout() calls >> pci_remove_detatched() like it's done when DM calls are successful. >> >> We also clean the QMP states and associated timeouts earlier, as soon >> as they are not needed anymore. >> >> Reported-by: Sander Eikelenboom >> Fixes: fae4880c45fe015e567afa223f78bf17a6d98e1b >> Signed-off-by: Anthony PERARD >> > >Hi Anthony / Chao, > >I have to come back to this, a bit because perhaps there is an underlying >issue. >While it earlier occurred to me that the VM to which I passed through most >pci-devices >(8 to be exact) became very slow to shutdown, but I didn't investigate it >further. > >But after you commit messages from this patch it kept nagging, so today I did >some testing >and bisecting. > >The difference in tear-down time at least from what the IOMMU code logs is >quite large: > >xen-4.12.0 > Setup: 7.452 s > Tear-down: 7.626 s > >xen-unstable-ee7170822f1fc209f33feb47b268bab35541351d > Setup: 7.468 s > Tear-down: 50.239 s > >Bisection turned up: > commit c4b1ef0f89aa6a74faa4618ce3efed1de246ec40 > Author: Chao Gao > Date: Fri Jul 19 10:24:08 2019 +0100 > libxl_qmp: wait for completion of device removal > >Which makes me wonder if there is something going wrong in Qemu ? Hi Sander, Thanks for your testing and the bisection. I tried on my machine, the destruction time of a guest with 8 pass-thru devices increased from 4s to 12s after applied the commit above. In my understanding, I guess you might get the error message "timed out waiting for DM to remove...". There might be some issues on your assigned devices' drivers. You can first unbind the devices with their drivers in VM and then tear down the VM, and check whether the VM teardown gets much faster. Anthony & Wei, The commit above basically serializes and synchronizes detaching assigned devices and thus increases VM teardown time significantly if there are multiple assigned devices. The commit aimed to avoid qemu's access to PCI configuration space coinciding with the device reset initiated by xl (which is not desired and is exactly the case which triggers the assertion in Xen [1]). I personally insist that xl should wait for DM's completion of device detaching. Otherwise, besides Xen panic (which can be fixed in another way), in theory, such sudden unawared device reset might cause a disaster (e.g. data loss for a storage device). [1]: https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg03287.html But considering fast creation and teardown is an important benefit of virtualization, I am not sure how to deal with the situation. Anyway, you can make the decision. To fix the regression on VM teardown, we can revert the commit by removing the timeout logic. What's your opinion? Thanks Chao > >-- >Sander > > > >xen-4.12.0 setup: > (XEN) [2019-10-10 09:54:14.846] AMD-Vi: Disable: device id = 0x900, > domain = 0, paging mode = 3 > (XEN) [2019-10-10 09:54:14.846] AMD-Vi: Setup I/O page table: device id > = 0x900, type = 0x1, root table = 0x4aa847000, domain = 1, paging mode = 3 > (XEN) [2019-10-10 09:54:14.846] AMD-Vi: Re-assign :09:00.0 from > dom0 to dom1 > ... > (XEN) [2019-10-10 09:54:22.298] AMD-Vi: Disable: device id = 0x907, > domain = 0, paging mode = 3 > (XEN) [2019-10-10 09:54:22.298] AMD-Vi: Setup I/O page table: device id > = 0x907, type = 0x1, root table = 0x4aa847000, domain = 1, paging mode = 3 > (XEN) [2019-10-10 09:54:22.298] AMD-Vi: Re-assign :09:00.7 from > dom0 to dom1 > > >xen-4.12.0 tear-down: > (XEN) [2019-10-10 10:01:11.971] AMD-Vi: Disable: device id = 0x900, > domain = 1, paging mode = 3 > (XEN) [2019-10-10 10:01:11.971] AMD-Vi: Setup I/O page table: device id > = 0x900, type = 0x1, root table = 0x53572c000, domain = 0, paging mode = 3 > (XEN) [2019-10-10 10:01:11.971] AMD-Vi: Re-assign :09:00.0 from > dom1 to dom0 > ... > (XEN) [2019-10-10 10:01:19.597] AMD-Vi: Disable: device id = 0x907, > domain = 1, paging mode = 3 > (XEN) [2019-10-10 10:01:19.597] AMD-Vi: Setup I/O page table: device id > = 0x907, type = 0x1, root
[Xen-devel] [xen-unstable test] 142722: tolerable FAIL
flight 142722 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/142722/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 19 leak-check/check fail in 142683 pass in 142722 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 142683 test-armhf-armhf-xl-vhd 18 leak-check/check fail pass in 142683 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 142683 like 142642 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 142683 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 142683 never pass test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 142683 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 142683 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142683 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142683 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142683 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142683 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142683 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 142683 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142683 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142683 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142683 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass 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-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-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-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 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-libvirt-vhd 12 migrate-support-checkfail 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 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-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts
On 10/9/19 6:35 AM, Jan Beulich wrote: > On 09.10.2019 14:52, Roger Pau Monne wrote: >> When using posted interrupts and the guest migrates MSI from vCPUs Xen >> needs to flush any pending PIRR vectors on the previous vCPU, or else >> those vectors could get wrongly injected at a later point when the MSI >> fields are already updated. >> >> Rename sync_pir_to_irr to vlapic_sync_pir_to_irr and export it so it >> can be called when updating the posted interrupt descriptor field in >> pi_update_irte. While there also remove the unlock_out from >> pi_update_irte, it's used in a single goto and removing it makes the >> function smaller. >> >> Note that PIRR is synced to IRR both in pt_irq_destroy_bind and >> pt_irq_create_bind when the interrupt delivery data is being updated. >> >> Also store the vCPU ID in multi-destination mode when using posted >> interrupts and the interrupt is bound to a single vCPU in order for >> posted interrupts to be used. >> >> While there guard pi_update_irte with CONFIG_HVM since it's only used >> with HVM guests. >> >> Reported-by: Joe Jin >> Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich > > Like for the other patch I'd prefer to wait a little with committing > (even if the VT-d ack appeared quickly) until hopefully a Tested-by > could be provided. My test env has not been fixed yet, not sure when it can be fixed, once it available I'll test it. Thanks, Joe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 20/20] hw/i386/pc: Clean up includes
Various headers are not required by hw/i386/pc.h: - "qemu/range.h" - "qemu/bitmap.h" - "qemu/module.h" - "exec/memory.h" - "hw/pci/pci.h" - "hw/mem/pc-dimm.h" - "hw/mem/nvdimm.h" - "net/net.h" Remove them. Add 3 headers that were missing: - "hw/hotplug.h" PCMachineState::acpi_dev is of type HotplugHandler - "qemu/notify.h" PCMachineState::machine_done is of type Notifier - "qapi/qapi-types-common.h" PCMachineState::vmport/smm is of type OnOffAuto Signed-off-by: Philippe Mathieu-Daudé --- include/hw/i386/pc.h | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index 6df4f4b6fb..e5c2dc9081 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -1,21 +1,15 @@ #ifndef HW_PC_H #define HW_PC_H -#include "exec/memory.h" +#include "qemu/notify.h" +#include "qapi/qapi-types-common.h" #include "hw/boards.h" #include "hw/isa/isa.h" #include "hw/block/fdc.h" #include "hw/block/flash.h" -#include "net/net.h" #include "hw/i386/ioapic.h" - -#include "qemu/range.h" -#include "qemu/bitmap.h" -#include "qemu/module.h" -#include "hw/pci/pci.h" -#include "hw/mem/pc-dimm.h" -#include "hw/mem/nvdimm.h" #include "hw/acpi/acpi_dev_interface.h" +#include "hw/hotplug.h" #define HPET_INTCAP "hpet-intcap" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 19/20] hw/pci-host/q35: Remove unused includes
Only q35.c requires declarations from "hw/i386/pc.h", move it there. Remove all the includes not used by "q35.h". Signed-off-by: Philippe Mathieu-Daudé --- hw/pci-host/q35.c | 1 + include/hw/pci-host/q35.h | 7 --- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index 158d270b9f..918843d373 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -29,6 +29,7 @@ */ #include "qemu/osdep.h" +#include "hw/i386/pc.h" #include "hw/pci-host/q35.h" #include "hw/qdev-properties.h" #include "migration/vmstate.h" diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h index 79a88d67b1..534d90dbaf 100644 --- a/include/hw/pci-host/q35.h +++ b/include/hw/pci-host/q35.h @@ -22,16 +22,9 @@ #ifndef HW_Q35_H #define HW_Q35_H -#include "hw/isa/isa.h" -#include "hw/sysbus.h" -#include "hw/i386/pc.h" -#include "hw/isa/apm.h" #include "hw/pci/pci.h" #include "hw/pci/pcie_host.h" -#include "hw/acpi/acpi.h" -#include "hw/acpi/ich9.h" #include "hw/pci-host/pam.h" -#include "hw/i386/intel_iommu.h" #include "qemu/range.h" #define TYPE_Q35_HOST_DEVICE "q35-pcihost" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 18/20] hw/i386: Include "hw/mem/nvdimm.h"
All this files use methods/definitions declared in the NVDIMM
device header. Include it.
This fixes (when modifying unrelated headers):
hw/i386/acpi-build.c:2733:9: error: implicit declaration of function
'nvdimm_build_acpi' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
nvdimm_build_acpi(table_offsets, tables_blob, tables->linker,
^
hw/i386/pc.c:1996:61: error: use of undeclared identifier 'TYPE_NVDIMM'
const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
^
hw/i386/pc.c:2032:55: error: use of undeclared identifier 'TYPE_NVDIMM'
bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
^
hw/i386/pc.c:2040:9: error: implicit declaration of function 'nvdimm_plug' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
nvdimm_plug(ms->nvdimms_state);
^
hw/i386/pc.c:2040:9: error: this function declaration is not a prototype
[-Werror,-Wstrict-prototypes]
nvdimm_plug(ms->nvdimms_state);
^
hw/i386/pc.c:2065:42: error: use of undeclared identifier 'TYPE_NVDIMM'
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
^
hw/i386/pc_i440fx.c:307:9: error: implicit declaration of function
'nvdimm_init_acpi_state' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
^
hw/i386/pc_q35.c:332:9: error: implicit declaration of function
'nvdimm_init_acpi_state' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
^
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/acpi-build.c | 1 +
hw/i386/pc.c | 1 +
hw/i386/pc_piix.c| 1 +
hw/i386/pc_q35.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4e0f9f425a..ac46936f63 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -48,6 +48,7 @@
#include "hw/timer/mc146818rtc_regs.h"
#include "migration/vmstate.h"
#include "hw/mem/memory-device.h"
+#include "hw/mem/nvdimm.h"
#include "sysemu/numa.h"
#include "sysemu/reset.h"
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index bcda50efcc..cff330802d 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -73,6 +73,7 @@
#include "hw/boards.h"
#include "acpi-build.h"
#include "hw/mem/pc-dimm.h"
+#include "hw/mem/nvdimm.h"
#include "qapi/error.h"
#include "qapi/qapi-visit-common.h"
#include "qapi/visitor.h"
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 6824b72124..8651b6e2ec 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -58,6 +58,7 @@
#include "migration/misc.h"
#include "kvm_i386.h"
#include "sysemu/numa.h"
+#include "hw/mem/nvdimm.h"
#define MAX_IDE_BUS 2
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 8fad20f314..91ba231ef1 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -53,6 +53,7 @@
#include "qapi/error.h"
#include "qemu/error-report.h"
#include "sysemu/numa.h"
+#include "hw/mem/nvdimm.h"
/* ICH9 AHCI has 6 ports */
#define MAX_SATA_PORTS 6
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 17/20] hw/acpi: Include "hw/mem/nvdimm.h"
Both ich9.c and piix4.c use methods/definitions declared in the
NVDIMM device header. Include it.
This fixes (when modifying unrelated headers):
hw/acpi/ich9.c:507:46: error: use of undeclared identifier 'TYPE_NVDIMM'
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
^
hw/acpi/ich9.c:508:13: error: implicit declaration of function
'nvdimm_acpi_plug_cb' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
nvdimm_acpi_plug_cb(hotplug_dev, dev);
^
hw/acpi/piix4.c:403:46: error: use of undeclared identifier 'TYPE_NVDIMM'
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
^
hw/acpi/piix4.c:404:13: error: implicit declaration of function
'nvdimm_acpi_plug_cb' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
nvdimm_acpi_plug_cb(hotplug_dev, dev);
^
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/ich9.c | 1 +
hw/acpi/piix4.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index fdd0a6c79e..4e74284b65 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -39,6 +39,7 @@
#include "hw/i386/ich9.h"
#include "hw/mem/pc-dimm.h"
+#include "hw/mem/nvdimm.h"
//#define DEBUG
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 5742c3df87..11a3e33e5b 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -39,6 +39,7 @@
#include "hw/acpi/cpu.h"
#include "hw/hotplug.h"
#include "hw/mem/pc-dimm.h"
+#include "hw/mem/nvdimm.h"
#include "hw/acpi/memory_hotplug.h"
#include "hw/acpi/acpi_dev_interface.h"
#include "hw/xen/xen.h"
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 16/20] hw/pci-host/piix: Include "qemu/range.h"
hw/pci-host/piix.c calls various functions from the Range API.
Include "qemu/range.h" which declares them.
This fixes (when modifying unrelated headers):
hw/pci-host/i440fx.c:54:11: error: field has incomplete type 'Range' (aka
'struct Range')
Range pci_hole;
^
include/qemu/typedefs.h:116:16: note: forward declaration of 'struct Range'
typedef struct Range Range;
^
hw/pci-host/i440fx.c:126:9: error: implicit declaration of function
'ranges_overlap' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (ranges_overlap(address, len, I440FX_PAM, I440FX_PAM_SIZE) ||
^
hw/pci-host/i440fx.c:126:9: error: this function declaration is not a
prototype [-Werror,-Wstrict-prototypes]
hw/pci-host/i440fx.c:127:9: error: implicit declaration of function
'range_covers_byte' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
range_covers_byte(address, len, I440FX_SMRAM)) {
^
hw/pci-host/i440fx.c:127:9: error: this function declaration is not a
prototype [-Werror,-Wstrict-prototypes]
hw/pci-host/i440fx.c:189:13: error: implicit declaration of function
'range_is_empty' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
val64 = range_is_empty(>pci_hole) ? 0 : range_lob(>pci_hole);
^
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/piix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 135c645535..76ed252a60 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -23,6 +23,7 @@
*/
#include "qemu/osdep.h"
+#include "qemu/range.h"
#include "hw/i386/pc.h"
#include "hw/irq.h"
#include "hw/pci/pci.h"
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 15/20] hw/i2c/smbus_ich9: Include "qemu/range.h"
hw/i2c/smbus_ich9.c calls range_covers_byte(). Include "qemu/range.h"
which declares it.
This fixes (when modifying unrelated headers):
hw/i2c/smbus_ich9.c:66:9: error: implicit declaration of function
'range_covers_byte' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (range_covers_byte(address, len, ICH9_SMB_HOSTC)) {
^
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i2c/smbus_ich9.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/i2c/smbus_ich9.c b/hw/i2c/smbus_ich9.c
index fd50fb851a..48f1ff4191 100644
--- a/hw/i2c/smbus_ich9.c
+++ b/hw/i2c/smbus_ich9.c
@@ -21,6 +21,7 @@
*/
#include "qemu/osdep.h"
+#include "qemu/range.h"
#include "hw/i2c/pm_smbus.h"
#include "hw/pci/pci.h"
#include "migration/vmstate.h"
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 14/20] hw/pci-host/q35: Include "qemu/range.h"
The MCHPCIState structure uses the Range type which is declared in "qemu/range.h". Include it. This fixes (when modifying unrelated headers): In file included from hw/pci-host/q35.c:32: include/hw/pci-host/q35.h:57:11: error: field has incomplete type 'Range' (aka 'struct Range') Range pci_hole; ^ include/qemu/typedefs.h:116:16: note: forward declaration of 'struct Range' typedef struct Range Range; ^ Signed-off-by: Philippe Mathieu-Daudé --- include/hw/pci-host/q35.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h index b3bcf2e632..79a88d67b1 100644 --- a/include/hw/pci-host/q35.h +++ b/include/hw/pci-host/q35.h @@ -32,6 +32,7 @@ #include "hw/acpi/ich9.h" #include "hw/pci-host/pam.h" #include "hw/i386/intel_iommu.h" +#include "qemu/range.h" #define TYPE_Q35_HOST_DEVICE "q35-pcihost" #define Q35_HOST_DEVICE(obj) \ -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 08/20] hw/xen/xen_pt_load_rom: Remove unused includes
On Mon, 14 Oct 2019 at 15:27, Philippe Mathieu-Daudé wrote: > > xen_pt_load_rom.c does not use any of these includes, remove them. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Paul Durrant > --- > hw/xen/xen_pt_load_rom.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c > index 307a5c93e2..a50a80837e 100644 > --- a/hw/xen/xen_pt_load_rom.c > +++ b/hw/xen/xen_pt_load_rom.c > @@ -3,12 +3,8 @@ > */ > #include "qemu/osdep.h" > #include "qapi/error.h" > -#include "hw/i386/pc.h" > #include "qemu/error-report.h" > -#include "ui/console.h" > #include "hw/loader.h" > -#include "monitor/monitor.h" > -#include "qemu/range.h" > #include "hw/pci/pci.h" > #include "xen_pt.h" > > -- > 2.21.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 13/20] hw/timer/hpet: Include "exec/address-spaces.h"
hw/timer/hpet.c calls address_space_stl_le() declared in "exec/address-spaces.h". Include it. This fixes (when modifying unrelated headers): hw/timer/hpet.c:210:31: error: use of undeclared identifier 'address_space_memory' address_space_stl_le(_space_memory, timer->fsb >> 32, ^~~~ Signed-off-by: Philippe Mathieu-Daudé --- hw/timer/hpet.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c index 4772cccfe3..6589d63ebb 100644 --- a/hw/timer/hpet.c +++ b/hw/timer/hpet.c @@ -35,6 +35,7 @@ #include "hw/timer/mc146818rtc.h" #include "migration/vmstate.h" #include "hw/timer/i8254.h" +#include "exec/address-spaces.h" //#define HPET_DEBUG #ifdef HPET_DEBUG -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 12/20] hw/acpi/cpu_hotplug: Include "hw/pci/pci.h"
hw/acpi/cpu_hotplug.c calls pci_address_space_io(). Include "hw/pci/pci.h" which declares it. This fixes (when modifying unrelated headers): hw/acpi/cpu_hotplug.c:103:28: error: implicit declaration of function 'pci_address_space_io' is invalid in C99 [-Werror,-Wimplicit-function-declaration] MemoryRegion *parent = pci_address_space_io(PCI_DEVICE(gpe_cpu->device)); ^ Signed-off-by: Philippe Mathieu-Daudé --- hw/acpi/cpu_hotplug.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c index 6e8293aac9..7fb65d9065 100644 --- a/hw/acpi/cpu_hotplug.c +++ b/hw/acpi/cpu_hotplug.c @@ -14,6 +14,7 @@ #include "qapi/error.h" #include "hw/core/cpu.h" #include "hw/i386/pc.h" +#include "hw/pci/pci.h" #include "qemu/error-report.h" #define CPU_EJECT_METHOD "CPEJ" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 11/20] hw/hppa/machine: Include "net/net.h"
hw/hppa/machine.c uses NICInfo variables which are declared in
"net/net.h". Include it.
This fixes (when modifying unrelated headers):
hw/hppa/machine.c:126:21: error: use of undeclared identifier 'nb_nics'
for (i = 0; i < nb_nics; i++) {
^
hw/hppa/machine.c:127:30: error: use of undeclared identifier 'nd_table'
pci_nic_init_nofail(_table[i], pci_bus, "e1000", NULL);
^
Signed-off-by: Philippe Mathieu-Daudé
---
hw/hppa/machine.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 7e23675429..6c55ed0af1 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -20,6 +20,7 @@
#include "qemu/units.h"
#include "qapi/error.h"
#include "qemu/log.h"
+#include "net/net.h"
#define MAX_IDE_BUS 2
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 10/20] hw/alpha/dp264: Include "net/net.h"
hw/alpha/dp264.c uses NICInfo variables which are declared in
"net/net.h". Include it.
This fixes (when modifying unrelated headers):
hw/alpha/dp264.c:89:21: error: use of undeclared identifier 'nb_nics'
for (i = 0; i < nb_nics; i++) {
^
hw/alpha/dp264.c:90:30: error: use of undeclared identifier 'nd_table'
pci_nic_init_nofail(_table[i], pci_bus, "e1000", NULL);
^
Signed-off-by: Philippe Mathieu-Daudé
---
hw/alpha/dp264.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index 51feee8558..013a9d3510 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -20,6 +20,7 @@
#include "hw/isa/superio.h"
#include "hw/dma/i8257.h"
#include "qemu/cutils.h"
+#include "net/net.h"
#define MAX_IDE_BUS 2
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 09/20] hw/alpha/alpha_sys: Remove unused "hw/ide.h" header
alpha_sys.h does not use anything from the "hw/ide.h" header. Remove it. Signed-off-by: Philippe Mathieu-Daudé --- hw/alpha/alpha_sys.h | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/alpha/alpha_sys.h b/hw/alpha/alpha_sys.h index 4e127a6de8..9991535c0d 100644 --- a/hw/alpha/alpha_sys.h +++ b/hw/alpha/alpha_sys.h @@ -6,7 +6,6 @@ #include "target/alpha/cpu-qom.h" #include "hw/pci/pci.h" #include "hw/pci/pci_host.h" -#include "hw/ide.h" #include "hw/i386/pc.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 07/20] hw/i386/intel_iommu: Remove unused includes
intel_iommu.h does not use any of these includes, remove them. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/i386/intel_iommu.h | 4 1 file changed, 4 deletions(-) diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h index 66b931e526..a1c4afcda5 100644 --- a/include/hw/i386/intel_iommu.h +++ b/include/hw/i386/intel_iommu.h @@ -22,11 +22,7 @@ #ifndef INTEL_IOMMU_H #define INTEL_IOMMU_H -#include "sysemu/dma.h" #include "hw/i386/x86-iommu.h" -#include "hw/i386/ioapic.h" -#include "hw/pci/msi.h" -#include "hw/sysbus.h" #include "qemu/iova-tree.h" #define TYPE_INTEL_IOMMU_DEVICE "intel-iommu" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 08/20] hw/xen/xen_pt_load_rom: Remove unused includes
xen_pt_load_rom.c does not use any of these includes, remove them. Signed-off-by: Philippe Mathieu-Daudé --- hw/xen/xen_pt_load_rom.c | 4 1 file changed, 4 deletions(-) diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c index 307a5c93e2..a50a80837e 100644 --- a/hw/xen/xen_pt_load_rom.c +++ b/hw/xen/xen_pt_load_rom.c @@ -3,12 +3,8 @@ */ #include "qemu/osdep.h" #include "qapi/error.h" -#include "hw/i386/pc.h" #include "qemu/error-report.h" -#include "ui/console.h" #include "hw/loader.h" -#include "monitor/monitor.h" -#include "qemu/range.h" #include "hw/pci/pci.h" #include "xen_pt.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 142739: regressions - trouble: blocked/fail
flight 142739 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/142739/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501 Tests which did not succeed, but are not blocking: build-amd64-freebsd-again 1 build-check(1) blocked n/a build-amd64-xen-freebsd 1 build-check(1) blocked n/a version targeted for testing: freebsd 45f4571813a9798c70a71bc55050d95e746fdb5a baseline version: freebsd 14aef6dfca96006e52b8fb920bde7c612ba58b79 Last test of basis 141501 2019-09-20 09:19:51 Z 24 days Failing since141701 2019-09-23 09:19:41 Z 21 days9 attempts Testing same since 142739 2019-10-14 09:23:41 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> alc Alek Pinchuk allanjude ambrisko andrew asomers avg bapt bdragon br brooks cem cognet cperciva cy dab daichi dchagin dim dougm emaste erj gallatin gjb glebius gonzo grembo hrs hselasky ian imp jhb jhibbits jilles jkim jlh jmg jtl kaktus kan karels kevans kib kp lstewart lwhsu manu markj mav mckusick mhorne mjg mm mmacy olivier oshogbo philip Piotr Pietruszewski ray rmacklem royger rrs rstone samm schweikh scottl sef sjg tijl Tom Caputi trasz tsoome tuexen vangyzen vmaffione yuripv jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail build-amd64-xen-freebsd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 8505 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 06/20] hw/usb/dev-storage: Remove unused "ui/console.h" header
The USB models related to storage don't need anything from "ui/console.h". Remove it. Signed-off-by: Philippe Mathieu-Daudé --- hw/usb/dev-storage.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c index 8545193488..a2ff52d3e5 100644 --- a/hw/usb/dev-storage.c +++ b/hw/usb/dev-storage.c @@ -17,7 +17,6 @@ #include "desc.h" #include "hw/qdev-properties.h" #include "hw/scsi/scsi.h" -#include "ui/console.h" #include "migration/vmstate.h" #include "monitor/monitor.h" #include "sysemu/sysemu.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/20] hw/timer: Remove unused "ui/console.h" header
The timer models don't need anything from "ui/console.h". Remove it. Signed-off-by: Philippe Mathieu-Daudé --- hw/timer/hpet.c | 1 - hw/timer/twl92230.c | 1 - 2 files changed, 2 deletions(-) diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c index 1ddae4e7d7..4772cccfe3 100644 --- a/hw/timer/hpet.c +++ b/hw/timer/hpet.c @@ -27,7 +27,6 @@ #include "qemu/osdep.h" #include "hw/i386/pc.h" #include "hw/irq.h" -#include "ui/console.h" #include "qapi/error.h" #include "qemu/error-report.h" #include "qemu/timer.h" diff --git a/hw/timer/twl92230.c b/hw/timer/twl92230.c index 63bd13d2ca..d0011be89e 100644 --- a/hw/timer/twl92230.c +++ b/hw/timer/twl92230.c @@ -27,7 +27,6 @@ #include "migration/qemu-file-types.h" #include "migration/vmstate.h" #include "sysemu/sysemu.h" -#include "ui/console.h" #include "qemu/bcd.h" #include "qemu/module.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 04/20] hw/i386/ioapic_internal: Remove unused "hw/i386/ioapic.h" header
The "ioapic_internal.h" does not use anything from "hw/i386/ioapic.h", remove it. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/i386/ioapic_internal.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/hw/i386/ioapic_internal.h b/include/hw/i386/ioapic_internal.h index d46c87c510..fe06938bda 100644 --- a/include/hw/i386/ioapic_internal.h +++ b/include/hw/i386/ioapic_internal.h @@ -23,7 +23,6 @@ #define QEMU_IOAPIC_INTERNAL_H #include "exec/memory.h" -#include "hw/i386/ioapic.h" #include "hw/sysbus.h" #include "qemu/notify.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 03/20] hw/input/pckbd: Remove unused "hw/i386/pc.h" header
The keyboard controller model don't need anything from "hw/i386/pc.h". Remove it. Signed-off-by: Philippe Mathieu-Daudé --- hw/input/pckbd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c index f0acfd86f7..2f09f780ba 100644 --- a/hw/input/pckbd.c +++ b/hw/input/pckbd.c @@ -26,7 +26,6 @@ #include "qemu/log.h" #include "hw/isa/isa.h" #include "migration/vmstate.h" -#include "hw/i386/pc.h" #include "hw/input/ps2.h" #include "hw/irq.h" #include "hw/input/i8042.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/20] hw/southbridge/ich9: Removed unused headers
The ICH9 chipset is not X86/PC specific. These files don't use anything declared by the "hw/i386/pc.h" or "hw/i386/ioapic.h" headers. Remove them. Signed-off-by: Philippe Mathieu-Daudé --- hw/acpi/ich9.c | 1 - hw/isa/lpc_ich9.c | 2 -- include/hw/i386/ich9.h | 1 - 3 files changed, 4 deletions(-) diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c index 2034dd749e..fdd0a6c79e 100644 --- a/hw/acpi/ich9.c +++ b/hw/acpi/ich9.c @@ -27,7 +27,6 @@ #include "qemu/osdep.h" #include "qapi/error.h" #include "qapi/visitor.h" -#include "hw/i386/pc.h" #include "hw/pci/pci.h" #include "migration/vmstate.h" #include "qemu/timer.h" diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c index 17c292e306..61cee2ae3a 100644 --- a/hw/isa/lpc_ich9.c +++ b/hw/isa/lpc_ich9.c @@ -35,10 +35,8 @@ #include "hw/isa/isa.h" #include "hw/sysbus.h" #include "migration/vmstate.h" -#include "hw/i386/pc.h" #include "hw/irq.h" #include "hw/isa/apm.h" -#include "hw/i386/ioapic.h" #include "hw/pci/pci.h" #include "hw/pci/pci_bridge.h" #include "hw/i386/ich9.h" diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h index 72e803f6e2..a98d10b252 100644 --- a/include/hw/i386/ich9.h +++ b/include/hw/i386/ich9.h @@ -5,7 +5,6 @@ #include "hw/sysbus.h" #include "hw/i386/pc.h" #include "hw/isa/apm.h" -#include "hw/i386/ioapic.h" #include "hw/pci/pci.h" #include "hw/pci/pcie_host.h" #include "hw/pci/pci_bridge.h" -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/20] vl: Add missing "hw/boards.h" include
vl.c calls machine_usb() declared in "hw/boards.h". Include it.
This fixes (when modifying unrelated headers):
vl.c:1283:10: error: implicit declaration of function 'machine_usb' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (!machine_usb(current_machine)) {
^
vl.c:1283:10: error: this function declaration is not a prototype
[-Werror,-Wstrict-prototypes]
vl.c:1283:22: error: use of undeclared identifier 'current_machine'
if (!machine_usb(current_machine)) {
^
Signed-off-by: Philippe Mathieu-Daudé
---
vl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/vl.c b/vl.c
index 002bf4919e..e85b31df1b 100644
--- a/vl.c
+++ b/vl.c
@@ -25,6 +25,7 @@
#include "qemu/osdep.h"
#include "qemu-common.h"
#include "qemu/units.h"
+#include "hw/boards.h"
#include "hw/qdev-properties.h"
#include "qapi/error.h"
#include "qemu-version.h"
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 00/20] hw: Clean up hw/i386 headers (and few alpha/hppa)
This is a follow-up of Markus's cleanup series: Tame a few "touch this, recompile the world" https://www.mail-archive.com/qemu-devel@nongnu.org/msg635748.html This part is mostly restricted to X86, but since some file from the Alpha/PA-RISC machines include "hw/i386/pc.h" I had to fix them too. Eventually I'll succeed at removing hw/i386/ dependency on non-X86 platforms (Quest I started 2 years ago...). Regards, Phil. Philippe Mathieu-Daudé (20): vl: Add missing "hw/boards.h" include hw/southbridge/ich9: Removed unused headers hw/input/pckbd: Remove unused "hw/i386/pc.h" header hw/i386/ioapic_internal: Remove unused "hw/i386/ioapic.h" header hw/timer: Remove unused "ui/console.h" header hw/usb/dev-storage: Remove unused "ui/console.h" header hw/i386/intel_iommu: Remove unused includes hw/xen/xen_pt_load_rom: Remove unused includes hw/alpha/alpha_sys: Remove unused "hw/ide.h" header hw/alpha/dp264: Include "net/net.h" hw/hppa/machine: Include "net/net.h" hw/acpi/cpu_hotplug: Include "hw/pci/pci.h" hw/timer/hpet: Include "exec/address-spaces.h" hw/pci-host/q35: Include "qemu/range.h" hw/i2c/smbus_ich9: Include "qemu/range.h" hw/pci-host/piix: Include "qemu/range.h" hw/acpi: Include "hw/mem/nvdimm.h" hw/i386: Include "hw/mem/nvdimm.h" hw/pci-host/q35: Remove unused includes hw/i386/pc: Clean up includes hw/acpi/cpu_hotplug.c | 1 + hw/acpi/ich9.c| 2 +- hw/acpi/piix4.c | 1 + hw/alpha/alpha_sys.h | 1 - hw/alpha/dp264.c | 1 + hw/hppa/machine.c | 1 + hw/i2c/smbus_ich9.c | 1 + hw/i386/acpi-build.c | 1 + hw/i386/pc.c | 1 + hw/i386/pc_piix.c | 1 + hw/i386/pc_q35.c | 1 + hw/input/pckbd.c | 1 - hw/isa/lpc_ich9.c | 2 -- hw/pci-host/piix.c| 1 + hw/pci-host/q35.c | 1 + hw/timer/hpet.c | 2 +- hw/timer/twl92230.c | 1 - hw/usb/dev-storage.c | 1 - hw/xen/xen_pt_load_rom.c | 4 include/hw/i386/ich9.h| 1 - include/hw/i386/intel_iommu.h | 4 include/hw/i386/ioapic_internal.h | 1 - include/hw/i386/pc.h | 12 +++- include/hw/pci-host/q35.h | 8 +--- vl.c | 1 + 25 files changed, 18 insertions(+), 34 deletions(-) -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 142733: regressions - FAIL
flight 142733 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/142733/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423 version targeted for testing: ovmf a1f94045ffe9218ec438c4d23980de4243d21cd0 baseline version: ovmf 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 Last test of basis 142423 2019-10-08 01:39:34 Z6 days Failing since142455 2019-10-08 19:21:52 Z5 days 10 attempts Testing same since 142733 2019-10-14 07:49:48 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Bob Feng Feng, Bob C Jiewen Yao Laszlo Ersek Pete Batard jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 945 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 025/126] scripts: add coccinelle script to use auto propagated errp
On 10/14/19 3:19 AM, Vladimir Sementsov-Ogievskiy wrote: +| +- error_propagate(errp, local_err); +) + ...> + } + It looks like once this script is run, error_propagate_prepend() will have no clients. No, it still have a bit, when working with error_copy, and/or moving errors from/to structures. No public clients. So can we turn it into a static function only used by error.c? Is there a non-generated cleanup patch that removes it (and once it is removed, it can also be removed from the .cocci script as no further clients will reappear later)? Maybe. Basically, if we can get error_propagate out of error.h, that's a good sign. But it's not a show-stopper if we can't do it for some legitimate reason (such a reason might include that the definition of the ERRP_AUTO_PROPAGATE macro is easier to write if error_propagate remains in the .h), so we'll just have to see what is possible. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 142742: tolerable all pass - PUSHED
flight 142742 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/142742/ 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 518c935fac4d30b3ec35d4b6add82b17b7d7aca3 baseline version: xen fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8 Last test of basis 142565 2019-10-10 20:06:10 Z3 days Testing same since 142742 2019-10-14 11:01:21 Z0 days1 attempts People who touched revisions under test: Ian Jackson 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 fef8d99fbc..518c935fac 518c935fac4d30b3ec35d4b6add82b17b7d7aca3 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] x86/VT-d: Drop unhelpful information in diagnostics
On 11.10.19 17:02, Andrew Cooper wrote: The virtual address of the base of the IOMMU's regsters is not useful for diagnostic purposes, and is quite voluminous. The PCI coordinates is by far the most useful piece of identifying information. Signed-off-by: Andrew Cooper Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] docs: Extend with details about runtime microcode loading
On 12.10.19 20:18, Andrew Cooper wrote: The xen-ucode utility is new with the late loading improvements in 4.13. Update the documentation suitably. Signed-off-by: Andrew Cooper Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/8] stubdom/vtpm: include stdio.h for declaration of printf
On 14.10.19 11:02, Wei Liu wrote: Cc Juergen. Looks pretty harmless for 4.13. Yes. Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v3 09/10] libxl: Move domain_create_info_setdefault earlier
On Fri, Oct 11, 2019 at 05:55:48PM +0100, Ian Jackson wrote: > We need this before we start to figure out the passthrough mode. > > I have checked that nothing in libxl__domain_create_info_setdefault > nor the two implementations of ..._arch_... accesses anything else, > other than (i) the domain type (which this function is responsible for > setting and nothing before it looks at) (ii) c_info->ssidref (which is > defaulted by flask code near the top of > libxl__domain_config_setdefault and not accessed afterwards). > > So no functional change. > > Signed-off-by: Ian Jackson Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl: Move shadow_memkb and iommu_memkb defaulting into libxl
On Fri, Oct 11, 2019 at 05:55:44PM +0100, Ian Jackson wrote: > Defaulting is supposed to be done by libxl. So these calculations > should be here in libxl. libxl__domain_config_setdefault has all the > necessary information including the values of max_memkb and max_vcpus. > > The overall functional effect depends on the caller: > > For xl, no change. The code moves from xl to libxl. > > For callers who set one or both shadow_memkb and iommu_memkb (whether > from libxl_get_required_shadow_memory or otherwise) before calling > libxl_domain_need_memory (any version): the new code will leave their > setting(s) unchanged. > > For callers who do not call libxl_domain_need_memory at all, and who > fail to set one of these memory values: now they are both are properly > set. The shadow and iommu memory to be properly accounted for as > intended. > > For callers which call libxl_domain_need_memory and request the > current API (4.13) or which track libxl, the default values are also > now right and everything works as intended. > > For callers which call libxl_domain_need_memory, and request an old > pre-4.13 libxl API, and which leave one of these memkb settings unset, > we take special measures to preserve the old behaviour. > > This means that they don't get the additional iommu memory and are at > risk of the domain running out of memory as a result of f89f555827a6 > "remove late (on-demand) construction of IOMMU page tables". But this > is no worse than the state just after f89f555827a6, which already > broke such callers in that way. This is perhaps justifiable because > of the API stability warning next to libxl_domain_need_memory. > > An alternative would be to drop the special-casing of these callers. > That would cause a discrepancy between libxl_domain_need_memory and > libxl_domain_create: the former would not include the iommu memory and > the latter would. That seems worse, but it's debateable. > > Signed-off-by: Ian Jackson > --- > v2: Replace _Bool with bool > Fix logic sense in ok_to_default_memkb_in_create Reviewed-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ANNOUNCE] Xen 4.13 RC1
Hi all, Xen 4.13 rc1 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.13.0-rc1 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.13.0-rc1/xen-4.13.0-rc1.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.13.0-rc1/xen-4.13.0-rc1.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (jgr...@suse.com). There will be a Xen Test Day on Feb 15th. See instructions on: https://wiki.xenproject.org/wiki/Xen_4.13_RC_test_instructions https://wiki.xenproject.org/wiki/Xen_Project_Test_Days Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 07/11] dts: arm64: layerscape: add dma-ranges property to qoric-mc node
On Mon, Oct 14, 2019 at 12:00:25PM +0200, Nicolas Saenz Julienne wrote:
> On Mon, 2019-10-14 at 16:28 +0800, Shawn Guo wrote:
> > On Tue, Sep 24, 2019 at 08:12:38PM +0200, Nicolas Saenz Julienne wrote:
> > > qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
> > > which acts a bus in this regard. So far it maked all devices as
> > > dma-coherent but no dma-ranges recommendation is made.
> > >
> > > The truth is that the underlying interconnect has DMA constraints, so
> > > add an empty dma-ranges in qoriq-mc's node in order for DT's DMA
> > > configuration code to get the DMA constraints from it.
> > >
> > > Signed-off-by: Nicolas Saenz Julienne
> >
> > Updated subject prefix as 'arm64: dts: ...', and applied the patch.
>
> Hi Shawn,
> these two patches are no longer needed. This series has been superseded by
> this
> patch[1] 951d48855d ('of: Make of_dma_get_range() work on bus nodes',
> available
> in linux-next) which fixed the issue directly in OF code.
>
> Sorry for the noise.
Okay, thanks for letting me know. Dropped them.
Shawn
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Commit moratorium is lifted for getting a push
Committers, The commit moratorium is lifted, please commit patches that are already Release-acked. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/netback: cleanup init and deinit code
On Mon, 14 Oct 2019 at 10:09, Juergen Gross wrote:
>
> Do some cleanup of the netback init and deinit code:
>
> - add an omnipotent queue deinit function usable from
> xenvif_disconnect_data() and the error path of xenvif_connect_data()
> - only install the irq handlers after initializing all relevant items
> (especially the kthreads related to the queue)
> - there is no need to use get_task_struct() after creating a kthread
> and using put_task_struct() again after having stopped it.
> - use kthread_run() instead of kthread_create() to spare the call of
> wake_up_process().
I guess the reason it was done that way was to ensure that queue->task
and queue->dealloc_task would be set before the relevant threads
executed, but I don't see anywhere relying on this so I guess change
is safe. The rest of it looks fine.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
> ---
> drivers/net/xen-netback/interface.c | 114
> +---
> 1 file changed, 54 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/net/xen-netback/interface.c
> b/drivers/net/xen-netback/interface.c
> index 103ed00775eb..68dd7bb07ca6 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -626,6 +626,38 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t
> ring_ref,
> return err;
> }
>
> +static void xenvif_disconnect_queue(struct xenvif_queue *queue)
> +{
> + if (queue->tx_irq) {
> + unbind_from_irqhandler(queue->tx_irq, queue);
> + if (queue->tx_irq == queue->rx_irq)
> + queue->rx_irq = 0;
> + queue->tx_irq = 0;
> + }
> +
> + if (queue->rx_irq) {
> + unbind_from_irqhandler(queue->rx_irq, queue);
> + queue->rx_irq = 0;
> + }
> +
> + if (queue->task) {
> + kthread_stop(queue->task);
> + queue->task = NULL;
> + }
> +
> + if (queue->dealloc_task) {
> + kthread_stop(queue->dealloc_task);
> + queue->dealloc_task = NULL;
> + }
> +
> + if (queue->napi.poll) {
> + netif_napi_del(>napi);
> + queue->napi.poll = NULL;
> + }
> +
> + xenvif_unmap_frontend_data_rings(queue);
> +}
> +
> int xenvif_connect_data(struct xenvif_queue *queue,
> unsigned long tx_ring_ref,
> unsigned long rx_ring_ref,
> @@ -651,13 +683,27 @@ int xenvif_connect_data(struct xenvif_queue *queue,
> netif_napi_add(queue->vif->dev, >napi, xenvif_poll,
> XENVIF_NAPI_WEIGHT);
>
> + queue->stalled = true;
> +
> + task = kthread_run(xenvif_kthread_guest_rx, queue,
> + "%s-guest-rx", queue->name);
> + if (IS_ERR(task))
> + goto kthread_err;
> + queue->task = task;
> +
> + task = kthread_run(xenvif_dealloc_kthread, queue,
> + "%s-dealloc", queue->name);
> + if (IS_ERR(task))
> + goto kthread_err;
> + queue->dealloc_task = task;
> +
> if (tx_evtchn == rx_evtchn) {
> /* feature-split-event-channels == 0 */
> err = bind_interdomain_evtchn_to_irqhandler(
> queue->vif->domid, tx_evtchn, xenvif_interrupt, 0,
> queue->name, queue);
> if (err < 0)
> - goto err_unmap;
> + goto err;
> queue->tx_irq = queue->rx_irq = err;
> disable_irq(queue->tx_irq);
> } else {
> @@ -668,7 +714,7 @@ int xenvif_connect_data(struct xenvif_queue *queue,
> queue->vif->domid, tx_evtchn, xenvif_tx_interrupt, 0,
> queue->tx_irq_name, queue);
> if (err < 0)
> - goto err_unmap;
> + goto err;
> queue->tx_irq = err;
> disable_irq(queue->tx_irq);
>
> @@ -678,47 +724,18 @@ int xenvif_connect_data(struct xenvif_queue *queue,
> queue->vif->domid, rx_evtchn, xenvif_rx_interrupt, 0,
> queue->rx_irq_name, queue);
> if (err < 0)
> - goto err_tx_unbind;
> + goto err;
> queue->rx_irq = err;
> disable_irq(queue->rx_irq);
> }
>
> - queue->stalled = true;
> -
> - task = kthread_create(xenvif_kthread_guest_rx,
> - (void *)queue, "%s-guest-rx", queue->name);
> - if (IS_ERR(task)) {
> - pr_warn("Could not allocate kthread for %s\n", queue->name);
> - err = PTR_ERR(task);
> - goto err_rx_unbind;
> - }
> - queue->task = task;
> - get_task_struct(task);
> -
> - task = kthread_create(xenvif_dealloc_kthread,
> -
Re: [Xen-devel] [PATCH 1/2] xen/netback: fix error path of xenvif_connect_data()
On Mon, 14 Oct 2019 at 10:09, Juergen Gross wrote:
>
> xenvif_connect_data() calls module_put() in case of error. This is
> wrong as there is no related module_get().
>
> Remove the superfluous module_put().
>
> Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif
> is shut down")
> Cc: # 3.12
> Signed-off-by: Juergen Gross
Yes, looks like this should have been cleaned up a long time ago.
Reviewed-by: Paul Durrant
> ---
> drivers/net/xen-netback/interface.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/xen-netback/interface.c
> b/drivers/net/xen-netback/interface.c
> index 240f762b3749..103ed00775eb 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -719,7 +719,6 @@ int xenvif_connect_data(struct xenvif_queue *queue,
> xenvif_unmap_frontend_data_rings(queue);
> netif_napi_del(>napi);
> err:
> - module_put(THIS_MODULE);
> return err;
> }
>
> --
> 2.16.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 07/11] dts: arm64: layerscape: add dma-ranges property to qoric-mc node
On Mon, 2019-10-14 at 16:28 +0800, Shawn Guo wrote:
> On Tue, Sep 24, 2019 at 08:12:38PM +0200, Nicolas Saenz Julienne wrote:
> > qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
> > which acts a bus in this regard. So far it maked all devices as
> > dma-coherent but no dma-ranges recommendation is made.
> >
> > The truth is that the underlying interconnect has DMA constraints, so
> > add an empty dma-ranges in qoriq-mc's node in order for DT's DMA
> > configuration code to get the DMA constraints from it.
> >
> > Signed-off-by: Nicolas Saenz Julienne
>
> Updated subject prefix as 'arm64: dts: ...', and applied the patch.
Hi Shawn,
these two patches are no longer needed. This series has been superseded by this
patch[1] 951d48855d ('of: Make of_dma_get_range() work on bus nodes', available
in linux-next) which fixed the issue directly in OF code.
Sorry for the noise.
Regards,
Nicolas
[1] https://lkml.org/lkml/2019/10/8/870
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 01/28] linkage: Introduce new macros for assembler symbols
On Fri, Oct 11, 2019 at 1:53 PM Jiri Slaby wrote: > > Introduce new C macros for annotations of functions and data in > assembly. There is a long-standing mess in macros like ENTRY, END, > ENDPROC and similar. They are used in different manners and sometimes > incorrectly. > > So introduce macros with clear use to annotate assembly as follows: > > a) Support macros for the ones below >SYM_T_FUNC -- type used by assembler to mark functions >SYM_T_OBJECT -- type used by assembler to mark data >SYM_T_NONE -- type used by assembler to mark entries of unknown type > >They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE >respectively. According to the gas manual, this is the most portable >way. I am not sure about other assemblers, so this can be switched >back to %function and %object if this turns into a problem. >Architectures can also override them by something like ", @function" >if they need. > >SYM_A_ALIGN, SYM_A_NONE -- align the symbol? >SYM_L_GLOBAL, SYM_L_WEAK, SYM_L_LOCAL -- linkage of symbols > > b) Mostly internal annotations, used by the ones below >SYM_ENTRY -- use only if you have to (for non-paired symbols) >SYM_START -- use only if you have to (for paired symbols) >SYM_END -- use only if you have to (for paired symbols) > > c) Annotations for code >SYM_INNER_LABEL_ALIGN -- only for labels in the middle of code >SYM_INNER_LABEL -- only for labels in the middle of code > >SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for > one function >SYM_FUNC_START_ALIAS -- use where there are two global names for one > function >SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function > >SYM_FUNC_START -- use for global functions >SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment >SYM_FUNC_START_LOCAL -- use for local functions >SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o > alignment >SYM_FUNC_START_WEAK -- use for weak functions >SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment >SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START, > SYM_FUNC_START_WEAK, ... > >For functions with special (non-C) calling conventions: >SYM_CODE_START -- use for non-C (special) functions >SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o > alignment >SYM_CODE_START_LOCAL -- use for local non-C (special) functions >SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special) > functions, w/o alignment >SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START > > d) For data >SYM_DATA_START -- global data symbol >SYM_DATA_START_LOCAL -- local data symbol >SYM_DATA_END -- the end of the SYM_DATA_START symbol >SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol >SYM_DATA -- start+end wrapper around simple global data >SYM_DATA_LOCAL -- start+end wrapper around simple local data > > == > > The macros allow to pair starts and ends of functions and mark functions > correctly in the output ELF objects. > > All users of the old macros in x86 are converted to use these in further > patches. > > Signed-off-by: Jiri Slaby > Cc: Andrew Morton > Cc: Boris Ostrovsky > Cc: h...@zytor.com > Cc: Ingo Molnar > Cc: jpoim...@redhat.com > Cc: Juergen Gross > Cc: Len Brown > Cc: Linus Torvalds > Cc: linux-ker...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: Borislav Petkov > Cc: mi...@redhat.com > Cc: Pavel Machek > Cc: Peter Zijlstra > Cc: "Rafael J. Wysocki" > Cc: Thomas Gleixner > Cc: xen-devel@lists.xenproject.org > Cc: x...@kernel.org Acked-by: Rafael J. Wysocki for all the changes in the series affecting the power management code maintained by me. Thanks! > --- > > Notes: > [v2] > * use SYM_ prefix and sane names > * add SYM_START and SYM_END and parametrize all the macros > > [v3] > * add SYM_DATA, SYM_DATA_LOCAL, and SYM_DATA_END_LABEL > > [v4] > * add _NOALIGN versions of some macros > * add _CODE_ derivates of _FUNC_ macros > > [v5] > * drop "SIMPLE" from data annotations > * switch NOALIGN and ALIGN variants of inner labels > * s/visibility/linkage/; s@SYM_V_@SYM_L_@ > * add Documentation > > [v6] > * fixed typos found by Randy Dunlap > * remove doubled INNER_LABEL macros, one pair was unused > > [v8] > * use lkml.kernel.org for links > * link the docs from index.rst (by Boris) > * fixed typos on the docs > > [v9] > * updated the docs as requested by Boris > > Documentation/asm-annotations.rst | 216 ++ > Documentation/index.rst | 8 + > arch/x86/include/asm/linkage.h| 10 +- > include/linux/linkage.h | 245 +- > 4 files changed, 468 insertions(+), 11 deletions(-) > create mode 100644
Re: [Xen-devel] [XEN PATCH for-4.13 v1] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot
Hi Ian,
On 11/10/2019 16:14, Ian Jackson wrote:
Oleksandr Grytsov writes ("[PATCH v1] Reset iomem's gfn to LIBXL_INVALID_GFN on
reboot"):
During domain reboot its configuration is partially reused
to re-create a new domain, but iomem's GFN field for the
iomem is only restored for those memory ranges, which are
configured in form of [IOMEM_START,NUM_PAGES[@GFN], but not for
those in form of [IOMEM_START,NUM_PAGES], e.g. without GFN.
For the latter GFN is reset to 0, but while mapping ranges
to a domain during reboot there is a check that GFN treated
as valid if it is not equal to LIBXL_INVALID_GFN, thus making
Xen to map IOMEM_START to address 0 in the guest's address space.
Workaround it by resseting GFN to LIBXL_INVALID_GFN, so xl
can set proper values for mapping on reboot.
Thanks for this patch.
I confess that I am not sure what is going on here. Where is this
troublesome 0 coming from ? I see that the default value for gfn in
the struct is 0 and looking for assignments before this patch, gfn is
defaulted from b_info->iomem[i].start, which is presumably non-0.
I suspect that your patch may be fixing this the wrong way. I have
addressed this mail to various people who have touched this area of
code and hope they will be able to clarify.
I found a thread from December 2017 related to the problem described here [1].
Looking at the thread, there were no conclusion on the root causes and some
questions were left unanswered by the contributor (see [2]).
Oleksandr, could you look at the thread and see if you can provide more details
what's going on? Answering back here would be fine.
BTW, please do ping this (and your other patches) by email, if the
conversation seems to stall.
Thanks,
Ian.
Signed-off-by: Oleksandr Andrushchenko
---
tools/libxl/libxl_domain.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 9d0eb5aed1..0ae16a5b12 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -2120,6 +2120,15 @@ static void retrieve_domain_configuration_end(libxl__egc
*egc,
}
}
+/* reset IOMEM's GFN to initial value */
+{
+int i;
+
+for (i = 0; i < d_config->b_info.num_iomem; i++)
+if (d_config->b_info.iomem[i].gfn == 0)
+d_config->b_info.iomem[i].gfn = LIBXL_INVALID_GFN;
+}
+
/* Devices: disk, nic, vtpm, pcidev etc. */
/* The MERGE macro implements following logic:
--
2.17.1
Cheers,
[1]
[2] <20180213122432.h4fh22ej4dfe7...@citrix.com>
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
12.10.2019 5:10, no-re...@patchew.org wrote: > Patchew URL: > https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/ > > > > Hi, > > This series failed the docker-quick@centos7 build test. Please find the > testing commands and > their output below. If you have Docker installed, you can probably reproduce > it > locally. > > === TEST SCRIPT BEGIN === > #!/bin/bash > make docker-image-centos7 V=1 NETWORK=1 > time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 > === TEST SCRIPT END === > >TESTiotest-qcow2: 013 >TESTcheck-unit: tests/test-block-iothread >TESTcheck-unit: tests/test-image-locking > warning: Failed to get shared "consistent read" lock > Is another process using the image [/tmp/qtest.O66l3t]? > warning: Failed to get shared "consistent read" lock > Is another process using the image [/tmp/qtest.G0M9V8]? >TESTcheck-unit: tests/test-x86-cpuid >TESTcheck-unit: tests/test-xbzrle > --- >TESTiotest-qcow2: 267 > Failures: 054 > Failed 1 of 108 iotests > make: *** [check-tests/check-block.sh] Error 1 > make: *** Waiting for unfinished jobs >TESTcheck-qtest-aarch64: tests/qos-test > Traceback (most recent call last): > --- > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', > '--label', 'com.qemu.instance.uuid=2c55fb61a63a409382f2b3a99fca93d9', '-u', > '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', > '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', > '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', > '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', > '/var/tmp/patchew-tester-tmp-usvi8fob/src/docker-src.2019-10-11-22.00.10.1933:/var/tmp/qemu:z,ro', > 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit > status 2. > filter=--filter=label=com.qemu.instance.uuid=2c55fb61a63a409382f2b3a99fca93d9 > make[1]: *** [docker-run] Error 1 > make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-usvi8fob/src' > make: *** [docker-run-test-quick@centos7] Error 2 Something strange. Who knows, what is it? > > real10m33.714s > user0m8.360s > > > The full log is available at > http://patchew.org/logs/20191011160552.22907-1-vsement...@virtuozzo.com/testing.docker-quick@centos7/?type=message. "" Not Found The requested resource was not found on this server. "" > --- > Email generated automatically by Patchew [https://patchew.org/]. > Please send your feedback to patchew-de...@redhat.com > -- Best regards, Vladimir ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
12.10.2019 5:52, no-re...@patchew.org wrote: > Patchew URL: > https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/ > > > > Hi, > > This series seems to have some coding style problems. See output below for > more information: > > Subject: [RFC v5 000/126] error: auto propagated local_err > Type: series > Message-id: 20191011160552.22907-1-vsement...@virtuozzo.com > > === TEST SCRIPT BEGIN === > #!/bin/bash > git rev-parse base > /dev/null || exit 0 > git config --local diff.renamelimit 0 > git config --local diff.renames True > git config --local diff.algorithm histogram > ./scripts/checkpatch.pl --mailback base.. > === TEST SCRIPT END === > > Switched to a new branch 'test' > 319b206 util/qemu-config.c: introduce ERRP_AUTO_PROPAGATE > 3ee6567 tests/test-image-locking.c: introduce ERRP_AUTO_PROPAGATE > 2e4f371 target/tilegx/cpu.c: introduce ERRP_AUTO_PROPAGATE > 5f766d7 memory_mapping.c: introduce ERRP_AUTO_PROPAGATE > 8969c6f iothread.c: introduce ERRP_AUTO_PROPAGATE > 1534a92 hw/sd/ssi-sd.c: introduce ERRP_AUTO_PROPAGATE > b5b1e0a hw/cpu/core.c: introduce ERRP_AUTO_PROPAGATE > dd3f310 hw/core/bus.c: introduce ERRP_AUTO_PROPAGATE > 21ee5f8 PVRDMA: introduce ERRP_AUTO_PROPAGATE > 84365ab Replication: introduce ERRP_AUTO_PROPAGATE > 225bbc5 vvfat: introduce ERRP_AUTO_PROPAGATE > 2da58d6 vpc: introduce ERRP_AUTO_PROPAGATE > e7fb0b9 blkdebug: introduce ERRP_AUTO_PROPAGATE > 39d367e qcow: introduce ERRP_AUTO_PROPAGATE > 1b7546c qcow2: introduce ERRP_AUTO_PROPAGATE > c0352a1 raw: introduce ERRP_AUTO_PROPAGATE > 612aebf qed: introduce ERRP_AUTO_PROPAGATE > 155f6ea parallels: introduce ERRP_AUTO_PROPAGATE > 5d3c3fd blkverify: introduce ERRP_AUTO_PROPAGATE > 36132e6 blklogwrites: introduce ERRP_AUTO_PROPAGATE > 785cfb4 Quorum: introduce ERRP_AUTO_PROPAGATE > 5acba63 Bootdevice: introduce ERRP_AUTO_PROPAGATE > 0e0d3fb NVMe Block Driver: introduce ERRP_AUTO_PROPAGATE > 1cf6911 GLUSTER: introduce ERRP_AUTO_PROPAGATE > cb4c8f7 CURL: introduce ERRP_AUTO_PROPAGATE > 4e32493 SSH: introduce ERRP_AUTO_PROPAGATE > abbecd4 NFS: introduce ERRP_AUTO_PROPAGATE > f4f937d nbd: introduce ERRP_AUTO_PROPAGATE > 7b638b3 iSCSI: introduce ERRP_AUTO_PROPAGATE > 4727ffc VDI: introduce ERRP_AUTO_PROPAGATE > 2c03145 VHDX: introduce ERRP_AUTO_PROPAGATE > 7916a87 Sheepdog: introduce ERRP_AUTO_PROPAGATE > db15fdd RBD: introduce ERRP_AUTO_PROPAGATE > 05ea2cf VMDK: introduce ERRP_AUTO_PROPAGATE > ff11144 Record/replay: introduce ERRP_AUTO_PROPAGATE > a95fab2 colo: introduce ERRP_AUTO_PROPAGATE > be71202 Sockets: introduce ERRP_AUTO_PROPAGATE > 69a59b0 I/O Channels: introduce ERRP_AUTO_PROPAGATE > e4f56f3 Cryptography: introduce ERRP_AUTO_PROPAGATE > 4f5f412 Migration: introduce ERRP_AUTO_PROPAGATE > 985da1a TPM: introduce ERRP_AUTO_PROPAGATE > b19cdab Tracing: introduce ERRP_AUTO_PROPAGATE > 3113fc7 SLIRP: introduce ERRP_AUTO_PROPAGATE > 51e2f48 QMP: introduce ERRP_AUTO_PROPAGATE > 1c0c827 QOM: introduce ERRP_AUTO_PROPAGATE > fc0eec4 qga: introduce ERRP_AUTO_PROPAGATE > af16041 QAPI: introduce ERRP_AUTO_PROPAGATE > 21ed21e cryptodev: introduce ERRP_AUTO_PROPAGATE > 7ab6e12 hostmem: introduce ERRP_AUTO_PROPAGATE > 994c02c net: introduce ERRP_AUTO_PROPAGATE > 26fe9a4 Human Monitor (HMP): introduce ERRP_AUTO_PROPAGATE > 82b7f8b Main loop: introduce ERRP_AUTO_PROPAGATE > 863100d Graphics: introduce ERRP_AUTO_PROPAGATE > 45a8d41 SPICE: introduce ERRP_AUTO_PROPAGATE > 6d967ec Memory API: introduce ERRP_AUTO_PROPAGATE > 5645325 Dump: introduce ERRP_AUTO_PROPAGATE > 6d795b4 cmdline: introduce ERRP_AUTO_PROPAGATE > 5fceaa3 chardev: introduce ERRP_AUTO_PROPAGATE > d551bda scsi: introduce ERRP_AUTO_PROPAGATE > cc3d83e block: introduce ERRP_AUTO_PROPAGATE > 75b948b Audio: introduce ERRP_AUTO_PROPAGATE > c3fee2f XIVE: introduce ERRP_AUTO_PROPAGATE > 42ba3e1 fw_cfg: introduce ERRP_AUTO_PROPAGATE > 90c4efa virtio-gpu: introduce ERRP_AUTO_PROPAGATE > 4db3f47 eepro100: introduce ERRP_AUTO_PROPAGATE > d7634f4 NVDIMM: introduce ERRP_AUTO_PROPAGATE > 706ee21 megasas: introduce ERRP_AUTO_PROPAGATE > a037a5c virtio-rng: introduce ERRP_AUTO_PROPAGATE > dcf1769 virtio-serial: introduce ERRP_AUTO_PROPAGATE > 77d26d1 virtio-input: introduce ERRP_AUTO_PROPAGATE > 7f62cb1 virtio-ccw: introduce ERRP_AUTO_PROPAGATE > 2bdd860 virtio-blk: introduce ERRP_AUTO_PROPAGATE > 026260e virtio-9p: introduce ERRP_AUTO_PROPAGATE > 191c845 virtio: introduce ERRP_AUTO_PROPAGATE > 24510de vhost: introduce ERRP_AUTO_PROPAGATE > e8a1779 vfio-ccw: introduce ERRP_AUTO_PROPAGATE > 00baaa3 VFIO: introduce ERRP_AUTO_PROPAGATE > 361c201 USB (serial adapter): introduce ERRP_AUTO_PROPAGATE > 0f70e97 USB: introduce ERRP_AUTO_PROPAGATE > 9548378 SD (Secure Card): introduce ERRP_AUTO_PROPAGATE > 90b472d SCSI: introduce ERRP_AUTO_PROPAGATE > 312220a pflash: introduce ERRP_AUTO_PROPAGATE > 47a7bb5 Network devices: introduce ERRP_AUTO_PROPAGATE > bf2e1ef ACPI/SMBIOS: introduce ERRP_AUTO_PROPAGATE > 98f6d04 PCI: introduce ERRP_AUTO_PROPAGATE > e3e14fe IPack: introduce
[Xen-devel] [PATCH 1/2] xen/netback: fix error path of xenvif_connect_data()
xenvif_connect_data() calls module_put() in case of error. This is
wrong as there is no related module_get().
Remove the superfluous module_put().
Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif is
shut down")
Cc: # 3.12
Signed-off-by: Juergen Gross
---
drivers/net/xen-netback/interface.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 240f762b3749..103ed00775eb 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -719,7 +719,6 @@ int xenvif_connect_data(struct xenvif_queue *queue,
xenvif_unmap_frontend_data_rings(queue);
netif_napi_del(>napi);
err:
- module_put(THIS_MODULE);
return err;
}
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] xen/netback: cleanup init and deinit code
Do some cleanup of the netback init and deinit code:
- add an omnipotent queue deinit function usable from
xenvif_disconnect_data() and the error path of xenvif_connect_data()
- only install the irq handlers after initializing all relevant items
(especially the kthreads related to the queue)
- there is no need to use get_task_struct() after creating a kthread
and using put_task_struct() again after having stopped it.
- use kthread_run() instead of kthread_create() to spare the call of
wake_up_process().
Signed-off-by: Juergen Gross
---
drivers/net/xen-netback/interface.c | 114 +---
1 file changed, 54 insertions(+), 60 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 103ed00775eb..68dd7bb07ca6 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -626,6 +626,38 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t
ring_ref,
return err;
}
+static void xenvif_disconnect_queue(struct xenvif_queue *queue)
+{
+ if (queue->tx_irq) {
+ unbind_from_irqhandler(queue->tx_irq, queue);
+ if (queue->tx_irq == queue->rx_irq)
+ queue->rx_irq = 0;
+ queue->tx_irq = 0;
+ }
+
+ if (queue->rx_irq) {
+ unbind_from_irqhandler(queue->rx_irq, queue);
+ queue->rx_irq = 0;
+ }
+
+ if (queue->task) {
+ kthread_stop(queue->task);
+ queue->task = NULL;
+ }
+
+ if (queue->dealloc_task) {
+ kthread_stop(queue->dealloc_task);
+ queue->dealloc_task = NULL;
+ }
+
+ if (queue->napi.poll) {
+ netif_napi_del(>napi);
+ queue->napi.poll = NULL;
+ }
+
+ xenvif_unmap_frontend_data_rings(queue);
+}
+
int xenvif_connect_data(struct xenvif_queue *queue,
unsigned long tx_ring_ref,
unsigned long rx_ring_ref,
@@ -651,13 +683,27 @@ int xenvif_connect_data(struct xenvif_queue *queue,
netif_napi_add(queue->vif->dev, >napi, xenvif_poll,
XENVIF_NAPI_WEIGHT);
+ queue->stalled = true;
+
+ task = kthread_run(xenvif_kthread_guest_rx, queue,
+ "%s-guest-rx", queue->name);
+ if (IS_ERR(task))
+ goto kthread_err;
+ queue->task = task;
+
+ task = kthread_run(xenvif_dealloc_kthread, queue,
+ "%s-dealloc", queue->name);
+ if (IS_ERR(task))
+ goto kthread_err;
+ queue->dealloc_task = task;
+
if (tx_evtchn == rx_evtchn) {
/* feature-split-event-channels == 0 */
err = bind_interdomain_evtchn_to_irqhandler(
queue->vif->domid, tx_evtchn, xenvif_interrupt, 0,
queue->name, queue);
if (err < 0)
- goto err_unmap;
+ goto err;
queue->tx_irq = queue->rx_irq = err;
disable_irq(queue->tx_irq);
} else {
@@ -668,7 +714,7 @@ int xenvif_connect_data(struct xenvif_queue *queue,
queue->vif->domid, tx_evtchn, xenvif_tx_interrupt, 0,
queue->tx_irq_name, queue);
if (err < 0)
- goto err_unmap;
+ goto err;
queue->tx_irq = err;
disable_irq(queue->tx_irq);
@@ -678,47 +724,18 @@ int xenvif_connect_data(struct xenvif_queue *queue,
queue->vif->domid, rx_evtchn, xenvif_rx_interrupt, 0,
queue->rx_irq_name, queue);
if (err < 0)
- goto err_tx_unbind;
+ goto err;
queue->rx_irq = err;
disable_irq(queue->rx_irq);
}
- queue->stalled = true;
-
- task = kthread_create(xenvif_kthread_guest_rx,
- (void *)queue, "%s-guest-rx", queue->name);
- if (IS_ERR(task)) {
- pr_warn("Could not allocate kthread for %s\n", queue->name);
- err = PTR_ERR(task);
- goto err_rx_unbind;
- }
- queue->task = task;
- get_task_struct(task);
-
- task = kthread_create(xenvif_dealloc_kthread,
- (void *)queue, "%s-dealloc", queue->name);
- if (IS_ERR(task)) {
- pr_warn("Could not allocate kthread for %s\n", queue->name);
- err = PTR_ERR(task);
- goto err_rx_unbind;
- }
- queue->dealloc_task = task;
-
- wake_up_process(queue->task);
- wake_up_process(queue->dealloc_task);
-
return 0;
-err_rx_unbind:
- unbind_from_irqhandler(queue->rx_irq, queue);
- queue->rx_irq = 0;
-err_tx_unbind:
- unbind_from_irqhandler(queue->tx_irq, queue);
-
[Xen-devel] [PATCH 0/2] xen/netback: bug fix and cleanup
One bugfix (patch 1) I stumbled over while doing a cleanup (patch 2) of the xen-netback init/deinit code. Juergen Gross (2): xen/netback: fix error path of xenvif_connect_data() xen/netback: cleanup init and deinit code drivers/net/xen-netback/interface.c | 115 +--- 1 file changed, 54 insertions(+), 61 deletions(-) -- 2.16.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 142711: regressions - FAIL
flight 142711 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/142711/ 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 142648 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142685 pass in 142606 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 142685 pass in 142648 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142648 test-amd64-amd64-xl-pvshim 12 guest-startfail pass in 142685 test-armhf-armhf-libvirt-raw 7 xen-boot fail pass in 142685 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 142606 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 142606 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-xl-credit1 7 xen-boot 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-arm64-arm64-libvirt-xsm 7 xen-boot 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-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail 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-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-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-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-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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 test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail 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-arm64-arm64-xl 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-amd64-i386-xl-qemuu-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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-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
Re: [Xen-devel] [PATCH v2 1/8] stubdom/vtpm: include stdio.h for declaration of printf
Cc Juergen. Looks pretty harmless for 4.13. On Mon, 14 Oct 2019 at 05:23, Samuel Thibault wrote: > > Olaf Hering, le dim. 13 oct. 2019 18:50:32 +0200, a ecrit: > > Am Sun, 13 Oct 2019 18:21:27 +0200 > > schrieb Samuel Thibault : > > > > > > > cked-by: Daniel De Graaf > > > > > > Note that you miss an 'A' at the beginning of the line there. > > > > Thanks for spotting. > > > > Should I resend this patch? > > With the fixed Acked-by and my Reviewed-by, yes. > > Samuel > > ___ > 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] [RFC v5 000/126] error: auto propagated local_err
11.10.2019 20:02, Eric Blake wrote: > On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote: >> Hi all! >> >> At the request of Markus: full version of errp propagation. Let's look >> at it. Cover as much as possible, except inserting macro invocation >> where it's not necessary. >> >> It's huge, and so it's an RFC. > > Is there a repo containing these patches, to make it easier to play with them > locally without having to 'git am' the entire 126 messages? Done: https://src.openvz.org/users/vsementsov/repos/qemu/browse https://src.openvz.org/scm/~vsementsov/qemu.git #tag up-auto-local-err-v5 > > >> util/qemu-sockets.c | 31 +-- >> vl.c | 14 +- >> python/commit-per-subsystem.py | 204 ++ >> scripts/coccinelle/auto-propagated-errp.cocci | 118 >> 341 files changed, 3851 insertions(+), 4455 deletions(-) >> create mode 100755 python/commit-per-subsystem.py >> create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci > > So, whether or not we take commit-per-subsystem.py, the overall series > appears to be a nice reduction in lines of code. > -- Best regards, Vladimir ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 142709: regressions - FAIL
flight 142709 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/142709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 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-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 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-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-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-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 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-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-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-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 133580 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: 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-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133580 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail 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-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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail 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-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 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
Re: [Xen-devel] [PATCH 08/11] dts: arm64: layerscape: add dma-ranges property to pcie nodes
On Tue, Sep 24, 2019 at 08:12:39PM +0200, Nicolas Saenz Julienne wrote: > The bus behind the board's PCIe core has DMA addressing limitations. Add > an empty 'dma-ranges' property on all PCIe bus descriptions to inform > the OF core that a translation is due further down the line. > > Signed-off-by: Nicolas Saenz Julienne Applied, thanks. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 07/11] dts: arm64: layerscape: add dma-ranges property to qoric-mc node
On Tue, Sep 24, 2019 at 08:12:38PM +0200, Nicolas Saenz Julienne wrote: > qoriq-mc's dpmacs DMA configuration is inherited from their parent node, > which acts a bus in this regard. So far it maked all devices as > dma-coherent but no dma-ranges recommendation is made. > > The truth is that the underlying interconnect has DMA constraints, so > add an empty dma-ranges in qoriq-mc's node in order for DT's DMA > configuration code to get the DMA constraints from it. > > Signed-off-by: Nicolas Saenz Julienne Updated subject prefix as 'arm64: dts: ...', and applied the patch. Shawn > --- > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 1 + > arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 1 + > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 1 + > 3 files changed, 3 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > index c676d0771762..f0d0b6145b72 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > @@ -698,6 +698,7 @@ > <0x 0x0834 0 0x4>; /* MC control > reg */ > msi-parent = <>; > iommu-map = <0 0 0>; /* This is fixed-up by > u-boot */ > + dma-ranges; > dma-coherent; > #address-cells = <3>; > #size-cells = <1>; > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi > b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi > index 7a0be8eaa84a..fd6036b7865c 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi > @@ -340,6 +340,7 @@ > <0x 0x0834 0 0x4>; /* MC control > reg */ > msi-parent = <>; > iommu-map = <0 0 0>; /* This is fixed-up by > u-boot */ > + dma-ranges; > dma-coherent; > #address-cells = <3>; > #size-cells = <1>; > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > index 408e0ecdce6a..3735bb139cb2 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > @@ -868,6 +868,7 @@ > msi-parent = <>; > /* iommu-map property is fixed up by u-boot */ > iommu-map = <0 0 0>; > + dma-ranges; > dma-coherent; > #address-cells = <3>; > #size-cells = <1>; > -- > 2.23.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 025/126] scripts: add coccinelle script to use auto propagated errp
11.10.2019 20:12, Eric Blake wrote:
> On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> ---
>>
>
>> scripts/coccinelle/auto-propagated-errp.cocci | 118 ++
>> 1 file changed, 118 insertions(+)
>> create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
>>
>> diff --git a/scripts/coccinelle/auto-propagated-errp.cocci
>> b/scripts/coccinelle/auto-propagated-errp.cocci
>> new file mode 100644
>> index 00..d9731620aa
>> --- /dev/null
>> +++ b/scripts/coccinelle/auto-propagated-errp.cocci
>
>> +@rule1@
>> +// Drop local_err
>> +identifier fn, local_err;
>> +symbol errp;
>> +@@
>> +
>> + fn(..., Error **errp, ...)
>> + {
>> + <...
>> +- Error *local_err = NULL;
>> + ...>
>> + }
>> +
>
> So our goal is to automate removal of all local_err (including when it is
> spelled err)...
>
>> +@@
>> +// Handle pattern with goto, otherwise we'll finish up
>> +// with labels at function end which will not compile.
>> +identifier rule1.fn;
>> +identifier rule1.local_err;
>> +identifier OUT;
>> +@@
>> +
>> + fn(...)
>> + {
>> + <...
>> +- goto OUT;
>> ++ return;
>> + ...>
>> +- OUT:
>> +- error_propagate(errp, local_err);
>> + }
>> +
>
> this dangling label cleanup makes sense
>
>> +@@
>> +identifier rule1.fn;
>> +identifier rule1.local_err;
>> +@@
>> +
>> + fn(...)
>> + {
>> + <...
>> +(
>> +- error_free(local_err);
>> +- local_err = NULL;
>> ++ error_free_errp(errp);
>
> This does not make sense - error_free_errp() is not defined prior to this
> series or anywhere in patches 1-24, if I'm reading it correctly.
>
>> +|
>> +- error_free(local_err);
>> ++ error_free_errp(errp);
>
> and again
>
>> +|
>> +- error_report_err(local_err);
>> ++ error_report_errp(errp);
>> +|
>> +- warn_report_err(local_err);
>> ++ warn_report_errp(errp);
>> +|
>> +- error_propagate_prepend(errp, local_err,
>> ++ error_prepend(errp,
>> + ...);
>> +|
>> +- error_propagate(errp, local_err);
>> +)
>> + ...>
>> + }
>> +
>
> It looks like once this script is run, error_propagate_prepend() will have no
> clients.
No, it still have a bit, when working with error_copy, and/or moving errors
from/to structures.
> Is there a non-generated cleanup patch that removes it (and once it is
> removed, it can also be removed from the .cocci script as no further clients
> will reappear later)?
Maybe.
>
>
>> +@@
>> +identifier rule1.fn;
>> +identifier rule1.local_err;
>> +@@
>> +
>> + fn(...)
>> + {
>> + <...
>> +(
>> +- _err
>> ++ errp
>> +|
>> +- local_err
>> ++ *errp
>> +)
>> + ...>
>> + }
>> +
>> +@@
>> +symbol errp;
>> +@@
>> +
>> +- *errp != NULL
>> ++ *errp
>>
>
> Seems to make sense.
>
--
Best regards,
Vladimir
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic
On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
>
> Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> Overhaul passthrough setting logic"):
> > On 11.10.19 15:31, Ian Jackson wrote:
> > > I do not have a strong opinion about this. I would be happy with
> > > "auto" (or "default" maybe).
> >
> > "unspecified"?
>
> That is IMO the best suggestion so far so I will go with that in my
> v3.
Seems odd to specify a parameter with a value of 'unspecified' ;-)
Paul
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 142717: regressions - FAIL
flight 142717 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/142717/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423 version targeted for testing: ovmf 778832bcad33512ae09bbf7235a1ddcfa7403083 baseline version: ovmf 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 Last test of basis 142423 2019-10-08 01:39:34 Z6 days Failing since142455 2019-10-08 19:21:52 Z5 days9 attempts Testing same since 142636 2019-10-12 01:55:30 Z2 days4 attempts People who touched revisions under test: Ard Biesheuvel Jiewen Yao Laszlo Ersek Pete Batard jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 929 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
