[Xen-devel] [linux-3.18 test] 123480: regressions - FAIL
flight 123480 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123480/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail REGR. vs. 123222 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 123274 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123274 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123274 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123274 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123274 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123274 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123274 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123274 build-arm64-pvops 6 kernel-build fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail 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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 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-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-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 version targeted for testing: linuxb0b357c20ca6171b8ac698351f5202402b7ad7d5 baseline version: linuxb87af3ab9dae0dc53b201701725ed6e2af4f2f74 Last test of basis 123274 2018-05-27 22:03:44 Z5 days Failing since123396 2018-05-30 06:10:32 Z2 days2 attempts Testing same since 123480 2018-05-31 17:23:55 Z1 days1 attempts People who touched revisions under test:
[Xen-devel] [xen-4.9-testing test] 123473: regressions - FAIL
flight 123473 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123473/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123122 test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail REGR. vs. 123122 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail like 122960 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 123009 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 123122 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 123122 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123122 test-amd64-i386-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail like 123122 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 123122 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123122 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-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-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 1c6b8f23b9c5099cdf9a530e0d044b1ab5a83511 baseline version: xen 74fa9552c1e3ef79bd4db0a67fc538bbd61b7561 Last test of basis 123122 2018-05-23 17:52:21 Z9 days Failing since123343 2018-05-29 08:06:53 Z3 days3 attempts Testing same since 123473 2018-05-31 16:12:30 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Juergen Gross Wei Liu
[Xen-devel] [distros-debian-jessie test] 74770: tolerable FAIL
flight 74770 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74770/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74743 baseline version: flight 74743 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub pass test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub fail test-amd64-amd64-i386-jessie-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 10/10] xen: add per-platform defaults for NR_CPUS
On Fri, 1 Jun 2018, Julien Grall wrote: > Hi, > Sorry for the formatting. I am pretty sure you need to CC "THE REST" here. > > On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote: > Add specific per-platform defaults for NR_CPUS. Note that the order of > the defaults matter: they need to go first, otherwise the generic > defaults will be applied. > > This is done so that Xen builds customized for a specific hardware > platform can have the right NR_CPUS number. > > Signed-off-by: Stefano Stabellini > CC: jbeul...@suse.com > CC: andrew.coop...@citrix.com > --- > xen/arch/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig > index cf0acb7..d451eb8 100644 > --- a/xen/arch/Kconfig > +++ b/xen/arch/Kconfig > @@ -2,6 +2,9 @@ > config NR_CPUS > int "Maximum number of physical CPUs" > range 1 4095 > + default "8" if ARM && RCAR3 > + default "4" if ARM && QEMU > + default "4" if ARM && MPSOC > default "256" if X86 > default "128" if ARM > ---help--- > > > But I am not sure how this will work as with this series you can select > multiple platforms in on Kconfig. What will be the end > result? The end result is the first default that applies. In this case, if RCAR3, QEMU and MPSOC are all selected, then NR_CPUS would be set to 8, which is actually what one would want if she is trying to build Xen for these three platforms, but it is not what one would want if she was trying to build a generic Xen config for distros. This is not great. The option list you suggested could help solve the NR_CPUS issue, see below. > Anyway, as I mention the way to go is a option list with only one possible > choice. I am OK with an option list, the issue that we cannot have an ALL option in the list that selects the other options as I wrote previously. For instance, the following is NOT allowed: config ALL bool "All Platforms" select MPSOC However, having CONFIG_ALL would solve the NR_CPUS problem because we could do: config NR_CPUS default "128" if ARM && ALL default "8" if ARM && RCAR3 default "4" if ARM && QEMU default "4" if ARM && MPSOC default "128" if ARM Which would give us exactly the default we want for NR_CPUS. So I agree that we should turn platform support into an option list and we should also add an ALL option to solve the NR_CPUS problem. If we do that, the remaining problem is how to implement ALL. I found a workaround for the kconfig issue described above. The following works correctly: choice prompt "Platform Support" default ALL ---help--- Choose Xen support for different hardware platforms. config ALL bool "All Platforms" select MPSOC_PLATFORM select QEMU_PLATFORM select RCAR3_PLATFORM ---help--- Enable support for all platforms. config QEMU bool "QEMU aarch virt machine support" depends on ARM_64 select QEMU_PLATFORM ---help--- Enable all the required drivers for QEMU aarch64 virt emulated machine. config RCAR3 bool "Renesas RCar3 support" depends on ARM_64 select RCAR3_PLATFORM ---help--- Enable all the required drivers for Renesas RCar3 config MPSOC bool "Xilinx Ultrascale+ MPSoC support" depends on ARM_64 select MPSOC_PLATFORM ---help--- Enable all the required drivers for Xilinx Ultrascale+ MPSoC endchoice config QEMU_PLATFORM bool select GICV3 select HAS_PL011 config RCAR3_PLATFORM bool select HAS_SCIF config MPSOC_PLATFORM bool select HAS_CADENCE_UART select ARM_SMMU This looks like the best way forward and would solve all issues.___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 10/10] xen: add per-platform defaults for NR_CPUS
On Fri, 1 Jun 2018, Jan Beulich wrote: > >>> On 31.05.18 at 23:48, wrote: > > Add specific per-platform defaults for NR_CPUS. Note that the order of > > the defaults matter: they need to go first, otherwise the generic > > defaults will be applied. > > Still I'd prefer the ARM ones to follow the X86 one (keeping the ARM ones > together), unless you follow Julien's advice anyway and move the setting > into arch//Kconfig. I'll move the x86 default first. I would prefer to keep the NR_CPUS option shared in xen/arch/Kconfig. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 07/10] arm: add a tiny kconfig configuration
On Fri, 1 Jun 2018, Julien Grall wrote: > Hi, > Sorry for the formatting. > > On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote: > Add a tiny kconfig configuration. Enabled NULL and Credit schedulers. > Support only 8 cpus. It only carries non-default options (use make > olddefconfig to produce a complete .config file). > > Signed-off-by: Stefano Stabellini > > --- > Note that this approach has a limitation: it is not possible to "select > a range". In other words, using tiny.config NR_CPUS is set to 4. It is > not possible to increase it to 8 from config RCAR3. > > > Is that still true? I thought we discussed a solution to do it yesterday. No, it is not true anymore. See the longer explanation I sent in reply to the other emails. I'll remove this paragraph next time. > By that, I mean the platform would be selected at olddefconfig. > > --- > xen/arch/arm/configs/tiny.conf | 43 > ++ > 1 file changed, 43 insertions(+) > create mode 100644 xen/arch/arm/configs/tiny.conf > > diff --git a/xen/arch/arm/configs/tiny.conf > b/xen/arch/arm/configs/tiny.conf > new file mode 100644 > index 000..e9a5e65 > --- /dev/null > +++ b/xen/arch/arm/configs/tiny.conf > @@ -0,0 +1,43 @@ > +CONFIG_ARM_64=y > +CONFIG_ARM=y > + > +# > +# Architecture Features > +# > +# CONFIG_GICV3 is not set > +# CONFIG_MEM_ACCESS is not set > +# CONFIG_SBSA_VUART_CONSOLE is not set > + > +# > +# Common Features > +# > +# CONFIG_TMEM is not set > + > +# > +# Schedulers > +# > +# CONFIG_SCHED_CREDIT2 is not set > +# CONFIG_SCHED_RTDS is not set > +# CONFIG_SCHED_ARINC653 is not set > +CONFIG_SCHED_NULL=y > +CONFIG_SCHED_NULL_DEFAULT=y > +CONFIG_SCHED_DEFAULT="null" > +# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set > + > +# > +# Device Drivers > +# > +# CONFIG_HAS_NS16550 is not set > +# CONFIG_HAS_CADENCE_UART is not set > +# CONFIG_HAS_MVEBU is not set > +# CONFIG_HAS_PL011 is not set > +# CONFIG_HAS_SCIF is not set > +# CONFIG_ARM_SMMU is not set > + > +# > +# Debugging Options > +# > +# CONFIG_DEBUG is not set > +# CONFIG_FRAME_POINTER is not set > +# CONFIG_VERBOSE_DEBUG is not set > +# CONFIG_SCRUB_DEBUG is not set > -- > 1.9.1 > > > ___ > 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] [PATCH v4 08/10] arm: add QEMU, Rcar3 and MPSoC configs
On Fri, 1 Jun 2018, Julien Grall wrote: > Hi Stefano, > Sorry for formatting. > > On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote: > Add a "Platform Support" menu with three umbrella kconfig options: QEMU, > RCAR3 and MPSOC. They enable the required options for their hardware > platform. > > > This patch is nothing close to what we discussed. As far as I can tell, the > tiny.config will end up to select all the platforms > with their driver. It will not be possible to deselect the driver selected > for a platform afterwards. > > I still think the best if providing a choice list where only one option can > be selected. I would like to understand why you > didn't go this path. Yes, sorry, I didn't explain why I did this and what I told you on the call was wrong, adding to the confusion. First, it is true that `make olddefconfig' is run automatically on any make target. Except for `make menuconfig', that's special. If you copy a partial config (like tiny.config) to .config, then execute `make menuconfig', the menu gets automatically populated with the missing values using defaults (as if olddefconfig was run), but it won't automatically save them to file (fortunately!!). That means that all the platform options below (QEMU, RCAR3, MPSOC) will show as selected in the menu, but if the user deselects two of them, for instance QEMU and RCAR3, the result is that *only* MPSOC and related options will be written down to the .config. The kconfig infrastructure is not as bad as I initially thought :-) In short, the following steps work: - copy tiny.config to .config - make menuconfig -> deselect QEMU and RCAR3, save .config - as a results the final .config will have: CONFIG_MPSOC=y CONFIG_HAS_CADENCE_UART=y but it won't have GICV3, any other platform options, or any other uart drivers. Moreover, even NR_CPUS will be set correctly: CONFIG_NR_CPUS=4 I am attaching the .config for MPSOC produced using these steps as a reference. More on the NR_CPUS topic in my next email reply. > In the case of the MPSOC that has a platform file under > arch/arm/platforms/, build the file if MPSOC. > > Signed-off-by: Stefano Stabellini > CC: artem_myga...@epam.com > CC: volodymyr_babc...@epam.com > > --- > Changes in v4: > - fix GICv3/GICV3 > - default y to all options > - build xilinx-zynqmp if MPSOC > --- > xen/arch/arm/Kconfig | 2 ++ > xen/arch/arm/platforms/Kconfig | 30 ++ > xen/arch/arm/platforms/Makefile | 2 +- > 3 files changed, 33 insertions(+), 1 deletion(-) > create mode 100644 xen/arch/arm/platforms/Kconfig > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 2b87111..75cacfb 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR > config ARM32_HARDEN_BRANCH_PREDICTOR > def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR > > +source "arch/arm/platforms/Kconfig" > + > source "common/Kconfig" > > source "drivers/Kconfig" > diff --git a/xen/arch/arm/platforms/Kconfig > b/xen/arch/arm/platforms/Kconfig > new file mode 100644 > index 000..fea8f9a > --- /dev/null > +++ b/xen/arch/arm/platforms/Kconfig > @@ -0,0 +1,30 @@ > +menu "Platform Support" > + > +config QEMU > + bool "QEMU aarch virt machine support" > + default y > + depends on ARM_64 > + select GICV3 > + select HAS_PL011 > + ---help--- > + Enable all the required drivers for QEMU aarch64 virt emulated > + machine. > + > +config RCAR3 > + bool "Renesas RCar3 support" > + default y > + depends on ARM_64 > + select HAS_SCIF > + ---help--- > + Enable all the required drivers for Renesas RCar3 > + > +config MPSOC > + bool "Xilinx Ultrascale+ MPSoC support" > + default y > + depends on ARM_64 > + select HAS_CADENCE_UART > + select ARM_SMMU > + ---help--- > + Enable all the required drivers for Xilinx Ultrascale+ MPSoC > + > +endmenu > diff --git a/xen/arch/arm/platforms/Makefile > b/xen/arch/arm/platforms/Makefile > index 80e555c..f4ff411 100644 > --- a/xen/arch/arm/platforms/Makefile > +++ b/xen/arch/arm/platforms/Makefile > @@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o > obj-y += sunxi.o > obj-$(CONFIG_ARM_64) += thunderx.o > obj-$(CONFIG_ARM_64) += xgene-storm.o > -obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o > +obj-$(CONFIG_MPSOC) += xilinx-zynqmp.o > -- > 1.9.1 > > >
[Xen-devel] [qemu-mainline test] 123449: tolerable FAIL - PUSHED
flight 123449 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/123449/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123367 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123367 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123367 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123367 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123367 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123367 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail 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-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 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-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 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-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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-qemuu-ws16-amd64 17 guest-stop fail never pass 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 version targeted for testing: qemuub5725385d17c876a12aa176a4a436d32d34ed06d baseline version: qemuue609fa71e89c81fbe2670411be62da95dfb093e0 Last test of basis 123367 2018-05-29 14:41:59 Z3 days Testing same since 123449 2018-05-31 09:06:49 Z1 days1 attempts People who touched revisions under test: Peter Maydell jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt
Re: [Xen-devel] [PATCH v4 0/10] arm: more kconfig configurability and small default configs
On 5/31/18 4:48 PM, Stefano Stabellini wrote: > One note about Kconfig renaming: I can see the benefit of being > consistent with the naming and using HAS_ only for options that are > always enabled, but I really don't have a strong opinion on this topic. So fwiw, the HAS_ fields come from the Linux kernel. Its mostly used to let the build system know that this hardware HAS this ability and then later there is an option to allow it to be configured on and off. Our use of Kconfig didn't actually introduce these. The Xen build system relied on them before I added Kconfig since we sync a number of drivers over from the Linux kernel tree. It just felt natural to move them out of being hard coded values in the Makefiles and into Kconfig proper so they could be used as Linux uses them. -- Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XSM in osstest, grub config, outstanding patch
On 5/29/18 5:28 AM, Ian Jackson wrote:
> Doug Goldstein writes ("Re: [Xen-devel] XSM in osstest, grub config,
> outstanding patch"):
>> So I believe the path forward here was that we'd bake the "default" XSM
>> policy into Xen and the user could then override it by supplying one
>> with the current name.
>
> Can you explain why this is better than shipping the default policy
> file separately (via xen's dist/install/boot/) ?
>
> This is a genuine question - I'm not arguing for the current approach,
> but we should consider the merits. Normally, as a rule of thumb,
> baking configuration into things makes people's lives harder. In this
> case, for example, maybe it makes it hard to find the default policy
> to examine it, or harder to know what to call the replacement.
>
> Ian.
>
To me it seemed sane. It solves the question of where do user supplied
policies go (they go into the current name). It solves the issue with
users having to currently overwrite a distro package provided file (the
policy isn't marked as a config file in any distro currently). It would
solve the question you asked since the defaults would be baked in. In
effect we could have a build of Xen that supports XSM with a default
policy that mirrors the current DAC setup and it could functionally
behave the same.
The policy file isn't something that users can examine since its a
compiled thing. That way the default policy ships with the Xen tree and
we could have a separate repo with some other policies. That would make
it easier for users to understand how to create their own policies.
I'm more just throwing ideas out there so I'd be happy to hear better
suggestions.
--
Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
On 5/31/2018 11:16 PM, Manish Jaggi wrote:
>
>
> On 05/31/2018 09:27 PM, Sameer Goel wrote:
>>
>> On 5/30/2018 10:13 PM, Manish Jaggi wrote:
>>>
>>> On 05/31/2018 04:31 AM, Sameer Goel wrote:
+
+static int arm_smmu_iommu_domain_init(struct domain *d)
>>> Where is iommu_domain initialized?
>>> The function does not use a iommu_domain * variable
Please check iommu.c 2 levels up.
>>> In this function do you see iommu_domain getting allocated or initialized?
>>> As per the name of function arm_smmu iommu_domain_init.
>>> Where is init of iommu_domain in this function?
>> Well without the xen_domain the iommu_domain is not initialized. It is just
>> the default value. This generic iommu code makes an .init call to our code
>> for whatever initialization is needed. So the name here seemed absolutely
>> fine to me.
>>
>> Initialization does not always refer to allocation. In this case this is
>> driver specific initialization. Since, the iommu code is making an init call
>> to the smmu code hence the name arm_smmu_iommu_domain_init. So, again I
>> agree with your comments on the domain variable names and I'm making these
>> changes as they would make the code cleaner. This function name change
>> probably will not do much but the move along the discussion, let me know
>> what you were thinking.
> Sameer, few points
> a. all the functions are prefixed with arm_smmu_ , so what the function is
> doing can be understood by the rest part of the name
> In this case it is iommu_domain_init.
>
> b. By the name it seems to suggest that you are doing some kind of init for
> iommu_domain
>
> c. But in this complete function, iommu_domain pointer is never used.
>
> If I take your point, the appropriate name of the function should be
> arm_smmu_xen_domain_init().
Its not the iommu domain defined within the current driver. I'll change the
name to arm_smmu_xen_iommu_init().
arm_smmu for just keeping the prefixes as needed. Sounds good?
Thanks,
Sameer
>
> -Manish
>>> +static int arm_smmu_iommu_domain_init(struct domain *d)
>>> +{
>>> + struct arm_smmu_xen_domain *xen_domain;
>>> +
>>> + xen_domain = xzalloc(struct arm_smmu_xen_domain);
>>> + if (!xen_domain)
>>> + return -ENOMEM;
>>> +
>>> + spin_lock_init(_domain->lock);
>>> + INIT_LIST_HEAD(_domain->contexts);
>>> +
>>> + dom_iommu(d)->arch.priv = xen_domain;
>>> +
>>> + return 0;
>>> +}
>>> +
>>>
>>>
>>>
Thanks,
Sameer
> ___
> 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
>
>
> ___
> 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] [PATCH for-4.11 0/2] xenstore: reduce use of unsafe conversions
On 31/05/18 15:05, Marcello Seri wrote: > When xenstore was updated to support safe-string, some unnecessary > copies were introduced. A further patch reduced the copies at the price > of many calls to unsafe conversions between bytes and strings. In the > port we also did not notice that some C stubs were still incorrectly > using ocaml strings as mutable payload. > > This set of patches updates the C stubs that use mutable payloads passed > from ocaml, and reduces the amount of unsafe conversions where possible > without further increasing the number of copies. > > This seems also to fix some unclear instabilities that appeared after > the former patch introducing the unsafe conversion with some version of > the ocaml compiler. > > Marcello Seri (2): > ocaml/libs/xb: use bytes in place of strings for mutable buffers > ocaml/xenstored: reduce use of unsafe conversions For the series: 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.11] x86/traps: Fix error handling of the pv %dr7 shadow state
On 01/06/18 16:06, Andrew Cooper wrote: > c/s "x86/pv: Introduce and use x86emul_write_dr()" fixed a bug with IO shadow > handling, in that it remained stale and visible until %dr7.L/G got set again. > > However, it neglected the -EPERM return inbetween these two hunks, introducing > a different bug in which a write to %dr7 which tries to set IO breakpoints > without %cr4.DE being set clobbers the IO state, rather than leaves it alone. > > Instead, move the zeroing slightly later, which guarentees that the shadow > gets written exactly once, on a successful update to %dr7. > > 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
[Xen-devel] [libvirt test] 123456: tolerable all pass - PUSHED
flight 123456 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/123456/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123391 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123391 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123391 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-xsm 13 migrate-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-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass version targeted for testing: libvirt 879cff55ac9e4b18af39ab5ca8c4a70676030b63 baseline version: libvirt 57d6df39bd7eb8166fee68f4b6da03c0cb0802bf Last test of basis 123391 2018-05-30 04:19:07 Z2 days Testing same since 123456 2018-05-31 10:10:30 Z1 days1 attempts People who touched revisions under test: Jiri Denemark Ján Tomko Michal Privoznik jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at 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
[Xen-devel] [linux-4.14 test] 123447: tolerable FAIL - PUSHED
flight 123447 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123447/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: 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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 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-amd64-amd64-libvirt 13 migrate-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-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-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-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 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-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-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux57a3ca7835962109d94533465a75e8c716b26845 baseline version: linux102b97d6241d938ac153193504a5936fc0be27ed Last test of basis 123382 2018-05-30 00:04:28 Z2 days Testing same since 123447 2018-05-31 08:17:59 Z1 days1 attempts 464 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm
[Xen-devel] [RFC] xen: Don't use memory_region_init_ram_nomigrate() in pci_assign_dev_load_option_rom()
The xen pci_assign_dev_load_option_rom() currently creates a RAM
memory region with memory_region_init_ram_nomigrate(), and then
manually registers it with vmstate_register_ram(). In fact for
its only callsite, the 'owner' pointer we use for the init call
and the '>qdev' pointer we use for the vmstate_register_ram()
call refer to the same object. Simplify the function to only
take a pointer to the device once instead of twice, and use
memory_region_init_ram() which automatically does the vmstate
register for us.
Signed-off-by: Peter Maydell
---
This is a fairly trivial no-behaviour-change code cleanup, but
I've marked it as RFC because I don't have a setup for doing
more than just compile-testing Xen related patches.
This was found as part of a sweep through for code using
the _nomigrate versions of functions.
hw/xen/xen_pt.h | 2 +-
hw/xen/xen_pt_graphics.c | 2 +-
hw/xen/xen_pt_load_rom.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index aa39a9aa5f..dbee3308fd 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -319,7 +319,7 @@ static inline bool
xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
}
extern void *pci_assign_dev_load_option_rom(PCIDevice *dev,
-struct Object *owner, int *size,
+int *size,
unsigned int domain,
unsigned int bus, unsigned int
slot,
unsigned int function);
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 0f4c8d77e2..135c8df1e7 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -132,7 +132,7 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
static void *get_vgabios(XenPCIPassthroughState *s, int *size,
XenHostPCIDevice *dev)
{
-return pci_assign_dev_load_option_rom(>dev, OBJECT(>dev), size,
+return pci_assign_dev_load_option_rom(>dev, size,
dev->domain, dev->bus,
dev->dev, dev->func);
}
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 71063c4d79..e6a86ca818 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -19,7 +19,7 @@
* load the corresponding ROM data to RAM. If an error occurs while loading an
* option ROM, we just ignore that option ROM and continue with the next one.
*/
-void *pci_assign_dev_load_option_rom(PCIDevice *dev, struct Object *owner,
+void *pci_assign_dev_load_option_rom(PCIDevice *dev,
int *size, unsigned int domain,
unsigned int bus, unsigned int slot,
unsigned int function)
@@ -29,6 +29,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev, struct
Object *owner,
uint8_t val;
struct stat st;
void *ptr = NULL;
+Object *owner = OBJECT(dev);
/* If loading ROM from file, pci handles it */
if (dev->romfile || !dev->rom_bar) {
@@ -59,8 +60,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev, struct
Object *owner,
fseek(fp, 0, SEEK_SET);
snprintf(name, sizeof(name), "%s.rom", object_get_typename(owner));
-memory_region_init_ram_nomigrate(>rom, owner, name, st.st_size,
_abort);
-vmstate_register_ram(>rom, >qdev);
+memory_region_init_ram(>rom, owner, name, st.st_size, _abort);
ptr = memory_region_get_ram_ptr(>rom);
memset(ptr, 0xff, st.st_size);
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 123442: tolerable FAIL - PUSHED
flight 123442 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/123442/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail in 123379 pass in 123442 test-armhf-armhf-xl-arndale 5 host-ping-check-native fail in 123379 pass in 123442 test-armhf-armhf-xl 6 xen-installfail pass in 123379 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 123379 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 13 migrate-support-check fail in 123379 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 123379 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123323 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123323 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123323 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123323 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123323 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123323 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 123323 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123323 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123323 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123323 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 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-amd64-amd64-libvirt-xsm 13 migrate-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-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 version targeted for testing: xen 06f542f8f2e446c01bd0edab51e9450af7f6e05b baseline version: xen fc5805daef091240cd5fc06634a8bcdb2f3bb843 Last test of basis 123323 2018-05-28 23:34:10 Z3 days Testing same since 123379 2018-05-29 21:42:20 Z
Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
On Thu, 31 May 2018 23:30:35 -0600
"Jan Beulich" wrote:
Alexey G 05/31/18 7:15 AM >>>
>>On Wed, 30 May 2018 02:12:37 -0600 "Jan Beulich" wrote:
>> On 29.05.18 at 20:47, wrote:
On Wed, 30 May 2018 03:56:07 +1000
Alexey G wrote:
>On Tue, 29 May 2018 08:23:51 -0600
>"Jan Beulich" wrote:
> On 12.03.18 at 19:33, wrote:
>>> @@ -172,10 +173,14 @@ void pci_setup(void)
>>>
>>> /* Create a list of device BARs in descending order of size. */
>>> struct bars {
>>> -uint32_t is_64bar;
>>> uint32_t devfn;
>>> uint32_t bar_reg;
>>> uint64_t bar_sz;
>>> +uint64_t addr_mask; /* which bits of the base address can be
>>> written */
>>> +uint32_t bar_data; /* initial value - BAR flags here */
>>>
>>
>>Why 32 bits? You only use the low few ones afaics. Also please avoid
>>fixed width
>>types unless you really need them.
>
>bar_data is supposed to hold only BAR's kludge bits like 'enabled' bit
>values or MMCONFIG width bits. All of them occupy the low dword only
>while BAR's high dword is just a part of the address which will be
>replaced by allocated one (for mem64 BARs), thus no need to keep the
>high half.
>
>So this is a sort of minor optimization -- avoiding using 64-bit operand
>size when 32 bit is enough.
Sorry, looks like I've misread the question. You were actually
suggesting to make bar_data shorter. 8 bits is enough at the moment, so
bar_data can be changed to uint8_t, yes.
>>>
>>>Right.
>>
>>Ok, I'll switch to smaller types though not sure if it will make any
>>significant impact I'm afraid.
>>
>>In particular, bar_data will be typically used in 32/64-bit
>>arithmetics, using a 32-bit datatype means we avoiding explicit zero
>>extension for both 32 and 64-bit operations while for an uint8_t field
>>the compiler will have to provide extra MOVZX instructions to embed a
>>8-bit operand into 32/64-bit expressions. 32-bit bar_reg can be made
>>16-bit in the same way but any memory usage improvements will be
>>similarly counteracted by a requirement to use 66h-prefixed
>>instructions for it.
>
>Hmm, yes, the space saving from using less wide types are probably indeed
>not worth it. But then please switch to "unsigned int" instead of uint_t
>whenever the exact size doesn't matter.
Ok, will do in v2.
>Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 18/27] xen: Adapt assembly for PIE support
On Fri, Jun 1, 2018 at 8:40 AM Boris Ostrovsky wrote: > > On 05/29/2018 06:15 PM, Thomas Garnier wrote: > > diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S > > index ca2d3b2bf2af..82ba89ba8bb3 100644 > > --- a/arch/x86/xen/xen-pvh.S > > +++ b/arch/x86/xen/xen-pvh.S > > @@ -114,8 +114,8 @@ ENTRY(pvh_start_xen) > > call xen_prepare_pvh > > > > /* startup_64 expects boot_params in %rsi. */ > > - mov $_pa(pvh_bootparams), %rsi > > - mov $_pa(startup_64), %rax > > + movabs $_pa(pvh_bootparams), %rsi > > + movabs $_pa(startup_64), %rax > > jmp *%rax > > > > #else /* CONFIG_X86_64 */ > > @@ -161,10 +161,15 @@ END(pvh_start_xen) > > > > .section ".init.data","aw" > > .balign 8 > > + /* > > + * Use a quad for _pa(gdt_start) because PIE does not understand a > > + * long is enough. The resulting value will still be in the lower long > > + * part. > > + */ > > gdt: > > .word gdt_end - gdt_start > > - .long _pa(gdt_start) > > - .word 0 > > + .quad _pa(gdt_start) > > > With this becoming .quad 32-bit compilation fails: > > /data/root/linux/arch/x86/xen/xen-pvh.S: Assembler messages: > /data/root/linux/arch/x86/xen/xen-pvh.S:147: Error: cannot represent > relocation type BFD_RELOC_64 Thanks, I will look to fix this in the next patch set and run a full 32-bit build. > > > -boris > > > > + .balign 8 > > gdt_start: > > .quad 0x/* NULL descriptor */ > > #ifdef CONFIG_X86_64 > -- Thomas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 05/10] make it possible to enable/disable UART drivers
>>> On 01.06.18 at 17:28, wrote: > On Fri, 1 Jun 2018, Jan Beulich wrote: >> >>> On 31.05.18 at 23:48, wrote: >> > @@ -54,6 +54,7 @@ config HAS_SCIF >> > >> > config HAS_EHCI >> >bool >> > + depends on X86 >> >> Just FTR: I won't NAK this, but I also won't ACK it. > > Just this one line change, right? You would be fine with acking the rest > of the patch? If so, then I only need Julien's ack? Yes. > FYI I am happy with anything regarding HAS_EHCI: I don't particularly > care whether we make it available on ARM or not. As long as both Julien > and you agree, I am fine with it. Well, Julien and I don't agree, that's the whole point. But the disagreement isn't bad enough to block this change, so I'm not against it going in with someone else's ack. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 18/27] xen: Adapt assembly for PIE support
On 05/29/2018 06:15 PM, Thomas Garnier wrote: > diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S > index ca2d3b2bf2af..82ba89ba8bb3 100644 > --- a/arch/x86/xen/xen-pvh.S > +++ b/arch/x86/xen/xen-pvh.S > @@ -114,8 +114,8 @@ ENTRY(pvh_start_xen) > call xen_prepare_pvh > > /* startup_64 expects boot_params in %rsi. */ > - mov $_pa(pvh_bootparams), %rsi > - mov $_pa(startup_64), %rax > + movabs $_pa(pvh_bootparams), %rsi > + movabs $_pa(startup_64), %rax > jmp *%rax > > #else /* CONFIG_X86_64 */ > @@ -161,10 +161,15 @@ END(pvh_start_xen) > > .section ".init.data","aw" > .balign 8 > + /* > + * Use a quad for _pa(gdt_start) because PIE does not understand a > + * long is enough. The resulting value will still be in the lower long > + * part. > + */ > gdt: > .word gdt_end - gdt_start > - .long _pa(gdt_start) > - .word 0 > + .quad _pa(gdt_start) With this becoming .quad 32-bit compilation fails: /data/root/linux/arch/x86/xen/xen-pvh.S: Assembler messages: /data/root/linux/arch/x86/xen/xen-pvh.S:147: Error: cannot represent relocation type BFD_RELOC_64 -boris > + .balign 8 > gdt_start: > .quad 0x/* NULL descriptor */ > #ifdef CONFIG_X86_64 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 05/10] make it possible to enable/disable UART drivers
On Fri, 1 Jun 2018, Jan Beulich wrote: > >>> On 31.05.18 at 23:48, wrote: > > @@ -54,6 +54,7 @@ config HAS_SCIF > > > > config HAS_EHCI > > bool > > + depends on X86 > > Just FTR: I won't NAK this, but I also won't ACK it. Just this one line change, right? You would be fine with acking the rest of the patch? If so, then I only need Julien's ack? FYI I am happy with anything regarding HAS_EHCI: I don't particularly care whether we make it available on ARM or not. As long as both Julien and you agree, I am fine with it. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 04/10] Make MEM_ACCESS configurable
On Fri, 1 Jun 2018, Jan Beulich wrote: > >>> On 31.05.18 at 23:48, wrote: > > --- a/xen/common/Kconfig > > +++ b/xen/common/Kconfig > > @@ -20,8 +20,16 @@ config HAS_DEVICE_TREE > > config HAS_EX_TABLE > > bool > > > > -config HAS_MEM_ACCESS > > - bool > > +config MEM_ACCESS_ALWAYS_ON > > + def_bool n > > Only "bool" please - there should be no defaults other than y for options > without > prompts. Otherwise, if later an option gains a prompt, the user won't be > presented with the option to enable it when using one of the *oldconfig > targets > (due to the previously recorded setting). done > With that replaced > Acked-by: Jan Beulich > also in case you follow Tamas'es suggestion and switch ... > > > +config MEM_ACCESS > > + def_bool y > > + prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON > > ... the default here to MEM_ACCESS_ALWAYS_ON (or !ARM or X86). I changed it to: config MEM_ACCESS def_bool y if MEM_ACCESS_ALWAYS_ON prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON Thank you, I'll add your acked. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 23/31] libxl_qmp_ev: Handle messages from QEMU
This will handle messages received, and call callbacks registered via
libxl__ev_qmp_register().
This also print error messages from QMP on behalf of the callback.
Signed-off-by: Anthony PERARD
---
Should we let callbacks print error messages themself? They already have
the error class, which is often GenericError, a human readable
error message.
---
tools/libxl/libxl_qmp.c | 100
1 file changed, 100 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 0e7ec54b9f..db07c1822a 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1420,6 +1420,101 @@ static int ev_qmp_queue_command(libxl__gc *gc,
return 0;
}
+/*
+ * Handle messages received from QMP server
+ */
+
+static void ev_qmp_handle_return(libxl__egc *egc,
+ libxl__ev_qmp_state *qmp,
+ const libxl__json_object *resp,
+ libxl__qmp_message_type type)
+{
+EGC_GC;
+const libxl__json_object *o;
+int id;
+libxl__ev_qmp *ev;
+const libxl__json_object *ret;
+libxl__qmp_error_class error_class = 0;
+
+o = libxl__json_map_get("id", resp, JSON_INTEGER);
+if (!o) {
+const char *error_desc;
+
+/* unexpected message, attempt to find an error description */
+o = libxl__json_map_get("error", resp, JSON_MAP);
+o = libxl__json_map_get("desc", o, JSON_STRING);
+error_desc = libxl__json_object_get_string(o);
+if (error_desc)
+LOGD(ERROR, qmp->domid, "%s", error_desc);
+else
+LOGD(ERROR, qmp->domid, "Received unexpected message: %s",
+ libxl__json_object_to_json(gc, resp));
+return;
+}
+
+id = libxl__json_object_get_integer(o);
+LIBXL_TAILQ_FOREACH(ev, >qmp_events, entry) {
+if (ev->id == id)
+break;
+}
+if (!ev)
+/* callback not found */
+return;
+
+switch (type) {
+case LIBXL__QMP_MESSAGE_TYPE_RETURN: {
+ret = libxl__json_map_get("return", resp, JSON_ANY);
+break;
+}
+case LIBXL__QMP_MESSAGE_TYPE_ERROR: {
+const char *s;
+const libxl__json_object *err;
+
+error_class = LIBXL__QMP_ERROR_CLASS_UNKNOWN;
+err = libxl__json_map_get("error", resp, JSON_MAP);
+o = libxl__json_map_get("class", err, JSON_STRING);
+s = libxl__json_object_get_string(o);
+if (s)
+libxl__qmp_error_class_from_string(s, _class);
+
+o = libxl__json_map_get("desc", err, JSON_STRING);
+s = libxl__json_object_get_string(o);
+if (s)
+LOGD(ERROR, qmp->domid, "%s", s);
+
+ret = NULL;
+break;
+}
+default:
+abort();
+}
+ev->id = -1;
+ev->callback(egc, ev, ret, error_class);
+}
+
+static void ev_qmp_handle_message(libxl__egc *egc,
+ libxl__ev_qmp_state *qmp,
+ const libxl__json_object *resp)
+{
+EGC_GC;
+libxl__qmp_message_type type = qmp_response_type(resp);
+
+switch (type) {
+case LIBXL__QMP_MESSAGE_TYPE_QMP:
+/* greeting message */
+return;
+case LIBXL__QMP_MESSAGE_TYPE_RETURN:
+case LIBXL__QMP_MESSAGE_TYPE_ERROR:
+ev_qmp_handle_return(egc, qmp, resp, type);
+return;
+case LIBXL__QMP_MESSAGE_TYPE_EVENT:
+/* Event are ignored */
+return;
+case LIBXL__QMP_MESSAGE_TYPE_INVALID:
+return;
+}
+}
+
static int ev_qmp_callback_readable(libxl__egc *egc, libxl__ev_qmp_state *qmp,
int fd)
{
@@ -1557,6 +1652,8 @@ static int ev_qmp_callback_readable(libxl__egc *egc,
libxl__ev_qmp_state *qmp,
LOG_QMP("JSON object received: %s", libxl__json_object_to_json(gc, o));
+ev_qmp_handle_message(egc, qmp, o);
+
/* check if there is another message received at the same time */
if (buf) {
end = strstr(buf->buf + buf->consumed, "\r\n");
@@ -1762,6 +1859,9 @@ void libxl__ev_qmp_stop(libxl__gc *gc,
libxl__ev_qmp_state *qmp)
LOGD(DEBUG, qmp->domid, "Stopping QMP handler");
+/* There should be no more events requested */
+assert(LIBXL_TAILQ_EMPTY(>qmp_events));
+
LIBXL_TAILQ_FOREACH_SAFE(buf, >bufs, entry, tbuf)
free(buf);
LIBXL_TAILQ_INIT(>bufs);
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 18/31] libxl_json: libxl__json_object_to_json
Allow to generate a JSON string from a libxl__json_object,
usefull for debugging.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_json.c | 36
2 files changed, 39 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c87712c83a..9271701246 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2046,6 +2046,9 @@ _hidden int libxl__json_parse_partial(libxl__gc *gc,
libxl__yajl_ctx *yajl_ctx,
_hidden libxl__json_object *libxl__json_complete_parse(libxl__gc *gc,
libxl__yajl_ctx *yajl_ctx);
+_hidden char *libxl__json_object_to_json(libxl__gc *gc,
+ const libxl__json_object *args);
+
/* Based on /local/domain/$domid/dm-version xenstore key
* default is qemu xen traditional */
_hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 3727af34d8..3322ea12b5 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -1073,6 +1073,42 @@ out:
return ret;
}
+char *libxl__json_object_to_json(libxl__gc *gc,
+ const libxl__json_object *args)
+{
+const unsigned char *buf;
+libxl_yajl_length len;
+yajl_gen_status s;
+yajl_gen hand;
+char *ret = NULL;
+int rc;
+
+if (!args)
+return NULL;
+
+hand = libxl_yajl_gen_alloc(NULL);
+
+if (!hand) {
+return NULL;
+}
+
+rc = libxl__json_object_to_yajl_gen(gc, hand, args);
+if (rc)
+goto out;
+
+s = yajl_gen_get_buf(hand, , );
+
+if (s) {
+goto out;
+}
+
+ret = libxl__strndup(gc, (const char *)buf, len);
+
+out:
+yajl_gen_free(hand);
+return ret;
+}
+
yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val)
{
char *num;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 13/31] libxl_qmp: Separate QMP message generation from qmp_send_prepare
This new function qmp_prepare_qmp_cmd() can be reuse later when
introducing a different way to communicate with a QMP server,
libxl__ev_qmp.
Also, add the QMP end of command '\r\n' into the generated string.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 60 +
1 file changed, 43 insertions(+), 17 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1184ca823f..9f4c3f5c20 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -578,17 +578,17 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler
*qmp)
return rc;
}
-static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
- const char *cmd, libxl__json_object *args,
- qmp_callback_t callback, void *opaque,
- qmp_request_context *context)
+static char *qmp_prepare_qmp_cmd(libxl__gc *gc,
+ const char *cmd,
+ const libxl__json_object *args,
+ int id,
+ size_t *len_r)
{
-const unsigned char *buf = NULL;
-char *ret = NULL;
-libxl_yajl_length len = 0;
+const unsigned char *buf;
+libxl_yajl_length len;
yajl_gen_status s;
yajl_gen hand;
-callback_id_pair *elm = NULL;
+char *ret = NULL;
hand = libxl_yajl_gen_alloc(NULL);
@@ -600,7 +600,7 @@ static char *qmp_send_prepare(libxl__gc *gc,
libxl__qmp_handler *qmp,
libxl__yajl_gen_asciiz(hand, "execute");
libxl__yajl_gen_asciiz(hand, cmd);
libxl__yajl_gen_asciiz(hand, "id");
-yajl_gen_integer(hand, ++qmp->last_id_used);
+yajl_gen_integer(hand, id);
if (args) {
libxl__yajl_gen_asciiz(hand, "arguments");
libxl__json_object_to_yajl_gen(gc, hand, args);
@@ -610,6 +610,36 @@ static char *qmp_send_prepare(libxl__gc *gc,
libxl__qmp_handler *qmp,
s = yajl_gen_get_buf(hand, , );
if (s) {
+goto out;
+}
+
+ret = libxl__malloc(NOGC, len + 3);
+strncpy(ret, (const char *)buf, len + 3);
+strncpy(ret + len, "\r\n", 3);
+len += 2;
+
+if (len_r)
+*len_r = len;
+
+out:
+yajl_gen_free(hand);
+return ret;
+}
+
+static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
+ const char *cmd, libxl__json_object *args,
+ qmp_callback_t callback, void *opaque,
+ qmp_request_context *context,
+ size_t *len_r)
+{
+char *buf;
+callback_id_pair *elm;
+
+buf = qmp_prepare_qmp_cmd(gc,
+ cmd, args, ++qmp->last_id_used,
+ NULL);
+
+if (!buf) {
LOGD(ERROR, qmp->domid, "Failed to generate a qmp command");
goto out;
}
@@ -625,13 +655,10 @@ static char *qmp_send_prepare(libxl__gc *gc,
libxl__qmp_handler *qmp,
elm->context = context;
LIBXL_STAILQ_INSERT_TAIL(>callback_list, elm, next);
-ret = libxl__strndup(gc, (const char*)buf, len);
-
LOGD(DEBUG, qmp->domid, "next qmp command: '%s'", buf);
out:
-yajl_gen_free(hand);
-return ret;
+return buf;
}
static int qmp_send(libxl__qmp_handler *qmp,
@@ -643,7 +670,8 @@ static int qmp_send(libxl__qmp_handler *qmp,
int rc = -1;
GC_INIT(qmp->ctx);
-buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context);
+buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context,
+ NULL);
if (buf == NULL) {
goto out;
@@ -659,12 +687,10 @@ static int qmp_send(libxl__qmp_handler *qmp,
"QMP command", "QMP socket"))
goto out;
}
-if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-"CRLF", "QMP socket"))
-goto out;
rc = qmp->last_id_used;
out:
+free(buf);
GC_FREE;
return rc;
}
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 16/31] libxl_json: Allow partial parsing
This set of function allow to parse a JSON string that is spread accross
different memory location.
This is usefull when a JSON string is received from a remote process,
and in order to avoid using realloc, the message is recorded in multiple
buffers.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 6 +++
tools/libxl/libxl_json.c | 100 +++
2 files changed, 84 insertions(+), 22 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d9eebfd98b..c87712c83a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2039,6 +2039,12 @@ _hidden void libxl__json_object_free(libxl__gc *gc_opt,
libxl__json_object *obj);
_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char
*s);
+/* allow to parse a json string store in multiple buffers */
+_hidden libxl__yajl_ctx *libxl__json_parse_alloc(libxl__gc *gc);
+_hidden int libxl__json_parse_partial(libxl__gc *gc, libxl__yajl_ctx *yajl_ctx,
+ const char *s, size_t len);
+_hidden libxl__json_object *libxl__json_complete_parse(libxl__gc *gc,
+ libxl__yajl_ctx *yajl_ctx);
/* Based on /local/domain/$domid/dm-version xenstore key
* default is qemu xen traditional */
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index b7f9077f0d..3727af34d8 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -912,47 +912,103 @@ static void yajl_ctx_free(libxl__yajl_ctx *yajl_ctx)
DEBUG_GEN_FREE(yajl_ctx);
}
-libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
+/*
+ * Only to use with:
+ * libxl__json_parse_partial
+ * libxl__json_complete_parse
+ *
+ * gc should be the same accross all functions.
+ * NOGC is not allowed unless called from libxl__json_parse()
+ */
+libxl__yajl_ctx *libxl__json_parse_alloc(libxl__gc *gc)
{
-yajl_status status;
-libxl__yajl_ctx yajl_ctx;
-libxl__json_object *o = NULL;
-unsigned char *str = NULL;
+libxl__yajl_ctx *yajl_ctx;
-memset(_ctx, 0, sizeof (yajl_ctx));
-yajl_ctx.gc = gc;
+GCNEW(yajl_ctx);
-DEBUG_GEN_ALLOC(_ctx);
+yajl_ctx->gc = gc;
-if (yajl_ctx.hand == NULL) {
-yajl_ctx.hand = libxl__yajl_alloc(, NULL, _ctx);
-}
-status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
+DEBUG_GEN_ALLOC(yajl_ctx);
+
+yajl_ctx->hand = libxl__yajl_alloc(, NULL, yajl_ctx);
+
+return yajl_ctx;
+}
+
+static void json_parse_error(libxl__gc *gc, libxl__yajl_ctx *yajl_ctx,
+ const char *s, size_t len)
+{
+unsigned char *str;
+str = yajl_get_error(yajl_ctx->hand, 1, (const unsigned char*)s, len);
+LOGE(ERROR, "yajl error: %s", str);
+yajl_free_error(yajl_ctx->hand, str);
+yajl_ctx_free(yajl_ctx);
+}
+
+int libxl__json_parse_partial(libxl__gc *gc, libxl__yajl_ctx *yajl_ctx,
+ const char *s, size_t len)
+{
+yajl_status status;
+
+assert(gc == yajl_ctx->gc);
+
+status = yajl_parse(yajl_ctx->hand, (const unsigned char *)s, strlen(s));
if (status != yajl_status_ok)
goto out;
-status = yajl_complete_parse(yajl_ctx.hand);
+return 0;
+
+out:
+json_parse_error(gc, yajl_ctx, s, len);
+return ERROR_FAIL;
+}
+
+libxl__json_object *libxl__json_complete_parse(libxl__gc *gc,
+ libxl__yajl_ctx *yajl_ctx)
+{
+yajl_status status;
+libxl__json_object *o;
+
+assert(gc == yajl_ctx->gc);
+
+status = yajl_complete_parse(yajl_ctx->hand);
if (status != yajl_status_ok)
goto out;
-o = yajl_ctx.head;
+o = yajl_ctx->head;
-DEBUG_GEN_REPORT(_ctx);
+DEBUG_GEN_REPORT(yajl_ctx);
-yajl_ctx.head = NULL;
+yajl_ctx->head = NULL;
-yajl_ctx_free(_ctx);
+yajl_ctx_free(yajl_ctx);
return o;
out:
-str = yajl_get_error(yajl_ctx.hand, 1, (const unsigned char*)s, strlen(s));
-
-LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str);
-yajl_free_error(yajl_ctx.hand, str);
-yajl_ctx_free(_ctx);
+json_parse_error(gc, yajl_ctx, NULL, 0);
return NULL;
}
+libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
+{
+libxl__yajl_ctx *yajl_ctx;
+int rc;
+libxl__json_object *o = NULL;
+
+yajl_ctx = libxl__json_parse_alloc(gc);
+
+rc = libxl__json_parse_partial(gc, yajl_ctx, s, strlen(s));
+if (rc)
+goto out;
+
+o = libxl__json_complete_parse(gc, yajl_ctx);
+
+out:
+if (!libxl__gc_is_real(gc))
+free(yajl_ctx);
+return o;
+}
+
static const char *yajl_gen_status_to_string(yajl_gen_status s)
{
switch (s) {
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
[Xen-devel] [PATCH v3 14/31] libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP
This is a first patch to implement libxl__ev_qmp, it only connect to the
QMP socket of QEMU and register a callback that does nothing.
Callback functions will be implemented in following patches.
Signed-off-by: Anthony PERARD
---
TODO:
This would probably needs to have a list in CTX, with state for
different domid.
---
tools/libxl/libxl.c | 4 ++
tools/libxl/libxl_internal.h | 8 +++
tools/libxl/libxl_qmp.c | 106 +++
3 files changed, 118 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b41ade9fda..b3fb8c1f8b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -162,6 +162,10 @@ int libxl_ctx_free(libxl_ctx *ctx)
assert(!libxl__ev_fd_isregistered(>evtchn_efd));
assert(!libxl__ev_fd_isregistered(>sigchld_selfpipe_efd));
+libxl__ev_qmp_stop(gc, ctx->qmp_ev);
+free(ctx->qmp_ev);
+ctx->qmp_ev = NULL;
+
/* Now there should be no more events requested from the application: */
assert(LIBXL_LIST_EMPTY(>efds));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 12bbfe4a63..d9eebfd98b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -201,6 +201,7 @@ typedef struct libxl__ao libxl__ao;
typedef struct libxl__aop_occurred libxl__aop_occurred;
typedef struct libxl__osevent_hook_nexus libxl__osevent_hook_nexus;
typedef struct libxl__osevent_hook_nexi libxl__osevent_hook_nexi;
+typedef struct libxl__ev_qmp_state libxl__ev_qmp_state;
typedef struct libxl__domain_create_state libxl__domain_create_state;
typedef void libxl__domain_create_cb(struct libxl__egc *egc,
@@ -503,6 +504,9 @@ struct libxl__ctx {
LIBXL_LIST_ENTRY(libxl_ctx) sigchld_users_entry;
libxl_version_info version_info;
+
+// FIXME: May need a list, with on state for each domid
+libxl__ev_qmp_state *qmp_ev;
};
/*
@@ -4418,6 +4422,10 @@ static inline bool libxl__string_is_default(char **s)
{
return *s == NULL;
}
+
+_hidden libxl__ev_qmp_state *libxl__ev_qmp_start(libxl__gc *gc, uint32_t
domid);
+/* Allow to disconnect from a QMP server and free ressources */
+_hidden void libxl__ev_qmp_stop(libxl__gc *, libxl__ev_qmp_state *qmp);
#endif
/*
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9f4c3f5c20..077cac9c8a 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1351,6 +1351,112 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t
domid,
return ret;
}
+/* Implementation of libxl__ev_qmp */
+
+struct libxl__ev_qmp_state {
+libxl__carefd *cfd;
+libxl__ev_fd efd;
+uint32_t domid;
+};
+
+static void ev_qmp_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
+ int fd, short events, short revents)
+{
+}
+
+static void libxl__ev_qmp_state_init(libxl__ev_qmp_state *qmp)
+{
+qmp->domid = INVALID_DOMID;
+qmp->cfd = NULL;
+libxl__ev_fd_init(>efd);
+}
+
+libxl__ev_qmp_state *libxl__ev_qmp_start(libxl__gc *gc, uint32_t domid)
+{
+int rc, r;
+struct sockaddr_un un;
+const char *qmp_socket_path;
+libxl__ev_qmp_state *qmp;
+
+CTX_LOCK;
+
+if (!CTX->qmp_ev) {
+qmp = libxl__malloc(NOGC, sizeof(*qmp));
+CTX->qmp_ev = qmp;
+libxl__ev_qmp_state_init(qmp);
+} else {
+qmp = CTX->qmp_ev;
+}
+
+if (libxl__ev_fd_isregistered(>efd)) {
+LOG(DEBUG, "reusing connection: %d == %d", domid, qmp->domid);
+assert(domid == qmp->domid);
+rc = 0;
+goto out;
+}
+
+qmp->domid = domid;
+
+qmp_socket_path = GCSPRINTF("%s/qmp-libxl-%d",
+libxl__run_dir_path(), domid);
+
+LOGD(DEBUG, domid, "Starting new QMP event handler");
+libxl__carefd_begin();
+qmp->cfd = libxl__carefd_opened(CTX, socket(AF_UNIX, SOCK_STREAM, 0));
+if (!qmp->cfd) {
+LOGED(ERROR, domid, "socket() failed");
+rc = ERROR_FAIL;
+goto out;
+}
+rc = libxl_fd_set_nonblock(CTX, libxl__carefd_fd(qmp->cfd), 1);
+if (rc)
+goto out;
+
+if (sizeof(un.sun_path) <= strlen(qmp_socket_path)) {
+rc = -1;
+goto out;
+}
+memset(, 0, sizeof(un));
+un.sun_family = AF_UNIX;
+assert(strlen(qmp_socket_path) <= sizeof(un.sun_path));
+strncpy(un.sun_path, qmp_socket_path, sizeof(un.sun_path));
+
+r = connect(libxl__carefd_fd(qmp->cfd),
+(struct sockaddr *) , sizeof(un));
+if (r) {
+LOGED(ERROR, domid, "Failed to connect to QMP socket %s",
+ qmp_socket_path);
+rc = ERROR_FAIL;
+goto out;
+}
+
+rc = libxl__ev_fd_register(gc, >efd,
+ ev_qmp_fd_callback,
+ libxl__carefd_fd(qmp->cfd),
+ POLLIN);
+
+out:
+if (rc)
+libxl__ev_qmp_stop(gc, qmp);
+CTX_UNLOCK;
+return qmp;
+}
+
+void
[Xen-devel] [PATCH v3 11/31] libxl_qmp: Remove unused yajl_ctx form handler
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 4da84dcf16..1184ca823f 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -111,8 +111,6 @@ struct libxl__qmp_handler {
/* wait_for_id will be used by the synchronous send function */
int wait_for_id;
-libxl__yajl_ctx *yajl_ctx;
-
libxl_ctx *ctx;
uint32_t domid;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 12/31] libxl_json: constify libxl__json_object_to_yajl_gen arguments
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 2 +-
tools/libxl/libxl_json.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c582894589..12bbfe4a63 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2030,7 +2030,7 @@ _hidden const libxl__json_object
*libxl__json_map_get(const char *key,
libxl__json_node_type expected_type);
_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt,
yajl_gen hand,
- libxl__json_object *param);
+ const libxl__json_object
*param);
_hidden void libxl__json_object_free(libxl__gc *gc_opt,
libxl__json_object *obj);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index dc93a88ef1..b7f9077f0d 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -612,7 +612,7 @@ const libxl__json_object *libxl__json_map_get(const char
*key,
yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
yajl_gen hand,
- libxl__json_object *obj)
+ const libxl__json_object *obj)
{
int idx = 0;
yajl_status rc;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 15/31] libxl_qmp_ev: Implement fd callback and read data
First step into taking care of the input from QEMU's QMP socket. For
now, we read data and store them in buffers.
Parsing of the data will be done in the following patches.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 113
1 file changed, 113 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 077cac9c8a..48dc376307 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -75,6 +75,12 @@
# define DEBUG_REPORT_RECEIVED(dom, buf, len) ((void)0)
#endif
+#ifdef DEBUG_QMP_CLIENT
+# define LOG_QMP(f, ...) LOGD(DEBUG, qmp->domid, f, ##__VA_ARGS__)
+#else
+# define LOG_QMP(f, ...)
+#endif
+
/*
* QMP types & constant
*/
@@ -1353,15 +1359,115 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t
domid,
/* Implementation of libxl__ev_qmp */
+typedef struct libxl__qmp_rx_buf libxl__qmp_rx_buf;
+struct libxl__qmp_rx_buf {
+LIBXL_TAILQ_ENTRY(libxl__qmp_rx_buf) entry;
+/* How much data there is in buf */
+int used;
+/* How much have been parsed */
+size_t consumed;
+char buf[QMP_RECEIVE_BUFFER_SIZE];
+};
+
struct libxl__ev_qmp_state {
libxl__carefd *cfd;
libxl__ev_fd efd;
uint32_t domid;
+
+LIBXL_TAILQ_HEAD(libxl__qmp_bufs, libxl__qmp_rx_buf) bufs;
};
+
+static int ev_qmp_callback_readable(libxl__egc *egc, libxl__ev_qmp_state *qmp,
+int fd)
+{
+EGC_GC;
+ssize_t r;
+libxl__qmp_rx_buf *buf;
+
+/* Check if last buffer still have space, or alloc a new one */
+buf = LIBXL_TAILQ_LAST(>bufs, libxl__qmp_bufs);
+if (buf) {
+/* The -1 is because there is always space for a NUL character */
+if (buf->used == sizeof(buf->buf) - 1) {
+buf = NULL;
+}
+}
+if (!buf) {
+buf = libxl__malloc(NOGC, sizeof(*buf));
+buf->used = 0;
+buf->consumed = 0;
+LIBXL_TAILQ_INSERT_TAIL(>bufs, buf, entry);
+}
+
+for (;;) {
+/* The -1 is because there is always space for a NUL character */
+r = read(fd, buf->buf + buf->used, sizeof(buf->buf) - buf->used - 1);
+if (r < 0) {
+if (errno == EINTR) continue;
+assert(errno);
+if (errno == EWOULDBLOCK) {
+return 0;
+}
+LOGED(ERROR, qmp->domid, "error reading QMP socket");
+return ERROR_FAIL;
+}
+break;
+}
+
+if (r == 0) {
+LOGD(ERROR, qmp->domid, "No data read on QMP socket");
+return 0;
+}
+
+LOG_QMP("received %ldB: '%.*s'", r, (int)r, buf->buf + buf->used);
+
+buf->used += r;
+assert(buf->used < sizeof(buf->buf));
+
+return 0;
+}
+
+/* When the QMP client reach the conclusion that the QMP connection doesn't
+ * work anymore, this function can be called to propagate the error to every
+ * callback registered. And stop the client. */
+static void ev_qmp_callback_error(libxl__egc *egc, libxl__ev_qmp_state *qmp)
+{
+EGC_GC;
+
+LOGD(ERROR, qmp->domid, "Error happend with the QMP connection to QEMU");
+libxl__ev_qmp_stop(gc, qmp);
+}
+
static void ev_qmp_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
int fd, short events, short revents)
{
+EGC_GC;
+int rc;
+
+libxl__ev_qmp_state *qmp = CONTAINER_OF(ev_fd, *qmp, efd);
+
+if (revents & (POLLHUP)) {
+LOGD(DEBUG, qmp->domid, "received POLLHUP from QMP socket");
+ev_qmp_callback_error(egc, qmp);
+return;
+}
+if (revents & ~(POLLIN|POLLOUT)) {
+LOGD(ERROR, qmp->domid,
+ "unexpected poll event 0x%x on QMP socket (expected POLLIN "
+ "and/or POLLOUT)",
+revents);
+ev_qmp_callback_error(egc, qmp);
+return;
+}
+
+if (revents & POLLIN) {
+rc = ev_qmp_callback_readable(egc, qmp, fd);
+if (rc) {
+ev_qmp_callback_error(egc, qmp);
+return;
+}
+}
}
static void libxl__ev_qmp_state_init(libxl__ev_qmp_state *qmp)
@@ -1369,6 +1475,7 @@ static void libxl__ev_qmp_state_init(libxl__ev_qmp_state
*qmp)
qmp->domid = INVALID_DOMID;
qmp->cfd = NULL;
libxl__ev_fd_init(>efd);
+LIBXL_TAILQ_INIT(>bufs);
}
libxl__ev_qmp_state *libxl__ev_qmp_start(libxl__gc *gc, uint32_t domid)
@@ -1444,6 +1551,8 @@ out:
void libxl__ev_qmp_stop(libxl__gc *gc, libxl__ev_qmp_state *qmp)
{
+libxl__qmp_rx_buf *buf, *tbuf;
+
if (!qmp)
return;
@@ -1451,6 +1560,10 @@ void libxl__ev_qmp_stop(libxl__gc *gc,
libxl__ev_qmp_state *qmp)
LOGD(DEBUG, qmp->domid, "Stopping QMP handler");
+LIBXL_TAILQ_FOREACH_SAFE(buf, >bufs, entry, tbuf)
+free(buf);
+LIBXL_TAILQ_INIT(>bufs);
+
libxl__ev_fd_deregister(gc, >efd);
libxl__carefd_close(qmp->cfd);
qmp->cfd = NULL;
--
Anthony PERARD
[Xen-devel] [PATCH v3 28/31] libxl_disk: Cut libxl_cdrom_insert into step
This is to prepare libxl_cdrom_insert to be able to send commands to
QEMU via the libxl__ev_qmp. The next patch is going to make use of it.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_disk.c | 195 +++
1 file changed, 138 insertions(+), 57 deletions(-)
diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index e9eceb65e3..a3bf974fe3 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -661,31 +661,56 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t
domid,
return rc;
}
+typedef struct {
+libxl__ao *ao;
+libxl_domain_config d_config;
+const char *be_path;
+const char *libxl_path;
+libxl_device_disk *disk;
+libxl_device_disk disk_empty;
+libxl_device_disk disk_saved;
+int dm_ver;
+int domid;
+libxl__domain_userdata_lock *lock;
+} libxl__cdrom_insert_state;
+static void cdrom_insert_ejected(libxl__egc *egc,
+ libxl__cdrom_insert_state *cis);
+static void cdrom_insert_inserted(libxl__egc *egc,
+ libxl__cdrom_insert_state *cis);
+static void cdrom_insert_done(libxl__egc *egc,
+ libxl__cdrom_insert_state *cis,
+ int rc);
+
int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
{
AO_CREATE(ctx, domid, ao_how);
int num = 0, i;
-libxl_device_disk *disks = NULL, disk_saved, disk_empty;
-libxl_domain_config d_config;
-int rc, dm_ver;
+libxl_device_disk *disks = NULL, *disk_saved, *disk_empty;
+int rc;
libxl__device device;
-const char *be_path, *libxl_path;
-char * tmp;
-libxl__domain_userdata_lock *lock = NULL;
-xs_transaction_t t = XBT_NULL;
-flexarray_t *insert = NULL, *empty = NULL;
+libxl__cdrom_insert_state *cis;
-libxl_domain_config_init(_config);
-libxl_device_disk_init(_empty);
-libxl_device_disk_init(_saved);
-libxl_device_disk_copy(ctx, _saved, disk);
+GCNEW(cis);
+cis->ao = ao;
+cis->domid = domid;
+// XXX: can I do that? is disk going to exist until the AO is over?
+cis->disk = disk;
-disk_empty.format = LIBXL_DISK_FORMAT_EMPTY;
-disk_empty.vdev = libxl__strdup(NOGC, disk->vdev);
-disk_empty.pdev_path = libxl__strdup(NOGC, "");
-disk_empty.is_cdrom = 1;
-libxl__device_disk_setdefault(gc, domid, _empty, false);
+disk_empty = >disk_empty;
+disk_saved = >disk_saved;
+
+
+libxl_domain_config_init(>d_config);
+libxl_device_disk_init(disk_empty);
+libxl_device_disk_init(disk_saved);
+libxl_device_disk_copy(ctx, disk_saved, disk);
+
+disk_empty->format = LIBXL_DISK_FORMAT_EMPTY;
+disk_empty->vdev = libxl__strdup(NOGC, disk->vdev);
+disk_empty->pdev_path = libxl__strdup(NOGC, "");
+disk_empty->is_cdrom = 1;
+libxl__device_disk_setdefault(gc, domid, disk_empty, false);
libxl_domain_type type = libxl__domain_type(gc, domid);
if (type == LIBXL_DOMAIN_TYPE_INVALID) {
@@ -704,8 +729,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
goto out;
}
-dm_ver = libxl__device_model_version_running(gc, domid);
-if (dm_ver == -1) {
+cis->dm_ver = libxl__device_model_version_running(gc, domid);
+if (cis->dm_ver == -1) {
LOGD(ERROR, domid, "Cannot determine device model version");
rc = ERROR_FAIL;
goto out;
@@ -737,31 +762,14 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
rc = libxl__device_from_disk(gc, domid, disk, );
if (rc) goto out;
-be_path = libxl__device_backend_path(gc, );
-libxl_path = libxl__device_libxl_path(gc, );
-
-insert = flexarray_make(gc, 4, 1);
-
-flexarray_append_pair(insert, "type",
- libxl__device_disk_string_of_backend(disk->backend));
-if (disk->format != LIBXL_DISK_FORMAT_EMPTY)
-flexarray_append_pair(insert, "params",
-GCSPRINTF("%s:%s",
-libxl__device_disk_string_of_format(disk->format),
-disk->pdev_path));
-else
-flexarray_append_pair(insert, "params", "");
-
-empty = flexarray_make(gc, 4, 1);
-flexarray_append_pair(empty, "type",
- libxl__device_disk_string_of_backend(disk->backend));
-flexarray_append_pair(empty, "params", "");
+cis->be_path = libxl__device_backend_path(gc, );
+cis->libxl_path = libxl__device_libxl_path(gc, );
/* Note: CTX lock is already held at this point so lock hierarchy
* is maintained.
*/
-lock = libxl__lock_domain_userdata(gc, domid);
-if (!lock) {
+cis->lock = libxl__lock_domain_userdata(gc, domid);
+if (!cis->lock) {
rc = ERROR_LOCK_FAIL;
goto out;
}
@@ -769,11 +777,46 @@ int
[Xen-devel] [PATCH v3 21/31] libxl_qmp_ev: Handle write to socket
The libxl__ev_qmp_* will now send commands to QEMU when the socket is
ready for writes. Also stop pulling for POLLOUT events once the send
queue is empty.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9b5eb8fd35..02eae1f5ce 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1416,6 +1416,7 @@ static int ev_qmp_queue_command(libxl__gc *gc,
out->len = len;
out->efd = efd;
LIBXL_TAILQ_INSERT_TAIL(>tx_buf, out, entry);
+libxl__ev_fd_modify(gc, >efd, qmp->efd.events | POLLOUT);
return 0;
}
@@ -1568,6 +1569,46 @@ static int ev_qmp_callback_readable(libxl__egc *egc,
libxl__ev_qmp_state *qmp,
return 0;
}
+static int ev_qmp_callback_writable(libxl__egc *egc,
+libxl__ev_qmp_state *qmp,
+int fd)
+{
+EGC_GC;
+libxl__qmp_tx_buf *buf;
+int rc;
+
+if (!qmp->ready) {
+return 0;
+}
+
+if (LIBXL_TAILQ_EMPTY(>tx_buf))
+return 0;
+
+buf = LIBXL_TAILQ_FIRST(>tx_buf);
+
+LOG_QMP("sending: '%.*s'", (int)buf->len, buf->buf);
+
+if (buf->efd) {
+int buf_fd = libxl__carefd_fd(buf->efd);
+rc = libxl__sendmsg_fds(gc, fd, buf->buf, buf->len,
+1, _fd, "QMP socket");
+libxl__carefd_close(buf->efd);
+} else {
+rc = libxl_write_exactly(CTX, fd, buf->buf, buf->len,
+ "QMP command", "QMP socket");
+}
+
+if (rc)
+goto out;
+
+LIBXL_TAILQ_REMOVE(>tx_buf, buf, entry);
+free(buf->buf);
+free(buf);
+
+out:
+return 1;
+}
+
/* When the QMP client reach the conclusion that the QMP connection doesn't
* work anymore, this function can be called to propagate the error to every
* callback registered. And stop the client. */
@@ -1617,6 +1658,13 @@ static void ev_qmp_fd_callback(libxl__egc *egc,
libxl__ev_fd *ev_fd,
return;
}
}
+if (revents & POLLOUT) {
+int ret = ev_qmp_callback_writable(egc, qmp, fd);
+if (ret == 0) {
+/* nothing to write, disable it. */
+libxl__ev_fd_modify(gc, >efd, events & ~POLLOUT);
+}
+}
}
static void libxl__ev_qmp_state_init(libxl__ev_qmp_state *qmp)
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 10/31] libxl_qmp: Move buffers to the stack of qmp_next.
That buffer is only used locally, and never reuse accross different call
of qmp_next. So remove it form the handler.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 251840a155..4da84dcf16 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -111,7 +111,6 @@ struct libxl__qmp_handler {
/* wait_for_id will be used by the synchronous send function */
int wait_for_id;
-char buffer[QMP_RECEIVE_BUFFER_SIZE + 1];
libxl__yajl_ctx *yajl_ctx;
libxl_ctx *ctx;
@@ -501,6 +500,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
char *incomplete = NULL;
size_t incomplete_size = 0;
int rc = 0;
+char buffer[QMP_RECEIVE_BUFFER_SIZE + 1];
do {
fd_set rfds;
@@ -524,7 +524,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
return -1;
}
-rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE);
+rd = read(qmp->qmp_fd, buffer, QMP_RECEIVE_BUFFER_SIZE);
if (rd == 0) {
LOGD(ERROR, qmp->domid, "Unexpected end of socket");
return -1;
@@ -532,20 +532,20 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler
*qmp)
LOGED(ERROR, qmp->domid, "Socket read error");
return rd;
}
-qmp->buffer[rd] = '\0';
+buffer[rd] = '\0';
-DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, (int)rd);
+DEBUG_REPORT_RECEIVED(qmp->domid, buffer, (int)rd);
if (incomplete) {
size_t current_pos = s - incomplete;
incomplete = libxl__realloc(gc, incomplete,
incomplete_size + rd + 1);
-strncat(incomplete + incomplete_size, qmp->buffer, rd);
+strncat(incomplete + incomplete_size, buffer, rd);
s = incomplete + current_pos;
incomplete_size += rd;
s_end = incomplete + incomplete_size;
} else {
-incomplete = libxl__strndup(gc, qmp->buffer, rd);
+incomplete = libxl__strndup(gc, buffer, rd);
incomplete_size = rd;
s = incomplete;
s_end = s + rd;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 20/31] libxl_qmp: Introduce libxl__ev_qmp functions
Calling libxl__ev_qmp_register() will prepare a command to be sent to
QEMU and stash it in a queue to be sent later.
The actual sent will be done in a separate patch.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 39 +++-
tools/libxl/libxl_qmp.c | 139 +++
tools/libxl/libxl_types_internal.idl | 14 +++
3 files changed, 190 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9271701246..16533f651e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -202,6 +202,8 @@ typedef struct libxl__aop_occurred libxl__aop_occurred;
typedef struct libxl__osevent_hook_nexus libxl__osevent_hook_nexus;
typedef struct libxl__osevent_hook_nexi libxl__osevent_hook_nexi;
typedef struct libxl__ev_qmp_state libxl__ev_qmp_state;
+typedef struct libxl__json_object libxl__json_object;
+typedef struct libxl__carefd libxl__carefd;
typedef struct libxl__domain_create_state libxl__domain_create_state;
typedef void libxl__domain_create_cb(struct libxl__egc *egc,
@@ -357,6 +359,39 @@ struct libxl__ev_child {
LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
};
+/*
+ * libxl__ev_qmp
+ */
+
+typedef struct libxl__ev_qmp libxl__ev_qmp;
+/* response: QMP response on success, or NULL on error.
+ * error_class: NONE on success, otherwise QMP error class or libxl error */
+typedef void libxl__ev_qmp_callback(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+libxl__qmp_error_class error_class);
+struct libxl__ev_qmp {
+/* read-only once registered */
+uint32_t domid;
+libxl__ev_qmp_callback *callback;
+/* If !NULL, this file descriptor will be sent to the QMP server,
+ * and closed once sent. */
+libxl__carefd *efd;
+
+/* private */
+
+/* id == -1: initial state or response already received and callback
called.
+ * id > 0: id used to send a command to qemu. */
+int id;
+LIBXL_TAILQ_ENTRY(libxl__ev_qmp) entry;
+};
+
+_hidden void libxl__ev_qmp_init(libxl__ev_qmp *ev);
+_hidden int libxl__ev_qmp_register(libxl__gc *gc, libxl__ev_qmp *ev,
+ libxl__ev_qmp_callback *,
+ uint32_t domid,
+ const char *cmd, libxl__json_object *args);
+_hidden void libxl__ev_qmp_deregister(libxl__gc *gc, libxl__ev_qmp *ev);
+_hidden int libxl__ev_qmp_isregistered(const libxl__ev_qmp *ev);
/*
* evgen structures, which are the state we use for generating
@@ -1905,7 +1940,7 @@ typedef enum {
JSON_ANY = 255 /* this is a mask of all values above, adjust as needed
*/
} libxl__json_node_type;
-typedef struct libxl__json_object {
+struct libxl__json_object {
libxl__json_node_type type;
union {
bool b;
@@ -1918,7 +1953,7 @@ typedef struct libxl__json_object {
flexarray_t *map;
} u;
struct libxl__json_object *parent;
-} libxl__json_object;
+};
typedef int (*libxl__json_parse_callback)(libxl__gc *gc,
libxl__json_object *o,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e4441f76f4..9b5eb8fd35 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1369,15 +1369,57 @@ struct libxl__qmp_rx_buf {
char buf[QMP_RECEIVE_BUFFER_SIZE];
};
+typedef struct libxl__qmp_tx_buf libxl__qmp_tx_buf;
+struct libxl__qmp_tx_buf {
+LIBXL_TAILQ_ENTRY(libxl__qmp_tx_buf) entry;
+size_t len;
+char *buf;
+/* File descriptor to send along the command */
+libxl__carefd *efd;
+};
+
struct libxl__ev_qmp_state {
libxl__carefd *cfd;
libxl__ev_fd efd;
uint32_t domid;
LIBXL_TAILQ_HEAD(libxl__qmp_bufs, libxl__qmp_rx_buf) bufs;
+
+unsigned int last_id_used;
+/* Indicate that QEMU is ready to respond to command. */
+bool ready;
+LIBXL_TAILQ_HEAD(libxl__qmp_tx_bufs, libxl__qmp_tx_buf) tx_buf;
+
+LIBXL_TAILQ_HEAD(libxl__ev_qmps, libxl__ev_qmp) qmp_events;
};
+/* Prepare a QMP command to be sent */
+static int ev_qmp_queue_command(libxl__gc *gc,
+libxl__ev_qmp_state *qmp,
+const char *cmd,
+const libxl__json_object *args,
+libxl__carefd *efd)
+{
+char *buf = NULL;
+size_t len;
+libxl__qmp_tx_buf *out;
+
+buf = qmp_prepare_qmp_cmd(gc,
+ cmd, args, ++qmp->last_id_used,
+ );
+if (!buf)
+return ERROR_FAIL;
+
+out = libxl__malloc(NOGC, sizeof(*out));
+out->buf = buf;
+out->len = len;
+out->efd = efd;
+LIBXL_TAILQ_INSERT_TAIL(>tx_buf, out, entry);
+
+return 0;
+}
+
static int ev_qmp_callback_readable(libxl__egc *egc, libxl__ev_qmp_state *qmp,
[Xen-devel] [PATCH v3 19/31] libxl_qmp_ev: Parse JSON input from QMP
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 98 +
1 file changed, 98 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 48dc376307..e4441f76f4 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1383,7 +1383,9 @@ static int ev_qmp_callback_readable(libxl__egc *egc,
libxl__ev_qmp_state *qmp,
{
EGC_GC;
ssize_t r;
+char *end = NULL;
libxl__qmp_rx_buf *buf;
+int rc;
/* Check if last buffer still have space, or alloc a new one */
buf = LIBXL_TAILQ_LAST(>bufs, libxl__qmp_bufs);
@@ -1425,6 +1427,102 @@ static int ev_qmp_callback_readable(libxl__egc *egc,
libxl__ev_qmp_state *qmp,
buf->used += r;
assert(buf->used < sizeof(buf->buf));
+/* workaround strstr limitation */
+buf->buf[buf->used] = '\0';
+
+/*
+ * Search for the end of a QMP message: "\r\n".
+ * - First check if those two chr were received accross 2 read.
+ * - Then, look for them within the newly read data.
+ *
+ * end: This point to the address right after \r\n
+ */
+if (buf->buf[buf->used - r] == '\n') {
+/* First new chr read is \n, look if the previous one is \r. */
+
+if (buf->used - r == 0) {
+libxl__qmp_rx_buf *prev_buf;
+
+prev_buf = LIBXL_TAILQ_PREV(buf, libxl__qmp_bufs, entry);
+if (prev_buf &&
+prev_buf->buf[prev_buf->used - 1] == '\r') {
+end = buf->buf + 1;
+}
+} else if (buf->buf[buf->used - r - 1] == '\r') {
+end = buf->buf + buf->used - r - 1;
+end += 2;
+}
+}
+if (!end) {
+end = strstr(buf->buf + buf->used - r, "\r\n");
+if (end)
+end += 2;
+}
+
+while (end) {
+libxl__json_object *o;
+libxl__yajl_ctx *yajl_ctx;
+libxl__qmp_rx_buf *parse_buf, *tbuf;
+
+yajl_ctx = libxl__json_parse_alloc(gc);
+
+LIBXL_TAILQ_FOREACH_SAFE(parse_buf, >bufs, entry, tbuf) {
+size_t len;
+char *s;
+
+/* Start parsing from s */
+s = parse_buf->buf + parse_buf->consumed;
+/* Findout how much can be parsed */
+if (buf == parse_buf) {
+/* this is the last buffer to parse, stop at end */
+len = end - parse_buf->buf - parse_buf->consumed;
+} else {
+/* parse all the buffer */
+len = parse_buf->used - parse_buf->consumed;
+}
+
+LOG_QMP("parsing %luB: '%.*s'", len, (int)len, s);
+
+rc = libxl__json_parse_partial(gc, yajl_ctx, s, len);
+if (rc)
+break;
+
+parse_buf->consumed += len;
+
+if (parse_buf->consumed >= parse_buf->used) {
+LIBXL_TAILQ_REMOVE(>bufs, parse_buf, entry);
+free(parse_buf);
+if (buf == parse_buf) {
+buf = NULL;
+break;
+}
+}
+
+/* Last buffer to parse, will call complete */
+if (buf == parse_buf)
+break;
+}
+
+if (rc)
+return rc;
+
+o = libxl__json_complete_parse(gc, yajl_ctx);
+
+if (!o) {
+LOGD(ERROR, qmp->domid, "Parse error");
+return ERROR_FAIL;
+}
+
+LOG_QMP("JSON object received: %s", libxl__json_object_to_json(gc, o));
+
+/* check if there is another message received at the same time */
+if (buf) {
+end = strstr(buf->buf + buf->consumed, "\r\n");
+if (end)
+end += 2;
+} else
+end = NULL;
+}
return 0;
}
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 27/31] libxl_qmp: Implement libxl__qmp_insert_cdrom_ev
This function is a reimplementation of libxl__qmp_insert_cdrom() but to be
use with libxl__ev_qmp.
It also open the cdrom in libxl and send the FD via QMP, so QEMU doesn't
need access permition on the cdrom file.
libxl_cdrom_insert() will need to be reorganize to be able to use that
new function, this is done in the next few patches.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 4 ++
tools/libxl/libxl_qmp.c | 102 +++
2 files changed, 106 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 16533f651e..371b27e866 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1870,6 +1870,10 @@ _hidden int libxl__qmp_restore(libxl__gc *gc, int domid,
const char *filename);
/* Set dirty bitmap logging status */
_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool
enable);
_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const
libxl_device_disk *disk);
+int libxl__qmp_insert_cdrom_ev(libxl__gc *gc, int domid,
+ libxl__ev_qmp *ev,
+ libxl__ev_qmp_callback *callback,
+ const libxl_device_disk *disk);
/* Add a virtual CPU */
_hidden int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int index);
/* Query the bitmap of CPUs */
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f44b313a5e..6728e5ad9e 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1361,6 +1361,108 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t
domid,
return ret;
}
+/*
+ * Function using libxl__ev_qmp
+ */
+
+/* libxl__qmp_insert_cdrom_ev */
+
+struct cdrom_insert_ev_callback {
+libxl__ev_qmp ev;
+libxl__ev_qmp *callback_ev;
+libxl__ev_qmp_callback *callback;
+const libxl_device_disk *disk;
+};
+
+static void cdrom_insert_fd_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+ const libxl__json_object *response,
+ libxl__qmp_error_class error)
+{
+EGC_GC;
+libxl__json_object *args = NULL;
+const libxl__json_object *o;
+struct cdrom_insert_ev_callback *cb = CONTAINER_OF(ev, *cb, ev);
+const libxl_device_disk *disk = cb->disk;
+int dev_number = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+int fdset;
+int rc;
+
+o = libxl__json_map_get("fdset-id", response, JSON_INTEGER);
+if (!o) {
+rc = ERROR_FAIL;
+goto out;
+}
+fdset = libxl__json_object_get_integer(o);
+
+QMP_PARAMETERS_SPRINTF(, "device", "ide-%i", dev_number);
+QMP_PARAMETERS_SPRINTF(, "target", "/dev/fdset/%d", fdset);
+qmp_parameters_add_string(gc, , "arg",
+ libxl__qemu_disk_format_string(disk->format));
+rc = libxl__ev_qmp_register(gc, cb->callback_ev,
+cb->callback,
+ev->domid,
+"change", args);
+if (rc)
+goto out;
+out:
+libxl__ev_qmp_deregister(gc, ev);
+if (!o || rc) {
+cb->callback(egc, cb->callback_ev, NULL,
+ LIBXL__QMP_ERROR_CLASS_LIBXL_ERROR);
+}
+free(cb);
+}
+
+
+int libxl__qmp_insert_cdrom_ev(libxl__gc *gc, int domid, libxl__ev_qmp *ev,
+ libxl__ev_qmp_callback *callback,
+ const libxl_device_disk *disk)
+{
+libxl__json_object *args = NULL;
+int dev_number = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+int rc;
+libxl__carefd *cdrom_efd = NULL;
+struct cdrom_insert_ev_callback *cb = NULL;
+
+if (disk->format == LIBXL_DISK_FORMAT_EMPTY) {
+QMP_PARAMETERS_SPRINTF(, "device", "ide-%i", dev_number);
+rc = libxl__ev_qmp_register(gc, ev, callback, domid,
+"eject", args);
+} else {
+libxl__carefd_begin();
+cdrom_efd = libxl__carefd_opened(CTX, open(disk->pdev_path, O_RDONLY));
+if (!cdrom_efd) {
+LOGED(ERROR, domid,
+ "Failed to open cdrom file %s", disk->pdev_path);
+rc = ERROR_FAIL;
+goto out;
+}
+
+cb = libxl__malloc(NOGC, sizeof (*cb));
+libxl__ev_qmp_init(>ev);
+cb->callback = callback;
+cb->callback_ev = ev;
+cb->disk = disk;
+
+/* This free form parameter is not use by QEMU or libxl. */
+QMP_PARAMETERS_SPRINTF(, "opaque", "%s:%s",
+ libxl_disk_format_to_string(disk->format),
+ disk->pdev_path);
+cb->ev.efd = cdrom_efd;
+rc = libxl__ev_qmp_register(gc, >ev, cdrom_insert_fd_cb, domid,
+"add-fd", args);
+if (rc)
+goto out;
+}
+out:
+if (rc) {
+free(cb);
+libxl__carefd_close(cdrom_efd);
+}
+return
[Xen-devel] [PATCH v3 30/31] libxl_dm: Pre-open QMP socket for QEMU
When starting QEMU with dm_restrict=1, pre-open the QMP socket before
exec QEMU. That socket will be usefull to findout if QEMU is ready, and
pre-opening it means that libxl can connect to it without waiting for
QEMU to create it.
The pre-openning is conditionnal, based on the use of dm_restrict
because it is using a new command line option of QEMU, and dm_restrict
support in QEMU is newer.
-chardev socket,fd=X is available with QEMU 2.12, since commit:
> char: allow passing pre-opened socket file descriptor at startup
> 0935700f8544033ebbd41e1f13cd528f8a58d24d
dm_restrict will be available in QEMU 3.0.
Signed-off-by: Anthony PERARD
---
Notes:
We may want to set cloexec on the socket up to the forking point. Because if
the socket stay open in a random process, libxl will not detected right
away if
QEMU as failed to start. On the other hand, we can rely on timeouts.
tools/libxl/libxl_dm.c | 73 --
1 file changed, 64 insertions(+), 9 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 18ada69e8b..10b35d822a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
static const char *libxl_tapif_script(libxl__gc *gc)
{
@@ -913,7 +915,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
const libxl_domain_config
*guest_config,
char ***args, char ***envs,
const libxl__domain_build_state *state,
-int *dm_state_fd)
+int *dm_state_fd, int *dm_monitor_fd)
{
const libxl_domain_create_info *c_info = _config->c_info;
const libxl_domain_build_info *b_info = _config->b_info;
@@ -942,10 +944,58 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
GCSPRINTF("%d", guest_domid), NULL);
flexarray_append(dm_args, "-chardev");
-flexarray_append(dm_args,
- GCSPRINTF("socket,id=libxl-cmd,"
-"path=%s/qmp-libxl-%d,server,nowait",
-libxl__run_dir_path(), guest_domid));
+/* If we have to use dm_restrict, QEMU need to be new enough and will have
+ * the new interface where we can pre-open the QMP socket. */
+if (libxl_defbool_val(b_info->dm_restrict))
+{
+int socket_fd = -1;
+struct sockaddr_un un;
+const char *socket_path;
+
+socket_fd = socket(AF_UNIX, SOCK_STREAM, 0);
+*dm_monitor_fd = socket_fd;
+if (socket_fd < 0) {
+LOGED(ERROR, guest_domid, "Failed to create UNIX socket");
+return ERROR_FAIL;
+}
+
+socket_path = GCSPRINTF("%s/qmp-libxl-%d",
+libxl__run_dir_path(), guest_domid);
+if (strlen(socket_path) > sizeof(un.sun_path)) {
+LOGD(ERROR, guest_domid, "UNIX socket path '%s' is too long",
+ socket_path);
+LOGD(DEBUG, guest_domid, "Path must be less than %zu bytes",
+ sizeof(un.sun_path));
+return ERROR_FAIL;
+}
+
+if (unlink(socket_path) < 0 && errno != ENOENT) {
+LOGED(ERROR, guest_domid, "Failed to unlink socket %s",
socket_path);
+return ERROR_FAIL;
+}
+
+memset(, 0, sizeof(un));
+un.sun_family = AF_UNIX;
+strncpy(un.sun_path, socket_path, sizeof(un.sun_path));
+if (bind(socket_fd, (struct sockaddr*) , sizeof(un)) < 0) {
+LOGED(ERROR, guest_domid, "Failed to bind socket to %s",
socket_path);
+return ERROR_FAIL;
+}
+
+if (listen(socket_fd, 1) < 0) {
+LOGED(ERROR, guest_domid, "Failed to listen on socket");
+return ERROR_FAIL;
+}
+
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxl-cmd,fd=%d,server,nowait",
+ socket_fd));
+} else {
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxl-cmd,"
+ "path=%s/qmp-libxl-%d,server,nowait",
+ libxl__run_dir_path(), guest_domid));
+}
flexarray_append(dm_args, "-no-shutdown");
flexarray_append(dm_args, "-mon");
@@ -1722,7 +1772,8 @@ static int libxl__build_device_model_args(libxl__gc *gc,
const libxl_domain_config
*guest_config,
char ***args, char ***envs,
const libxl__domain_build_state *state,
-int *dm_state_fd)
+int *dm_state_fd,
+int *dm_monitor_fd)
/* dm_state_fd
[Xen-devel] [PATCH v3 31/31] libxl: QEMU startup sync based on QMP
This is only activated when dm_restrict=1, as explained in the previous
patch "libxl_dm: Pre-open QMP socket for QEMU"
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_dm.c | 7 ++
tools/libxl/libxl_exec.c | 44
tools/libxl/libxl_internal.h | 5
3 files changed, 56 insertions(+)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 10b35d822a..4e89e09fc8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2398,6 +2398,13 @@ retry_transaction:
spawn->failure_cb = device_model_startup_failed;
spawn->detached_cb = device_model_detached;
+spawn->qmp_domid = INVALID_DOMID;
+if (dm_monitor_fd >= 0) {
+/* There is a valid QMP socket available now, have libxl__spawn_spawn
+ * use it to find out when QEMU is ready */
+spawn->qmp_domid = domid;
+}
+
rc = libxl__spawn_spawn(egc, spawn);
if (rc < 0)
goto out_close;
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 02e6c917f0..e61297ed2f 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -258,6 +258,9 @@ err:
/* Event callbacks. */
static void spawn_watch_event(libxl__egc *egc, libxl__xswait_state *xswa,
int rc, const char *xsdata);
+static void spawn_qmp_callback(libxl__egc *egc, libxl__ev_qmp *ev,
+ const libxl__json_object *response,
+ libxl__qmp_error_class error);
static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
pid_t pid, int status);
@@ -272,6 +275,7 @@ void libxl__spawn_init(libxl__spawn_state *ss)
{
libxl__ev_child_init(>mid);
libxl__xswait_init(>xswait);
+libxl__ev_qmp_init(>ev_qmp);
}
int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -291,6 +295,11 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state
*ss)
ss->xswait.callback = spawn_watch_event;
rc = libxl__xswait_start(gc, >xswait);
if (rc) goto out_err;
+if (ss->qmp_domid != INVALID_DOMID) {
+rc = libxl__ev_qmp_register(gc, >ev_qmp, spawn_qmp_callback,
+ss->qmp_domid, "query-status", NULL);
+if (rc) goto out_err;
+}
pid_t middle = libxl__ev_child_fork(gc, >mid, spawn_middle_death);
if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
@@ -347,6 +356,7 @@ static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state
*ss)
{
assert(!libxl__ev_child_inuse(>mid));
libxl__xswait_stop(gc, >xswait);
+libxl__ev_qmp_deregister(gc, >ev_qmp);
}
static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
@@ -359,6 +369,7 @@ static void spawn_detach(libxl__gc *gc, libxl__spawn_state
*ss)
assert(libxl__ev_child_inuse(>mid));
assert(ss->detaching || ss->rc);
libxl__xswait_stop(gc, >xswait);
+libxl__ev_qmp_deregister(gc, >ev_qmp);
pid_t child = ss->mid.pid;
r = kill(child, SIGKILL);
@@ -399,6 +410,39 @@ static void spawn_watch_event(libxl__egc *egc,
libxl__xswait_state *xswa,
ss->confirm_cb(egc, ss, p); /* must be last */
}
+static void spawn_qmp_callback(libxl__egc *egc, libxl__ev_qmp *ev,
+ const libxl__json_object *response,
+ libxl__qmp_error_class error)
+{
+EGC_GC;
+libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, ev_qmp);
+const libxl__json_object *o;
+const char *status;
+
+if (error) {
+goto failed;
+}
+o = libxl__json_map_get("status", response, JSON_STRING);
+if (!o) {
+LOGD(DEBUG, ev->domid, "QMP unexpected response");
+goto failed;
+}
+status = libxl__json_object_get_string(o);
+if (!strcmp(status, "running")) {
+/* success */
+} else {
+LOGD(DEBUG, ev->domid, "Unexpected QEMU status: %s", status);
+goto failed;
+}
+
+ss->confirm_cb(egc, ss, status); /* must be last */
+return;
+
+failed:
+LOGD(ERROR, ev->domid, "QEMU did not start properly");
+spawn_fail(egc, ss, ERROR_FAIL); /* must be last */
+}
+
static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
pid_t pid, int status)
/* On entry, is Attached or Detaching */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 371b27e866..61cc8c9f0c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1603,11 +1603,16 @@ struct libxl__spawn_state {
libxl__spawn_confirm_cb *confirm_cb;
libxl__spawn_detached_cb *detached_cb;
+/* If qmp_domid != INVALID_DOMID, then libxl__spawn_spawn will also use QMP
+ * to find out when the process is started */
+uint32_t qmp_domid;
+
/* remaining fields are private to libxl_spawn_... */
int detaching; /* we are in Detaching */
int rc; /* might be non-0 whenever we are not Idle
[Xen-devel] [PATCH v3 29/31] libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp
So when QEMU is involve, the operation will be asynchrone and will
finish later.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_disk.c | 55 +++-
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index a3bf974fe3..9808a53c1b 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -663,6 +663,7 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t
domid,
typedef struct {
libxl__ao *ao;
+libxl__ev_qmp ev;
libxl_domain_config d_config;
const char *be_path;
const char *libxl_path;
@@ -675,8 +676,14 @@ typedef struct {
} libxl__cdrom_insert_state;
static void cdrom_insert_ejected(libxl__egc *egc,
libxl__cdrom_insert_state *cis);
+static void cdrom_insert_ejected_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+libxl__qmp_error_class error);
static void cdrom_insert_inserted(libxl__egc *egc,
libxl__cdrom_insert_state *cis);
+static void cdrom_insert_inserted_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+ const libxl__json_object *response,
+ libxl__qmp_error_class error);
static void cdrom_insert_done(libxl__egc *egc,
libxl__cdrom_insert_state *cis,
int rc);
@@ -694,6 +701,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
GCNEW(cis);
cis->ao = ao;
cis->domid = domid;
+libxl__ev_qmp_init(>ev);
// XXX: can I do that? is disk going to exist until the AO is over?
cis->disk = disk;
@@ -778,12 +786,14 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
* by inserting empty media. JSON is not updated.
*/
if (cis->dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-rc = libxl__qmp_insert_cdrom(gc, domid, disk_empty);
+rc = libxl__qmp_insert_cdrom_ev(gc, domid, >ev,
+cdrom_insert_ejected_qmp_cb,
+disk_empty);
if (rc) goto out;
+} else {
+cdrom_insert_ejected(egc, cis);
}
-cdrom_insert_ejected(egc, cis);
-
return AO_INPROGRESS;
out:
@@ -794,6 +804,21 @@ out:
return AO_INPROGRESS;
}
+static void cdrom_insert_ejected_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+libxl__qmp_error_class error)
+{
+EGC_GC;
+libxl__cdrom_insert_state *cis = CONTAINER_OF(ev, *cis, ev);
+
+if (error) {
+cdrom_insert_done(egc, cis, ERROR_FAIL);
+} else {
+libxl__ev_qmp_deregister(gc, ev);
+cdrom_insert_ejected(egc, cis);
+}
+}
+
static void cdrom_insert_ejected(libxl__egc *egc,
libxl__cdrom_insert_state *cis)
{
@@ -852,12 +877,14 @@ static void cdrom_insert_ejected(libxl__egc *egc,
if (rc) goto out;
if (cis->dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-rc = libxl__qmp_insert_cdrom(gc, domid, disk);
+rc = libxl__qmp_insert_cdrom_ev(gc, domid, >ev,
+cdrom_insert_inserted_qmp_cb,
+disk);
if (rc) goto out;
+} else {
+cdrom_insert_inserted(egc, cis);
}
-cdrom_insert_inserted(egc, cis);
-
return;
out:
@@ -865,6 +892,21 @@ out:
cdrom_insert_done(egc, cis, rc);
}
+static void cdrom_insert_inserted_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+ const libxl__json_object *response,
+ libxl__qmp_error_class error)
+{
+EGC_GC;
+libxl__cdrom_insert_state *cis = CONTAINER_OF(ev, *cis, ev);
+
+if (error) {
+cdrom_insert_done(egc, cis, ERROR_FAIL);
+} else {
+libxl__ev_qmp_deregister(gc, ev);
+cdrom_insert_inserted(egc, cis);
+}
+}
+
static void cdrom_insert_inserted(libxl__egc *egc,
libxl__cdrom_insert_state *cis)
{
@@ -934,6 +976,7 @@ static void cdrom_insert_done(libxl__egc *egc,
{
STATE_AO_GC(cis->ao);
+libxl__ev_qmp_deregister(gc, >ev);
libxl_domain_config_dispose(>d_config);
libxl_device_disk_dispose(>disk_empty);
libxl_device_disk_dispose(>disk_saved);
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 22/31] libxl_qmp: Simplify qmp_response_type() prototype
Remove the libxl__qmp_handler* argument so the function can be reused
later in a different context.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 02eae1f5ce..0e7ec54b9f 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -280,8 +280,7 @@ static int enable_qmp_capabilities(libxl__qmp_handler *qmp)
* Helpers
*/
-static libxl__qmp_message_type qmp_response_type(libxl__qmp_handler *qmp,
- const libxl__json_object *o)
+static libxl__qmp_message_type qmp_response_type(const libxl__json_object *o)
{
libxl__qmp_message_type type;
libxl__json_map_node *node = NULL;
@@ -347,7 +346,7 @@ static int qmp_handle_response(libxl__gc *gc,
libxl__qmp_handler *qmp,
{
libxl__qmp_message_type type = LIBXL__QMP_MESSAGE_TYPE_INVALID;
-type = qmp_response_type(qmp, resp);
+type = qmp_response_type(resp);
LOGD(DEBUG, qmp->domid, "message type: %s",
libxl__qmp_message_type_to_string(type));
switch (type) {
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 24/31] libxl_qmp_ev: Respond to QMP greeting
Slight change in the infrastructure to allow to send a buffer before any
command that would already been prepared.
qmp_capabilities needs to be the first command sent.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 87 ++---
1 file changed, 82 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index db07c1822a..adf466e4c4 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1387,6 +1387,8 @@ struct libxl__ev_qmp_state {
unsigned int last_id_used;
/* Indicate that QEMU is ready to respond to command. */
bool ready;
+/* Allow to commands while !ready, to respond to QMP greeting. */
+int priority_send;
LIBXL_TAILQ_HEAD(libxl__qmp_tx_bufs, libxl__qmp_tx_buf) tx_buf;
LIBXL_TAILQ_HEAD(libxl__ev_qmps, libxl__ev_qmp) qmp_events;
@@ -1398,7 +1400,8 @@ static int ev_qmp_queue_command(libxl__gc *gc,
libxl__ev_qmp_state *qmp,
const char *cmd,
const libxl__json_object *args,
-libxl__carefd *efd)
+libxl__carefd *efd,
+bool high_priority)
{
char *buf = NULL;
size_t len;
@@ -1414,12 +1417,78 @@ static int ev_qmp_queue_command(libxl__gc *gc,
out->buf = buf;
out->len = len;
out->efd = efd;
-LIBXL_TAILQ_INSERT_TAIL(>tx_buf, out, entry);
+if (high_priority) {
+/* qmp_capabilities cmd need to be send out first */
+LIBXL_TAILQ_INSERT_HEAD(>tx_buf, out, entry);
+qmp->priority_send += 1;
+} else {
+LIBXL_TAILQ_INSERT_TAIL(>tx_buf, out, entry);
+}
libxl__ev_fd_modify(gc, >efd, qmp->efd.events | POLLOUT);
return 0;
}
+/* QMP greeting response */
+typedef struct {
+libxl__ev_qmp ev;
+libxl__ev_qmp_state *qmp;
+} ev_qmp_greeting_state;
+static void ev_qmp_callback_capabilities(libxl__egc *egc,
+libxl__ev_qmp *ev,
+const libxl__json_object *o,
+libxl__qmp_error_class error)
+{
+EGC_GC;
+ev_qmp_greeting_state *qegs = CONTAINER_OF(ev, *qegs, ev);
+libxl__ev_qmp_state *qmp = qegs->qmp;
+
+CTX_LOCK;
+qmp->ready = true;
+
+/* Allow potential command to be sent */
+libxl__ev_fd_modify(gc, >efd, qmp->efd.events | POLLOUT);
+
+CTX_UNLOCK;
+
+libxl__ev_qmp_deregister(gc, ev);
+
+free(qegs);
+}
+
+static int ev_qmp_callback_greeting(libxl__egc *egc,
+libxl__ev_qmp_state *qmp)
+{
+EGC_GC;
+ev_qmp_greeting_state *qegs;
+int rc;
+
+/* Will be freed in callback */
+qegs = libxl__malloc(NOGC, sizeof(*qegs));
+
+libxl__ev_qmp_init(>ev);
+
+/* Do part of libxl__ev_qmp_register as this is the only time where the
+ * argument high_priority is true. */
+
+qegs->qmp = qmp;
+qegs->ev.domid = qmp->domid;
+qegs->ev.callback = ev_qmp_callback_capabilities;
+rc = ev_qmp_queue_command(gc, qmp, "qmp_capabilities", NULL, NULL, true);
+if (rc)
+goto out;
+qegs->ev.id = qmp->last_id_used;
+
+CTX_LOCK;
+LIBXL_TAILQ_INSERT_TAIL(>qmp_events, >ev, entry);
+CTX_UNLOCK;
+
+out:
+if (rc)
+free(qegs);
+return rc;
+}
+
/*
* Handle messages received from QMP server
*/
@@ -1501,7 +1570,8 @@ static void ev_qmp_handle_message(libxl__egc *egc,
switch (type) {
case LIBXL__QMP_MESSAGE_TYPE_QMP:
-/* greeting message */
+/* On the greeting message from the server, call qmp_capabilities */
+ev_qmp_callback_greeting(egc, qmp);
return;
case LIBXL__QMP_MESSAGE_TYPE_RETURN:
case LIBXL__QMP_MESSAGE_TYPE_ERROR:
@@ -1673,7 +1743,9 @@ static int ev_qmp_callback_writable(libxl__egc *egc,
libxl__qmp_tx_buf *buf;
int rc;
-if (!qmp->ready) {
+/* Don't send anything until connected, unless there is the response to the
+ * greeting message */
+if (!qmp->ready && !qmp->priority_send) {
return 0;
}
@@ -1701,6 +1773,9 @@ static int ev_qmp_callback_writable(libxl__egc *egc,
free(buf->buf);
free(buf);
+if (!qmp->ready && qmp->priority_send)
+qmp->priority_send -= 1;
+
out:
return 1;
}
@@ -1771,6 +1846,7 @@ static void libxl__ev_qmp_state_init(libxl__ev_qmp_state
*qmp)
LIBXL_TAILQ_INIT(>bufs);
qmp->last_id_used = 0;
qmp->ready = false;
+qmp->priority_send = 0;
LIBXL_TAILQ_INIT(>tx_buf);
LIBXL_TAILQ_INIT(>qmp_events);
}
@@ -1878,6 +1954,7 @@ void libxl__ev_qmp_stop(libxl__gc *gc,
libxl__ev_qmp_state *qmp)
LIBXL_TAILQ_INIT(>qmp_events);
qmp->ready = false;
+qmp->priority_send = 0;
libxl__ev_fd_deregister(gc, >efd);
libxl__carefd_close(qmp->cfd);
@@ -1917,7 +1994,7 @@ int
Re: [Xen-devel] [PATCH v3 00/31] libxl: Enable save/restore/migration of a restricted QEMU + libxl__ev_qmp_*
On Fri, Jun 01, 2018 at 03:36:49PM +0100, Anthony PERARD wrote: > The real meat in this patch series start with patch > "libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP" > which implement libxl__ev_qmp_* functions to turn the QMP client into > asynchronous mode. > > This comes with two examples on how to use it: > * "libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp" > with patches: > - "libxl_qmp: Implement libxl__qmp_insert_cdrom_ev" > - "libxl_disk: Cut libxl_cdrom_insert into step" > * "libxl: QEMU startup sync based on QMP" > which can use QMP to find out when QEMU as started. > this requires: "libxl_dm: Pre-open QMP socket for QEMU" > But that only works with dm_restrict=1 as explain in the patch. > > The first few patches do some cleanup and fixes of the current qmp client > implementation, mostly because it bothered me as I think we should remove the > current implementation. There is also two patches to allow to save a > restricted > QEMU, but that would need to be converted over to libxl__ev_qmp_*. > > There is still one bug that I haven't fix yet. When creating a guest with > dm_restrict=1, the call to libxl__qmp_initializations() is going to fail > because libxl is still connected to the QMP socket. But libxl doesn't care > about failure, and that just mean that `xl console` will not work and vnc will > not have any password. save/restore of the same guest will works fine because > libxl__ev_qmp_* will have an oportunity to disconnect from the socket before > libxl__qmp_initializations() is called. > > Cheers, Patches series available in a git tag: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git libxl-migration-fdset-v3 -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 08/31] libxl_qmp: Have QEMU save its state to a file descriptor
In case QEMU have restricted access to the system, open the file for it,
and QEMU will save its state to this file descritor.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e1fcce2291..c71c3cbca4 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -998,25 +998,61 @@ int libxl__qmp_system_wakeup(libxl__gc *gc, int domid)
return qmp_run_command(gc, domid, "system_wakeup", NULL, NULL, NULL);
}
+/* Find out which fdset have been allocated */
+static int qmp_fdset_add_fd_callback(libxl__qmp_handler *qmp,
+ const libxl__json_object *ret,
+ void *opaque)
+{
+const libxl__json_object *o;
+int fdset;
+
+o = libxl__json_map_get("fdset-id", ret, JSON_INTEGER);
+if (!o)
+return 1;
+
+fdset = libxl__json_object_get_integer(o);
+*(int*)opaque = fdset;
+return 0;
+}
+
int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename, bool live)
{
libxl__json_object *args = NULL;
libxl__qmp_handler *qmp = NULL;
int rc;
+int state_fd;
+int new_fdset;
qmp = libxl__qmp_initialize(gc, domid);
if (!qmp)
return ERROR_FAIL;
-qmp_parameters_add_string(gc, , "filename", (char *)filename);
+state_fd = open(filename, O_WRONLY | O_CREAT, 0600);
+if (state_fd < 0) {
+LOGED(ERROR, domid,
+ "Failed to open file %s for QEMU", filename);
+goto out;
+}
+
+qmp->fd_to_send = state_fd;
+
+rc = qmp_synchronous_send(qmp, "add-fd", NULL,
+ qmp_fdset_add_fd_callback, _fdset,
+ qmp->timeout);
+if (rc)
+goto out;
/* live parameter was added to QEMU 2.11. It signal QEMU that the save
* operation is for a live migration rather that for taking a snapshot. */
if (qmp_qemu_check_version(qmp, 2, 11, 0))
qmp_parameters_add_bool(gc, , "live", live);
+QMP_PARAMETERS_SPRINTF(, "filename", "/dev/fdset/%d", new_fdset);
rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
NULL, NULL, qmp->timeout);
+out:
+if (state_fd >= 0)
+close(state_fd);
libxl__qmp_close(qmp);
return rc;
}
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 00/31] libxl: Enable save/restore/migration of a restricted QEMU + libxl__ev_qmp_*
The real meat in this patch series start with patch "libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP" which implement libxl__ev_qmp_* functions to turn the QMP client into asynchronous mode. This comes with two examples on how to use it: * "libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp" with patches: - "libxl_qmp: Implement libxl__qmp_insert_cdrom_ev" - "libxl_disk: Cut libxl_cdrom_insert into step" * "libxl: QEMU startup sync based on QMP" which can use QMP to find out when QEMU as started. this requires: "libxl_dm: Pre-open QMP socket for QEMU" But that only works with dm_restrict=1 as explain in the patch. The first few patches do some cleanup and fixes of the current qmp client implementation, mostly because it bothered me as I think we should remove the current implementation. There is also two patches to allow to save a restricted QEMU, but that would need to be converted over to libxl__ev_qmp_*. There is still one bug that I haven't fix yet. When creating a guest with dm_restrict=1, the call to libxl__qmp_initializations() is going to fail because libxl is still connected to the QMP socket. But libxl doesn't care about failure, and that just mean that `xl console` will not work and vnc will not have any password. save/restore of the same guest will works fine because libxl__ev_qmp_* will have an oportunity to disconnect from the socket before libxl__qmp_initializations() is called. Cheers, Anthony PERARD (31): libxl_event: Fix DEBUG prints libxl_qmp: Documentation of the logic of the QMP client libxl_qmp: Fix use of DEBUG_RECEIVED libxl_json: fix build with DEBUG_ANSWER libxl_qmp: Move the buffer realloc to the same scope level as read libxl_qmp: Add a warning to not trust QEMU libxl_qmp: Learned to send FD through QMP to QEMU libxl_qmp: Have QEMU save its state to a file descriptor libxl_qmp: Move struct sockaddr_un variable to qmp_open() libxl_qmp: Move buffers to the stack of qmp_next. libxl_qmp: Remove unused yajl_ctx form handler libxl_json: constify libxl__json_object_to_yajl_gen arguments libxl_qmp: Separate QMP message generation from qmp_send_prepare libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP libxl_qmp_ev: Implement fd callback and read data libxl_json: Allow partial parsing libxl_json: Enable yajl_allow_trailing_garbage libxl_json: libxl__json_object_to_json libxl_qmp_ev: Parse JSON input from QMP libxl_qmp: Introduce libxl__ev_qmp functions libxl_qmp_ev: Handle write to socket libxl_qmp: Simplify qmp_response_type() prototype libxl_qmp_ev: Handle messages from QEMU libxl_qmp_ev: Respond to QMP greeting libxl_qmp_ev: Disconnect QMP when no more events libxl_qmp: Disable beautify for QMP generated cmd libxl_qmp: Implement libxl__qmp_insert_cdrom_ev libxl_disk: Cut libxl_cdrom_insert into step libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp libxl_dm: Pre-open QMP socket for QEMU libxl: QEMU startup sync based on QMP tools/libxl/libxl.c |4 + tools/libxl/libxl_disk.c | 242 -- tools/libxl/libxl_dm.c | 80 +- tools/libxl/libxl_event.c|8 +- tools/libxl/libxl_exec.c | 44 ++ tools/libxl/libxl_internal.h | 67 +- tools/libxl/libxl_json.c | 142 +++- tools/libxl/libxl_json.h |5 +- tools/libxl/libxl_qmp.c | 1024 -- tools/libxl/libxl_types_internal.idl | 14 + 10 files changed, 1478 insertions(+), 152 deletions(-) -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 03/31] libxl_qmp: Fix use of DEBUG_RECEIVED
This patch fix complilation error with #define DEBUG_RECEIVED of the
macro DEBUG_REPORT_RECEIVED.
error: field precision specifier ‘.*’ expects argument of type ‘int’, but
argument 9 has type ‘ssize_t {aka long int}’
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
---
Notes:
New in RFC v2
tools/libxl/libxl_qmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 36b183c8c4..c42e2bf4b8 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -528,7 +528,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
}
qmp->buffer[rd] = '\0';
-DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, rd);
+DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, (int)rd);
do {
char *end = NULL;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 01/31] libxl_event: Fix DEBUG prints
The libxl__log() call was missing the domid.
The macro DBG is using LIBXL__LOG which rely on a "gc". Add a GC where
needed.
Signed-off-by: Anthony PERARD
Reviewed-by: Wei Liu
---
Notes:
v3:
- Add a commit message.
New in RFC v2
tools/libxl/libxl_event.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 484f9bab4d..0370b6acdd 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -248,6 +248,7 @@ void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd
*ev)
short libxl__fd_poll_recheck(libxl__egc *egc, int fd, short events) {
struct pollfd check;
int r;
+EGC_GC;
for (;;) {
check.fd = fd;
@@ -336,7 +337,7 @@ static void time_done_debug(libxl__gc *gc, const char *func,
libxl__ev_time *ev, int rc)
{
#ifdef DEBUG
-libxl__log(CTX, XTL_DEBUG, -1,__FILE__,0,func,
+libxl__log(CTX, XTL_DEBUG, -1, __FILE__, 0, func, INVALID_DOMID,
"ev_time=%p done rc=%d .func=%p infinite=%d abs=%lu.%06lu",
ev, rc, ev->func, ev->infinite,
(unsigned long)ev->abs.tv_sec, (unsigned long)ev->abs.tv_usec);
@@ -445,6 +446,8 @@ void libxl__ev_time_deregister(libxl__gc *gc,
libxl__ev_time *ev)
static void time_occurs(libxl__egc *egc, libxl__ev_time *etime, int rc)
{
+EGC_GC;
+
DBG("ev_time=%p occurs abs=%lu.%06lu",
etime, (unsigned long)etime->abs.tv_sec,
(unsigned long)etime->abs.tv_usec);
@@ -1192,6 +1195,7 @@ static int afterpoll_check_fd(libxl__poller *poller,
static void fd_occurs(libxl__egc *egc, libxl__ev_fd *efd, short revents_ign)
{
short revents_current = libxl__fd_poll_recheck(egc, efd->fd, efd->events);
+EGC_GC;
DBG("ev_fd=%p occurs fd=%d events=%x revents_ign=%x revents_current=%x",
efd, efd->fd, efd->events, revents_ign, revents_current);
@@ -2117,6 +2121,8 @@ int libxl_ao_abort(libxl_ctx *ctx, const
libxl_asyncop_how *how)
int libxl__ao_aborting(libxl__ao *ao)
{
libxl__ao *root = ao_nested_root(ao);
+AO_GC;
+
if (root->aborting) {
DBG("ao=%p: aborting at explicit check (root=%p)", ao, root);
return ERROR_ABORTED;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 04/31] libxl_json: fix build with DEBUG_ANSWER
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_json.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0823b8cfd2..dc93a88ef1 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -59,8 +59,8 @@ struct libxl__yajl_ctx {
const unsigned char *buf = NULL; \
size_t len = 0; \
yajl_gen_get_buf((yajl_ctx)->g, , ); \
-LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), LIBXL__LOG_DEBUG,
- "response:\n", buf); \
+LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), XTL_DEBUG, \
+ "response: %s\n", buf); \
yajl_gen_free((yajl_ctx)->g); \
(yajl_ctx)->g = NULL; \
} while (0)
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 09/31] libxl_qmp: Move struct sockaddr_un variable to qmp_open()
This variable is only used once, no need to keep it in the handler.
Also fix coding style (remove space after sizeof).
And allow strncpy to use all the space in sun_path.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c71c3cbca4..251840a155 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -105,7 +105,6 @@ typedef struct callback_id_pair {
} callback_id_pair;
struct libxl__qmp_handler {
-struct sockaddr_un addr;
int qmp_fd;
bool connected;
time_t timeout;
@@ -436,6 +435,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char
*qmp_socket_path,
{
int ret = -1;
int i = 0;
+struct sockaddr_un addr;
qmp->qmp_fd = socket(AF_UNIX, SOCK_STREAM, 0);
if (qmp->qmp_fd < 0) {
@@ -452,18 +452,16 @@ static int qmp_open(libxl__qmp_handler *qmp, const char
*qmp_socket_path,
goto out;
}
-if (sizeof (qmp->addr.sun_path) <= strlen(qmp_socket_path)) {
+if (sizeof(addr.sun_path) <= strlen(qmp_socket_path)) {
ret = -1;
goto out;
}
-memset(>addr, 0, sizeof (qmp->addr));
-qmp->addr.sun_family = AF_UNIX;
-strncpy(qmp->addr.sun_path, qmp_socket_path,
-sizeof (qmp->addr.sun_path)-1);
+memset(, 0, sizeof(addr));
+addr.sun_family = AF_UNIX;
+strncpy(addr.sun_path, qmp_socket_path, sizeof(addr.sun_path) - 1);
do {
-ret = connect(qmp->qmp_fd, (struct sockaddr *) >addr,
- sizeof (qmp->addr));
+ret = connect(qmp->qmp_fd, (struct sockaddr *) , sizeof(addr));
if (ret == 0)
break;
if (errno == ENOENT || errno == ECONNREFUSED) {
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 02/31] libxl_qmp: Documentation of the logic of the QMP client
Signed-off-by: Anthony PERARD Acked-by: Wei Liu --- Notes: v3: - Add documentation of the qmp_callback_t type. New in RFC v2 tools/libxl/libxl_qmp.c | 42 + 1 file changed, 42 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index be1fda18ba..36b183c8c4 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -18,6 +18,42 @@ * Specification, see in the QEMU repository. */ +/* + * Logic used to send command to QEMU + * + * qmp_open(): + * Will open a socket and connect to QEMU. + * + * qmp_next(): + * Will read data sent by QEMU and then call qmp_handle_response() once a + * complete QMP message is received. + * The function return on timeout/error or once every data received as been + * processed. + * + * qmp_handle_response() + * This process json messages received from QEMU and update different list and + * may call callback function. + * `libxl__qmp_handler.wait_for_id` is reset once a message with this ID is + *processed. + * `libxl__qmp_handler.callback_list`: list with ID of command sent and + *optional assotiated callback function. The return value of a callback is + *set in context. + * + * qmp_send(): + * Simply prepare a QMP command and send it to QEMU. + * It also add a `struct callback_id_pair` on the + * `libxl__qmp_handler.callback_list` via qmp_send_prepare(). + * + * qmp_synchronous_send(): + * This function calls qmp_send(), then wait for QEMU to reply to the command. + * The wait is done by calling qmp_next() over and over again until either + * there is a response for the command or there is an error. + * + * An ID can be set for each QMP command, this is set into + * `libxl__qmp_handler.wait_for_id`. qmp_next will check every response's ID + * again this field and change the value of the field once the ID is found. + */ + #include "libxl_osdeps.h" /* must come before any other headers */ #include @@ -43,6 +79,12 @@ #define QMP_RECEIVE_BUFFER_SIZE 4096 #define PCI_PT_QDEV_ID "pci-pt-%02x_%02x.%01x" +/* + * qmp_callback_t is call whenever a message from QMP contain the "id" + * associated with the callback. + * "tree" contain the JSON tree that is in "return" of a QMP message. If QMP + * sent an error message, "tree" will be NULL. + */ typedef int (*qmp_callback_t)(libxl__qmp_handler *qmp, const libxl__json_object *tree, void *opaque); -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 05/31] libxl_qmp: Move the buffer realloc to the same scope level as read
In qmp_next(), the inner loop should only try to parse messages from
QMP, if there is more than one.
The handling of the receive buffer ('incomplete'), should be done at the
same scope level as read(). It doesn't need to be handle more that once
after a read.
Before this patch, when on message what handled, the inner loop would
restart by adding the 'buffer' into 'incomplete' (after reallocation).
Since 'rd' was not reset, the buffer would be strcat a second time.
After that, the stream from the QMP server would have syntax error, and
the parsor would throw errors.
This is unlikely to happen as the receive buffer is very large. And
receiving two messages in a row is unlikely. In the current case, this
could be an event and a response to a command.
Signed-off-by: Anthony PERARD
---
Notes:
New in RFC v2
tools/libxl/libxl_qmp.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c42e2bf4b8..58ecd4baf3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -530,23 +530,24 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler
*qmp)
DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, (int)rd);
+if (incomplete) {
+size_t current_pos = s - incomplete;
+incomplete = libxl__realloc(gc, incomplete,
+incomplete_size + rd + 1);
+strncat(incomplete + incomplete_size, qmp->buffer, rd);
+s = incomplete + current_pos;
+incomplete_size += rd;
+s_end = incomplete + incomplete_size;
+} else {
+incomplete = libxl__strndup(gc, qmp->buffer, rd);
+incomplete_size = rd;
+s = incomplete;
+s_end = s + rd;
+rd = 0;
+}
+
do {
char *end = NULL;
-if (incomplete) {
-size_t current_pos = s - incomplete;
-incomplete = libxl__realloc(gc, incomplete,
-incomplete_size + rd + 1);
-strncat(incomplete + incomplete_size, qmp->buffer, rd);
-s = incomplete + current_pos;
-incomplete_size += rd;
-s_end = incomplete + incomplete_size;
-} else {
-incomplete = libxl__strndup(gc, qmp->buffer, rd);
-incomplete_size = rd;
-s = incomplete;
-s_end = s + rd;
-rd = 0;
-}
end = strstr(s, "\r\n");
if (end) {
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 07/31] libxl_qmp: Learned to send FD through QMP to QEMU
Adding the ability to send a file descriptor from libxl to QEMU via the
QMP interface. This will be use with the "add-fd" QMP command.
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
---
tools/libxl/libxl_qmp.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 8b3ed94868..e1fcce2291 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -125,6 +125,9 @@ struct libxl__qmp_handler {
int minor;
int micro;
} version;
+
+/* File descriptor to send to QEMU on the next command */
+int fd_to_send;
};
static int qmp_send(libxl__qmp_handler *qmp,
@@ -423,6 +426,8 @@ static libxl__qmp_handler *qmp_init_handler(libxl__gc *gc,
uint32_t domid)
LIBXL_STAILQ_INIT(>callback_list);
+qmp->fd_to_send = -1;
+
return qmp;
}
@@ -648,9 +653,16 @@ static int qmp_send(libxl__qmp_handler *qmp,
goto out;
}
-if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, strlen(buf),
-"QMP command", "QMP socket"))
-goto out;
+if (qmp->fd_to_send >= 0) {
+if (libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf),
+ 1, >fd_to_send, "QMP socket"))
+goto out;
+qmp->fd_to_send = -1;
+} else {
+if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, strlen(buf),
+"QMP command", "QMP socket"))
+goto out;
+}
if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
"CRLF", "QMP socket"))
goto out;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/traps: Fix error handling of the pv %dr7 shadow state
On 01/06/18 15:06, Andrew Cooper wrote:
> c/s "x86/pv: Introduce and use x86emul_write_dr()" fixed a bug with IO shadow
> handling, in that it remained stale and visible until %dr7.L/G got set again.
>
> However, it neglected the -EPERM return inbetween these two hunks, introducing
> a different bug in which a write to %dr7 which tries to set IO breakpoints
> without %cr4.DE being set clobbers the IO state, rather than leaves it alone.
>
> Instead, move the zeroing slightly later, which guarentees that the shadow
> gets written exactly once, on a successful update to %dr7.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Juergen Gross
>
> Although minor, this is a regression from Xen 4.10, so should be considered
> for 4.11 at this point. Given that PV debugging was basically completely
> broken before the XSA-263 investigation work, the risk of further issues is
> very small.
Sorry - this is a bad way of phrasing what I meant to say. The
behaviour of 4.11 is less bad than 4.10, but still wrong (and in a way
which is technically a regression from 4.10).
~Andrew
> ---
> xen/arch/x86/traps.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 8a99174..e79ca88 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2123,9 +2123,6 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
> unsigned long value)
> if ( value & DR_GENERAL_DETECT )
> return -EPERM;
>
> -/* Zero the IO shadow before recalculating the real %dr7 */
> -v->arch.debugreg[5] = 0;
> -
> /* DR7.{G,L}E = 0 => debugging disabled for this domain. */
> if ( value & DR7_ACTIVE_MASK )
> {
> @@ -2154,6 +2151,10 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
> unsigned long value)
> !(v->arch.debugreg[7] & DR7_ACTIVE_MASK) )
> activate_debugregs(v);
> }
> +else
> +/* Zero the emulated controls if %dr7 isn't active. */
> +v->arch.debugreg[5] = 0;
> +
> if ( v == curr )
> write_debugreg(7, value);
> break;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11] x86/traps: Fix error handling of the pv %dr7 shadow state
c/s "x86/pv: Introduce and use x86emul_write_dr()" fixed a bug with IO shadow
handling, in that it remained stale and visible until %dr7.L/G got set again.
However, it neglected the -EPERM return inbetween these two hunks, introducing
a different bug in which a write to %dr7 which tries to set IO breakpoints
without %cr4.DE being set clobbers the IO state, rather than leaves it alone.
Instead, move the zeroing slightly later, which guarentees that the shadow
gets written exactly once, on a successful update to %dr7.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Juergen Gross
Although minor, this is a regression from Xen 4.10, so should be considered
for 4.11 at this point. Given that PV debugging was basically completely
broken before the XSA-263 investigation work, the risk of further issues is
very small.
---
xen/arch/x86/traps.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 8a99174..e79ca88 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2123,9 +2123,6 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
if ( value & DR_GENERAL_DETECT )
return -EPERM;
-/* Zero the IO shadow before recalculating the real %dr7 */
-v->arch.debugreg[5] = 0;
-
/* DR7.{G,L}E = 0 => debugging disabled for this domain. */
if ( value & DR7_ACTIVE_MASK )
{
@@ -2154,6 +2151,10 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
!(v->arch.debugreg[7] & DR7_ACTIVE_MASK) )
activate_debugregs(v);
}
+else
+/* Zero the emulated controls if %dr7 isn't active. */
+v->arch.debugreg[5] = 0;
+
if ( v == curr )
write_debugreg(7, value);
break;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 06/10] xen/common: Restore IRQ affinity when hotplugging a pCPU
Non-boot pCPUs are being hot-unplugged during the system suspend to
RAM and hotplugged during the resume. When non-boot pCPUs are
hot-unplugged the interrupts that were targeted to them are migrated
to the boot pCPU.
On suspend, each guest could have its own wake-up devices/interrupts
(passthrough) that could trigger the system resume. These interrupts
could be targeted to a non-boot pCPU, e.g. if the guest's vCPU is
pinned to a non-boot pCPU. Due to the hot-unplug of non-boot pCPUs
during the suspend such interrupts will be migrated from non-boot pCPUs
to the boot pCPU (this is fine). However, when non-boot pCPUs are
hotplugged on resume, these interrupts are not migrated back to non-boot
pCPUs, i.e. IRQ affinity is not restored on resume (this is wrong).
This patch adds the restoration of IRQ affinity when a pCPU is hotplugged.
Signed-off-by: Mirela Simonovic
Reviewed-by: Dario Faggioli
---
CC: George Dunlap
CC: Dario Faggioli
---
Changes in v2:
-Instead of checking whether the affinity was broken check whether
vcpu's processor has changed in order to trigger restoring of the
IRQ affinity
-Fix commit message
Changes in v4:
-Added reviewed by Dario
---
xen/common/schedule.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 049f93f7aa..ccf936db83 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -737,6 +737,7 @@ void restore_vcpu_affinity(struct domain *d)
for_each_vcpu ( d, v )
{
spinlock_t *lock;
+unsigned int old_cpu = v->processor;
ASSERT(!vcpu_runnable(v));
@@ -769,6 +770,9 @@ void restore_vcpu_affinity(struct domain *d)
lock = vcpu_schedule_lock_irq(v);
v->processor = SCHED_OP(vcpu_scheduler(v), pick_cpu, v);
spin_unlock_irq(lock);
+
+if ( old_cpu != v->processor )
+sched_move_irqs(v);
}
domain_update_node_affinity(d);
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume
In existing code the virtual paging for non-boot CPUs is setup only on boot.
The setup is triggered from start_xen() after all CPUs are brought online.
In other words, the initialization of VTCR_EL2 register is done out of the
cpu_up/start_secondary() control flow. However, the cpu_up flow is also used
to hotplug non-boot CPUs on resume from suspend to RAM state, in which case
the virtual paging will not be configured.
With this patch the setting of paging is triggered from start_secondary()
function using cpu starting notifier (notify_cpu_starting() call). The
notifier is registered in p2m.c using init call. This has to be done with
init call rather than presmp_init because the registered callback depends
on vtcr configuration value which is setup after the presmp init calls
are executed (do_presmp_initcalls() called from start_xen()). Init calls
are executed after initial virtual paging is set up for all CPUs on boot.
This ensures that no callback can fire until the vtcr value is calculated
by Xen and virtual paging is set up initially for all CPUs. Also, this way
the virtual paging setup in boot scenario remains unchanged.
It is assumed here that after the system completed the boot, CPUs that
execute start_secondary() were booted as well when the Xen itself was
booted. According to this assumption non-boot CPUs will always be compliant
with the VTCR_EL2 value that was selected by Xen on boot.
Currently, there is no mechanism to trigger hotplugging of a CPU. This
will be added with the suspend to RAM support for ARM, where the hotplug
of non-boot CPUs will be triggered via enable_nonboot_cpus() call.
Signed-off-by: Mirela Simonovic
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v2:
-Fix commit message
-Save configured VTCR_EL2 value into static variable that will be used
by non-boot CPUs on hotplug
-Add setup_virt_paging_secondary() and invoke it from start_secondary()
if that CPU has to setup virtual paging (if the system state is not boot)
Changes in v3:
-Fix commit message
-Remove setup_virt_paging_secondary() and use notifier to setup virtual
paging for non-boot CPU on hotplug.
-In setup_virt_paging() use vtcr static variable instead of local val
-In setup_virt_paging_one() use vtcr static variable instead of provided
argument
Changes in v4:
-Add includes alphabetically
-Add newline before return in cpu_virt_paging_init()
-Fix indentation in cpu_virt_paging_callback() definition
-Use local val in setup_virt_paging() for calculation, assign it to vtcr
after the calculation is done
-Remove priority initialization in the notifier structure (priority
doesn't matter here)
Changes in v5:
-Define vtcr as uint32_t instead uint64_t
---
xen/arch/arm/p2m.c | 53 -
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..14791388ad 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -1451,10 +1453,12 @@ err:
return page;
}
-static void __init setup_virt_paging_one(void *data)
+/* VTCR value to be configured by all CPUs. Set only once by the boot CPU */
+static uint32_t __read_mostly vtcr;
+
+static void setup_virt_paging_one(void *data)
{
-unsigned long val = (unsigned long)data;
-WRITE_SYSREG32(val, VTCR_EL2);
+WRITE_SYSREG32(vtcr, VTCR_EL2);
isb();
}
@@ -1538,10 +1542,49 @@ void __init setup_virt_paging(void)
/* It is not allowed to concatenate a level zero root */
BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
-setup_virt_paging_one((void *)val);
-smp_call_function(setup_virt_paging_one, (void *)val, 1);
+vtcr = val;
+setup_virt_paging_one(NULL);
+smp_call_function(setup_virt_paging_one, NULL, 1);
+}
+
+static int cpu_virt_paging_callback(struct notifier_block *nfb,
+unsigned long action,
+void *hcpu)
+{
+switch ( action )
+{
+case CPU_STARTING:
+ASSERT(system_state != SYS_STATE_boot);
+setup_virt_paging_one(NULL);
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
}
+static struct notifier_block cpu_virt_paging_nfb = {
+.notifier_call = cpu_virt_paging_callback,
+};
+
+static int __init cpu_virt_paging_init(void)
+{
+register_cpu_notifier(_virt_paging_nfb);
+
+return 0;
+}
+/*
+ * Initialization of the notifier has to be done at init rather than
presmp_init
+ * phase because: the registered notifier is used to setup virtual paging for
+ * non-boot CPUs after the initial virtual paging for all CPUs is already
setup,
+ * i.e. when a non-boot CPU is hotplugged after the system has booted. In other
+ * words, the notifier should be registered after the virtual paging is
+ * initially setup (setup_virt_paging() is called from start_xen()). This is
+ *
[Xen-devel] [PATCH v5 01/10] xen/arm64: Added handling of the trapped access to OSLSR register
Linux/dom0 accesses OSLSR register when saving CPU context during the
suspend procedure. Xen traps access to this register, but has no handling
for it. Consequently, Xen injects undef exception to linux, causing it to
crash. This patch adds handling of the trapped access to OSLSR as read
only as a fixed value.
Signed-off-by: Mirela Simonovic
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v2:
- Commit message fix (arm64 related change instead of arm)
- Add Stefano's reviewed-by
Changes in v3:
- Added Julien's acked-by
Changes in v5:
-Insted of zero the reading of OSLSR_EL1 should return set bit 3
-Implement new helper handle_ro_read_val() to support read only as a value.
handle_ro_read_val() reuses the implementation of handle_ro_raz() and
extends it with additional argument for passing the value to be returned
-Use handle_ro_read_val() for handle_ro_raz() implementation to avoid code
duplication
-Fix commit message to reflect changes made in this version
---
xen/arch/arm/arm64/vsysreg.c | 4 +++-
xen/arch/arm/traps.c | 26 ++
xen/include/asm-arm/traps.h | 4
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index c57ac12503..6e60824572 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -57,13 +57,15 @@ void do_sysreg(struct cpu_user_regs *regs,
* ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
*
* Unhandled:
- *OSLSR_EL1
*DBGPRCR_EL1
*/
case HSR_SYSREG_OSLAR_EL1:
return handle_wo_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
case HSR_SYSREG_OSDLR_EL1:
return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_OSLSR_EL1:
+return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+ 1 << 3);
/*
* MDCR_EL2.TDA
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5c18e918b0..d71adfa745 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1739,12 +1739,13 @@ void handle_wo_wi(struct cpu_user_regs *regs,
advance_pc(regs, hsr);
}
-/* Read only as read as zero */
-void handle_ro_raz(struct cpu_user_regs *regs,
- int regidx,
- bool read,
- const union hsr hsr,
- int min_el)
+/* Read only as value provided with 'val' argument of this function */
+void handle_ro_read_val(struct cpu_user_regs *regs,
+int regidx,
+bool read,
+const union hsr hsr,
+int min_el,
+register_t val)
{
ASSERT((min_el == 0) || (min_el == 1));
@@ -1753,13 +1754,22 @@ void handle_ro_raz(struct cpu_user_regs *regs,
if ( !read )
return inject_undef_exception(regs, hsr);
-/* else: raz */
-set_user_reg(regs, regidx, 0);
+set_user_reg(regs, regidx, val);
advance_pc(regs, hsr);
}
+/* Read only as read as zero */
+inline void handle_ro_raz(struct cpu_user_regs *regs,
+ int regidx,
+ bool read,
+ const union hsr hsr,
+ int min_el)
+{
+handle_ro_read_val(regs, regidx, read, hsr, min_el, 0);
+}
+
void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
{
register_t ttbcr = READ_SYSREG(TCR_EL1);
diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
index a0e5e92ebb..70b52d1d16 100644
--- a/xen/include/asm-arm/traps.h
+++ b/xen/include/asm-arm/traps.h
@@ -27,6 +27,10 @@ void handle_wo_wi(struct cpu_user_regs *regs, int regidx,
bool read,
void handle_ro_raz(struct cpu_user_regs *regs, int regidx, bool read,
const union hsr hsr, int min_el);
+/* Read only as value provided with 'val' argument */
+void handle_ro_read_val(struct cpu_user_regs *regs, int regidx, bool read,
+const union hsr hsr, int min_el, register_t val);
+
/* Co-processor registers emulation (see arch/arm/vcpreg.c). */
void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr);
void do_cp15_64(struct cpu_user_regs *regs, const union hsr hsr);
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 04/10] xen/arm: Remove __initdata and __init to enable CPU hotplug
CPU up flow is currently used during the initial boot to start secondary
CPUs. However, the same flow should be used for CPU hotplug, e.g. when
hotplugging secondary CPUs within the resume procedure (resume from the
suspend to RAM). Therefore, prefixes __initdata and __init had to be removed
from few data structures and functions that are used within the cpu up flow.
Signed-off-by: Mirela Simonovic
Acked-by: Julien Grall
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v3:
- Added acked-by Julien
---
xen/arch/arm/arm64/smpboot.c | 2 +-
xen/arch/arm/irq.c | 2 +-
xen/arch/arm/processor.c | 2 +-
xen/arch/arm/smpboot.c | 4 ++--
xen/include/asm-arm/procinfo.h | 4 ++--
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 4fd0ac68b7..694fbf67e6 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -104,7 +104,7 @@ int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
return smp_psci_init(cpu);
}
-int __init arch_cpu_up(int cpu)
+int arch_cpu_up(int cpu)
{
if ( !smp_enable_ops[cpu].prepare_cpu )
return -ENODEV;
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index aa4e832cae..098281f8ab 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -65,7 +65,7 @@ irq_desc_t *__irq_to_desc(int irq)
return _desc[irq-NR_LOCAL_IRQS];
}
-int __init arch_init_one_irq_desc(struct irq_desc *desc)
+int arch_init_one_irq_desc(struct irq_desc *desc)
{
desc->arch.type = IRQ_TYPE_INVALID;
return 0;
diff --git a/xen/arch/arm/processor.c b/xen/arch/arm/processor.c
index ce4385064a..acad8b31d6 100644
--- a/xen/arch/arm/processor.c
+++ b/xen/arch/arm/processor.c
@@ -20,7 +20,7 @@
static DEFINE_PER_CPU(struct processor *, processor);
-void __init processor_setup(void)
+void processor_setup(void)
{
const struct proc_info_list *procinfo;
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 8b1e274bf3..ad1f6b751b 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,8 +52,8 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
static unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
__attribute__((__aligned__(STACK_SIZE)));
-/* Initial boot cpu data */
-struct init_info __initdata init_data =
+/* Boot cpu data */
+struct init_info init_data =
{
.stack = cpu0_boot_stack,
};
diff --git a/xen/include/asm-arm/procinfo.h b/xen/include/asm-arm/procinfo.h
index 26306b35f8..02be56e348 100644
--- a/xen/include/asm-arm/procinfo.h
+++ b/xen/include/asm-arm/procinfo.h
@@ -35,9 +35,9 @@ struct proc_info_list {
struct processor*processor;
};
-const __init struct proc_info_list *lookup_processor_type(void);
+const struct proc_info_list *lookup_processor_type(void);
-void __init processor_setup(void);
+void processor_setup(void);
void processor_vcpu_initialise(struct vcpu *v);
#endif
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged
When a CPU is hot-unplugged the maintenance interrupt has to be
released in order to free the memory that was allocated when the CPU
was hotplugged and interrupt requested. The interrupt was requested
using request_irq() which is called from start_secondary->
init_maintenance_interrupt. With this patch the interrupt will be
released when the CPU_DYING event is received by the callback which
is added in gic.c.
Signed-off-by: Mirela Simonovic
Acked-by: Julien Grall
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v3:
-Add notifier in order to trigger releasing of the maintenance
interrupt when the CPU is dying.
Changes in v4:
-Add includes alphabetically
-Added newline before the return in cpu_gic_notifier_init()
-Fix indentation in cpu_gic_callback() definition
-Added acked-by Julien
---
xen/arch/arm/gic.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 653a815127..5474030386 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -462,6 +464,35 @@ int gic_iomem_deny_access(const struct domain *d)
return gic_hw_ops->iomem_deny_access(d);
}
+static int cpu_gic_callback(struct notifier_block *nfb,
+unsigned long action,
+void *hcpu)
+{
+switch ( action )
+{
+case CPU_DYING:
+/* This is reverting the work done in init_maintenance_interrupt */
+release_irq(gic_hw_ops->info->maintenance_irq, NULL);
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_gic_nfb = {
+.notifier_call = cpu_gic_callback,
+};
+
+static int __init cpu_gic_notifier_init(void)
+{
+register_cpu_notifier(_gic_nfb);
+
+return 0;
+}
+__initcall(cpu_gic_notifier_init);
+
/*
* Local variables:
* mode: C
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 08/10] xen/arm: Disable timers and release their interrupts on CPU hot-unplug
When a CPU is hot-unplugged we need to disable timers and release
their interrupts in order to free the memory that was allocated when
interrupts were requested (using request_irq()). The request_irq()
is called for each timer interrupt when the CPU gets hotplugged
(start_secondary->init_timer_interrupt->request_irq).
With this patch timers will be disabled and interrupts will be
released when the newly added callback receives CPU_DYING event.
Signed-off-by: Mirela Simonovic
Acked-by: Julien Grall
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v3:
-Trigger releasing of timer interrupts using notifiers
Changes in v4:
-Fix commit message to include disabling of timers
-Disable timers prior to releasing interrupts
-Add new line before the return in cpu_time_notifier_init()
-Add includes alphabetically
-Fix indentation in cpu_time_callback() definition
Changes in v5:
-Added acked-by Julien
---
xen/arch/arm/time.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index c11fcfeadd..1635c8822d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -312,6 +314,21 @@ void init_timer_interrupt(void)
check_timer_irq_cfg(timer_irq[TIMER_PHYS_NONSECURE_PPI], "NS-physical");
}
+/*
+ * Revert actions done in init_timer_interrupt that are required to properly
+ * disable this CPU.
+ */
+static void deinit_timer_interrupt(void)
+{
+WRITE_SYSREG32(0, CNTP_CTL_EL0);/* Disable physical timer */
+WRITE_SYSREG32(0, CNTHP_CTL_EL2); /* Disable hypervisor's timer */
+isb();
+
+release_irq(timer_irq[TIMER_HYP_PPI], NULL);
+release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
+release_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], NULL);
+}
+
/* Wait a set number of microseconds */
void udelay(unsigned long usecs)
{
@@ -340,6 +357,34 @@ void domain_set_time_offset(struct domain *d, int64_t
time_offset_seconds)
/* XXX update guest visible wallclock time */
}
+static int cpu_time_callback(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
+{
+switch ( action )
+{
+case CPU_DYING:
+deinit_timer_interrupt();
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_time_nfb = {
+.notifier_call = cpu_time_callback,
+};
+
+static int __init cpu_time_notifier_init(void)
+{
+register_cpu_notifier(_time_nfb);
+
+return 0;
+}
+__initcall(cpu_time_notifier_init);
+
/*
* Local variables:
* mode: C
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 03/10] xen/arm: Implement CPU_OFF PSCI call (physical interface)
During the system suspend to RAM non-boot CPUs will be hotplugged.
This will be triggered via disable_nonboot_cpus() call. When
hotplugged the CPU will end up in an infinite wfi loop in stop_cpu().
This patch adds PSCI CPU_OFF call to the EL3 with the aim to get powered
down the calling CPU during the suspend. The CPU_OFF call will be made
only if the PSCI version is higher than v0.1 (Note that the CPU_OFF
function is mandatory since PSCI v0.2).
If PSCI CPU_OFF call to the EL3 succeeds it will not return. Otherwise,
when the PSCI CPU_OFF call returns we'll raise panic, because the
calling CPU couldn't be enabled afterwards (stays in WFI loop forever).
Note that if the PSCI version is higher than v0.1 the CPU_OFF will be
called regardless of the system state. This is done because scenarios
other than suspend may benefit from powering off the CPU.
Signed-off-by: Mirela Simonovic
Acked-by: Julien Grall
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v2:
-Issue PSCI CPU_OFF only if the system is suspending
-If PSCI CPU_OFF call fails (unlikely to ever happen) raise panic
-Fixed commit message
Changes in v3:
-Check for PSCI version prior to calling CPU_OFF
-Don't check for system state - invoke CPU_OFF in all system states
-Don't check if returned error is not zero because it's always not
zero if CPU_OFF SMC returns
-Fixed commit message
Changes in v4:
-Use smp_processor_id() instead of get_processor_id()
-Fixed indentation
-Added acked-by Julien
---
xen/arch/arm/psci.c| 13 +
xen/arch/arm/smpboot.c | 2 ++
xen/include/asm-arm/psci.h | 1 +
3 files changed, 16 insertions(+)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 94b616df9b..3cf5ecf0f3 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -46,6 +46,19 @@ int call_psci_cpu_on(int cpu)
return call_smc(psci_cpu_on_nr, cpu_logical_map(cpu),
__pa(init_secondary), 0);
}
+void call_psci_cpu_off(void)
+{
+if ( psci_ver > PSCI_VERSION(0, 1) )
+{
+int errno;
+
+/* If successfull the PSCI cpu_off call doesn't return */
+errno = call_smc(PSCI_0_2_FN32_CPU_OFF, 0, 0, 0);
+panic("PSCI cpu off failed for CPU%d err=%d\n", smp_processor_id(),
+ errno);
+}
+}
+
void call_psci_system_off(void)
{
if ( psci_ver > PSCI_VERSION(0, 1) )
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b2116f0d2d..8b1e274bf3 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -395,6 +395,8 @@ void stop_cpu(void)
/* Make sure the write happens before we sleep forever */
dsb(sy);
isb();
+call_psci_cpu_off();
+
while ( 1 )
wfi();
}
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index 9ac820e94a..832f77afff 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -20,6 +20,7 @@ extern uint32_t psci_ver;
int psci_init(void);
int call_psci_cpu_on(int cpu);
+void call_psci_cpu_off(void);
void call_psci_system_off(void);
void call_psci_system_reset(void);
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 00/10] xen/arm64: Suspend preconditions and CPU hotplug fixes
This patch set contains fixes that are required as precondition for suspend to RAM support, including the CPU hotplug which is required to suspend non-boot CPUs. The first two patches in this series: 1) xen/arm64: Added handling of the trapped access to OSLSR register 2) xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2) are required to avoid Dom0 crashes when Dom0 performs its own suspend. This patch set does not include the implementation of virtual PSCI system suspend call that would allow guests to finalize their suspend procedures. This will be submitted in the following series. Remaining of the patches are related to enabling CPU hotplug for non-boot CPUs is resume scenario. CPU hotplug of non-boot CPUs will be used for suspend to RAM support for ARM. In suspend procedure, the hot-unplug of non-boot CPUs will be triggered with disable_nonboot_cpus(), while the hotplug is triggered with enable_nonboot_cpus(). Using these calls, the physical non-boot CPUs could be powered down/up on suspend/resume, respectively, if the underlying firmware allows so. Calls to enable/disable_nonboot_cpus() functions currently do not exist in Xen ARM code. This will be added with the suspend to RAM support for ARM. When non-boot pCPUs are hot-unplugged their interrupts are migrated to the boot pCPU. This series also includes a fix that would restore the interrupts affinity once non-boot pCPUs are hotplugged. Here only SPIs used by guests are covered. Migration of Xen internal SPIs is not covered. According to my understanding Xen internal SPIs are routed to the boot CPU which initializes the respective devices. Therefore, there is no need to migrate Xen internal SPIs. The code is tested on Xilinx Zynq UltraScale+ MPSoC/ZCU102 board (includes physical power down/up of non-boot CPUs). The testing requires additional patches for issuing system suspend. These patches and instructions for testing will be submitted later, when we get closer to the final version of the series. --- Changes in v2: -Rename cover-letter title and emphasize that 2 patches from this series are not specific to CPU hotplug (my initial fault, splitting it now could be confusing) -Fix cover-letter explanations -Address all the issues and comments as discussed on mailing list for v1 -Add 3 patches to ensure that suspend/resume does not cause any memory leaks. All the memory allocated when a CPU was hotplugged is now freed when the CPU is hot-unplugged. -Remove from the v1 series the patch which incorrectly dealt with an issue: [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly One solution to the issue addressed by the patch above is to add rcu_barrier() prior to calling enable_nonboot_cpus() during the suspend. This is how it is done in x86 suspend implementation. Until the discussion here https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01199.html doesn't conclude differently, I need to assume that adding rcu_barrier() prior to calling enable_nonboot_cpus() as it is done for x86 is the right way to go. Therefore, the fix to the issue will be part of the suspend to RAM series. Changes in v3: -Add acked-by where needed -Fix CPU_OFF PSCI implementation (physical interface) -Use notifiers to implement freeing memory and releasing interrupts on CPU hotplug -Use notifier to trigger setup of virtual paging for non-boot CPUs on CPU hotplug -Add enabling errata workarounds on CPU hotplug, also based on a notifier -Remove patch: [PATCH v2 10/10] xen/arm: Call check_local_cpu_errata for secondary CPU only on boot Changes in v4: -Add acked-by/reviewed-by where needed -Cleanup: use smp_processor_id() instead of get_processor_id(), fixed indentation, add includes alphabetically, add newline before return, etc. -Disable timers prior to releasing timer interrupts -Initialize cpu_smpboot notifier at presmp_init rather than init phase -In the last patch of the series errata notifier now returns an error Changes in v5: -Introduce handle_ro_read_val() to handle traps as read-only as fixed value -Fix handling accesses to OSLSR_EL1 -Fix variable type in 5th patch --- CC: Stefano Stabellini CC: Julien Grall CC: George Dunlap CC: Dario Faggioli --- Mirela Simonovic (10): xen/arm64: Added handling of the trapped access to OSLSR register xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2) xen/arm: Implement CPU_OFF PSCI call (physical interface) xen/arm: Remove __initdata and __init to enable CPU hotplug xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume xen/common: Restore IRQ affinity when hotplugging a pCPU xen/arm: Release maintenance interrupt when CPU is hot-unplugged xen/arm: Disable timers and release their interrupts on CPU hot-unplug xen/arm: Free memory allocated for sibling/core maps on CPU hot-unplug xen/arm: Enable errata for secondary CPU on hotplug after the boot xen/arch/arm/arm64/smpboot.c | 2 +- xen/arch/arm/arm64/vsysreg.c | 4 ++-
[Xen-devel] [PATCH v5 09/10] xen/arm: Free memory allocated for sibling/core maps on CPU hot-unplug
The memory allocated in setup_cpu_sibling_map() when a CPU is hotplugged
has to be freed when the CPU is hot-unplugged. This is done in
remove_cpu_sibling_map() and called when the CPU dies. The call to
remove_cpu_sibling_map() is made from a notifier callback when
CPU_DEAD event is received.
Signed-off-by: Mirela Simonovic
Acked-by: Julien Grall
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v3:
-Use notifier to trigger remove_cpu_sibling_map() when the CPU dies.
Changes in v4:
-Initialize cpu_smpboot notifier at presmp_init rather than init phase
to cover the case where a secondary CPU dies beforehand the initcall
-Added newline before the return in cpu_smpboot_notifier_init()
-Fix indentation in cpu_smpboot_callback() definition
Changes in v5:
-Added acked-by Julien
---
xen/arch/arm/smpboot.c | 36
1 file changed, 36 insertions(+)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ad1f6b751b..cf3a4ce659 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -89,6 +89,12 @@ static void setup_cpu_sibling_map(int cpu)
cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
}
+static void remove_cpu_sibling_map(int cpu)
+{
+free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
+free_cpumask_var(per_cpu(cpu_core_mask, cpu));
+}
+
void __init
smp_clear_cpu_maps (void)
{
@@ -499,6 +505,36 @@ void __cpu_die(unsigned int cpu)
smp_mb();
}
+static int cpu_smpboot_callback(struct notifier_block *nfb,
+unsigned long action,
+void *hcpu)
+{
+unsigned int cpu = (unsigned long)hcpu;
+
+switch ( action )
+{
+case CPU_DEAD:
+remove_cpu_sibling_map(cpu);
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_smpboot_nfb = {
+.notifier_call = cpu_smpboot_callback,
+};
+
+static int __init cpu_smpboot_notifier_init(void)
+{
+register_cpu_notifier(_smpboot_nfb);
+
+return 0;
+}
+presmp_initcall(cpu_smpboot_notifier_init);
+
/*
* Local variables:
* mode: C
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot
On boot, enabling errata workarounds will be triggered by the boot CPU
from start_xen(). On CPU hotplug (non-boot scenario) this would not be
done. This patch adds the code required to enable errata workarounds for
a CPU being hotplugged after the system boots. This is triggered using
a notifier. If the CPU fails to enable workarounds the notifier will
return an error and Xen will hit the BUG_ON() in notify_cpu_starting().
To avoid the BUG_ON() in an error case either enabling notifiers should
be fixed to return void (not propagate error to notify_cpu_starting())
and the errata notifier will always return success for CPU_STARTING
event, or the notify_cpu_starting() and other common code should be
fixed to expect an error at CPU_STARTING phase.
Signed-off-by: Mirela Simonovic
Reviewed-by: Julien Grall
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v4:
-Add includes alphabetically
-Added newline before the return in cpu_errata_notifier_init()
-Enabling capabilities returns an error if enabling a capability fails
(enable_nonboot_cpu_caps() returns int instead of void). When enabling
any of the capability fails the error is remembered into a variable and
the remaining capabilities are enabled. If enabling multiple capabilities
fails the error returned by enable_nonboot_cpu_caps() represents the
error code of the last failure.
-Callback enable_nonboot_cpu_caps() can return an error when CPU_STARTING
fires. This is not right because of the assumption that starting a CPU
cannot fail at this phase. Consequently, if an error happens it will
cause Xen to hit the BUG_ON() in notify_cpu_starting(). In future,
either this notifier/enabling capabilities should be fixed to always
return success/void, or notify_cpu_starting() and other common code
should be fixed to expect an error at CPU_STARTING phase.
-Fix commit message to reflect changes in v4
Changes in v5:
-Added reviewed-by Julien
---
xen/arch/arm/cpuerrata.c | 49
xen/arch/arm/cpufeature.c| 29
xen/include/asm-arm/cpufeature.h | 1 +
3 files changed, 79 insertions(+)
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..b829d226ef 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -1,3 +1,4 @@
+#include
#include
#include
#include
@@ -5,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -349,6 +351,53 @@ void __init enable_errata_workarounds(void)
enable_cpu_capabilities(arm_errata);
}
+static int cpu_errata_callback(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
+{
+int rc = 0;
+
+switch ( action )
+{
+case CPU_STARTING:
+/*
+ * At CPU_STARTING phase no notifier shall return an error, because the
+ * system is designed with the assumption that starting a CPU cannot
+ * fail at this point. If an error happens here it will cause Xen to
hit
+ * the BUG_ON() in notify_cpu_starting(). In future, either this
+ * notifier/enabling capabilities should be fixed to always return
+ * success/void or notify_cpu_starting() and other common code should
be
+ * fixed to expect an error at CPU_STARTING phase.
+ */
+ASSERT(system_state != SYS_STATE_boot);
+rc = enable_nonboot_cpu_caps(arm_errata);
+break;
+default:
+break;
+}
+
+return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_errata_nfb = {
+.notifier_call = cpu_errata_callback,
+};
+
+static int __init cpu_errata_notifier_init(void)
+{
+register_cpu_notifier(_errata_nfb);
+
+return 0;
+}
+/*
+ * Initialization has to be done at init rather than presmp_init phase because
+ * the callback should execute only after the secondary CPUs are initially
+ * booted (in hotplug scenarios when the system state is not boot). On boot,
+ * the enabling of errata workarounds will be triggered by the boot CPU from
+ * start_xen().
+ */
+__initcall(cpu_errata_notifier_init);
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 525b45e22f..3aaff4c0e6 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -69,6 +69,35 @@ void __init enable_cpu_capabilities(const struct
arm_cpu_capabilities *caps)
}
/*
+ * Run through the enabled capabilities and enable() them on the calling CPU.
+ * If enabling of any capability fails the error is returned. After enabling a
+ * capability fails the error will be remembered into 'rc' and the remaining
+ * capabilities will be enabled. If enabling multiple capabilities fail the
+ * error returned by this function represents the error code of the last
+ * failure.
+ */
+int enable_nonboot_cpu_caps(const struct arm_cpu_capabilities *caps)
+{
+int rc = 0;
+
[Xen-devel] [PATCH v5 02/10] xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2)
Guests attempt to write into these registers on resume (for example Linux). Without this patch a data abort exception will be raised to the guest. This patch handles the write access by ignoring it, but only if the value to be written is zero. This should be fine because reading these registers is already handled as 'read as zero'. Signed-off-by: Mirela Simonovic Reviewed-by: Julien Grall --- CC: Stefano Stabellini CC: Julien Grall --- Changes in v2: - Write should be ignored only if the value to be written is zero (in v1 the write was ignored regardless of the value) Changes in v3: - Print warning only if the value to be written is not zero Changes in v4: - Added reviewed-by Julien --- xen/arch/arm/vgic-v2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c index 646d1f3d12..f6c11f1e41 100644 --- a/xen/arch/arm/vgic-v2.c +++ b/xen/arch/arm/vgic-v2.c @@ -485,6 +485,8 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, mmio_info_t *info, case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN): if ( dabt.size != DABT_WORD ) goto bad_width; +if ( r == 0 ) +goto write_ignore_32; printk(XENLOG_G_ERR "%pv: vGICD: unhandled word write %#"PRIregister" to ISACTIVER%d\n", v, r, gicd_reg - GICD_ISACTIVER); -- 2.13.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing baseline-only test] 74768: regressions - FAIL
This run is configured for baseline tests only. flight 74768 xen-4.10-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74768/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail REGR. vs. 74742 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74742 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-qemut-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-armhf-armhf-xl-midway 12 guest-start fail never pass test-armhf-armhf-xl 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 guest-start fail never pass test-armhf-armhf-xl-credit2 12 guest-start fail never pass test-armhf-armhf-xl-multivcpu 12 guest-start fail never pass test-armhf-armhf-xl-rtds 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 10 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 10 debian-di-installfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 7b35e7807c9efba0f74e6663a7205bd97602c8d1 baseline version: xen a0355180b660b149f8054b9facdd9cac8ec86a95 Last test of basis74742 2018-05-25 02:46:44 Z7 days Testing same since74768 2018-05-31 11:18:50 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Juergen Gross Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5
[Xen-devel] [linux-linus test] 123438: regressions - FAIL
flight 123438 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/123438/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumprun6 rumprun-buildfail REGR. vs. 123370 test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 123370 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123370 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123370 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123370 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123370 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123370 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123370 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123370 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123370 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123370 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123370 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-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-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-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux88a867653065dc14b0fdeeb626efb8d7ebe39be5 baseline version: linux3d661e2a2d1cf0ad1ce54d690f05e755da59e6c9 Last test of basis 123370 2018-05-29 17:23:49 Z2 days Testing same since 123438 2018-05-31 03:18:48 Z1 days1 attempts People who touched revisions under test: Aaron Ma
Re: [Xen-devel] [PULL 0/3] xen-20180531-tag
On 31 May 2018 at 20:08, Stefano Stabellini wrote: > The following changes since commit c181ddaa176856b3cd2dfd12bbcf25fa9c884a97: > > Merge remote-tracking branch > 'remotes/pmaydell/tags/pull-target-arm-20180531-1' into staging (2018-05-31 > 17:00:55 +0100) > > are available in the git repository at: > > > http://xenbits.xenproject.org/git-http/people/sstabellini/qemu-dm.git > tags/xen-20180531-tag > > for you to fetch changes up to dfb6578d69d60e464be36dafed9741dcfd73d2cf: > > xen-hvm: stop faking I/O to access PCI config space (2018-05-31 12:05:01 > -0700) > > > Xen 2018/05/31 > > > Igor Druzhinin (1): > xen/hvm: correct reporting of modified memory under physmap during > migration > > Paul Durrant (2): > xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages > xen-hvm: stop faking I/O to access PCI config space Applied, thanks. -- PMM ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/9] xen/grant-table: Make set/clear page private code shared
Boris, I dropped your r-b for this patch as I changed
EXPORT_SYMBOL to EXPORT_SYMBOL_GPL as Juergen requested
On 06/01/2018 02:41 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table.h | 3 +++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index ba36ff3e4903..dbb48a89e987 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
}
EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
-/**
- * gnttab_alloc_pages - alloc pages suitable for grant mapping into
- * @nr_pages: number of pages to alloc
- * @pages: returns the pages
- */
-int gnttab_alloc_pages(int nr_pages, struct page **pages)
+int gnttab_pages_set_private(int nr_pages, struct page **pages)
{
int i;
- int ret;
-
- ret = alloc_xenballooned_pages(nr_pages, pages);
- if (ret < 0)
- return ret;
for (i = 0; i < nr_pages; i++) {
#if BITS_PER_LONG < 64
struct xen_page_foreign *foreign;
foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
- if (!foreign) {
- gnttab_free_pages(nr_pages, pages);
+ if (!foreign)
return -ENOMEM;
- }
+
set_page_private(pages[i], (unsigned long)foreign);
#endif
SetPagePrivate(pages[i]);
@@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+EXPORT_SYMBOL_GPL(gnttab_pages_set_private);
/**
- * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
- * @nr_pages; number of pages to free
- * @pages: the pages
+ * gnttab_alloc_pages - alloc pages suitable for grant mapping into
+ * @nr_pages: number of pages to alloc
+ * @pages: returns the pages
*/
-void gnttab_free_pages(int nr_pages, struct page **pages)
+int gnttab_alloc_pages(int nr_pages, struct page **pages)
+{
+ int ret;
+
+ ret = alloc_xenballooned_pages(nr_pages, pages);
+ if (ret < 0)
+ return ret;
+
+ ret = gnttab_pages_set_private(nr_pages, pages);
+ if (ret < 0)
+ gnttab_free_pages(nr_pages, pages);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+
+void gnttab_pages_clear_private(int nr_pages, struct page **pages)
{
int i;
@@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
ClearPagePrivate(pages[i]);
}
}
+}
+EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);
+
+/**
+ * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
+ * @nr_pages; number of pages to free
+ * @pages: the pages
+ */
+void gnttab_free_pages(int nr_pages, struct page **pages)
+{
+ gnttab_pages_clear_private(nr_pages, pages);
free_xenballooned_pages(nr_pages, pages);
}
EXPORT_SYMBOL_GPL(gnttab_free_pages);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2e37741f6b8d..de03f2542bb7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void);
int gnttab_alloc_pages(int nr_pages, struct page **pages);
void gnttab_free_pages(int nr_pages, struct page **pages);
+int gnttab_pages_set_private(int nr_pages, struct page **pages);
+void gnttab_pages_clear_private(int nr_pages, struct page **pages);
+
int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.
2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file descriptor
does not exist or has already been released, then -ENOENT is
returned. For valid file descriptors this must not be treated as
error.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 393 +++-
drivers/xen/gntdev-dmabuf.h | 9 +-
drivers/xen/gntdev.c| 90 -
3 files changed, 486 insertions(+), 6 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 6bedd1387bd9..f612468879b4 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -3,15 +3,58 @@
/*
* Xen dma-buf functionality for gntdev.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
*/
+#include
#include
#include "gntdev-dmabuf.h"
+struct gntdev_dmabuf {
+ struct gntdev_dmabuf_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
+ union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+
+ struct gntdev_priv *priv;
+ struct grant_map *map;
+ void (*release)(struct gntdev_priv *priv,
+ struct grant_map *map);
+ } exp;
+ } u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct gntdev_dmabuf_wait_obj {
+ struct list_head next;
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ struct completion completion;
+};
+
+struct gntdev_dmabuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+};
+
struct gntdev_dmabuf_priv {
- int dummy;
+ /* List of exported DMA buffers. */
+ struct list_head exp_list;
+ /* List of wait objects. */
+ struct list_head exp_wait_list;
+ /* This is the lock which protects dma_buf_xxx lists. */
+ struct mutex lock;
};
/* -- */
@@ -22,19 +65,359 @@ struct gntdev_dmabuf_priv {
/* Implementation of wait for exported DMA buffer to be released. */
/* -- */
+static void dmabuf_exp_release(struct kref *kref);
+
+static struct gntdev_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ struct gntdev_dmabuf_wait_obj *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(>completion);
+ obj->gntdev_dmabuf = gntdev_dmabuf;
+
+ mutex_lock(>lock);
+ list_add(>next, >exp_wait_list);
+ /* Put our reference and wait for gntdev_dmabuf's release to fire. */
+ kref_put(_dmabuf->u.exp.refcount, dmabuf_exp_release);
+ mutex_unlock(>lock);
+ return obj;
+}
+
+static void dmabuf_exp_wait_obj_free(struct gntdev_dmabuf_priv *priv,
+struct gntdev_dmabuf_wait_obj *obj)
+{
+ struct gntdev_dmabuf_wait_obj *cur_obj, *q;
+
+ mutex_lock(>lock);
+ list_for_each_entry_safe(cur_obj, q, >exp_wait_list, next)
+ if (cur_obj == obj) {
+ list_del(>next);
+ kfree(obj);
+ break;
+ }
+ mutex_unlock(>lock);
+}
+
+static int dmabuf_exp_wait_obj_wait(struct gntdev_dmabuf_wait_obj *obj,
+ u32 wait_to_ms)
+{
+ if (wait_for_completion_timeout(>completion,
+ msecs_to_jiffies(wait_to_ms)) <= 0)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static void dmabuf_exp_wait_obj_signal(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ struct gntdev_dmabuf_wait_obj *obj, *q;
+
+ list_for_each_entry_safe(obj, q, >exp_wait_list, next)
+ if (obj->gntdev_dmabuf == gntdev_dmabuf) {
+ pr_debug("Found gntdev_dmabuf in the wait list,
wake\n");
+
[Xen-devel] [PATCH v2 1/9] xen/grant-table: Export gnttab_{alloc|free}_pages as GPL
From: Oleksandr Andrushchenko
Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
while all the rest are exported as EXPORT_SYMBOL_GPL, thus
effectively making it not possible for non-GPL driver modules
to use grant table module. Export gnttab_{alloc|free}_pages as
EXPORT_SYMBOL_GPL so all the exports are aligned.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 27be107d6480..ba36ff3e4903 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -799,7 +799,7 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL(gnttab_alloc_pages);
+EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
/**
* gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
@@ -820,7 +820,7 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
}
free_xenballooned_pages(nr_pages, pages);
}
-EXPORT_SYMBOL(gnttab_free_pages);
+EXPORT_SYMBOL_GPL(gnttab_free_pages);
/* Handling of paged out grant targets (GNTST_eagain) */
#define MAX_DELAY 256
--
2.17.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c | 99 ++-
include/uapi/xen/gntdev.h | 15 ++
2 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index bd56653b9bbc..9813fc440c70 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -37,6 +37,9 @@
#include
#include
#include
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+#include
+#endif
#include
#include
@@ -72,6 +75,11 @@ struct gntdev_priv {
struct mutex lock;
struct mm_struct *mm;
struct mmu_notifier mn;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /* Device for which DMA memory is allocated. */
+ struct device *dma_dev;
+#endif
};
struct unmap_notify {
@@ -96,10 +104,27 @@ struct grant_map {
struct gnttab_unmap_grant_ref *kunmap_ops;
struct page **pages;
unsigned long pages_vm_start;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /*
+* If dmabuf_vaddr is not NULL then this mapping is backed by DMA
+* capable memory.
+*/
+
+ struct device *dma_dev;
+ /* Flags used to create this DMA buffer: GNTDEV_DMA_FLAG_XXX. */
+ int dma_flags;
+ void *dma_vaddr;
+ dma_addr_t dma_bus_addr;
+ /* This is required for gnttab_dma_{alloc|free}_pages. */
+ xen_pfn_t *frames;
+#endif
};
static int unmap_grant_pages(struct grant_map *map, int offset, int pages);
+static struct miscdevice gntdev_miscdev;
+
/* -- */
static void gntdev_print_maps(struct gntdev_priv *priv,
@@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map)
if (map == NULL)
return;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ if (map->dma_vaddr) {
+ struct gnttab_dma_alloc_args args;
+
+ args.dev = map->dma_dev;
+ args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = map->count;
+ args.pages = map->pages;
+ args.frames = map->frames;
+ args.vaddr = map->dma_vaddr;
+ args.dev_bus_addr = map->dma_bus_addr;
+
+ gnttab_dma_free_pages();
+ } else
+#endif
if (map->pages)
gnttab_free_pages(map->count, map->pages);
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ kfree(map->frames);
+#endif
kfree(map->pages);
kfree(map->grants);
kfree(map->map_ops);
@@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map *map)
kfree(map);
}
-static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)
+static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count,
+ int dma_flags)
{
struct grant_map *add;
int i;
@@ -155,6 +200,37 @@ static struct grant_map *gntdev_alloc_map(struct
gntdev_priv *priv, int count)
NULL == add->pages)
goto err;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ add->dma_flags = dma_flags;
+
+ /*
+* Check if this mapping is requested to be backed
+* by a DMA buffer.
+*/
+ if (dma_flags & (GNTDEV_DMA_FLAG_WC | GNTDEV_DMA_FLAG_COHERENT)) {
+ struct gnttab_dma_alloc_args args;
+
+ add->frames = kcalloc(count, sizeof(add->frames[0]),
+ GFP_KERNEL);
+ if (!add->frames)
+ goto err;
+
+ /* Remember the device, so we can free DMA memory. */
+ add->dma_dev = priv->dma_dev;
+
+ args.dev = priv->dma_dev;
+ args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = count;
+ args.pages = add->pages;
+ args.frames = add->frames;
+
+ if (gnttab_dma_alloc_pages())
+ goto err;
+
+ add->dma_vaddr = args.vaddr;
+ add->dma_bus_addr = args.dev_bus_addr;
+ } else
+#endif
if (gnttab_alloc_pages(count, add->pages))
goto err;
@@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map *map)
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ else if (map->dma_vaddr) {
+ unsigned long mfn;
+
+ mfn = __pfn_to_mfn(page_to_pfn(map->pages[i]));
+ map->unmap_ops[i].dev_bus_addr = __pfn_to_phys(mfn);
+ }
+#endif
}
[Xen-devel] [PATCH v2 2/9] xen/grant-table: Make set/clear page private code shared
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table.h | 3 +++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index ba36ff3e4903..dbb48a89e987 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
}
EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
-/**
- * gnttab_alloc_pages - alloc pages suitable for grant mapping into
- * @nr_pages: number of pages to alloc
- * @pages: returns the pages
- */
-int gnttab_alloc_pages(int nr_pages, struct page **pages)
+int gnttab_pages_set_private(int nr_pages, struct page **pages)
{
int i;
- int ret;
-
- ret = alloc_xenballooned_pages(nr_pages, pages);
- if (ret < 0)
- return ret;
for (i = 0; i < nr_pages; i++) {
#if BITS_PER_LONG < 64
struct xen_page_foreign *foreign;
foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
- if (!foreign) {
- gnttab_free_pages(nr_pages, pages);
+ if (!foreign)
return -ENOMEM;
- }
+
set_page_private(pages[i], (unsigned long)foreign);
#endif
SetPagePrivate(pages[i]);
@@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+EXPORT_SYMBOL_GPL(gnttab_pages_set_private);
/**
- * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
- * @nr_pages; number of pages to free
- * @pages: the pages
+ * gnttab_alloc_pages - alloc pages suitable for grant mapping into
+ * @nr_pages: number of pages to alloc
+ * @pages: returns the pages
*/
-void gnttab_free_pages(int nr_pages, struct page **pages)
+int gnttab_alloc_pages(int nr_pages, struct page **pages)
+{
+ int ret;
+
+ ret = alloc_xenballooned_pages(nr_pages, pages);
+ if (ret < 0)
+ return ret;
+
+ ret = gnttab_pages_set_private(nr_pages, pages);
+ if (ret < 0)
+ gnttab_free_pages(nr_pages, pages);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+
+void gnttab_pages_clear_private(int nr_pages, struct page **pages)
{
int i;
@@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
ClearPagePrivate(pages[i]);
}
}
+}
+EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);
+
+/**
+ * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
+ * @nr_pages; number of pages to free
+ * @pages: the pages
+ */
+void gnttab_free_pages(int nr_pages, struct page **pages)
+{
+ gnttab_pages_clear_private(nr_pages, pages);
free_xenballooned_pages(nr_pages, pages);
}
EXPORT_SYMBOL_GPL(gnttab_free_pages);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2e37741f6b8d..de03f2542bb7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void);
int gnttab_alloc_pages(int nr_pages, struct page **pages);
void gnttab_free_pages(int nr_pages, struct page **pages);
+int gnttab_pages_set_private(int nr_pages, struct page **pages);
+void gnttab_pages_clear_private(int nr_pages, struct page **pages);
+
int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
--
2.17.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/9] xen: dma-buf support for grant device
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed solution,
can greatly benefit as well.
RFC for this series was published and discussed [9], comments addressed.
The original rationale behind this work was to enable zero-copying
use-cases while working with Xen para-virtual display driver [4]:
when using Xen PV DRM frontend driver then on backend side one will
need to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers and frames per
second it may result in unneeded huge data bus occupation and
performance loss.
The helper driver [4] allows implementing zero-copying use-cases
when using Xen para-virtualized frontend display driver by implementing
a DRM/KMS helper driver running on backend's side.
It utilizes PRIME buffers API (implemented on top of Linux dma-buf)
to share frontend's buffers with physical device drivers on
backend's side:
- a dumb buffer created on backend's side can be shared
with the Xen PV frontend driver, so it directly writes
into backend's domain memory (into the buffer exported from
DRM/KMS driver of a physical display device)
- a dumb buffer allocated by the frontend can be imported
into physical device DRM/KMS driver, thus allowing to
achieve no copying as well
Finally, it was discussed and decided ([1], [5]) that it is worth
implementing such use-cases via extension of the existing Xen gntdev
driver instead of introducing new DRM specific driver.
Please note, that the support of dma-buf is Linux only,
as dma-buf is a Linux only thing.
Now to the proposed solution. The changes to the existing Xen drivers
in the Linux kernel fall into 2 categories:
1. DMA-able memory buffer allocation and increasing/decreasing memory
reservation of the pages of such a buffer.
This is required if we are about to share dma-buf with the hardware
that does require those to be allocated with dma_alloc_xxx API.
(It is still possible to allocate a dma-buf from any system memory,
e.g. system pages).
2. Extension of the gntdev driver to enable it to import/export dma-buf’s.
The first five patches are in preparation for Xen dma-buf support,
but I consider those usable regardless of the dma-buf use-case,
e.g. other frontend/backend kernel modules may also benefit from these
for better code reuse:
0001-xen-grant-table-Export-gnttab_-alloc-free-_pages-as-.patch
0002-xen-grant-table-Make-set-clear-page-private-code-sha.patch
0003-xen-balloon-Share-common-memory-reservation-routines.patch
0004-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch
0005-xen-gntdev-Allow-mappings-for-DMA-buffers.patch
The next three patches are Xen implementation of dma-buf as part of
the grant device:
0006-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch
0007-xen-gntdev-Implement-dma-buf-export-functionality.patch
0008-xen-gntdev-Implement-dma-buf-import-functionality.patch
The last patch makes it possible for in-kernel use of Xen dma-buf API:
0009-xen-gntdev-Expose-gntdev-s-dma-buf-API-for-in-kernel.patch
The corresponding libxengnttab changes are available at [6].
All the above was tested with display backend [7] and its accompanying
helper library [8] on Renesas ARM64 based board.
Basic balloon tests on x86.
*To all the communities*: I would like to ask you to review the proposed
solution and give feedback on it, so I can improve and send final
patches for review (this is still work in progress, but enough to start
discussing the implementation).
Thank you in advance,
Oleksandr Andrushchenko
[1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html
[2]
https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst
[3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html
[4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen
[5] https://patchwork.kernel.org/patch/10279681/
[6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1
[7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1
[8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1
[9] https://lkml.org/lkml/2018/5/17/215
Changes since v1:
*
- Define GNTDEV_DMA_FLAG_XXX starting from bit 0
- Rename mem_reservation.h to mem-reservation.h
- Remove usless comments
- Change licenses from GPLv2 OR MIT to GPLv2 only
- Make xenmem_reservation_va_mapping_{update|clear} inline
- Change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL for new functions
- Make gnttab_dma_{alloc|free}_pages to request frames array
be allocated outside
- Fixe gnttab_dma_alloc_pages fail path (added xenmem_reservation_increase)
- Move most of dma-buf from gntdev.c
[Xen-devel] [PATCH v2 8/9] xen/gntdev: Implement dma-buf import functionality
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only valid for buffers created with
IOCTL_GNTDEV_DMABUF_IMP_TO_REFS.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 243 +++-
1 file changed, 241 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index f612468879b4..b5569a220f03 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -11,8 +11,20 @@
#include
#include
+#include
+#include
+
#include "gntdev-dmabuf.h"
+#ifndef GRANT_INVALID_REF
+/*
+ * Note on usage of grant reference 0 as invalid grant reference:
+ * grant reference 0 is valid, but never exposed to a driver,
+ * because of the fact it is already in use/reserved by the PV console.
+ */
+#define GRANT_INVALID_REF 0
+#endif
+
struct gntdev_dmabuf {
struct gntdev_dmabuf_priv *priv;
struct dma_buf *dmabuf;
@@ -29,6 +41,14 @@ struct gntdev_dmabuf {
void (*release)(struct gntdev_priv *priv,
struct grant_map *map);
} exp;
+ struct {
+ /* Granted references of the imported buffer. */
+ grant_ref_t *refs;
+ /* Scatter-gather table of the imported buffer. */
+ struct sg_table *sgt;
+ /* dma-buf attachment of the imported buffer. */
+ struct dma_buf_attachment *attach;
+ } imp;
} u;
/* Number of pages this buffer has. */
@@ -53,6 +73,8 @@ struct gntdev_dmabuf_priv {
struct list_head exp_list;
/* List of wait objects. */
struct list_head exp_wait_list;
+ /* List of imported DMA buffers. */
+ struct list_head imp_list;
/* This is the lock which protects dma_buf_xxx lists. */
struct mutex lock;
};
@@ -424,21 +446,237 @@ int gntdev_dmabuf_exp_from_pages(struct
gntdev_dmabuf_export_args *args)
/* DMA buffer import support. */
/* -- */
+static int
+dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
+ int count, int domid)
+{
+ grant_ref_t priv_gref_head;
+ int i, ret;
+
+ ret = gnttab_alloc_grant_references(count, _gref_head);
+ if (ret < 0) {
+ pr_err("Cannot allocate grant references, ret %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; i < count; i++) {
+ int cur_ref;
+
+ cur_ref = gnttab_claim_grant_reference(_gref_head);
+ if (cur_ref < 0) {
+ ret = cur_ref;
+ pr_err("Cannot claim grant reference, ret %d\n", ret);
+ goto out;
+ }
+
+ gnttab_grant_foreign_access_ref(cur_ref, domid,
+ xen_page_to_gfn(pages[i]), 0);
+ refs[i] = cur_ref;
+ }
+
+ ret = 0;
+
+out:
+ gnttab_free_grant_references(priv_gref_head);
+ return ret;
+}
+
+static void dmabuf_imp_end_foreign_access(u32 *refs, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++)
+ if (refs[i] != GRANT_INVALID_REF)
+ gnttab_end_foreign_access(refs[i], 0, 0UL);
+}
+
+static void dmabuf_imp_free_storage(struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ kfree(gntdev_dmabuf->pages);
+ kfree(gntdev_dmabuf->u.imp.refs);
+ kfree(gntdev_dmabuf);
+}
+
+static struct gntdev_dmabuf *dmabuf_imp_alloc_storage(int count)
+{
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ int i;
+
+ gntdev_dmabuf = kzalloc(sizeof(*gntdev_dmabuf), GFP_KERNEL);
+ if (!gntdev_dmabuf)
+ goto fail;
+
+ gntdev_dmabuf->u.imp.refs = kcalloc(count,
+
sizeof(gntdev_dmabuf->u.imp.refs[0]),
+ GFP_KERNEL);
+ if (!gntdev_dmabuf->u.imp.refs)
+ goto fail;
+
+ gntdev_dmabuf->pages = kcalloc(count,
+ sizeof(gntdev_dmabuf->pages[0]),
+ GFP_KERNEL);
+ if (!gntdev_dmabuf->pages)
+ goto fail;
+
+ gntdev_dmabuf->nr_pages = count;
+
+ for (i = 0; i < count; i++)
+ gntdev_dmabuf->u.imp.refs[i] = GRANT_INVALID_REF;
+
+ return gntdev_dmabuf;
+
+fail:
+ dmabuf_imp_free_storage(gntdev_dmabuf);
+ return ERR_PTR(-ENOMEM);
+}
+
struct gntdev_dmabuf *
gntdev_dmabuf_imp_to_refs(struct
[Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 6 +++
drivers/xen/gntdev.c| 92 +++--
include/xen/grant_dev.h | 37 +++
3 files changed, 101 insertions(+), 34 deletions(-)
create mode 100644 include/xen/grant_dev.h
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index b5569a220f03..3890ac9dfab6 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -196,6 +196,7 @@ int gntdev_dmabuf_exp_wait_released(struct
gntdev_dmabuf_priv *priv, int fd,
dmabuf_exp_wait_obj_free(priv, obj);
return ret;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_exp_wait_released);
/* -- */
/* DMA buffer export support. */
@@ -621,6 +622,7 @@ gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv,
struct device *dev,
dma_buf_put(dma_buf);
return ret;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_imp_to_refs);
u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
{
@@ -629,6 +631,7 @@ u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf
*gntdev_dmabuf)
return NULL;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_imp_get_refs);
/*
* Find the hyper dma-buf by its file descriptor and remove
@@ -678,6 +681,7 @@ int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv
*priv, u32 fd)
dmabuf_imp_free_storage(gntdev_dmabuf);
return 0;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_imp_release);
struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
{
@@ -694,8 +698,10 @@ struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
return priv;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_init);
void gntdev_dmabuf_fini(struct gntdev_dmabuf_priv *priv)
{
kfree(priv);
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_fini);
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index cf255d45f20f..63902f5298c9 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -621,14 +621,37 @@ static const struct mmu_notifier_ops gntdev_mmu_ops = {
/* -- */
-static int gntdev_open(struct inode *inode, struct file *flip)
+void gntdev_free_context(struct gntdev_priv *priv)
+{
+ struct grant_map *map;
+
+ pr_debug("priv %p\n", priv);
+
+ mutex_lock(>lock);
+ while (!list_empty(>maps)) {
+ map = list_entry(priv->maps.next, struct grant_map, next);
+ list_del(>next);
+ gntdev_put_map(NULL /* already removed */, map);
+ }
+ WARN_ON(!list_empty(>freeable_maps));
+
+ mutex_unlock(>lock);
+
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ gntdev_dmabuf_fini(priv->dmabuf_priv);
+#endif
+
+ kfree(priv);
+}
+EXPORT_SYMBOL_GPL(gntdev_free_context);
+
+struct gntdev_priv *gntdev_alloc_context(struct device *dev)
{
struct gntdev_priv *priv;
- int ret = 0;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(>maps);
INIT_LIST_HEAD(>freeable_maps);
@@ -637,12 +660,40 @@ static int gntdev_open(struct inode *inode, struct file
*flip)
#ifdef CONFIG_XEN_GNTDEV_DMABUF
priv->dmabuf_priv = gntdev_dmabuf_init();
if (IS_ERR(priv->dmabuf_priv)) {
- ret = PTR_ERR(priv->dmabuf_priv);
+ struct gntdev_priv *ret;
+
+ ret = ERR_CAST(priv->dmabuf_priv);
kfree(priv);
return ret;
}
#endif
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ priv->dma_dev = dev;
+
+ /*
+* The device is not spawn from a device tree, so arch_setup_dma_ops
+* is not called, thus leaving the device with dummy DMA ops.
+* Fix this call of_dma_configure() with a NULL node to set
+* default DMA ops.
+*/
+ of_dma_configure(priv->dma_dev, NULL);
+#endif
+ pr_debug("priv %p\n", priv);
+
+ return priv;
+}
+EXPORT_SYMBOL_GPL(gntdev_alloc_context);
+
+static int gntdev_open(struct inode *inode, struct file *flip)
+{
+ struct gntdev_priv *priv;
+ int ret = 0;
+
+ priv = gntdev_alloc_context(gntdev_miscdev.this_device);
+ if (IS_ERR(priv))
+ return PTR_ERR(priv);
+
if (use_ptemod) {
priv->mm = get_task_mm(current);
if (!priv->mm) {
@@ -655,23 +706,11 @@ static int gntdev_open(struct inode *inode, struct file
*flip)
}
if (ret) {
- kfree(priv);
+ gntdev_free_context(priv);
return ret;
}
flip->private_data = priv;
-#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
-
[Xen-devel] [PATCH v2 3/9] xen/balloon: Share common memory reservation routines
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
symbols for other kernel modules.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 ++--
drivers/xen/mem-reservation.c | 120 ++
include/xen/mem-reservation.h | 65 ++
4 files changed, 192 insertions(+), 65 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/mem-reservation.h
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 451e833f5931..3c87b0c3aca6 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
obj-$(CONFIG_X86) += fallback.o
obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o
+obj-y += mem-reservation.o
obj-y += events/
obj-y += xenbus/
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 065f0b607373..bdbce4257b65 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -71,6 +71,7 @@
#include
#include
#include
+#include
static int xen_hotplug_unpopulated;
@@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker,
balloon_process);
#define GFP_BALLOON \
(GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
-static void scrub_page(struct page *page)
-{
-#ifdef CONFIG_XEN_SCRUB_PAGES
- clear_highpage(page);
-#endif
-}
-
/* balloon_append: add the given page to the balloon. */
static void __balloon_append(struct page *page)
{
@@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
-* We don't support PV MMU when Linux and Xen is using
-* different page granularity.
-*/
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
- int ret;
- ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn <<
PAGE_SHIFT),
- mfn_pte(frame_list[i],
PAGE_KERNEL),
- 0);
- BUG_ON(ret);
- }
- }
-#endif
+ xenmem_reservation_va_mapping_update(1, , _list[i]);
/* Relinquish the page back to the allocator. */
free_reserved_page(page);
@@ -535,11 +500,6 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
unsigned long i;
struct page *page, *tmp;
int ret;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
LIST_HEAD(pages);
if (nr_pages > ARRAY_SIZE(frame_list))
@@ -553,7 +513,7 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
break;
}
adjust_managed_page_count(page, -1);
- scrub_page(page);
+ xenmem_reservation_scrub_page(page);
list_add(>lru, );
}
@@ -575,25 +535,8 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
/*
[Xen-devel] [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other domain use and grant references coming from a foreign
domain can be converted into a local dma-buf for local export.
Implement basic initialization and stubs for Xen DMA buffers'
support.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Kconfig | 10 +++
drivers/xen/Makefile| 1 +
drivers/xen/gntdev-dmabuf.c | 75 +++
drivers/xen/gntdev-dmabuf.h | 41 +++
drivers/xen/gntdev.c| 142
include/uapi/xen/gntdev.h | 91 +++
6 files changed, 360 insertions(+)
create mode 100644 drivers/xen/gntdev-dmabuf.c
create mode 100644 drivers/xen/gntdev-dmabuf.h
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 39536ddfbce4..52d64e4b6b81 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -152,6 +152,16 @@ config XEN_GNTDEV
help
Allows userspace processes to use grants.
+config XEN_GNTDEV_DMABUF
+ bool "Add support for dma-buf grant access device driver extension"
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
+ help
+ Allows userspace processes and kernel modules to use Xen backed
+ dma-buf implementation. With this extension grant references to
+ the pages of an imported dma-buf can be exported for other domain
+ use and grant references coming from a foreign domain can be
+ converted into a local dma-buf for local export.
+
config XEN_GRANT_DEV_ALLOC
tristate "User-space grant reference allocator driver"
depends on XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 3c87b0c3aca6..33afb7b2b227 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -41,5 +41,6 @@ obj-$(CONFIG_XEN_PVCALLS_BACKEND) += pvcalls-back.o
obj-$(CONFIG_XEN_PVCALLS_FRONTEND) += pvcalls-front.o
xen-evtchn-y := evtchn.o
xen-gntdev-y := gntdev.o
+xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF) += gntdev-dmabuf.o
xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
new file mode 100644
index ..6bedd1387bd9
--- /dev/null
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Xen dma-buf functionality for gntdev.
+ *
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#include
+
+#include "gntdev-dmabuf.h"
+
+struct gntdev_dmabuf_priv {
+ int dummy;
+};
+
+/* -- */
+/* DMA buffer export support. */
+/* -- */
+
+/* -- */
+/* Implementation of wait for exported DMA buffer to be released. */
+/* -- */
+
+int gntdev_dmabuf_exp_wait_released(struct gntdev_dmabuf_priv *priv, int fd,
+ int wait_to_ms)
+{
+ return -EINVAL;
+}
+
+/* -- */
+/* DMA buffer export support. */
+/* -- */
+
+int gntdev_dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args)
+{
+ return -EINVAL;
+}
+
+/* -- */
+/* DMA buffer import support. */
+/* -- */
+
+struct gntdev_dmabuf *
+gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev,
+ int fd, int count, int domid)
+{
+ return ERR_PTR(-ENOMEM);
+}
+
+u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ return NULL;
+}
+
+int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
+{
+ return -EINVAL;
+}
+
+struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
+{
+ struct gntdev_dmabuf_priv *priv;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return ERR_PTR(-ENOMEM);
+
+ return priv;
+}
+
+void gntdev_dmabuf_fini(struct gntdev_dmabuf_priv *priv)
+{
+ kfree(priv);
+}
diff --git a/drivers/xen/gntdev-dmabuf.h b/drivers/xen/gntdev-dmabuf.h
new file mode 100644
index ..040b2de904ac
--- /dev/null
+++ b/drivers/xen/gntdev-dmabuf.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier:
[Xen-devel] [PATCH v2 4/9] xen/grant-table: Allow allocating buffers suitable for DMA
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is made
({increase|decrease}_reservation and VA mappings updated if needed).
This is useful for sharing foreign buffers with HW drivers which
cannot work with scattered buffers provided by the balloon driver,
but require DMAable memory instead.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Kconfig | 13 +
drivers/xen/grant-table.c | 109 ++
include/xen/grant_table.h | 18 +++
3 files changed, 140 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e5d0c28372ea..39536ddfbce4 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -161,6 +161,19 @@ config XEN_GRANT_DEV_ALLOC
to other domains. This can be used to implement frontend drivers
or as part of an inter-domain shared memory channel.
+config XEN_GRANT_DMA_ALLOC
+ bool "Allow allocating DMA capable buffers with grant reference module"
+ depends on XEN && HAS_DMA
+ help
+ Extends grant table module API to allow allocating DMA capable
+ buffers and mapping foreign grant references on top of it.
+ The resulting buffer is similar to one allocated by the balloon
+ driver in terms that proper memory reservation is made
+ ({increase|decrease}_reservation and VA mappings updated if needed).
+ This is useful for sharing foreign buffers with HW drivers which
+ cannot work with scattered buffers provided by the balloon driver,
+ but require DMAable memory instead.
+
config SWIOTLB_XEN
def_bool y
select SWIOTLB
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index dbb48a89e987..5658e58d9cc6 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -45,6 +45,9 @@
#include
#include
#include
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+#include
+#endif
#include
#include
@@ -57,6 +60,7 @@
#ifdef CONFIG_X86
#include
#endif
+#include
#include
#include
@@ -811,6 +815,73 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
}
EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+/**
+ * gnttab_dma_alloc_pages - alloc DMAable pages suitable for grant mapping into
+ * @args: arguments to the function
+ */
+int gnttab_dma_alloc_pages(struct gnttab_dma_alloc_args *args)
+{
+ unsigned long pfn, start_pfn;
+ size_t size;
+ int i, ret;
+
+ size = args->nr_pages << PAGE_SHIFT;
+ if (args->coherent)
+ args->vaddr = dma_alloc_coherent(args->dev, size,
+>dev_bus_addr,
+GFP_KERNEL | __GFP_NOWARN);
+ else
+ args->vaddr = dma_alloc_wc(args->dev, size,
+ >dev_bus_addr,
+ GFP_KERNEL | __GFP_NOWARN);
+ if (!args->vaddr) {
+ pr_err("Failed to allocate DMA buffer of size %zu\n", size);
+ return -ENOMEM;
+ }
+
+ start_pfn = __phys_to_pfn(args->dev_bus_addr);
+ for (pfn = start_pfn, i = 0; pfn < start_pfn + args->nr_pages;
+ pfn++, i++) {
+ struct page *page = pfn_to_page(pfn);
+
+ args->pages[i] = page;
+ args->frames[i] = xen_page_to_gfn(page);
+ xenmem_reservation_scrub_page(page);
+ }
+
+ xenmem_reservation_va_mapping_reset(args->nr_pages, args->pages);
+
+ ret = xenmem_reservation_decrease(args->nr_pages, args->frames);
+ if (ret != args->nr_pages) {
+ pr_err("Failed to decrease reservation for DMA buffer\n");
+ ret = -EFAULT;
+ goto fail_free_dma;
+ }
+
+ ret = gnttab_pages_set_private(args->nr_pages, args->pages);
+ if (ret < 0)
+ goto fail_clear_private;
+
+ return 0;
+
+fail_clear_private:
+ gnttab_pages_clear_private(args->nr_pages, args->pages);
+fail_free_dma:
+ xenmem_reservation_increase(args->nr_pages, args->frames);
+ xenmem_reservation_va_mapping_update(args->nr_pages, args->pages,
+args->frames);
+ if (args->coherent)
+ dma_free_coherent(args->dev, size,
+ args->vaddr, args->dev_bus_addr);
+ else
+ dma_free_wc(args->dev, size,
+ args->vaddr, args->dev_bus_addr);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gnttab_dma_alloc_pages);
+#endif
+
void gnttab_pages_clear_private(int nr_pages, struct page **pages)
{
int i;
@@ -838,6 +909,44 @@ void gnttab_free_pages(int
Re: [Xen-devel] [PATCH v4 08/10] arm: add QEMU, Rcar3 and MPSoC configs
Hi Stefano, On 01.06.18 00:48, Stefano Stabellini wrote: Add a "Platform Support" menu with three umbrella kconfig options: QEMU, RCAR3 and MPSOC. They enable the required options for their hardware platform. In the case of the MPSOC that has a platform file under arch/arm/platforms/, build the file if MPSOC. Signed-off-by: Stefano Stabellini CC: artem_myga...@epam.com CC: volodymyr_babc...@epam.com Added Andrii Anisov and Oleksandr Tyshchenko. --- Changes in v4: - fix GICv3/GICV3 - default y to all options - build xilinx-zynqmp if MPSOC --- xen/arch/arm/Kconfig| 2 ++ xen/arch/arm/platforms/Kconfig | 30 ++ xen/arch/arm/platforms/Makefile | 2 +- 3 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/platforms/Kconfig diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 2b87111..75cacfb 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR config ARM32_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR +source "arch/arm/platforms/Kconfig" + source "common/Kconfig" source "drivers/Kconfig" diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig new file mode 100644 index 000..fea8f9a --- /dev/null +++ b/xen/arch/arm/platforms/Kconfig @@ -0,0 +1,30 @@ +menu "Platform Support" + +config QEMU + bool "QEMU aarch virt machine support" + default y + depends on ARM_64 + select GICV3 + select HAS_PL011 + ---help--- + Enable all the required drivers for QEMU aarch64 virt emulated + machine. + +config RCAR3 + bool "Renesas RCar3 support" + default y + depends on ARM_64 + select HAS_SCIF + ---help--- + Enable all the required drivers for Renesas RCar3 + +config MPSOC + bool "Xilinx Ultrascale+ MPSoC support" + default y + depends on ARM_64 + select HAS_CADENCE_UART + select ARM_SMMU + ---help--- + Enable all the required drivers for Xilinx Ultrascale+ MPSoC + +endmenu diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 80e555c..f4ff411 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o obj-y += sunxi.o obj-$(CONFIG_ARM_64) += thunderx.o obj-$(CONFIG_ARM_64) += xgene-storm.o -obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o +obj-$(CONFIG_MPSOC) += xilinx-zynqmp.o -- Volodymyr Babchuk ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 04/10] Make MEM_ACCESS configurable
>>> On 31.05.18 at 23:48, wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -20,8 +20,16 @@ config HAS_DEVICE_TREE > config HAS_EX_TABLE > bool > > -config HAS_MEM_ACCESS > - bool > +config MEM_ACCESS_ALWAYS_ON > + def_bool n Only "bool" please - there should be no defaults other than y for options without prompts. Otherwise, if later an option gains a prompt, the user won't be presented with the option to enable it when using one of the *oldconfig targets (due to the previously recorded setting). With that replaced Acked-by: Jan Beulich also in case you follow Tamas'es suggestion and switch ... > +config MEM_ACCESS > + def_bool y > + prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON ... the default here to MEM_ACCESS_ALWAYS_ON (or !ARM or X86). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 10/10] xen: add per-platform defaults for NR_CPUS
>>> On 31.05.18 at 23:48, wrote: > Add specific per-platform defaults for NR_CPUS. Note that the order of > the defaults matter: they need to go first, otherwise the generic > defaults will be applied. Still I'd prefer the ARM ones to follow the X86 one (keeping the ARM ones together), unless you follow Julien's advice anyway and move the setting into arch//Kconfig. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 09/10] xen: add cloc target
>>> On 31.05.18 at 23:48, wrote: > Add a Xen build target to count the lines of code of the source files > built. Uses `cloc' to do the job. > > With Xen on ARM taking off in embedded, IoT, and automotive, we are > seeing more and more uses of Xen in constrained environments. Users and > system integrators want the smallest Xen and Dom0 configurations. Some > of these deployments require certifications, where you definitely want > the smallest lines of code count. I provided this patch to give us the > lines of code count for that purpose. > > Use the .o.d files to account for all the built source files. Generate a > list for the `cloc' utility and invoke `cloc'. > > Signed-off-by: Stefano Stabellini Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 05/10] make it possible to enable/disable UART drivers
>>> On 31.05.18 at 23:48, wrote: > @@ -54,6 +54,7 @@ config HAS_SCIF > > config HAS_EHCI > bool > + depends on X86 Just FTR: I won't NAK this, but I also won't ACK it. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/6] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit
>>> On 30.05.18 at 19:34, wrote:
> @@ -117,6 +115,9 @@ integer_param("debug_stack_lines", debug_stack_lines);
> static bool opt_ler;
> boolean_param("ler", opt_ler);
>
> +/* LastExceptionFromIP on this hardware. Zero if LER is not in use. */
> +uint32_t __read_mostly ler_msr;
Hmm, this is still uint32_t rather than unsigned int, while you did change
calc_ler_msr()'s return type.
> +void percpu_traps_init(void)
> +{
> +subarch_percpu_traps_init();
> +
> +if ( !opt_ler )
> +return;
> +
> +if ( !ler_msr && (ler_msr = calc_ler_msr()) )
> +setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
I assume it was on purpose that you've adjusted the commit message
rather than the code here regarding the possibility of pointless multiple
invocation?
With preferably the type inconsistency addressed
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing bisection] complete test-amd64-amd64-xl-qemut-ws16-amd64
branch xen-4.9-testing xenbranch xen-4.9-testing job test-amd64-amd64-xl-qemut-ws16-amd64 testid xen-boot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 12259ff59c52c601ce7f67799575224b2c35b6a1 Bug not present: 516ac8a982a20a55ef8e28715e36c3aa917b7222 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/123539/ commit 12259ff59c52c601ce7f67799575224b2c35b6a1 Author: Juergen Gross Date: Thu Apr 26 13:33:12 2018 +0200 xen/x86: support per-domain flag for xpti Instead of switching XPTI globally on or off add a per-domain flag for that purpose. This allows to modify the xpti boot parameter to support running dom0 without Meltdown mitigations. Using "xpti=no-dom0" as boot parameter will achieve that. Move the xpti boot parameter handling to xen/arch/x86/pv/domain.c as it is pv-domain specific. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.9-testing/test-amd64-amd64-xl-qemut-ws16-amd64.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-4.9-testing/test-amd64-amd64-xl-qemut-ws16-amd64.xen-boot --summary-out=tmp/123539.bisection-summary --basis-template=123122 --blessings=real,real-bisect xen-4.9-testing test-amd64-amd64-xl-qemut-ws16-amd64 xen-boot Searching for failure / basis pass: 123343 fail [host=huxelrebe1] / 123122 ok. Failure / basis pass flights: 123343 / 123122 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 1dff08485b9e835d00bfb34a435bc6f07dadb6fd c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 f51d3681a81ee4bb8733840512e2a6cabf616ddf Basis pass 6ba89b52ba6916bc7a3d390d70951e992c0ca39e c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 74fa9552c1e3ef79bd4db0a67fc538bbd61b7561 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#6ba89b52ba6916bc7a3d390d70951e992c0ca39e-1dff08485b9e835d00bfb34a435bc6f07dadb6fd git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#b397ed6a586b0a93e9a8b47f5b3008fac34f5f37-b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 git://xenbits.xen.org/xen.git#74fa9552c1e3ef79bd4db0a67fc538bbd61b7561-f51d3681a81ee4bb8733840512e2a6cabf616ddf adhoc-revtuple-generator: tree discontiguous: linux-pvops Loaded 1002 nodes in revision graph Searching for test results: 122960 pass irrelevant 123009 pass irrelevant 123122 pass 6ba89b52ba6916bc7a3d390d70951e992c0ca39e c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 74fa9552c1e3ef79bd4db0a67fc538bbd61b7561 123343 fail 1dff08485b9e835d00bfb34a435bc6f07dadb6fd c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 f51d3681a81ee4bb8733840512e2a6cabf616ddf 123522 pass 1dff08485b9e835d00bfb34a435bc6f07dadb6fd c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 516ac8a982a20a55ef8e28715e36c3aa917b7222 123501 pass 6ba89b52ba6916bc7a3d390d70951e992c0ca39e c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 74fa9552c1e3ef79bd4db0a67fc538bbd61b7561 123515 fail 1dff08485b9e835d00bfb34a435bc6f07dadb6fd c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 f51d3681a81ee4bb8733840512e2a6cabf616ddf 123519 pass 1dff08485b9e835d00bfb34a435bc6f07dadb6fd c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d b397ed6a586b0a93e9a8b47f5b3008fac34f5f37 2aca1d7f00cbfa940bf72793e9f44a4d0772705c 123525 fail
Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL
On 01/06/18 10:10, Jan Beulich wrote: On 31.05.18 at 11:14, wrote: >> On 31/05/18 10:32, Juergen Gross wrote: >>> On 31/05/18 08:00, osstest service owner wrote: flight 123379 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/123379/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 >> fail REGR. vs. 123323 >>> >>> AFAICS this seems to be the suspected Windows reboot again? >> >> Hmm, thinking more about it: xl save is done with the domU paused, >> so the guest rebooting concurrently is rather improbable. > > Not sure, considering e.g. > > libxl: libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving > domain: domain responded to suspend request: Bad address That was at 2018-05-30 22:12:49.650+ Before that there was: 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14 = Bad address): Internal error But looking at the messages issued some seconds before that I see some xenstore watch related messages in: http://logs.test-lab.xenproject.org/osstest/logs/123379/test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm/huxelrebe1---var-log-libvirt-libxl-libxl-driver.log which make me wonder whether the libxl watch handling is really correct: e.g. libxl__ev_xswatch_register() first registers the watch with xenstore and only then writes the data needed for processing the watch in the related structure. Could it be that the real suspend watch event was interpreted as a @releaseDomain event? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.6-testing test] 123408: regressions - FAIL
>>> On 01.06.18 at 06:43, wrote: > flight 123408 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/123408/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. > 122997 Now this is unexpected: (XEN) Xen-e820 RAM map: (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Not enough memory to relocate the dom0 kernel image. (XEN) Not very helpful of course that we don't see any portion of the memory map. However, looking at the code I think this suggests that the table has zero entries. All the failures in this flight are on one of the albana-s, so there's surely some connection (but I'm not meaning to say at this point that it's a host problem - we might well be corrupting memory somewhere). Going back in serial log I see that 4.7 and 4.8 have the same issue, while 4.11 is fine. But it's booting in EFI mode, which explains the absence of any E820 entries: (XEN) EFI RAM map: Assuming that the EFI booting relies on Daniel's patches, I don't think branches older than 4.9 should be tested on these hosts, unless booting without grub (i.e. launching xen.efi either from the EFI shell or from the EFI boot manager). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 04/10] Make MEM_ACCESS configurable
>>> On 30.05.18 at 22:24, wrote: > On Tue, 29 May 2018, Jan Beulich wrote: >> Also - do we perhaps want the >> prompt to additionally have an EXPERT dependency? Without you saying why >> you want this configurable I can't tell whether this would make sense. > > I am doing this mostly to reduce the code size. I think we should > security support configurations without MEM_ACCESS. I also don't think > it should take an "expert" to disable MEM_ACCESS in Xen. Thus, my > preference is to avoid adding the EXPERT dependency. Well, okay, but please spell this out in the commit message. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL
>>> On 31.05.18 at 11:14, wrote: > On 31/05/18 10:32, Juergen Gross wrote: >> On 31/05/18 08:00, osstest service owner wrote: >>> flight 123379 xen-unstable real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/123379/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 > fail REGR. vs. 123323 >> >> AFAICS this seems to be the suspected Windows reboot again? > > Hmm, thinking more about it: xl save is done with the domU paused, > so the guest rebooting concurrently is rather improbable. Not sure, considering e.g. libxl: libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving domain: domain responded to suspend request: Bad address When looking into the Windows reboot issue (note this we're not dealing with Windows here), I had noticed that there was a problem with trying to save the guest at the "wrong" time. Generally, as explained back then, I think the tool stack should honor the guest trying to reboot when it is already in the process of being migrated/saved, and migration/save should not even be attempted when the guest has already signaled reboot (iirc it's only the former that is an actual issue). Otherwise the tool stack will internally try to drive the same guest into two distinct new states at the same time. Giving reboot (or shutdown) higher priority than migration/save seems natural to me: A rebooting guest can be moved to the new host with no migration cost at all, and a shut down guest doesn't need (live) moving in the first place. > As this is an issue occurring sporadically not only during 4.11 > development phase I don't think this should be a blocker. Yes and no: Yes, it's not a regression. But as long as we don't make this a blocker, I don't think the issue will be addressed, considering for how long it has been there already. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/VT-x: Fix printing of EFER in vmcs_dump_vcpu()
>>> On 31.05.18 at 18:03, wrote: > This is essentially a "take 2" of c/s 82540b66ce "x86/VT-x: Fix determination > of EFER.LMA in vmcs_dump_vcpu()" because in hindight, that change was more > problematic than useful. > > The original reason was to fix the logic for determining when not to print the > PDPTE pointers. However, mutating the efer variable (particularly LME and > LMA) before printing it interferes with diagnosing vmentry failures. I was wondering then, but not enough to ask back. > Instead of modifying efer, change the PDPTE conditional to use > VM_ENTRY_IA32E_MODE. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 00/10] Intel Processor Trace virtulization enabling
>>> On 31.05.18 at 11:10, wrote: > Hi, > > On 31/05/18 00:29, Kang, Luwei wrote: >>> -Original Message- >>> From: Julien Grall [mailto:julien.gr...@arm.com] >>> Sent: Wednesday, May 30, 2018 11:15 PM >>> To: Kang, Luwei ; xen-de...@lists.xen.org >>> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; > ian.jack...@eu.citrix.com; jbeul...@suse.com; >>> konrad.w...@oracle.com; sstabell...@kernel.org; t...@xen.org; > wei.l...@citrix.com; Nakajima, Jun ; Tian, >>> Kevin >>> Subject: Re: [PATCH v2 00/10] Intel Processor Trace virtulization enabling >>> >>> Hi, >>> >>> Can you please avoid CC everyone on each patch? You can use >>> scripts/get_maintainers.pl on each patch to see who is required to be >>> CCed. >> >> OK, get it. I use script/get_maintainers.pl to get the people who need to be > CC and indeed different patch may include different peoples. If somebody > just receive one patch of this patch set may feel a little strange and don't > understand the context. So I CC all the peoples who is mentioned in this > patch set. > > That's usually why I CC everyone on the cover letter. Then for each > patch I CC only the necessary person. > > This avoids maintainers to have to look for what they should review/ack. Indeed, plus most people are subscribed to xen-devel anyway, so get a copy of the other patches via the list. The default really should be to avoid spamming people; if there are people wanting to see full series (like George has told me he prefers), that can be taken care of individually. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
