[Xen-devel] [ovmf test] 148052: all pass - PUSHED
flight 148052 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/148052/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0980779a9ddcd9c98a68d57d214b4f466bb680b0 baseline version: ovmf 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70 Last test of basis 147928 2020-03-03 02:15:08 Z2 days Testing same since 148052 2020-03-04 09:09:35 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Laszlo Ersek jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 4c0f6e349d..0980779a9d 0980779a9ddcd9c98a68d57d214b4f466bb680b0 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
On 04.03.20 17:56, Jan Beulich wrote:
On 04.03.2020 17:31, Jürgen Groß wrote:
On 04.03.20 16:19, Jan Beulich wrote:
On 04.03.2020 16:07, Jürgen Groß wrote:
On 04.03.20 12:32, Jan Beulich wrote:
On 26.02.2020 13:47, Juergen Gross wrote:
+static void update_ept_param_append(const char *str, int val)
+{
+char *pos = opt_ept_setting + strlen(opt_ept_setting);
+
+snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
+ ",%s=%d", str, val);
+}
+
+static void update_ept_param(void)
+{
+snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
+if ( opt_ept_ad >= 0 )
+update_ept_param_append("ad", opt_ept_ad);
This won't correctly reflect reality: If you look at
vmx_init_vmcs_config(), even a negative value means "true" here,
unless on a specific Atom model. I think init_ept_param() wants
to have that erratum workaround logic moved there, such that
you can then assme the value to be non-negative here.
But isn't not mentioning it in the -1 case correct? -1 means: do the
correct thing on the current hardware.
Well, I think the output here should represent effective settings,
The minimum requirement is to reflect the effective parameters, like
cmdline is doing for boot-time only parameters. With runtime parameters
we had no way of telling what was set, and this is now possible.
and a sub-item should be suppressed only if a setting has no effect
at all in the current setup, like ...
+if ( opt_ept_exec_sp >= 0 )
+update_ept_param_append("exec-sp", opt_ept_exec_sp);
I agree for this one - if the value is still -1, it has neither
been set nor is its value of any interest.
... here.
I think we should not mix up specified parameters and effective
settings. In case an effective setting is of common interest it should
be reported via a specific node (like e.g. specific mitigation settings
where the cmdline is not providing enough details).
But then a boolean option that wasn't specified on the command line
should produce no output at all. And hence we'd need a way to tell
whether an option was set from command line for _all_ of them. I
don't think this would be very helpful.
I disagree here.
This is important only for cases where the hypervisor treats the
parameter as a tristate: true/false/unspecified. In all cases where
the bool value is really true or false it can be reported as such.
Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
if any other action would be derived from the parameter variable being
-1.
So either opt_ept_ad should be modified to change it to 0/1 instead of
only setting the VCMS flag, or the logic should be kept as is in this
patch. IMO changing the setting of opt_ept_ad should be done in another
patch if this is really wanted.
I'm curious if anyone else has any opinion either way (or yet
another one) here:
Me too.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 bisection] complete test-amd64-amd64-xl-qemuu-ovmf-amd64
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-qemuu-ovmf-amd64 testid debian-hvm-install Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Bug introduced: 999463c865d3768a8432a89508096ae6a43873a5 Bug not present: a5abd9cc2cebe7fac001f7bb7b647c47cf54af1a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/148104/ commit 999463c865d3768a8432a89508096ae6a43873a5 Author: Hao A Wu Date: Thu Dec 19 13:36:24 2019 +0800 UefiCpuPkg/MpInitLib: Collect processors' CPUID & Platform ID info REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2429 This commit will collect the CPUID and Platform ID information for each processor within system. They will be stored in the CPU_AP_DATA structure. These information will be used in the next commit to decide whether a microcode patch will be loaded into memory. Cc: Eric Dong Cc: Ray Ni Cc: Laszlo Ersek Cc: Star Zeng Cc: Siyuan Fu Cc: Michael D Kinney Signed-off-by: Hao A Wu Reviewed-by: Ray Ni Reviewed-by: Eric Dong For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.14/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-4.14/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install --summary-out=tmp/148104.bisection-summary --basis-template=142849 --blessings=real,real-bisect linux-4.14 test-amd64-amd64-xl-qemuu-ovmf-amd64 debian-hvm-install Searching for failure / basis pass: 147966 fail [host=rimava1] / 147487 [host=debina1] 147418 [host=godello1] 147334 [host=godello0] 147245 [host=albana1] 147166 [host=huxelrebe0] 147094 [host=elbling1] 147038 [host=italia0] 146981 [host=fiano1] 146905 [host=fiano0] 143911 [host=debina0] 143834 [host=huxelrebe0] 143610 [host=albana1] 143513 [host=debina1] 143409 [host=albana0] 143327 [host=godello1] 142849 [host=italia1] 142690 [host=italia0] 142660 [host=fiano1] 142410 [host=huxelrebe0] 142320 [host=fiano0] 141762 [host=huxelreb\ e1] 141640 [host=godello1] 141589 [host=fiano0] 141505 ok. Failure / basis pass flights: 147966 / 141505 (tree with no url: minios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 78d697fc93f98054e36a3ab76dca1a88802ba7be c530a75c1e6a472b0eb9558310b518f0dfcd8860 70911f1f4aee0366b6122f2b90d367ec0f066beb d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 76551856b28d227cb0386a1ab0e774329b941f7d e465fecbfdb865c75f762055c0396bc617005748 Basis pass b10ab5e2c476b69689bc0c46d309471b597c880c c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0c15fb128c518b9acd8611a2deea213e9e55193 d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 43f5df79dad6738d52ea79d072de2b56eb96a91f 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#b10ab5e2c476b69689bc0c46d309471b597c880c-78d697fc93f98054e36a3ab76dca1a88802ba7be git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#b0c15fb128c518b9acd8611a2deea213e9e55193-70911f1f4aee0366b6122f2b90d367ec0f066beb git://xenbits.xen.org/qemu-xen-traditional\ .git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#cef9660618a880ced798375a0fd16a8ad80bd0f0-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/osstest/seabios.git#43f5df79dad6738d52ea79d072de2b56eb96a91f-76551856b28d227cb0386a1ab0e774329b941f7d git://xenbits.xen.org/xen.git#1014f47c7a808e025b8920ab80bfe73a2888b3e5-e465fecbfdb865c75f762055c0396bc617005748 Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at
[Xen-devel] [xen-unstable test] 148033: regressions - FAIL
flight 148033 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/148033/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 147600 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 147600 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 147600 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 147600 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 147600 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 147600 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 147600 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 147600 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 147600 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 147600 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 147600 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 147600 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 147600 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 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-cubietruck 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen d6e732c32a82eb8f03c1bf86c6bc530f24dc05b3 baseline version: xen e465fecbfdb865c75f762055c0396bc617005748 Last test of basis 147600 2020-02-25 13:42:49 Z8 days Failing
Re: [Xen-devel] [PATCH v3 11/20] hw/ide/internal: Remove unused DMARestartFunc typedef
On 2/20/20 8:05 AM, Philippe Mathieu-Daudé wrote:
> The IDE DMA restart callback has been removed in commit fe09c7c9f0.
>
> Fixes: fe09c7c9f0
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/ide/internal.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/hw/ide/internal.h b/include/hw/ide/internal.h
> index 52ec197da0..ce766ac485 100644
> --- a/include/hw/ide/internal.h
> +++ b/include/hw/ide/internal.h
> @@ -326,7 +326,6 @@ typedef int DMAIntFunc(IDEDMA *, int);
> typedef int32_t DMAInt32Func(IDEDMA *, int32_t len);
> typedef void DMAu32Func(IDEDMA *, uint32_t);
> typedef void DMAStopFunc(IDEDMA *, bool);
> -typedef void DMARestartFunc(void *, int, RunState);
>
> struct unreported_events {
> bool eject_request;
>
Acked-by: John Snow
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 12/20] hw/ide: Let the DMAIntFunc prototype use a boolean 'is_write' argument
On 2/20/20 8:05 AM, Philippe Mathieu-Daudé wrote: > The 'is_write' argument is either 0 or 1. > Convert it to a boolean type. > > Signed-off-by: Philippe Mathieu-Daudé > --- > include/hw/ide/internal.h | 2 +- > hw/dma/rc4030.c | 6 +++--- > hw/ide/ahci.c | 2 +- > hw/ide/core.c | 2 +- > hw/ide/macio.c| 2 +- > hw/ide/pci.c | 2 +- > 6 files changed, 8 insertions(+), 8 deletions(-) Acked-by: John Snow ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] block: refactor duplicated macros
On Wed, Mar 4, 2020 at 9:57 PM Dan Williams wrote: > > On Sun, Feb 23, 2020 at 9:04 AM Matteo Croce wrote: > > > > The macros PAGE_SECTORS, PAGE_SECTORS_SHIFT and SECTOR_MASK are defined > > several times in different flavours across the whole tree. > > Define them just once in a common header. > > > > Signed-off-by: Matteo Croce > > --- > > block/blk-lib.c | 2 +- > > drivers/block/brd.c | 3 --- > > drivers/block/null_blk_main.c| 4 > > drivers/block/zram/zram_drv.c| 8 > > drivers/block/zram/zram_drv.h| 2 -- > > drivers/dax/super.c | 2 +- > > For the dax change: > > Acked-by: Dan Williams > > However... > > [..] > > include/linux/blkdev.h | 4 > [..] > > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h > > index 053ea4b51988..b3c9be6906a0 100644 > > --- a/include/linux/blkdev.h > > +++ b/include/linux/blkdev.h > > @@ -910,6 +910,10 @@ static inline struct request_queue > > *bdev_get_queue(struct block_device *bdev) > > #define SECTOR_SIZE (1 << SECTOR_SHIFT) > > #endif > > > > +#define PAGE_SECTORS_SHIFT (PAGE_SHIFT - SECTOR_SHIFT) > > +#define PAGE_SECTORS (1 << PAGE_SECTORS_SHIFT) > > +#define SECTOR_MASK(PAGE_SECTORS - 1) > > + > > ...I think SECTOR_MASK is misnamed given it considers pages, and > should probably match the polarity of PAGE_MASK, i.e. > > #define PAGE_SECTORS_MASK(~(PAGE_SECTORS - 1)) > Makes sense. I just kept the same value as in drivers/block/null_blk_main.c -- Matteo Croce per aspera ad upstream ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 147966: regressions - FAIL
flight 147966 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/147966/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-examine 8 reboot fail REGR. vs. 142849 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-xl-credit1 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-xl-multivcpu 7 xen-bootfail REGR. vs. 142849 test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 142849 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 142849 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142849 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142849 test-armhf-armhf-xl-arndale 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 142849 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 147856 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 147856 like 142849 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 147856 like 142849 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail 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-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-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux78d697fc93f98054e36a3ab76dca1a88802ba7be baseline version: linuxb98aebd298246df37b472c52a2ee1023256d02e3 Last test of basis 142849 2019-10-17 21:11:16 Z 139 days Failing since143327 2019-10-29 08:49:30 Z 127 days 23 attempts Testing same since 147755 2020-02-29 05:05:04 Z4 days4 attempts 1514 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm
Re: [Xen-devel] [PATCH] block: refactor duplicated macros
On Sun, Feb 23, 2020 at 9:04 AM Matteo Croce wrote: > > The macros PAGE_SECTORS, PAGE_SECTORS_SHIFT and SECTOR_MASK are defined > several times in different flavours across the whole tree. > Define them just once in a common header. > > Signed-off-by: Matteo Croce > --- > block/blk-lib.c | 2 +- > drivers/block/brd.c | 3 --- > drivers/block/null_blk_main.c| 4 > drivers/block/zram/zram_drv.c| 8 > drivers/block/zram/zram_drv.h| 2 -- > drivers/dax/super.c | 2 +- For the dax change: Acked-by: Dan Williams However... [..] > include/linux/blkdev.h | 4 [..] > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h > index 053ea4b51988..b3c9be6906a0 100644 > --- a/include/linux/blkdev.h > +++ b/include/linux/blkdev.h > @@ -910,6 +910,10 @@ static inline struct request_queue > *bdev_get_queue(struct block_device *bdev) > #define SECTOR_SIZE (1 << SECTOR_SHIFT) > #endif > > +#define PAGE_SECTORS_SHIFT (PAGE_SHIFT - SECTOR_SHIFT) > +#define PAGE_SECTORS (1 << PAGE_SECTORS_SHIFT) > +#define SECTOR_MASK(PAGE_SECTORS - 1) > + ...I think SECTOR_MASK is misnamed given it considers pages, and should probably match the polarity of PAGE_MASK, i.e. #define PAGE_SECTORS_MASK(~(PAGE_SECTORS - 1)) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] misc: Replace zero-length arrays with flexible array member
On 3/4/20 10:38 AM, Philippe Mathieu-Daudé wrote:
> v2:
> - do not modify qed.h (structure with single member)
> - based on hw/scsi/spapr_vscsi fix series:
> https://mid.mail-archive.com/20200304153311.22959-1-philmd@redhat.com
>
> This is a tree-wide cleanup inspired by a Linux kernel commit
> (from Gustavo A. R. Silva).
>
> --v-- description start --v--
>
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to
> declare variable-length types such as these ones is a flexible
> array member [1], introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler
> warning in case the flexible array does not occur last in the
> structure, which will help us prevent some kind of undefined
> behavior bugs from being unadvertenly introduced [2] to the
> Linux codebase from now on.
>
> --^-- description end --^--
>
> Do the similar housekeeping in the QEMU codebase (which uses
> C99 since commit 7be41675f7cb).
>
> The first patch is done with the help of a coccinelle semantic
> patch. However Coccinelle does not recognize:
>
> struct foo {
> int stuff;
> struct boo array[];
> } QEMU_PACKED;
>
> but does recognize:
>
> struct QEMU_PACKED foo {
> int stuff;
> struct boo array[];
> };
>
> I'm not sure why, neither it is worth refactoring all QEMU
> structures to use the attributes before the structure name,
> so I did the 2nd patch manually.
>
> Anyway this is annoying, because many structures are not handled
> by coccinelle. Maybe this needs to be reported to upstream
> coccinelle?
>
> I used spatch 1.0.8 with:
>
> -I include --include-headers \
> --macro-file scripts/cocci-macro-file.h \
> --keep-comments --indent 4
>
> Regards,
>
> Phil.
>
> Based-on: <20200304153311.22959-1-phi...@redhat.com>
> Supersedes: <20200304005105.27454-1-phi...@redhat.com>
>
> Philippe Mathieu-Daudé (2):
> misc: Replace zero-length arrays with flexible array member
> (automatic)
> misc: Replace zero-length arrays with flexible array member (manual)
>
> docs/interop/vhost-user.rst | 4 ++--
> bsd-user/qemu.h | 2 +-
> contrib/libvhost-user/libvhost-user.h | 2 +-
> hw/m68k/bootinfo.h| 2 +-
> hw/scsi/srp.h | 6 +++---
> hw/xen/xen_pt.h | 2 +-
> include/hw/acpi/acpi-defs.h | 16
> include/hw/arm/smmu-common.h | 2 +-
> include/hw/boards.h | 2 +-
> include/hw/i386/intel_iommu.h | 3 ++-
> include/hw/s390x/event-facility.h | 2 +-
> include/hw/s390x/sclp.h | 8
> include/hw/virtio/virtio-iommu.h | 2 +-
> include/sysemu/cryptodev.h| 2 +-
> include/tcg/tcg.h | 2 +-
> pc-bios/s390-ccw/bootmap.h| 2 +-
> pc-bios/s390-ccw/sclp.h | 2 +-
> tests/qtest/libqos/ahci.h | 2 +-
> block/linux-aio.c | 2 +-
> block/vmdk.c | 2 +-
> hw/acpi/nvdimm.c | 6 +++---
> hw/char/sclpconsole-lm.c | 2 +-
> hw/char/sclpconsole.c | 2 +-
> hw/dma/soc_dma.c | 2 +-
> hw/i386/x86.c | 2 +-
> hw/misc/omap_l4.c | 2 +-
> hw/nvram/eeprom93xx.c | 2 +-
> hw/rdma/vmw/pvrdma_qp_ops.c | 4 ++--
> hw/s390x/virtio-ccw.c | 2 +-
> hw/usb/dev-network.c | 2 +-
> hw/usb/dev-smartcard-reader.c | 4 ++--
> hw/virtio/virtio.c| 4 ++--
> net/queue.c | 2 +-
> target/s390x/ioinst.c | 2 +-
> 34 files changed, 53 insertions(+), 52 deletions(-)
>
I'll admit I did not manually verify ALL of this, but instead trust that:
1. The conversion is correct, and this is a desirable change to make.
2. Sample conversions I looked at appear correct.
3. It builds.
4. It passes tests.
So:
Acked-by: John Snow
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: Untangle Invariant TSC handling
On 04/03/2020 10:25, Jan Beulich wrote: > On 03.03.2020 19:24, Andrew Cooper wrote: >> ITSC being visible to the guest is currently implicit with the toolstack >> unconditionally asking for it, and Xen clipping it based on the vTSC and/or >> XEN_DOMCTL_disable_migrate settings. >> >> This is problematic for several reasons. >> >> First, the implicit vTSC behaviour manifests as a real bug on migration to a >> host with a different frequency, with ITSC but without TSC scaling >> capabilities, whereby the ITSC feature becomes advertised to the guest. ITSC >> will disappear again if the guest migrates to server with the same frequency >> as the original, or to one with TSC scaling support. >> >> Secondly, disallowing ITSC unless the guest doesn't migrate is conceptually >> wrong. It is common to have migration pools of identical hardware, at which >> point the TSC frequency is the same, > This statement is too broad: Pools of identical hardware may have the same > nominal frequencies, but two distinct systems are hardly ever going to have > the exact same actual (measured or even real) frequencies. There is no such thing as truly invariant TSC. Even with the best hardware in the world, the reference frequency will change based on physical properties of the surroundings, including things like ambient temperature. i.e. even a single server, sitting in a datacenter is likely to see a fractional change in frequency across a 24h period. What matters is the error margins, and how long until it manifests as a noticeable difference. > Recall Olaf's vTSC-tolerance patch that still hasn't landed anywhere? This is a different problem. Even on the same system, errors in Xen's frequency calculations can differ by several hundred kHz (iirc), boot to boot, making it quite useless for answering the question "am I running at the frequency the guest saw before?", which is how we just whether to intercept TSC accesses or not. There are things which can be done about this, such as using frequency data provided by the CPU directly (rather than correlating it with a separate timesource). At that point, the only difference between two identical systems will be the variability in the reference clock, and PLL circuitry which ultimately multiplies it up from 19.2/25/100 MHz to the 1-3.5GHz typically encountered for core frequencies. > >> and more modern hardware has TSC scaling >> support anyway. In both cases, it is safe to advertise ITSC and migrate the >> guest. >> >> Remove all implicit logic logic in Xen, and make ITSC part of the max CPUID >> policies for guests. Plumb an itsc parameter into xc_cpuid_apply_policy() >> and >> have libxl__cpuid_legacy() fill in the two cases where it can reasonably >> expect ITSC to be safe for the guest to see. >> >> This is a behaviour change for TSC_MODE_NATIVE, where the ITSC will now >> reliably not appear, and for the case where the user explicitly requests >> ITSC, >> in which case it will appear even if the guest isn't marked as nomigrate. > How sensible is it to allow the user to request something like ITSC with > no respective support underneath? Right now, Xen will ignore ITSC if the hardware isn't capable, just like any other missing feature flag. When we get the policy auditing logic in better shape, I intend to reject requests which can't be fulfilled. > Shouldn't we translate such a request > into enabling vTSC if there's no ITSC on the platform? No, because a) doing things implicitly like this is the root of far too many bugs, this patch included, and b) it probably isn't what the user wants. The reason to play around with TSC settings will ultimately to be try and avoid intercepting RDTSC, because the performance hit from interception dominates most other factors. > Actually looking > at the change to libxl__cpuid_legacy() I wonder whether you don't instead > mean "requests vTSC" here. I don't see how you come to that conclusion. It is two separate cases where the toolstack can reasonably expect the guest-observed frequency not to differ. > >> Signed-off-by: Andrew Cooper > Assuming I understand the tools side changes correctly, hypervisor > side > Reviewed-by: Jan Beulich Thanks, but the above confusion wants resolving first. > >> --- a/tools/libxl/libxl_cpuid.c >> +++ b/tools/libxl/libxl_cpuid.c >> @@ -418,6 +418,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, >> int i; >> char *cpuid_res[4]; >> bool pae = true; >> +bool itsc; >> >> /* >> * For PV guests, PAE is Xen-controlled (it is the 'p' that >> differentiates >> @@ -432,7 +433,22 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, >> if (info->type == LIBXL_DOMAIN_TYPE_HVM) >> pae = libxl_defbool_val(info->u.hvm.pae); >> >> -xc_cpuid_apply_policy(ctx->xch, domid, NULL, 0, pae); >> +/* >> + * Advertising Invariant TSC to a guest means that the TSC frequency >> won't >> + * change at any point in the future. >>
Re: [Xen-devel] [PATCH v5 2/2] docs/designs: Add a design document for migration of xenstore data
Hi Paul, On 13/02/2020 10:53, Paul Durrant wrote: This patch details proposes extra migration data and xenstore protocol extensions to support non-cooperative live migration of guests. Signed-off-by: Paul Durrant --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Wei Liu v5: - Add QUIESCE - Make semantics of in GET_DOMAIN_WATCHES more clear v4: - Drop the restrictions on special paths v3: - New in v3 --- docs/designs/xenstore-migration.md | 136 + 1 file changed, 136 insertions(+) create mode 100644 docs/designs/xenstore-migration.md diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md new file mode 100644 index 00..5cfe2d9a7d --- /dev/null +++ b/docs/designs/xenstore-migration.md @@ -0,0 +1,136 @@ +# Xenstore Migration + +## Background + +The design for *Non-Cooperative Migration of Guests*[1] explains that extra +save records are required in the migrations stream to allow a guest running +PV drivers to be migrated without its co-operation. Moreover the save +records must include details of registered xenstore watches as well as +content; information that cannot currently be recovered from `xenstored`, +and hence some extension to the xenstore protocol[2] will also be required. + +The *libxenlight Domain Image Format* specification[3] already defines a +record type `EMULATOR_XENSTORE_DATA` but this is not suitable for +transferring xenstore data pertaining to the domain directly as it is +specified such that keys are relative to the path +`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to +define at least one new save record type. + +## Proposal + +### New Save Record + +A new mandatory record type should be defined within the libxenlight Domain +Image Format: + +`0x0007: DOMAIN_XENSTORE_DATA` + +The format of each of these new records should be as follows: + + +``` +0 1 2 3 4 5 6 7 octet ++++ +| type | record specific data | +++| +... ++-+ +``` + + +| Field | Description | +|---|---| Did you indend to add more - so | is on the same column as the onter lines? +| `type` | 0x: invalid | +|| 0x0001: node data | +|| 0x0002: watch data | Should not the last | be some of the columns on all the lines? +|| 0x0003 - 0x: reserved for future use | Looking at the spec, the command TRANSACTION_END *must* be used with an existing transaction. As a guest would be migrate to a new domain, the transaction ID would now be invalid. I understand that xenstored is able to cope with it, but such behavior is not described in the spec. So I am not sure we can expect a guest to cope with an error value other than the ones described for the command. + + +where data is always in the form of a NUL separated and terminated tuple +as follows + + +**node data** + + +`|||` I don't think this would work. From the spec, is a binary data and therefore it can contain zero or nul. So you would not be able to find out where the starts. Regarding the , it is only describing the permission for one domain. If multiple domains can access the node, then you would have multiple . Do we want to transfer all the permissions, if not how do we define which permissions should be transferred? + + +`` is considered relative to the domain path `/local/domain/$domid` +and hence must not begin with `/`. +`` and `` should be suitable to formulate a `WRITE` operation +to the receiving xenstore and `` should be similarly suitable +to formulate a subsequent `SET_PERMS` operation. + +**watch data** + + +`||` + +`` again is considered relative and, together with ``, should +be suitable to formulate an `ADD_DOMAIN_WATCHES` operation (see below). AFAICT, a guest is allowed to watch /. So is it a sensible thing to only transfer relative watch? Also, how about special watch (i.e @...)? + + +### Protocol Extension + +Before xenstore state is migrated it is necessary to wait for any pending +reads, writes, watch registrations etc. to complete, and also to make sure +that xenstored does not start processing any new requests (so that new +requests remain pending on the shared ring for subsequent processing on the +new host). Hence the following operation is needed: + +``` +QUIESCE | + +Complete processing of any request issued by the specified domain, and +do not process any further requests from the shared ring. +``` + +The `WATCH` operation does not allow specification of a ``; it is +assumed that the watch pertains to the domain that owns the shared ring +over which the operation is passed. Hence, for the tool-stack to be able +to register a watch on behalf of a
Re: [Xen-devel] [PATCH v2] golang/xenlight: implement constructor generation
On 3/2/20 8:10 PM, Nick Rosbrook wrote:
> Generate constructors for generated Go types. Call libxl__init so
> the Go type can be properly initialized.
>
> If a type has a keyed union field, add a parameter to the function
> signature to set the key variable, and call the init function for the
> keyed union.>
> Signed-off-by: Nick Rosbrook
So gave this a spin and ran a cross a niggle...
> +// NewDomainBuildInfo returns an instance of DomainBuildInfo initialized
> with defaults.
> +func NewDomainBuildInfo(dtype DomainType) (*DomainBuildInfo, error) {
NewDomainBuildInfo() will take the domain type; but what I really want is...
> +// NewDomainConfig returns an instance of DomainConfig initialized with
> defaults.
> +func NewDomainConfig() (*DomainConfig, error) {
...for NewDomainConfig() to take the Domain Type. Otherwise I'm in a
position of having to do something like:
dconf, err := xl.NewDomainConfig(xl.DomainTypePv)
if err != nil {
fmt.Printf("NewDomainConfig: %v\n", err)
return
}
dconf.BInfo = xl.NewDomainBuildInfo(xl.DomainTypePv)
I've already got to do:
dconf.CInfo.Type = xl.DomainTypePv
Although, I'm not sure if that implies "There's already boilerplate, so
it's extra important to avoid adding more", or "There's already
boilerplate, so it won't hurt to have a bit more, and wrap the whole
thing in a nicer library."
OTOH, we should be able to have libxl automatically copy c_info.type
from b_info.type if c_info.type == LIBXL_DOMAIN_TYPE_INVALID -- if it
doesn't do so already.
Thoughts?
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] xen boot PVH guest with linux 5.6.0-rc4-ish kernel: general protection fault, RIP: 0010:__pv_queued_spin_lock_slowpath
Hi Juergen, Just tested a 5.6.0-rc4'ish kernel (8b614cb8f1dcac8ca77cf4dd85f46ef3055f8238, so it includes the xen fixes from x86 trees). Xen is the latest xen-unstable, dom0 kernel is 5.5.7. During boot of the PVH guest I got the splat below. With a 5.5.7 kernel the guest boots fine. -- Sander [1.921031] general protection fault, probably for non-canonical address 0x344a3feab7bf8: [#1] SMP NOPTI [1.921090] CPU: 1 PID: 1686 Comm: systemd-udevd Tainted: GW 5.6.0-rc4-20200304-doflr-mac80211debug+ #1 [1.921134] RIP: 0010:__pv_queued_spin_lock_slowpath+0x195/0x2a0 [1.921160] Code: c4 c1 ea 12 4c 8d 6d 14 41 be 01 00 00 00 41 83 e4 03 8d 42 ff 49 c1 e4 05 48 98 49 81 c4 80 c3 02 00 4c 03 24 c5 20 89 b7 82 <49> 89 2c 24 b8 00 80 00 00 eb 15 84 c0 75 0a 41 0f b6 54 24 14 84 [1.921229] RSP: 0018:c9213958 EFLAGS: 00010002 [1.921249] RAX: 327f RBX: 888005ce00e0 RCX: 0001 [1.921278] RDX: 3280 RSI: RDI: [1.921307] RBP: 88801f52c380 R08: fffea95e R09: 8880192d0c80 [1.921335] R10: 8880192d0cb8 R11: c9213b01 R12: 000344a3feab7bf8 [1.921365] R13: 88801f52c394 R14: 0001 R15: 0008 [1.921402] FS: 7f771d762d40() GS:88801f50() knlGS: [1.921438] CS: 0010 DS: ES: CR0: 80050033 [1.921461] CR2: 7fffaae16ec8 CR3: 04b04000 CR4: 06e0 [1.921608] Call Trace: [1.921628] ? ktime_get+0x31/0x90 [1.921646] _raw_spin_lock_irqsave+0x2b/0x30 [1.921669] blkif_queue_rq+0x6e/0x7c0 [1.921685] ? wait_woken+0x80/0x80 [1.921701] ? xen_clocksource_get_cycles+0x11/0x20 [1.921720] ? ktime_get+0x31/0x90 [1.921737] ? blk_mq_get_request+0x195/0x3b0 [1.921757] ? blk_account_io_start+0xd4/0x150 [1.921776] __blk_mq_try_issue_directly+0x10e/0x1c0 [1.921798] blk_mq_request_issue_directly+0x43/0xe0 [1.921819] blk_mq_try_issue_list_directly+0x3c/0xb0 [1.921840] blk_mq_sched_insert_requests+0xa0/0xf0 [1.921860] blk_mq_flush_plug_list+0x122/0x1e0 [1.921879] blk_flush_plug_list+0xc1/0xf0 [1.921897] blk_finish_plug+0x1c/0x29 [1.921914] read_pages+0x7a/0x140 [1.921931] __do_page_cache_readahead+0x188/0x1a0 [1.921952] force_page_cache_readahead+0x8b/0xf0 [1.921972] generic_file_read_iter+0x7e1/0xae0 [1.921993] ? mem_cgroup_throttle_swaprate+0x1f/0x145 [1.922014] ? _copy_to_user+0x26/0x30 [1.922031] ? cp_new_stat+0x127/0x160 [1.922048] new_sync_read+0x10f/0x1a0 [1.922064] vfs_read+0x8c/0x140 [1.922081] ksys_read+0x54/0xd0 [1.922098] do_syscall_64+0x49/0x130 [1.922114] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1.922138] RIP: 0033:0x7f771df43461 [1.922154] Code: fe ff ff 50 48 8d 3d fe d0 09 00 e8 e9 03 02 00 66 0f 1f 84 00 00 00 00 00 48 8d 05 99 62 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 41 54 49 89 d4 55 48 [1.95] RSP: 002b:7fffaae1a0c8 EFLAGS: 0246 ORIG_RAX: [1.922255] RAX: ffda RBX: 55d4cca138f0 RCX: 7f771df43461 [1.922284] RDX: 0040 RSI: 55d4cca164f8 RDI: 000c [1.922313] RBP: 55d4cca13940 R08: 55d4cca164d0 R09: 0005 [1.922342] R10: 55d4cc9fe010 R11: 0246 R12: 00013fff [1.922370] R13: 0040 R14: 55d4cca164e8 R15: 55d4cca164d0 [1.922398] Modules linked in: [1.922415] ---[ end trace baa27c3655b1ea59 ]--- [1.922435] RIP: 0010:__pv_queued_spin_lock_slowpath+0x195/0x2a0 [1.922459] Code: c4 c1 ea 12 4c 8d 6d 14 41 be 01 00 00 00 41 83 e4 03 8d 42 ff 49 c1 e4 05 48 98 49 81 c4 80 c3 02 00 4c 03 24 c5 20 89 b7 82 <49> 89 2c 24 b8 00 80 00 00 eb 15 84 c0 75 0a 41 0f b6 54 24 14 84 [1.922526] RSP: 0018:c9213958 EFLAGS: 00010002 [1.922545] RAX: 327f RBX: 888005ce00e0 RCX: 0001 [1.922574] RDX: 3280 RSI: RDI: [1.924268] RBP: 88801f52c380 R08: fffea95e R09: 8880192d0c80 [1.924302] R10: 8880192d0cb8 R11: c9213b01 R12: 000344a3feab7bf8 [1.924333] R13: 88801f52c394 R14: 0001 R15: 0008 [1.924377] FS: 7f771d762d40() GS:88801f50() knlGS: [1.924409] CS: 0010 DS: ES: CR0: 80050033 [1.924434] CR2: 7fffaae16ec8 CR3: 04b04000 CR4: 06e0 [1.924967] BUG: unable to handle page fault for address: 0013fff8 [1.924999] #PF: supervisor write access in kernel mode [1.925020] #PF: error_code(0x0002) - not-present page [1.925042] PGD 0 P4D 0 [1.925056] Oops: 0002 [#2] SMP NOPTI [1.925073] CPU: 1 PID: 1686 Comm: systemd-udevd T
Re: [Xen-devel] [PATCH] x86/cpuid: Untangle Invariant TSC handling
On 04/03/2020 09:33, Durrant, Paul wrote: >> -Original Message- >> From: Xen-devel On Behalf Of Andrew >> Cooper >> Sent: 03 March 2020 18:25 >> To: Xen-devel >> Cc: Wei Liu ; Andrew Cooper ; Jan >> Beulich ; >> Anthony PERARD ; Ian Jackson >> ; Roger Pau Monné >> >> Subject: [Xen-devel] [PATCH] x86/cpuid: Untangle Invariant TSC handling >> >> ITSC being visible to the guest is currently implicit with the toolstack >> unconditionally asking for it, and Xen clipping it based on the vTSC and/or >> XEN_DOMCTL_disable_migrate settings. >> >> This is problematic for several reasons. >> >> First, the implicit vTSC behaviour manifests as a real bug on migration to a >> host with a different frequency, with ITSC but without TSC scaling >> capabilities, whereby the ITSC feature becomes advertised to the guest. ITSC >> will disappear again if the guest migrates to server with the same frequency >> as the original, or to one with TSC scaling support. >> >> Secondly, disallowing ITSC unless the guest doesn't migrate is conceptually >> wrong. It is common to have migration pools of identical hardware, at which >> point the TSC frequency is the same, and more modern hardware has TSC scaling >> support anyway. In both cases, it is safe to advertise ITSC and migrate the >> guest. >> >> Remove all implicit logic logic in Xen, and make ITSC part of the max CPUID > One too many 'logic's there. Oops. > >> policies for guests. Plumb an itsc parameter into xc_cpuid_apply_policy() >> and >> have libxl__cpuid_legacy() fill in the two cases where it can reasonably >> expect ITSC to be safe for the guest to see. >> >> This is a behaviour change for TSC_MODE_NATIVE, where the ITSC will now >> reliably not appear, and for the case where the user explicitly requests >> ITSC, >> in which case it will appear even if the guest isn't marked as nomigrate. >> > Does this mean a guest that would have seen ITSC on 4.13 may now no longer > see it in 4.14 or is the TSC_MODE_NATIVE case just the one where the feature > may erroneously appear after migration? In general, guests don't get to see ITSC at all, even before this change. This is something which needs working on, but it is only a tractable problem in a multi-host toolstack. After this change, the TSC_MODE_NATIVE case will now not see a metastable ITSC feature depending on the properties of the host it happens to be on. It will default to consistently 0, unless overridden by the toolstack. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxenstat: fixed Makefile for building python-bindings
Am 04.03.20 um 11:31 schrieb Wei Liu:
> Hi Jonas
Hi Wei
> Thanks for this patch.
>
> On Mon, Mar 02, 2020 at 06:53:38PM +0100, jonas.li...@fem.tu-ilmenau.de wrote:
>> Fixes the libxenstat Makefile to determine the correct paths
>> of python includes when building python-bindings.
>> Also replaces the -lxenstat linking to correct object files
>> and use the libdir variable for installing.
>>
>> Signed-off-by: Jonas Licht
>> ---
>> tools/xenstat/libxenstat/Makefile | 11 +--
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/xenstat/libxenstat/Makefile
>> b/tools/xenstat/libxenstat/Makefile
>> index 03cb212e3b..4a02d2e563 100644
>> --- a/tools/xenstat/libxenstat/Makefile
>> +++ b/tools/xenstat/libxenstat/Makefile
>> @@ -114,18 +114,17 @@ $(BINDINGS): $(SHLIB) $(SHLIB_LINKS) src/xenstat.h
>> SWIG_FLAGS=-module xenstat -Isrc
>>
>> # Python bindings
>> -PYTHON_VERSION=$(PYTHON:python%=%)
>> -PYTHON_FLAGS=-I/usr/include/python$(PYTHON_VERSION)
>> -lpython$(PYTHON_VERSION)
>> +PYTHON_FLAGS=`$(PYTHON) -c 'import distutils.sysconfig; print("-I" +
> A better approach would be to use python-config here.
I'm not quite sure if I can require the python-config tool is installed.
As I see it's not checked by the configure.
I've seen some configure scripts, which has an extra fallback when
python-config is missing.
I was inspired by the m4/python_devel.m4 script too.
Best regards,
Jonas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
On 04.03.2020 17:31, Jürgen Groß wrote:
> On 04.03.20 16:19, Jan Beulich wrote:
>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>> On 04.03.20 12:32, Jan Beulich wrote:
On 26.02.2020 13:47, Juergen Gross wrote:
> +static void update_ept_param_append(const char *str, int val)
> +{
> +char *pos = opt_ept_setting + strlen(opt_ept_setting);
> +
> +snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
> + ",%s=%d", str, val);
> +}
> +
> +static void update_ept_param(void)
> +{
> +snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d",
> opt_ept_pml);
> +if ( opt_ept_ad >= 0 )
> +update_ept_param_append("ad", opt_ept_ad);
This won't correctly reflect reality: If you look at
vmx_init_vmcs_config(), even a negative value means "true" here,
unless on a specific Atom model. I think init_ept_param() wants
to have that erratum workaround logic moved there, such that
you can then assme the value to be non-negative here.
>>>
>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>> correct thing on the current hardware.
>>
>> Well, I think the output here should represent effective settings,
>
> The minimum requirement is to reflect the effective parameters, like
> cmdline is doing for boot-time only parameters. With runtime parameters
> we had no way of telling what was set, and this is now possible.
>
>> and a sub-item should be suppressed only if a setting has no effect
>> at all in the current setup, like ...
>>
> +if ( opt_ept_exec_sp >= 0 )
> +update_ept_param_append("exec-sp", opt_ept_exec_sp);
I agree for this one - if the value is still -1, it has neither
been set nor is its value of any interest.
>>
>> ... here.
>
> I think we should not mix up specified parameters and effective
> settings. In case an effective setting is of common interest it should
> be reported via a specific node (like e.g. specific mitigation settings
> where the cmdline is not providing enough details).
But then a boolean option that wasn't specified on the command line
should produce no output at all. And hence we'd need a way to tell
whether an option was set from command line for _all_ of them. I
don't think this would be very helpful.
I'm curious if anyone else has any opinion either way (or yet
another one) here:
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
On 04.03.20 16:19, Jan Beulich wrote:
On 04.03.2020 16:07, Jürgen Groß wrote:
On 04.03.20 12:32, Jan Beulich wrote:
On 26.02.2020 13:47, Juergen Gross wrote:
+static void update_ept_param_append(const char *str, int val)
+{
+char *pos = opt_ept_setting + strlen(opt_ept_setting);
+
+snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
+ ",%s=%d", str, val);
+}
+
+static void update_ept_param(void)
+{
+snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
+if ( opt_ept_ad >= 0 )
+update_ept_param_append("ad", opt_ept_ad);
This won't correctly reflect reality: If you look at
vmx_init_vmcs_config(), even a negative value means "true" here,
unless on a specific Atom model. I think init_ept_param() wants
to have that erratum workaround logic moved there, such that
you can then assme the value to be non-negative here.
But isn't not mentioning it in the -1 case correct? -1 means: do the
correct thing on the current hardware.
Well, I think the output here should represent effective settings,
The minimum requirement is to reflect the effective parameters, like
cmdline is doing for boot-time only parameters. With runtime parameters
we had no way of telling what was set, and this is now possible.
and a sub-item should be suppressed only if a setting has no effect
at all in the current setup, like ...
+if ( opt_ept_exec_sp >= 0 )
+update_ept_param_append("exec-sp", opt_ept_exec_sp);
I agree for this one - if the value is still -1, it has neither
been set nor is its value of any interest.
... here.
I think we should not mix up specified parameters and effective
settings. In case an effective setting is of common interest it should
be reported via a specific node (like e.g. specific mitigation settings
where the cmdline is not providing enough details).
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -85,8 +85,10 @@ struct grant_table {
struct grant_table_arch arch;
};
-static int parse_gnttab_limit(const char *param, const char *arg,
- unsigned int *valp)
+#define GRANT_CUSTOM_VAL_SZ 12
+
+static int parse_gnttab_limit(const char *arg, unsigned int *valp,
+ char *parval)
{
const char *e;
unsigned long val;
@@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const
char *arg,
return -ERANGE;
*valp = val;
+snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
return 0;
}
unsigned int __read_mostly opt_max_grant_frames = 64;
+static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
+
+static void __init gnttab_max_frames_init(struct param_hypfs *par)
+{
+custom_runtime_set_var(par, opt_max_grant_frames_val);
You still use a custom string buffer here. Can this "set-var"
operation record that the variable (for presentation purposes)
is simply of UINT type, handing a pointer to the actual
variable?
No, this would result in the need to set a custom parameter via a
binary value passed in from user land. So I'd need to convert this
binary into a string to be parseable by the custom function.
Hmm, not very fortunate, but I can see what you're saying.
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
return 0;
}
+int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+struct param_hypfs *p;
+char *buf;
+int ret;
+
+buf = xzalloc_array(char, ulen);
+if ( !buf )
+return -ENOMEM;
+
+ret = -EFAULT;
+if ( copy_from_guest(buf, uaddr, ulen) )
+goto out;
+
+ret = -EDOM;
+if ( !memchr(buf, 0, ulen) )
Once again " != buf + ulen - 1"? (EDOM also looks like an odd
error code to use in this case, but I guess there's no really
good one.)
" != buf + ulen - 1" is a logical choice with the change of patch 4.
I'm afraid I don't understand. You want to parse a string here.
The caller should tell you what the string length is (including
the nul again), not what its buffer size may be.
I agreed that changing to " != buf + ulen - 1" makes sense as I
agreed already to do so in patch 4.
@@ -79,41 +88,94 @@ extern const struct kernel_param __param_start[],
__param_end[];
.type = OPT_IGNORE }
#define __rtparam __param(__dataparam)
+#define __paramfs static __paramhypfs \
+__attribute__((__aligned__(sizeof(void * struct param_hypfs
-#define custom_runtime_only_param(_name, _var) \
+#define custom_runtime_set_var(parfs, var) \
+{ \
+(parfs)->hypfs.write_ptr = &(var); \
+(parfs)->hypfs.e.size = sizeof(var); \
All users of this use char[]. Why sizeof()
Re: [Xen-devel] [PATCH v5 1/2] docs/designs: Add a design document for non-cooperative live migration
> -Original Message-
> >>> +HVM guests can already be migrated on Xen without guest co-operation but
> >>> only
> >>> +if they don’t have PV drivers installed[1] or are in power state S3. The
> >>
> >> S3 is very ACPI centric, so I would prefer if we avoid the term. I think
> >> the non-ACPI description is "suspend to RAM". I would be OK is you
> >> mention S3 in parenthesis.
> >
> > I'm actually pulling this from the way the code is currently written, which
> > is clearly quite x86
> specific:
> >
> > xc_hvm_param_get(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, _s_state)
> > .
> > .
> > .
> > if (dsps->type == LIBXL_DOMAIN_TYPE_HVM && (!hvm_pvdrv || hvm_s_state)) {
> > LOGD(DEBUG, domid, "Calling xc_domain_shutdown on HVM domain");
> > ret = xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
> > .
> > .
> > }
> >
> > So actually I should say 'not in power state S0'.
>
> I understand that the current code is x86 specific. Arm would likely
> have a similar requirement although not based on ACPI.
>
> However, my point here is nothing in the document says it is focusing on
> x86 only. The concept itself is not arch specific, the document is
> mostly x86 free except in a couple of bits. So I would like them to be
> rewritten in an arch-agnostic way.
>
> Note that I am ok with arch-specific example.
>
Sure. I'll try not to be x86 specific where it's not necessary.
Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 21/23] xen/build: Use if_changed for prelink*.o
On 27.02.2020 14:16, Roger Pau Monné wrote: > On Wed, Feb 26, 2020 at 11:33:53AM +, Anthony PERARD wrote: >> We change the dependencies of prelink-efi.o so that we can use the >> same command line. The dependency on efi/built_in.o isn't needed >> because, we already have: >> efi/*.o: efi/built_in.o >> to build efi/*.o files that prelink-efi.o needs. >> >> Signed-off-by: Anthony PERARD > > Reviewed-by: Roger Pau Monné Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 19/23] xen/build: Use if_changed_rules with %.o:%.c targets
On 26.02.2020 12:33, Anthony PERARD wrote: > Use $(dot-target) to have the target name prefix with a dot. > > Now, when the CC command has run, it is recorded in .*.cmd > file, then if_changed_rules will compare it on subsequent runs. > > Signed-off-by: Anthony PERARD Reviewed-by: Jan Beulich with one question: > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -167,19 +167,27 @@ FORCE: > > SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR)) > > -%.o: %.c Makefile > +quiet_cmd_cc_o_c = CC $@ > ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y) > - $(CC) $(c_flags) -c $< -o $(@D)/.$(@F).tmp -MQ $@ > -ifeq ($(CONFIG_CC_IS_CLANG),y) > - $(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@ > -else > - $(OBJCOPY) --redefine-sym $( -endif > - rm -f $(@D)/.$(@F).tmp > +cmd_cc_o_c = $(CC) $(c_flags) -c $< -o $(dot-target).tmp -MQ $@ > +ifeq ($(CONFIG_CC_IS_CLANG),y) > +cmd_objcopy_fix_sym = $(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< > $(dot-target).tmp $@ > +else > +cmd_objcopy_fix_sym = $(OBJCOPY) --redefine-sym $( $(dot-target).tmp $@ > +endif > +cmd_objcopy_fix_sym += && rm -f $(dot-target).tmp > else > - $(CC) $(c_flags) -c $< -o $@ > +cmd_cc_o_c = $(CC) $(c_flags) -c $< -o $@ > endif > > +define rule_cc_o_c > +$(call cmd_and_record,cc_o_c) > +$(call cmd,objcopy_fix_sym) The machinery is resilient to a command (here: cmd_objcopy_fix_sym) not being defined, and will neither produce any undue output nor else incur any unnecessary overhead? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced
On Wed, Feb 19, 2020 at 3:25 AM Jan Beulich wrote: > > On 18.02.2020 22:45, Andrew Cooper wrote: > > On 18/02/2020 18:43, Jason Andryuk wrote: > >> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper > >> wrote: > >>> On 17/02/2020 20:41, Jason Andryuk wrote: > On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper > wrote: > > We have multiple bugs. > > > > First and foremost, Xen seems totally broken when running in ExtINT > > mode. This needs addressing, and ought to be sufficient to let Xen > > boot, at which point we can try to figure out why it is trying to fall > > back into 486(ish) compatibility mode. > >> Xen has "enabled ExtINT on CPU#0" while linux has "masked ExtINT on > >> CPU#0" so linux isn't using ExtINT? > > > > It would appear not. Even more concerningly, on my Kabylake box, > > > > # xl dmesg | grep ExtINT > > (XEN) enabled ExtINT on CPU#0 > > (XEN) masked ExtINT on CPU#1 > > (XEN) masked ExtINT on CPU#2 > > (XEN) masked ExtINT on CPU#3 > > (XEN) masked ExtINT on CPU#4 > > (XEN) masked ExtINT on CPU#5 > > (XEN) masked ExtINT on CPU#6 > > (XEN) masked ExtINT on CPU#7 > > > > which at first glance suggests that we have something asymmetric being > > set up. > > That's perfectly normal - ExtINT may be enabled on just one CPU, > and that's CPU0 in our case (until such time that we would want > to be able to offline CPU0). Thanks, Jan. Linux prints masked ExtINT for all 8 CPU threads. I inserted __print_IO_APIC() before the "IO-APIC + timer doesn't work" panic. Using vector-based indexing IRQ to ping mappings: IRQ240 -> 0:2 where Linux prints IRQ0 -> 0:2 That may just be the difference between Xen printing the Vector vs. Linux printing the IRQ number. Any pointers to what I should investigate? Regards, Jason ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced
> > >>> One other thing that might be noteworthy. Linux only prints ACPI IRQ0 > > >>> and IRQ9 used by override where Xen lists IRQ 0, 2 & 9. > > >> Huh - this is supposed to come directly from the ACPI tables, so Linux > > >> and Xen should be using the same source of information. Both Xen and Linux only see two ACPI overrides (0 & 9) from the tables. However the Xen logic in mp_config_acpi_legacy_irqs() thinks IRQ2 is an override irq 2: irq->mpc_srcbus 0, irq->mpc_srcbusirq 0, irq->mpc_dstapic 2, intsrc.mpc_dstapic 2 Matches ((irq->mpc_dstapic == intsrc.mpc_dstapic) && (irq->mpc_dstirq == i)) i is 2, so irq->mpc_dstirq must be as well. Regards, Jason ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 18/23] xen/build: use if_changed on built_in.o
On 26.02.2020 12:33, Anthony PERARD wrote: > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -126,14 +126,21 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk > c_flags += $(CFLAGS-y) > a_flags += $(CFLAGS-y) $(AFLAGS-y) > > -built_in.o: $(obj-y) $(extra-y) > +quiet_cmd_ld_builtin = LD $@ > +cmd_ld_builtin = \ > +$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) > +quiet_cmd_cc_builtin = LD $@ > +cmd_cc_builtin = \ > +$(CC) $(XEN_CFLAGS) -c -x c /dev/null -o $@ > + > +built_in.o: $(obj-y) $(extra-y) FORCE > ifeq ($(obj-y),) > - $(CC) $(c_flags) -c -x c /dev/null -o $@ > + $(call if_changed,cc_builtin) > else > ifeq ($(CONFIG_LTO),y) > $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^) What about this? Couldn't you simply vary what cmd_ld_builtin expands to, and drop this inner ifeq()? Jan > else > - $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^) > + $(call if_changed,ld_builtin) > endif > endif > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 17/23] xen/build: Start using if_changed
On 27.02.2020 14:09, Roger Pau Monné wrote: > On Wed, Feb 26, 2020 at 11:33:49AM +, Anthony PERARD wrote: >> @@ -161,29 +173,47 @@ else >> $(CC) $(c_flags) -c $< -o $@ >> endif >> >> -%.o: %.S Makefile >> -$(CC) $(a_flags) -c $< -o $@ >> +quiet_cmd_cc_o_S = CC $@ >> +cmd_cc_o_S = $(CC) $(a_flags) -c $< -o $@ >> + >> +%.o: %.S FORCE >> +$(call if_changed,cc_o_S) >> + >> + >> +quiet_cmd_obj_init_o = INIT_O $@ > > INIT_O seems kind of weird, maybe just using CHECK would be OK? CHECK is not expressing what's going on - one could/would imply that the object file doesn't get changed at all, but its sections get renamed. I think INIT_O is sufficiently expressive at least to people knowing the build system. > The rest LGTM: > > Reviewed-by: Roger Pau Monné 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 v2 1/4] qapi: net: Add query-netdevs command
On 04/03/2020 14:06, Alexey Kirillov wrote:
> Add a qmp command that provides information about currently attached
> network devices and their configuration.
>
> Signed-off-by: Alexey Kirillov
> ---
> include/net/net.h | 1 +
> net/hub.c | 8 +++
> net/l2tpv3.c | 19 +++
> net/net.c | 91 +
> net/netmap.c | 13 +
> net/slirp.c | 126 ++
> net/socket.c | 71 ++
> net/tap-win32.c | 9
> net/tap.c | 103 +++--
> net/vde.c | 26 ++
> net/vhost-user.c | 18 +--
> qapi/net.json | 89
> 12 files changed, 566 insertions(+), 8 deletions(-)
>
...
> diff --git a/net/net.c b/net/net.c
> index 9e93c3f8a1..01e0548295 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -54,6 +54,7 @@
> #include "sysemu/sysemu.h"
> #include "net/filter.h"
> #include "qapi/string-output-visitor.h"
> +#include "qapi/clone-visitor.h"
>
> /* Net bridge is currently not supported for W32. */
> #if !defined(_WIN32)
> @@ -128,6 +129,12 @@ char *qemu_mac_strdup_printf(const uint8_t *macaddr)
>
> void qemu_format_nic_info_str(NetClientState *nc, uint8_t macaddr[6])
> {
> +g_assert(nc->stored_config);
> +
> +g_free(nc->stored_config->u.nic.macaddr);
> +nc->stored_config->u.nic.macaddr = g_strdup_printf(MAC_FMT,
> + MAC_ARG(macaddr));
> +
Why do you use this rather than the qemu_mac_strdup_printf() function
defined above?
qemu_mac_strdup_printf():
890ee6abb385 ("net: add MAC address string printer")
MAC_FMT/MAC_ARG:
6d1d4939a647 ("net: Add macros for MAC address tracing")
MAC_FMT/MAC_ARG seems to be reserved for tracing.
Thanks,
Laurent
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 16/23] xen/build: introduce if_changed and if_changed_rule
On 26.02.2020 12:33, Anthony PERARD wrote:
> The if_changed macro from Linux can record the command used to build a
> target then compare it on rebuild. Thus if a command has changed, for
> example due to introducing new flags in CFLAGS or due to using a
> different compiler, the target will be rebuilt.
As to using a different compiler - I suppose this means "a compiler
with a different executable name" here? What about me having, say
gcc-5 in use, and then updating my system such that a 5.2 based
compiler of this name would be upgraded to a 5.4 based one of this
same name. If this newer compiler has better capabilities (that we
would want to use if available), would this or anything else trigger
a rebuild then too?
> --- a/.gitignore
> +++ b/.gitignore
> @@ -6,6 +6,7 @@
> *.o
> *.d
> *.d2
> +.*.cmd
> *.opic
> *.a
> *.so
I admit these entries aren't sorted very well, but anyway - how
did you end up with this insertion point? There are entries
starting with . at the very top of the file. (As an aside, I
wonder why it's *.d and *.d2 rather than .*.d and .*.d2 .)
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -52,7 +52,57 @@ dist: install
>
> ifeq ($(root-make-done),)
> # section to run before calling Rules.mk, but only once.
> +
> +# Beautify output
> +# ---
> +#
> +# Normally, we echo the whole command before executing it. By making
> +# that echo $($(quiet)$(cmd)), we now have the possibility to set
> +# $(quiet) to choose other forms of output instead, e.g.
> +#
> +# quiet_cmd_cc_o_c = Compiling $(RELDIR)/$@
> +# cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
> +#
> +# If $(quiet) is empty, the whole command will be printed.
> +# If it is set to "quiet_", only the short version will be printed.
> +# If it is set to "silent_", nothing will be printed at all, since
> +# the variable $(silent_cmd_cc_o_c) doesn't exist.
> +#
> +# A simple variant is to prefix commands with $(Q) - that's useful
> +# for commands that shall be hidden in non-verbose mode.
> #
> +#$(Q)ln $@ :<
> +#
> +# If KBUILD_VERBOSE equals 0 then the above command will be hidden.
> +# If KBUILD_VERBOSE equals 1 then the above command is displayed.
> +#
> +# To put more focus on warnings, be less verbose as default
> +# Use 'make V=1' to see the full commands
> +
> +ifeq ("$(origin V)", "command line")
> + KBUILD_VERBOSE = $(V)
> +endif
> +ifndef KBUILD_VERBOSE
> + KBUILD_VERBOSE = 0
> +endif
> +
> +ifeq ($(KBUILD_VERBOSE),1)
> + quiet =
> + Q =
> +else
> + quiet=quiet_
> + Q = @
> +endif
> +
> +# If the user is running make -s (silent mode), suppress echoing of
> +# commands
> +
> +ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
> + quiet=silent_
> +endif
Throughout the above, can the uses of = please become consistent?
Preferable all with a blank on the left and - unless there's no
value getting assigned - one on the right, plus := preferred over
= where not prohibited by other constraints (none here afaics).
> --- a/xen/scripts/Kbuild.include
> +++ b/xen/scripts/Kbuild.include
> @@ -2,11 +2,30 @@
>
> # kbuild: Generic definitions
>
> +# Convenient variables
> +squote := '
> +empty :=
> +space := $(empty) $(empty)
> +space_escape := _-_SPACE_-_
> +pound := \#
Nit: To fit with the three ones above space_escape you want to
add two blanks here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 1/2] docs/designs: Add a design document for non-cooperative live migration
> -Original Message-
> From: Xen-devel On Behalf Of Julien
> Grall
> Sent: 04 March 2020 15:11
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian Jackson ; Jan
> Beulich
> Subject: Re: [Xen-devel] [PATCH v5 1/2] docs/designs: Add a design document
> for non-cooperative live
> migration
>
> Hi Paul,
>
> The proposal looks sensible to me. Some NITpicking below.
>
> On 13/02/2020 10:53, Paul Durrant wrote:
> > It has become apparent to some large cloud providers that the current
> > model of cooperative migration of guests under Xen is not usable as it
> > relies on software running inside the guest, which is likely beyond the
> > provider's control.
> > This patch introduces a proposal for non-cooperative live migration,
> > designed not to rely on any guest-side software.
> >
> > Signed-off-by: Paul Durrant
> > ---
> > Cc: Andrew Cooper
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Jan Beulich
> > Cc: Julien Grall
> > Cc: Konrad Rzeszutek Wilk
> > Cc: Stefano Stabellini
> > Cc: Wei Liu
> >
> > v5:
> > - Note that PV domain are not just expected to co-operate, they are
> > required to
> >
> > v4:
> > - Fix issues raised by Wei
> >
> > v2:
> > - Use the term 'non-cooperative' instead of 'transparent'
> > - Replace 'trust in' with 'reliance on' when referring to guest-side
> > software
> > ---
> > docs/designs/non-cooperative-migration.md | 272 ++
> > 1 file changed, 272 insertions(+)
> > create mode 100644 docs/designs/non-cooperative-migration.md
> >
> > diff --git a/docs/designs/non-cooperative-migration.md
> > b/docs/designs/non-cooperative-migration.md
> > new file mode 100644
> > index 00..09f74c8c0d
> > --- /dev/null
> > +++ b/docs/designs/non-cooperative-migration.md
> > @@ -0,0 +1,272 @@
> > +# Non-Cooperative Migration of Guests on Xen
> > +
> > +## Background
> > +
> > +The normal model of migration in Xen is driven by the guest because it was
> > +originally implemented for PV guests, where the guest must be aware it is
> > +running under Xen and is hence expected to co-operate. This model dates
> > from
> > +an era when it was assumed that the host administrator had control of at
> > least
> > +the privileged software running in the guest (i.e. the guest kernel) which
> > may
> > +still be true in an enterprise deployment but is not generally true in a
> > cloud
> > +environment. The aim of this design is to provide a model which is purely
> > host
> > +driven, requiring no co-operation from the software running in the
> > +guest, and is thus suitable for cloud scenarios.
> > +
> > +PV guests are out of scope for this project because, as is outlined above,
> > they
> > +have a symbiotic relationship with the hypervisor and therefore a certain
> > level
> > +of co-operation is required.
> > +
> > +HVM guests can already be migrated on Xen without guest co-operation but
> > only
> > +if they don’t have PV drivers installed[1] or are in power state S3. The
>
> S3 is very ACPI centric, so I would prefer if we avoid the term. I think
> the non-ACPI description is "suspend to RAM". I would be OK is you
> mention S3 in parenthesis.
I'm actually pulling this from the way the code is currently written, which is
clearly quite x86 specific:
xc_hvm_param_get(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, _s_state)
.
.
.
if (dsps->type == LIBXL_DOMAIN_TYPE_HVM && (!hvm_pvdrv || hvm_s_state)) {
LOGD(DEBUG, domid, "Calling xc_domain_shutdown on HVM domain");
ret = xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
.
.
}
So actually I should say 'not in power state S0'.
>
> > +reason for not expecting co-operation if the guest is in S3 is obvious,
> > but the
> > +reason co-operation is expected if PV drivers are installed is due to the
> > +nature of PV protocols.
> > +
> > +## Xenstore Nodes and Domain ID
> > +
> > +The PV driver model consists of a *frontend* and a *backend*. The frontend
> > runs
> > +inside the guest domain and the backend runs inside a *service domain*
> > which
> > +may or may not be domain 0. The frontend and backend typically pass data
> > via
> > +memory pages which are shared between the two domains, but this channel of
> > +communication is generally established using xenstore (the store protocol
> > +itself being an exception to this for obvious chicken-and-egg reasons).
> > +
> > +Typical protocol establishment is based on use of two separate xenstore
> > +*areas*. If we consider PV drivers for the *netif* protocol (i.e. class
> > vif)
> > +and assume the guest has domid X, the service domain has domid Y, and the
> > vif
> > +has index Z then the frontend area will reside under the parent node:
> > +
> > +`/local/domain/Y/device/vif/Z`
> > +
> > +All backends, by convention, typically reside under parent node:
> > +
> > +`/local/domain/X/backend`
> > +
> > +and
Re: [Xen-devel] [PATCH v2 4/4] net: Remove field info_str of NetClientState
On 04/03/2020 14:06, Alexey Kirillov wrote: > Completely remove the info_str field of struct NetClientState because > it is no longer required due to the addition of the QMP query-netdevs command. > > Signed-off-by: Alexey Kirillov > --- > hw/net/allwinner_emac.c | 2 +- > hw/net/dp8393x.c| 2 +- > hw/net/e1000.c | 4 ++-- > hw/net/e1000e.c | 2 +- > hw/net/e1000e_core.c| 2 +- > hw/net/e1000x_common.c | 2 +- > hw/net/eepro100.c | 5 +++-- > hw/net/etraxfs_eth.c| 2 +- > hw/net/fsl_etsec/etsec.c| 2 +- > hw/net/ftgmac100.c | 2 +- > hw/net/i82596.c | 6 +++--- > hw/net/imx_fec.c| 2 +- > hw/net/lan9118.c| 4 ++-- > hw/net/mcf_fec.c| 2 +- > hw/net/milkymist-minimac2.c | 2 +- > hw/net/mipsnet.c| 2 +- > hw/net/ne2000-isa.c | 2 +- > hw/net/ne2000-pci.c | 2 +- > hw/net/pcnet.c | 2 +- > hw/net/rocker/rocker_fp.c | 4 ++-- > hw/net/rtl8139.c| 6 +++--- > hw/net/smc91c111.c | 2 +- > hw/net/spapr_llan.c | 6 +++--- > hw/net/stellaris_enet.c | 2 +- > hw/net/sungem.c | 4 ++-- > hw/net/sunhme.c | 2 +- > hw/net/tulip.c | 2 +- > hw/net/virtio-net.c | 8 > hw/net/vmxnet3.c| 4 ++-- > hw/net/xen_nic.c| 4 > hw/net/xgmac.c | 2 +- > hw/net/xilinx_axienet.c | 2 +- > hw/net/xilinx_ethlite.c | 2 +- > hw/usb/dev-network.c| 2 +- > include/net/net.h | 3 +-- > net/l2tpv3.c| 3 --- > net/net.c | 8 +--- > net/slirp.c | 4 > net/socket.c| 24 > net/tap.c | 12 > net/vde.c | 4 > net/vhost-user.c| 2 -- > 42 files changed, 51 insertions(+), 110 deletions(-) > Reviewed-by: Laurent Vivier Tested-by: Laurent Vivier ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] misc: Replace zero-length arrays with flexible array member (manual)
Description copied from Linux kernel commit from Gustavo A. R. Silva
(see [3]):
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these ones is a flexible
array member [1], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler
warning in case the flexible array does not occur last in the
structure, which will help us prevent some kind of undefined
behavior bugs from being unadvertenly introduced [2] to the
Linux codebase from now on.
--^-- description end --^--
Do the similar housekeeping in the QEMU codebase (which uses
C99 since commit 7be41675f7cb).
All these instances of code were found with the help of the
following command (then manual analysis, without modifying
structures only having a single flexible array member, such
QEDTable in block/qed.h):
git grep -F '[0];'
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1
Inspired-by: Gustavo A. R. Silva
Reviewed-by: David Hildenbrand
Signed-off-by: Philippe Mathieu-Daudé
---
v2: Do not modify block/qed.h:
block/qed.h:106:14: error: flexible array member 'offsets' not allowed in
otherwise empty struct
uint64_t offsets[]; /* in bytes */
^
---
docs/interop/vhost-user.rst | 4 ++--
include/hw/acpi/acpi-defs.h | 4 ++--
include/hw/boards.h | 2 +-
include/hw/s390x/event-facility.h | 2 +-
include/hw/s390x/sclp.h | 8
block/vmdk.c | 2 +-
hw/char/sclpconsole-lm.c | 2 +-
hw/char/sclpconsole.c | 2 +-
hw/s390x/virtio-ccw.c | 2 +-
target/s390x/ioinst.c | 2 +-
10 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 401652397c..3b1b6602c7 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -568,7 +568,7 @@ For split virtqueue, queue region can be implemented as:
uint16_t used_idx;
/* Used to track the state of each descriptor in descriptor table */
- DescStateSplit desc[0];
+ DescStateSplit desc[];
} QueueRegionSplit;
To track inflight I/O, the queue region should be processed as follows:
@@ -690,7 +690,7 @@ For packed virtqueue, queue region can be implemented as:
uint8_t padding[7];
/* Used to track the state of each descriptor fetched from descriptor
ring */
- DescStatePacked desc[0];
+ DescStatePacked desc[];
} QueueRegionPacked;
To track inflight I/O, the queue region should be processed as follows:
diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 19f7ba7b70..c13327fa78 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -152,7 +152,7 @@ typedef struct AcpiSerialPortConsoleRedirection
*/
struct AcpiRsdtDescriptorRev1 {
ACPI_TABLE_HEADER_DEF /* ACPI common table header */
-uint32_t table_offset_entry[0]; /* Array of pointers to other */
+uint32_t table_offset_entry[]; /* Array of pointers to other */
/* ACPI tables */
} QEMU_PACKED;
typedef struct AcpiRsdtDescriptorRev1 AcpiRsdtDescriptorRev1;
@@ -162,7 +162,7 @@ typedef struct AcpiRsdtDescriptorRev1
AcpiRsdtDescriptorRev1;
*/
struct AcpiXsdtDescriptorRev2 {
ACPI_TABLE_HEADER_DEF /* ACPI common table header */
-uint64_t table_offset_entry[0]; /* Array of pointers to other */
+uint64_t table_offset_entry[]; /* Array of pointers to other */
/* ACPI tables */
} QEMU_PACKED;
typedef struct AcpiXsdtDescriptorRev2 AcpiXsdtDescriptorRev2;
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 9bc42dfb22..c96120d15f 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -71,7 +71,7 @@ typedef struct CPUArchId {
*/
typedef struct {
int len;
-CPUArchId cpus[0];
+CPUArchId cpus[];
} CPUArchIdList;
/**
diff --git a/include/hw/s390x/event-facility.h
b/include/hw/s390x/event-facility.h
index bdc32a3c09..700a610f33 100644
--- a/include/hw/s390x/event-facility.h
+++ b/include/hw/s390x/event-facility.h
@@ -122,7 +122,7 @@ typedef struct MDBO {
typedef struct MDB {
MdbHeader header;
-MDBO mdbo[0];
+MDBO mdbo[];
} QEMU_PACKED MDB;
typedef struct SclpMsg {
diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h
index c54413b78c..cd7b24359f 100644
--- a/include/hw/s390x/sclp.h
+++ b/include/hw/s390x/sclp.h
@@ -132,7 +132,7 @@ typedef struct ReadInfo {
uint16_t highest_cpu;
uint8_t _reserved5[124 - 122]; /* 122-123 */
uint32_t hmfai;
-struct CPUEntry entries[0];
+
[Xen-devel] [PATCH v2 1/2] misc: Replace zero-length arrays with flexible array member (automatic)
Description copied from Linux kernel commit from Gustavo A. R. Silva
(see [3]):
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these ones is a flexible
array member [1], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler
warning in case the flexible array does not occur last in the
structure, which will help us prevent some kind of undefined
behavior bugs from being unadvertenly introduced [2] to the
Linux codebase from now on.
--^-- description end --^--
Do the similar housekeeping in the QEMU codebase (which uses
C99 since commit 7be41675f7cb).
All these instances of code were found with the help of the
following Coccinelle script:
@@
identifier s, m, a;
type t, T;
@@
struct s {
...
t m;
- T a[0];
+ T a[];
};
@@
identifier s, m, a;
type t, T;
@@
struct s {
...
t m;
- T a[0];
+ T a[];
} QEMU_PACKED;
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1
Inspired-by: Gustavo A. R. Silva
Reviewed-by: David Hildenbrand
Signed-off-by: Philippe Mathieu-Daudé
---
v2: cocci script updated to not match structures of onlyi
a single flexible array member:
block/qed.h:106:14: error: flexible array member 'offsets' not allowed in
otherwise empty struct
uint64_t offsets[]; /* in bytes */
^
---
bsd-user/qemu.h | 2 +-
contrib/libvhost-user/libvhost-user.h | 2 +-
hw/m68k/bootinfo.h| 2 +-
hw/scsi/srp.h | 6 +++---
hw/xen/xen_pt.h | 2 +-
include/hw/acpi/acpi-defs.h | 12 ++--
include/hw/arm/smmu-common.h | 2 +-
include/hw/i386/intel_iommu.h | 3 ++-
include/hw/virtio/virtio-iommu.h | 2 +-
include/sysemu/cryptodev.h| 2 +-
include/tcg/tcg.h | 2 +-
pc-bios/s390-ccw/bootmap.h| 2 +-
pc-bios/s390-ccw/sclp.h | 2 +-
tests/qtest/libqos/ahci.h | 2 +-
block/linux-aio.c | 2 +-
hw/acpi/nvdimm.c | 6 +++---
hw/dma/soc_dma.c | 2 +-
hw/i386/x86.c | 2 +-
hw/misc/omap_l4.c | 2 +-
hw/nvram/eeprom93xx.c | 2 +-
hw/rdma/vmw/pvrdma_qp_ops.c | 4 ++--
hw/usb/dev-network.c | 2 +-
hw/usb/dev-smartcard-reader.c | 4 ++--
hw/virtio/virtio.c| 4 ++--
net/queue.c | 2 +-
25 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 09e8aed9c7..f8bb1e5459 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -95,7 +95,7 @@ typedef struct TaskState {
struct sigqueue *first_free; /* first free siginfo queue entry */
int signal_pending; /* non zero if a signal may be pending */
-uint8_t stack[0];
+uint8_t stack[];
} __attribute__((aligned(16))) TaskState;
void init_task_state(TaskState *ts);
diff --git a/contrib/libvhost-user/libvhost-user.h
b/contrib/libvhost-user/libvhost-user.h
index 6fc8000e99..f30394fab6 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -286,7 +286,7 @@ typedef struct VuVirtqInflight {
uint16_t used_idx;
/* Used to track the state of each descriptor in descriptor table */
-VuDescStateSplit desc[0];
+VuDescStateSplit desc[];
} VuVirtqInflight;
typedef struct VuVirtqInflightDesc {
diff --git a/hw/m68k/bootinfo.h b/hw/m68k/bootinfo.h
index 5f8ded2686..c954270aad 100644
--- a/hw/m68k/bootinfo.h
+++ b/hw/m68k/bootinfo.h
@@ -14,7 +14,7 @@
struct bi_record {
uint16_t tag;/* tag ID */
uint16_t size; /* size of record */
-uint32_t data[0];/* data */
+uint32_t data[]; /* data */
};
/* machine independent tags */
diff --git a/hw/scsi/srp.h b/hw/scsi/srp.h
index d27f31d2d5..54c954badd 100644
--- a/hw/scsi/srp.h
+++ b/hw/scsi/srp.h
@@ -112,7 +112,7 @@ struct srp_direct_buf {
struct srp_indirect_buf {
struct srp_direct_buftable_desc;
uint32_t len;
-struct srp_direct_bufdesc_list[0];
+struct srp_direct_bufdesc_list[];
} QEMU_PACKED;
enum {
@@ -211,7 +211,7 @@ struct srp_cmd {
uint8_treserved4;
uint8_tadd_cdb_len;
uint8_tcdb[16];
-uint8_tadd_data[0];
+uint8_tadd_data[];
} QEMU_PACKED;
enum {
@@ -241,7 +241,7 @@ struct srp_rsp {
uint32_t data_in_res_cnt;
uint32_t
[Xen-devel] [PATCH v2 0/2] misc: Replace zero-length arrays with flexible array member
v2:
- do not modify qed.h (structure with single member)
- based on hw/scsi/spapr_vscsi fix series:
https://mid.mail-archive.com/20200304153311.22959-1-philmd@redhat.com
This is a tree-wide cleanup inspired by a Linux kernel commit
(from Gustavo A. R. Silva).
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these ones is a flexible
array member [1], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler
warning in case the flexible array does not occur last in the
structure, which will help us prevent some kind of undefined
behavior bugs from being unadvertenly introduced [2] to the
Linux codebase from now on.
--^-- description end --^--
Do the similar housekeeping in the QEMU codebase (which uses
C99 since commit 7be41675f7cb).
The first patch is done with the help of a coccinelle semantic
patch. However Coccinelle does not recognize:
struct foo {
int stuff;
struct boo array[];
} QEMU_PACKED;
but does recognize:
struct QEMU_PACKED foo {
int stuff;
struct boo array[];
};
I'm not sure why, neither it is worth refactoring all QEMU
structures to use the attributes before the structure name,
so I did the 2nd patch manually.
Anyway this is annoying, because many structures are not handled
by coccinelle. Maybe this needs to be reported to upstream
coccinelle?
I used spatch 1.0.8 with:
-I include --include-headers \
--macro-file scripts/cocci-macro-file.h \
--keep-comments --indent 4
Regards,
Phil.
Based-on: <20200304153311.22959-1-phi...@redhat.com>
Supersedes: <20200304005105.27454-1-phi...@redhat.com>
Philippe Mathieu-Daudé (2):
misc: Replace zero-length arrays with flexible array member
(automatic)
misc: Replace zero-length arrays with flexible array member (manual)
docs/interop/vhost-user.rst | 4 ++--
bsd-user/qemu.h | 2 +-
contrib/libvhost-user/libvhost-user.h | 2 +-
hw/m68k/bootinfo.h| 2 +-
hw/scsi/srp.h | 6 +++---
hw/xen/xen_pt.h | 2 +-
include/hw/acpi/acpi-defs.h | 16
include/hw/arm/smmu-common.h | 2 +-
include/hw/boards.h | 2 +-
include/hw/i386/intel_iommu.h | 3 ++-
include/hw/s390x/event-facility.h | 2 +-
include/hw/s390x/sclp.h | 8
include/hw/virtio/virtio-iommu.h | 2 +-
include/sysemu/cryptodev.h| 2 +-
include/tcg/tcg.h | 2 +-
pc-bios/s390-ccw/bootmap.h| 2 +-
pc-bios/s390-ccw/sclp.h | 2 +-
tests/qtest/libqos/ahci.h | 2 +-
block/linux-aio.c | 2 +-
block/vmdk.c | 2 +-
hw/acpi/nvdimm.c | 6 +++---
hw/char/sclpconsole-lm.c | 2 +-
hw/char/sclpconsole.c | 2 +-
hw/dma/soc_dma.c | 2 +-
hw/i386/x86.c | 2 +-
hw/misc/omap_l4.c | 2 +-
hw/nvram/eeprom93xx.c | 2 +-
hw/rdma/vmw/pvrdma_qp_ops.c | 4 ++--
hw/s390x/virtio-ccw.c | 2 +-
hw/usb/dev-network.c | 2 +-
hw/usb/dev-smartcard-reader.c | 4 ++--
hw/virtio/virtio.c| 4 ++--
net/queue.c | 2 +-
target/s390x/ioinst.c | 2 +-
34 files changed, 53 insertions(+), 52 deletions(-)
--
2.21.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] misc: Replace zero-length arrays with flexible array member
On 3/4/20 4:35 PM, Philippe Mathieu-Daudé wrote: v2: - do not modify qed.h (structure with single member) - based on hw/scsi/spapr_vscsi fix series This is a tree-wide cleanup inspired by a Linux kernel commit (from Gustavo A. R. Silva). Please ignore, for some reason the 'v2' tag is missing. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 1/2] docs/designs: Add a design document for non-cooperative live migration
Hi Paul,
On 04/03/2020 15:23, Durrant, Paul wrote:
-Original Message-
From: Xen-devel On Behalf Of Julien
Grall
Sent: 04 March 2020 15:11
To: Durrant, Paul ; xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ; Wei Liu ; Konrad
Rzeszutek Wilk
; George Dunlap ; Andrew
Cooper
; Ian Jackson ; Jan Beulich
Subject: Re: [Xen-devel] [PATCH v5 1/2] docs/designs: Add a design document for
non-cooperative live
migration
Hi Paul,
The proposal looks sensible to me. Some NITpicking below.
On 13/02/2020 10:53, Paul Durrant wrote:
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's control.
This patch introduces a proposal for non-cooperative live migration,
designed not to rely on any guest-side software.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Wei Liu
v5:
- Note that PV domain are not just expected to co-operate, they are
required to
v4:
- Fix issues raised by Wei
v2:
- Use the term 'non-cooperative' instead of 'transparent'
- Replace 'trust in' with 'reliance on' when referring to guest-side
software
---
docs/designs/non-cooperative-migration.md | 272 ++
1 file changed, 272 insertions(+)
create mode 100644 docs/designs/non-cooperative-migration.md
diff --git a/docs/designs/non-cooperative-migration.md
b/docs/designs/non-cooperative-migration.md
new file mode 100644
index 00..09f74c8c0d
--- /dev/null
+++ b/docs/designs/non-cooperative-migration.md
@@ -0,0 +1,272 @@
+# Non-Cooperative Migration of Guests on Xen
+
+## Background
+
+The normal model of migration in Xen is driven by the guest because it was
+originally implemented for PV guests, where the guest must be aware it is
+running under Xen and is hence expected to co-operate. This model dates from
+an era when it was assumed that the host administrator had control of at least
+the privileged software running in the guest (i.e. the guest kernel) which may
+still be true in an enterprise deployment but is not generally true in a cloud
+environment. The aim of this design is to provide a model which is purely host
+driven, requiring no co-operation from the software running in the
+guest, and is thus suitable for cloud scenarios.
+
+PV guests are out of scope for this project because, as is outlined above, they
+have a symbiotic relationship with the hypervisor and therefore a certain level
+of co-operation is required.
+
+HVM guests can already be migrated on Xen without guest co-operation but only
+if they don’t have PV drivers installed[1] or are in power state S3. The
S3 is very ACPI centric, so I would prefer if we avoid the term. I think
the non-ACPI description is "suspend to RAM". I would be OK is you
mention S3 in parenthesis.
I'm actually pulling this from the way the code is currently written, which is
clearly quite x86 specific:
xc_hvm_param_get(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, _s_state)
.
.
.
if (dsps->type == LIBXL_DOMAIN_TYPE_HVM && (!hvm_pvdrv || hvm_s_state)) {
LOGD(DEBUG, domid, "Calling xc_domain_shutdown on HVM domain");
ret = xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
.
.
}
So actually I should say 'not in power state S0'.
I understand that the current code is x86 specific. Arm would likely
have a similar requirement although not based on ACPI.
However, my point here is nothing in the document says it is focusing on
x86 only. The concept itself is not arch specific, the document is
mostly x86 free except in a couple of bits. So I would like them to be
rewritten in an arch-agnostic way.
Note that I am ok with arch-specific example.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] misc: Replace zero-length arrays with flexible array member (automatic)
Description copied from Linux kernel commit from Gustavo A. R. Silva
(see [3]):
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these ones is a flexible
array member [1], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler
warning in case the flexible array does not occur last in the
structure, which will help us prevent some kind of undefined
behavior bugs from being unadvertenly introduced [2] to the
Linux codebase from now on.
--^-- description end --^--
Do the similar housekeeping in the QEMU codebase (which uses
C99 since commit 7be41675f7cb).
All these instances of code were found with the help of the
following Coccinelle script:
@@
identifier s, m, a;
type t, T;
@@
struct s {
...
t m;
- T a[0];
+ T a[];
};
@@
identifier s, m, a;
type t, T;
@@
struct s {
...
t m;
- T a[0];
+ T a[];
} QEMU_PACKED;
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1
Inspired-by: Gustavo A. R. Silva
Reviewed-by: David Hildenbrand
Signed-off-by: Philippe Mathieu-Daudé
---
v2: cocci script updated to not match structures of onlyi
a single flexible array member:
block/qed.h:106:14: error: flexible array member 'offsets' not allowed in
otherwise empty struct
uint64_t offsets[]; /* in bytes */
^
---
bsd-user/qemu.h | 2 +-
contrib/libvhost-user/libvhost-user.h | 2 +-
hw/m68k/bootinfo.h| 2 +-
hw/scsi/srp.h | 6 +++---
hw/xen/xen_pt.h | 2 +-
include/hw/acpi/acpi-defs.h | 12 ++--
include/hw/arm/smmu-common.h | 2 +-
include/hw/i386/intel_iommu.h | 3 ++-
include/hw/virtio/virtio-iommu.h | 2 +-
include/sysemu/cryptodev.h| 2 +-
include/tcg/tcg.h | 2 +-
pc-bios/s390-ccw/bootmap.h| 2 +-
pc-bios/s390-ccw/sclp.h | 2 +-
tests/qtest/libqos/ahci.h | 2 +-
block/linux-aio.c | 2 +-
hw/acpi/nvdimm.c | 6 +++---
hw/dma/soc_dma.c | 2 +-
hw/i386/x86.c | 2 +-
hw/misc/omap_l4.c | 2 +-
hw/nvram/eeprom93xx.c | 2 +-
hw/rdma/vmw/pvrdma_qp_ops.c | 4 ++--
hw/usb/dev-network.c | 2 +-
hw/usb/dev-smartcard-reader.c | 4 ++--
hw/virtio/virtio.c| 4 ++--
net/queue.c | 2 +-
25 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 09e8aed9c7..f8bb1e5459 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -95,7 +95,7 @@ typedef struct TaskState {
struct sigqueue *first_free; /* first free siginfo queue entry */
int signal_pending; /* non zero if a signal may be pending */
-uint8_t stack[0];
+uint8_t stack[];
} __attribute__((aligned(16))) TaskState;
void init_task_state(TaskState *ts);
diff --git a/contrib/libvhost-user/libvhost-user.h
b/contrib/libvhost-user/libvhost-user.h
index 6fc8000e99..f30394fab6 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -286,7 +286,7 @@ typedef struct VuVirtqInflight {
uint16_t used_idx;
/* Used to track the state of each descriptor in descriptor table */
-VuDescStateSplit desc[0];
+VuDescStateSplit desc[];
} VuVirtqInflight;
typedef struct VuVirtqInflightDesc {
diff --git a/hw/m68k/bootinfo.h b/hw/m68k/bootinfo.h
index 5f8ded2686..c954270aad 100644
--- a/hw/m68k/bootinfo.h
+++ b/hw/m68k/bootinfo.h
@@ -14,7 +14,7 @@
struct bi_record {
uint16_t tag;/* tag ID */
uint16_t size; /* size of record */
-uint32_t data[0];/* data */
+uint32_t data[]; /* data */
};
/* machine independent tags */
diff --git a/hw/scsi/srp.h b/hw/scsi/srp.h
index d27f31d2d5..54c954badd 100644
--- a/hw/scsi/srp.h
+++ b/hw/scsi/srp.h
@@ -112,7 +112,7 @@ struct srp_direct_buf {
struct srp_indirect_buf {
struct srp_direct_buftable_desc;
uint32_t len;
-struct srp_direct_bufdesc_list[0];
+struct srp_direct_bufdesc_list[];
} QEMU_PACKED;
enum {
@@ -211,7 +211,7 @@ struct srp_cmd {
uint8_treserved4;
uint8_tadd_cdb_len;
uint8_tcdb[16];
-uint8_tadd_data[0];
+uint8_tadd_data[];
} QEMU_PACKED;
enum {
@@ -241,7 +241,7 @@ struct srp_rsp {
uint32_t data_in_res_cnt;
uint32_t
[Xen-devel] [PATCH 0/2] misc: Replace zero-length arrays with flexible array member
v2:
- do not modify qed.h (structure with single member)
- based on hw/scsi/spapr_vscsi fix series
This is a tree-wide cleanup inspired by a Linux kernel commit
(from Gustavo A. R. Silva).
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these ones is a flexible
array member [1], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler
warning in case the flexible array does not occur last in the
structure, which will help us prevent some kind of undefined
behavior bugs from being unadvertenly introduced [2] to the
Linux codebase from now on.
--^-- description end --^--
Do the similar housekeeping in the QEMU codebase (which uses
C99 since commit 7be41675f7cb).
The first patch is done with the help of a coccinelle semantic
patch. However Coccinelle does not recognize:
struct foo {
int stuff;
struct boo array[];
} QEMU_PACKED;
but does recognize:
struct QEMU_PACKED foo {
int stuff;
struct boo array[];
};
I'm not sure why, neither it is worth refactoring all QEMU
structures to use the attributes before the structure name,
so I did the 2nd patch manually.
Anyway this is annoying, because many structures are not handled
by coccinelle. Maybe this needs to be reported to upstream
coccinelle?
I used spatch 1.0.8 with:
-I include --include-headers \
--macro-file scripts/cocci-macro-file.h \
--keep-comments --indent 4
Regards,
Phil.
Based-on: <20200304153311.22959-1-phi...@redhat.com>
Supersedes: <20200304005105.27454-1-phi...@redhat.com>
Philippe Mathieu-Daudé (2):
misc: Replace zero-length arrays with flexible array member
(automatic)
misc: Replace zero-length arrays with flexible array member (manual)
docs/interop/vhost-user.rst | 4 ++--
bsd-user/qemu.h | 2 +-
contrib/libvhost-user/libvhost-user.h | 2 +-
hw/m68k/bootinfo.h| 2 +-
hw/scsi/srp.h | 6 +++---
hw/xen/xen_pt.h | 2 +-
include/hw/acpi/acpi-defs.h | 16
include/hw/arm/smmu-common.h | 2 +-
include/hw/boards.h | 2 +-
include/hw/i386/intel_iommu.h | 3 ++-
include/hw/s390x/event-facility.h | 2 +-
include/hw/s390x/sclp.h | 8
include/hw/virtio/virtio-iommu.h | 2 +-
include/sysemu/cryptodev.h| 2 +-
include/tcg/tcg.h | 2 +-
pc-bios/s390-ccw/bootmap.h| 2 +-
pc-bios/s390-ccw/sclp.h | 2 +-
tests/qtest/libqos/ahci.h | 2 +-
block/linux-aio.c | 2 +-
block/vmdk.c | 2 +-
hw/acpi/nvdimm.c | 6 +++---
hw/char/sclpconsole-lm.c | 2 +-
hw/char/sclpconsole.c | 2 +-
hw/dma/soc_dma.c | 2 +-
hw/i386/x86.c | 2 +-
hw/misc/omap_l4.c | 2 +-
hw/nvram/eeprom93xx.c | 2 +-
hw/rdma/vmw/pvrdma_qp_ops.c | 4 ++--
hw/s390x/virtio-ccw.c | 2 +-
hw/usb/dev-network.c | 2 +-
hw/usb/dev-smartcard-reader.c | 4 ++--
hw/virtio/virtio.c| 4 ++--
net/queue.c | 2 +-
target/s390x/ioinst.c | 2 +-
34 files changed, 53 insertions(+), 52 deletions(-)
--
2.21.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] block: refactor duplicated macros
On Sun, 23 Feb 2020 at 17:57, Matteo Croce wrote:
>
> The macros PAGE_SECTORS, PAGE_SECTORS_SHIFT and SECTOR_MASK are defined
> several times in different flavours across the whole tree.
> Define them just once in a common header.
>
> Signed-off-by: Matteo Croce
For mmc:
Acked-by: Ulf Hansson
Kind regards
Uffe
> ---
> block/blk-lib.c | 2 +-
> drivers/block/brd.c | 3 ---
> drivers/block/null_blk_main.c| 4
> drivers/block/zram/zram_drv.c| 8
> drivers/block/zram/zram_drv.h| 2 --
> drivers/dax/super.c | 2 +-
> drivers/md/bcache/util.h | 2 --
> drivers/md/dm-bufio.c| 6 +++---
> drivers/md/dm-integrity.c| 10 +-
> drivers/md/md.c | 4 ++--
> drivers/md/raid1.c | 2 +-
> drivers/mmc/core/host.c | 3 ++-
> drivers/scsi/xen-scsifront.c | 4 ++--
> fs/iomap/buffered-io.c | 2 +-
> fs/nfs/blocklayout/blocklayout.h | 2 --
> include/linux/blkdev.h | 4
> include/linux/device-mapper.h| 1 -
> 17 files changed, 26 insertions(+), 35 deletions(-)
>
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 5f2c429d4378..f5e705d307e0 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -260,7 +260,7 @@ static int __blkdev_issue_write_zeroes(struct
> block_device *bdev,
> */
> static unsigned int __blkdev_sectors_to_bio_pages(sector_t nr_sects)
> {
> - sector_t pages = DIV_ROUND_UP_SECTOR_T(nr_sects, PAGE_SIZE / 512);
> + sector_t pages = DIV_ROUND_UP_SECTOR_T(nr_sects, PAGE_SECTORS);
>
> return min(pages, (sector_t)BIO_MAX_PAGES);
> }
> diff --git a/drivers/block/brd.c b/drivers/block/brd.c
> index 220c5e18aba0..33e2cbe11400 100644
> --- a/drivers/block/brd.c
> +++ b/drivers/block/brd.c
> @@ -25,9 +25,6 @@
>
> #include
>
> -#define PAGE_SECTORS_SHIFT (PAGE_SHIFT - SECTOR_SHIFT)
> -#define PAGE_SECTORS (1 << PAGE_SECTORS_SHIFT)
> -
> /*
> * Each block ramdisk device has a radix_tree brd_pages of pages that stores
> * the pages containing the block device's contents. A brd page's ->index is
> diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
> index 16510795e377..c42af6cf0b97 100644
> --- a/drivers/block/null_blk_main.c
> +++ b/drivers/block/null_blk_main.c
> @@ -11,10 +11,6 @@
> #include
> #include "null_blk.h"
>
> -#define PAGE_SECTORS_SHIFT (PAGE_SHIFT - SECTOR_SHIFT)
> -#define PAGE_SECTORS (1 << PAGE_SECTORS_SHIFT)
> -#define SECTOR_MASK(PAGE_SECTORS - 1)
> -
> #define FREE_BATCH 16
>
> #define TICKS_PER_SEC 50ULL
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 1bdb5793842b..6ee59da4a6e2 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -1548,9 +1548,9 @@ static void __zram_make_request(struct zram *zram,
> struct bio *bio)
> struct bio_vec bvec;
> struct bvec_iter iter;
>
> - index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
> + index = bio->bi_iter.bi_sector >> PAGE_SECTORS_SHIFT;
> offset = (bio->bi_iter.bi_sector &
> - (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;
> + SECTOR_MASK) << SECTOR_SHIFT;
>
> switch (bio_op(bio)) {
> case REQ_OP_DISCARD:
> @@ -1643,8 +1643,8 @@ static int zram_rw_page(struct block_device *bdev,
> sector_t sector,
> goto out;
> }
>
> - index = sector >> SECTORS_PER_PAGE_SHIFT;
> - offset = (sector & (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;
> + index = sector >> PAGE_SECTORS_SHIFT;
> + offset = (sector & SECTOR_MASK) << SECTOR_SHIFT;
>
> bv.bv_page = page;
> bv.bv_len = PAGE_SIZE;
> diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
> index f2fd46daa760..12309175d55e 100644
> --- a/drivers/block/zram/zram_drv.h
> +++ b/drivers/block/zram/zram_drv.h
> @@ -21,8 +21,6 @@
>
> #include "zcomp.h"
>
> -#define SECTORS_PER_PAGE_SHIFT (PAGE_SHIFT - SECTOR_SHIFT)
> -#define SECTORS_PER_PAGE (1 << SECTORS_PER_PAGE_SHIFT)
> #define ZRAM_LOGICAL_BLOCK_SHIFT 12
> #define ZRAM_LOGICAL_BLOCK_SIZE(1 << ZRAM_LOGICAL_BLOCK_SHIFT)
> #define ZRAM_SECTOR_PER_LOGICAL_BLOCK \
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 0aa4b6bc5101..7f7672f72085 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -92,7 +92,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
> return false;
> }
>
> - last_page = PFN_DOWN((start + sectors - 1) * 512) * PAGE_SIZE / 512;
> + last_page = PFN_DOWN((start + sectors - 1) * 512) * PAGE_SECTORS;
> err = bdev_dax_pgoff(bdev, last_page, PAGE_SIZE, _end);
> if (err) {
> pr_debug("%s: error: unaligned partition for dax\n",
> diff --git a/drivers/md/bcache/util.h
[Xen-devel] [PATCH v3] x86/cpu: Sync any remaining RCU callbacks before CPU up/down
During CPU down operation RCU callbacks are scheduled to finish
off some actions later as soon as CPU is fully dead (the same applies
to CPU up operation in case error path is taken). If in the same grace
period another CPU up operation is performed on the same CPU, RCU callback
will be called later on a CPU in a potentially wrong (already up again
instead of still being down) state leading to eventual state inconsistency
and/or crash.
In order to avoid it - flush RCU callbacks explicitly before starting the
next CPU up/down operation.
Reviewed-by: Juergen Gross
Signed-off-by: Igor Druzhinin
---
This got discovered trying to resume PV shim with multiple vCPUs on AMD
machine (where park_offline_cpus == 0). RCU callback responsible for
freeing percpu area on CPU offline got finally called after CPU went
online again as the guest performed regular vCPU offline/online operations
on resume.
Note: this patch requires RCU series v3 from Juergen to be applied -
https://lists.xenproject.org/archives/html/xen-devel/2020-03/msg00200.html
v2: changed rcu_barrier() position, updated description
v3: moved rcu_barrier() to common cpu_up/cpu_down code to cover more cases
---
xen/arch/x86/acpi/power.c | 1 -
xen/arch/x86/sysctl.c | 8
xen/common/cpu.c | 2 ++
3 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index b5df00b..847c273 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -305,7 +305,6 @@ static int enter_state(u32 state)
cpufreq_add_cpu(0);
enable_cpu:
-rcu_barrier();
mtrr_aps_sync_begin();
enable_nonboot_cpus();
mtrr_aps_sync_end();
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 59a3840..b4e86a8 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -85,11 +85,7 @@ long cpu_up_helper(void *data)
int ret = cpu_up(cpu);
if ( ret == -EBUSY )
-{
-/* On EBUSY, flush RCU work and have one more go. */
-rcu_barrier();
ret = cpu_up(cpu);
-}
if ( !ret && !opt_smt &&
cpu_data[cpu].compute_unit_id == INVALID_CUID &&
@@ -110,11 +106,7 @@ long cpu_down_helper(void *data)
int cpu = (unsigned long)data;
int ret = cpu_down(cpu);
if ( ret == -EBUSY )
-{
-/* On EBUSY, flush RCU work and have one more go. */
-rcu_barrier();
ret = cpu_down(cpu);
-}
return ret;
}
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 31953f3..1f976db 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
unsigned int __read_mostly nr_cpu_ids = NR_CPUS;
#ifndef nr_cpumask_bits
@@ -53,6 +54,7 @@ void put_cpu_maps(void)
void cpu_hotplug_begin(void)
{
+rcu_barrier();
write_lock(_add_remove_lock);
}
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
On 04.03.2020 16:14, Jürgen Groß wrote:
> On 04.03.20 16:07, Jan Beulich wrote:
>> On 04.03.2020 15:39, Jürgen Groß wrote:
>>> On 04.03.20 14:03, Jan Beulich wrote:
On 04.03.2020 13:00, Jürgen Groß wrote:
> On 03.03.20 17:59, Jan Beulich wrote:
>> On 26.02.2020 13:46, Juergen Gross wrote:
>>> --- /dev/null
>>> +++ b/xen/common/hypfs.c
>>> @@ -0,0 +1,349 @@
>>> +/**
>>> + *
>>> + * hypfs.c
>>> + *
>>> + * Simple sysfs-like file system for the hypervisor.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#ifdef CONFIG_COMPAT
>>> +#include
>>> +CHECK_hypfs_direntry;
>>> +#undef CHECK_hypfs_direntry
>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>
>> I'm struggling to see why you need this #undef and #define.
>
> Without those I get:
>
> In file included from
> /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
> from
> /home/gross/xen/unstable/xen/include/xen/shared.h:6,
> from
> /home/gross/xen/unstable/xen/include/xen/sched.h:8,
> from
> /home/gross/xen/unstable/xen/include/asm/paging.h:29,
> from
> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
> from
> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
> from hypfs.c:9:
> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>^
> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
> definition of macro ‘CHECK_FIELD_COMMON_’
> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n
> *c) \
> ^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
> expansion of macro ‘CHECK_NAME_’
> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>^~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
> expansion of macro ‘CHECK_FIELD_’
> CHECK_FIELD_(struct, hypfs_direntry, flags); \
> ^~~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
> expansion of macro ‘CHECK_hypfs_direntry’
> CHECK_hypfs_direntry; \
> ^~~~
> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
> CHECK_hypfs_dirlistentry;
> ^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>^
> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
> definition of macro ‘CHECK_FIELD_COMMON_’
> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n
> *c) \
> ^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
> expansion of macro ‘CHECK_NAME_’
> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>^~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
> expansion of macro ‘CHECK_FIELD_’
> CHECK_FIELD_(struct, hypfs_direntry, flags); \
> ^~~~
> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
> CHECK_hypfs_direntry;
Which suggests to me that the explicit CHECK_hypfs_direntry invocation
is unneeded, as it's getting verified as part of the invocation of
CHECK_hypfs_dirlistentry.
>>>
>>> Ah, right. This is working. Will change.
>>>
>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
>>> ulen)
>>> +{
>>> +char *buf;
>>> +int ret;
>>> +
>>> +if ( ulen > leaf->e.size )
>>> +return -ENOSPC;
>>> +
>>> +if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>> +return -EDOM;
>>
>> Why the exception of string and blob? My concern about the
>> meaning of a partially written entry (without its size having
>> changed) remains.
>
> It is perfectly valid to write a shorter string into a character
> array. I could drop the blob here, but in the
Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
On 04.03.2020 16:07, Jürgen Groß wrote:
> On 04.03.20 12:32, Jan Beulich wrote:
>> On 26.02.2020 13:47, Juergen Gross wrote:
>>> +static void update_ept_param_append(const char *str, int val)
>>> +{
>>> +char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>> +
>>> +snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>> + ",%s=%d", str, val);
>>> +}
>>> +
>>> +static void update_ept_param(void)
>>> +{
>>> +snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d",
>>> opt_ept_pml);
>>> +if ( opt_ept_ad >= 0 )
>>> +update_ept_param_append("ad", opt_ept_ad);
>>
>> This won't correctly reflect reality: If you look at
>> vmx_init_vmcs_config(), even a negative value means "true" here,
>> unless on a specific Atom model. I think init_ept_param() wants
>> to have that erratum workaround logic moved there, such that
>> you can then assme the value to be non-negative here.
>
> But isn't not mentioning it in the -1 case correct? -1 means: do the
> correct thing on the current hardware.
Well, I think the output here should represent effective settings,
and a sub-item should be suppressed only if a setting has no effect
at all in the current setup, like ...
>>> +if ( opt_ept_exec_sp >= 0 )
>>> +update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>
>> I agree for this one - if the value is still -1, it has neither
>> been set nor is its value of any interest.
... here.
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -85,8 +85,10 @@ struct grant_table {
>>> struct grant_table_arch arch;
>>> };
>>>
>>> -static int parse_gnttab_limit(const char *param, const char *arg,
>>> - unsigned int *valp)
>>> +#define GRANT_CUSTOM_VAL_SZ 12
>>> +
>>> +static int parse_gnttab_limit(const char *arg, unsigned int *valp,
>>> + char *parval)
>>> {
>>> const char *e;
>>> unsigned long val;
>>> @@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const
>>> char *arg,
>>> return -ERANGE;
>>>
>>> *valp = val;
>>> +snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
>>>
>>> return 0;
>>> }
>>>
>>> unsigned int __read_mostly opt_max_grant_frames = 64;
>>> +static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
>>> +
>>> +static void __init gnttab_max_frames_init(struct param_hypfs *par)
>>> +{
>>> +custom_runtime_set_var(par, opt_max_grant_frames_val);
>>
>> You still use a custom string buffer here. Can this "set-var"
>> operation record that the variable (for presentation purposes)
>> is simply of UINT type, handing a pointer to the actual
>> variable?
>
> No, this would result in the need to set a custom parameter via a
> binary value passed in from user land. So I'd need to convert this
> binary into a string to be parseable by the custom function.
Hmm, not very fortunate, but I can see what you're saying.
>>> --- a/xen/common/hypfs.c
>>> +++ b/xen/common/hypfs.c
>>> @@ -10,6 +10,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> @@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
>>> return 0;
>>> }
>>>
>>> +int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
>>> ulen)
>>> +{
>>> +struct param_hypfs *p;
>>> +char *buf;
>>> +int ret;
>>> +
>>> +buf = xzalloc_array(char, ulen);
>>> +if ( !buf )
>>> +return -ENOMEM;
>>> +
>>> +ret = -EFAULT;
>>> +if ( copy_from_guest(buf, uaddr, ulen) )
>>> +goto out;
>>> +
>>> +ret = -EDOM;
>>> +if ( !memchr(buf, 0, ulen) )
>>
>> Once again " != buf + ulen - 1"? (EDOM also looks like an odd
>> error code to use in this case, but I guess there's no really
>> good one.)
>
> " != buf + ulen - 1" is a logical choice with the change of patch 4.
I'm afraid I don't understand. You want to parse a string here.
The caller should tell you what the string length is (including
the nul again), not what its buffer size may be.
>>> @@ -79,41 +88,94 @@ extern const struct kernel_param __param_start[],
>>> __param_end[];
>>> .type = OPT_IGNORE }
>>>
>>> #define __rtparam __param(__dataparam)
>>> +#define __paramfs static __paramhypfs \
>>> +__attribute__((__aligned__(sizeof(void * struct param_hypfs
>>>
>>> -#define custom_runtime_only_param(_name, _var) \
>>> +#define custom_runtime_set_var(parfs, var) \
>>> +{ \
>>> +(parfs)->hypfs.write_ptr = &(var); \
>>> +(parfs)->hypfs.e.size = sizeof(var); \
>>
>> All users of this use char[]. Why sizeof() rather than strlen(),
>
> That is the maximum string length. Otherwise I wouldn't know I am
> allowed to replace e.g. "on" by "noxpti".
As said elsewhere - if e.size is the buffer size, then the
reading function wants
Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
On 04.03.20 16:07, Jan Beulich wrote:
On 04.03.2020 15:39, Jürgen Groß wrote:
On 04.03.20 14:03, Jan Beulich wrote:
On 04.03.2020 13:00, Jürgen Groß wrote:
On 03.03.20 17:59, Jan Beulich wrote:
On 26.02.2020 13:46, Juergen Gross wrote:
--- /dev/null
+++ b/xen/common/hypfs.c
@@ -0,0 +1,349 @@
+/**
+ *
+ * hypfs.c
+ *
+ * Simple sysfs-like file system for the hypervisor.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_COMPAT
+#include
+CHECK_hypfs_direntry;
+#undef CHECK_hypfs_direntry
+#define CHECK_hypfs_direntry struct xen_hypfs_direntry
I'm struggling to see why you need this #undef and #define.
Without those I get:
In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
from
/home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
from
/home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
from hypfs.c:9:
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
redefinition of ‘__checkFstruct_hypfs_direntry__flags’
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry; \
^~~~
hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
CHECK_hypfs_dirlistentry;
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~
hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry;
Which suggests to me that the explicit CHECK_hypfs_direntry invocation
is unneeded, as it's getting verified as part of the invocation of
CHECK_hypfs_dirlistentry.
Ah, right. This is working. Will change.
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+char *buf;
+int ret;
+
+if ( ulen > leaf->e.size )
+return -ENOSPC;
+
+if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
+ leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
+return -EDOM;
Why the exception of string and blob? My concern about the
meaning of a partially written entry (without its size having
changed) remains.
It is perfectly valid to write a shorter string into a character
array. I could drop the blob here, but in the end I think allowing
for a blob to change the size should be fine.
But shouldn't this then also adjust the recorded size?
No, this is the max size of the buffer (you can have a look at patch 9
where the size is set to the provided space for custom and string
parameters).
If I'm not mistaken it is hypfs_read_leaf() which processes read
requests for strings. Yet that copies entry->size bytes, not the
potentially smaller strlen()-bounded payload. Things would be
There is no risk of leaking problematic data here.
even worse for BLOB-type entries, where one couldn't even look
for a nul terminator to determine actual payload size.
Right, this would probably require a blob-specific read function, in
case the blob is of variable length.
Juergen
Re: [Xen-devel] [PATCH v5 1/2] docs/designs: Add a design document for non-cooperative live migration
Hi Paul, The proposal looks sensible to me. Some NITpicking below. On 13/02/2020 10:53, Paul Durrant wrote: It has become apparent to some large cloud providers that the current model of cooperative migration of guests under Xen is not usable as it relies on software running inside the guest, which is likely beyond the provider's control. This patch introduces a proposal for non-cooperative live migration, designed not to rely on any guest-side software. Signed-off-by: Paul Durrant --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Wei Liu v5: - Note that PV domain are not just expected to co-operate, they are required to v4: - Fix issues raised by Wei v2: - Use the term 'non-cooperative' instead of 'transparent' - Replace 'trust in' with 'reliance on' when referring to guest-side software --- docs/designs/non-cooperative-migration.md | 272 ++ 1 file changed, 272 insertions(+) create mode 100644 docs/designs/non-cooperative-migration.md diff --git a/docs/designs/non-cooperative-migration.md b/docs/designs/non-cooperative-migration.md new file mode 100644 index 00..09f74c8c0d --- /dev/null +++ b/docs/designs/non-cooperative-migration.md @@ -0,0 +1,272 @@ +# Non-Cooperative Migration of Guests on Xen + +## Background + +The normal model of migration in Xen is driven by the guest because it was +originally implemented for PV guests, where the guest must be aware it is +running under Xen and is hence expected to co-operate. This model dates from +an era when it was assumed that the host administrator had control of at least +the privileged software running in the guest (i.e. the guest kernel) which may +still be true in an enterprise deployment but is not generally true in a cloud +environment. The aim of this design is to provide a model which is purely host +driven, requiring no co-operation from the software running in the +guest, and is thus suitable for cloud scenarios. + +PV guests are out of scope for this project because, as is outlined above, they +have a symbiotic relationship with the hypervisor and therefore a certain level +of co-operation is required. + +HVM guests can already be migrated on Xen without guest co-operation but only +if they don’t have PV drivers installed[1] or are in power state S3. The S3 is very ACPI centric, so I would prefer if we avoid the term. I think the non-ACPI description is "suspend to RAM". I would be OK is you mention S3 in parenthesis. +reason for not expecting co-operation if the guest is in S3 is obvious, but the +reason co-operation is expected if PV drivers are installed is due to the +nature of PV protocols. + +## Xenstore Nodes and Domain ID + +The PV driver model consists of a *frontend* and a *backend*. The frontend runs +inside the guest domain and the backend runs inside a *service domain* which +may or may not be domain 0. The frontend and backend typically pass data via +memory pages which are shared between the two domains, but this channel of +communication is generally established using xenstore (the store protocol +itself being an exception to this for obvious chicken-and-egg reasons). + +Typical protocol establishment is based on use of two separate xenstore +*areas*. If we consider PV drivers for the *netif* protocol (i.e. class vif) +and assume the guest has domid X, the service domain has domid Y, and the vif +has index Z then the frontend area will reside under the parent node: + +`/local/domain/Y/device/vif/Z` + +All backends, by convention, typically reside under parent node: + +`/local/domain/X/backend` + +and the normal backend area for vif Z would be: + +`/local/domain/X/backend/vif/Y/Z` + +but this should not be assumed. + +The toolstack will place two nodes in the frontend area to explicitly locate +the backend: + +* `backend`: the fully qualified xenstore path of the backend area +* `backend-id`: the domid of the service domain + +and similarly two nodes in the backend area to locate the frontend area: + +* `frontend`: the fully qualified xenstore path of the frontend area +* `frontend-id`: the domid of the guest domain + + +The guest domain only has write permission to the frontend area and similarly +the service domain only has write permission to the backend area, but both ends +have read permission to both areas. + +Under both frontend and backend areas is a node called *state*. This is key to +protocol establishment. Upon PV device creation the toolstack will set the +value of both state nodes to 1 (XenbusStateInitialising[2]). This should cause +enumeration of appropriate devices in both the guest and service domains. The +backend device, once it has written any necessary protocol specific information +into the xenstore backend area (to be read by the frontend driver) will update +the backend state node to 2 (XenbusStateInitWait). From this point on
Re: [Xen-devel] [PATCH v7 03/11] scripts: add coccinelle script to use auto propagated errp
Vladimir Sementsov-Ogievskiy writes:
> 23.02.2020 11:55, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
>>> does corresponding changes in code (look for details in
>>> include/qapi/error.h)
>>>
>>> Usage example:
>>> spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
>>> --macro-file scripts/cocci-macro-file.h --in-place --no-show-diff \
>>> blockdev-nbd.c qemu-nbd.c {block/nbd*,nbd/*,include/block/nbd*}.[hc]
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>>> ---
>>>
>>> CC: Eric Blake
>>> CC: Kevin Wolf
>>> CC: Max Reitz
>>> CC: Greg Kurz
>>> CC: Stefano Stabellini
>>> CC: Anthony Perard
>>> CC: Paul Durrant
>>> CC: Stefan Hajnoczi
>>> CC: "Philippe Mathieu-Daudé"
>>> CC: Laszlo Ersek
>>> CC: Gerd Hoffmann
>>> CC: Stefan Berger
>>> CC: Markus Armbruster
>>> CC: Michael Roth
>>> CC: qemu-bl...@nongnu.org
>>> CC: xen-devel@lists.xenproject.org
>>>
>>> include/qapi/error.h | 3 +
>>> scripts/coccinelle/auto-propagated-errp.cocci | 158 ++
>>> 2 files changed, 161 insertions(+)
>>> create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
>>>
>>> diff --git a/include/qapi/error.h b/include/qapi/error.h
>>> index b9452d4806..79f8e95214 100644
>>> --- a/include/qapi/error.h
>>> +++ b/include/qapi/error.h
>>> @@ -141,6 +141,9 @@
>>>* ...
>>>* }
>>>*
>>> + * For mass conversion use script
>>> + * scripts/coccinelle/auto-propagated-errp.cocci
>>> + *
>>>*
>>>* Receive and accumulate multiple errors (first one wins):
>>>* Error *err = NULL, *local_err = NULL;
>>
>> Extra blank line.
>>
>>> diff --git a/scripts/coccinelle/auto-propagated-errp.cocci
>>> b/scripts/coccinelle/auto-propagated-errp.cocci
>>> new file mode 100644
>>> index 00..fb03c871cb
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/auto-propagated-errp.cocci
>>> @@ -0,0 +1,158 @@
>>> +// Use ERRP_AUTO_PROPAGATE (see include/qapi/error.h)
>>> +//
>>> +// Copyright (c) 2020 Virtuozzo International GmbH.
>>> +//
>>> +// This program is free software; you can redistribute it and/or modify
>>> +// it under the terms of the GNU General Public License as published by
>>> +// the Free Software Foundation; either version 2 of the License, or
>>> +// (at your option) any later version.
>>> +//
>>> +// This program is distributed in the hope that it will be useful,
>>> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> +// GNU General Public License for more details.
>>> +//
>>> +// You should have received a copy of the GNU General Public License
>>> +// along with this program. If not, see
Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
On 04.03.20 12:32, Jan Beulich wrote:
On 26.02.2020 13:47, Juergen Gross wrote:
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
static bool __read_mostly opt_ept_pml = true;
static s8 __read_mostly opt_ept_ad = -1;
int8_t __read_mostly opt_ept_exec_sp = -1;
+static char opt_ept_setting[16];
I don't think this is quite big enough.
Yes, you are right.
+static void update_ept_param_append(const char *str, int val)
+{
+char *pos = opt_ept_setting + strlen(opt_ept_setting);
+
+snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
+ ",%s=%d", str, val);
+}
+
+static void update_ept_param(void)
+{
+snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
+if ( opt_ept_ad >= 0 )
+update_ept_param_append("ad", opt_ept_ad);
This won't correctly reflect reality: If you look at
vmx_init_vmcs_config(), even a negative value means "true" here,
unless on a specific Atom model. I think init_ept_param() wants
to have that erratum workaround logic moved there, such that
you can then assme the value to be non-negative here.
But isn't not mentioning it in the -1 case correct? -1 means: do the
correct thing on the current hardware.
In case we want to report an explicit value for "ad" we should add a
node for that purpose.
+if ( opt_ept_exec_sp >= 0 )
+update_ept_param_append("exec-sp", opt_ept_exec_sp);
I agree for this one - if the value is still -1, it has neither
been set nor is its value of any interest.
+static void __init init_ept_param(struct param_hypfs *par)
+{
+custom_runtime_set_var(par, opt_ept_setting);
+update_ept_param();
+}
static int __init parse_ept_param(const char *s)
{
@@ -93,6 +117,8 @@ static int __init parse_ept_param(const char *s)
s = ss + 1;
} while ( *ss );
+update_ept_param();
Isn't this redundant with the use in init_ept_param() (or the
other way around - there should be clear ordering between the
command line parsing functions and the param-init ones, I would
suppose)?
You are right. I can drop this call, as the param-init call will
come later.
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -20,8 +20,27 @@ static __read_mostly enum {
PCID_OFF,
PCID_ALL,
PCID_XPTI,
-PCID_NOXPTI
+PCID_NOXPTI,
+PCID_END
} opt_pcid = PCID_XPTI;
+static const char *opt_pcid_2_string[PCID_END] = {
You either want another const here, or (more space efficient) you
want to use const char[PCID_END][7].
Ah, right, good idea.
+[PCID_OFF] = "off",
+[PCID_ALL] = "on",
+[PCID_XPTI] = "xpti",
+[PCID_NOXPTI] = "noxpti"
+};
+static char opt_pcid_val[7];
+
+static void update_opt_pcid(void)
+{
+strlcpy(opt_pcid_val, opt_pcid_2_string[opt_pcid], sizeof(opt_pcid_val));
Instead of copying, couldn't you make the hypfs entry point
into the array above, by using custom_runtime_set_var() here?
Hmm, probably yes.
@@ -55,9 +74,12 @@ static int parse_pcid(const char *s)
break;
}
+if ( !rc )
+update_opt_pcid();
Personally I'd avoid the if() here - there's no harm updating
the hypfs entry anyway.
Okay.
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -85,8 +85,10 @@ struct grant_table {
struct grant_table_arch arch;
};
-static int parse_gnttab_limit(const char *param, const char *arg,
- unsigned int *valp)
+#define GRANT_CUSTOM_VAL_SZ 12
+
+static int parse_gnttab_limit(const char *arg, unsigned int *valp,
+ char *parval)
{
const char *e;
unsigned long val;
@@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const
char *arg,
return -ERANGE;
*valp = val;
+snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
return 0;
}
unsigned int __read_mostly opt_max_grant_frames = 64;
+static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
+
+static void __init gnttab_max_frames_init(struct param_hypfs *par)
+{
+custom_runtime_set_var(par, opt_max_grant_frames_val);
You still use a custom string buffer here. Can this "set-var"
operation record that the variable (for presentation purposes)
is simply of UINT type, handing a pointer to the actual
variable?
No, this would result in the need to set a custom parameter via a
binary value passed in from user land. So I'd need to convert this
binary into a string to be parseable by the custom function.
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
return 0;
}
+int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+
Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
On 04.03.2020 15:39, Jürgen Groß wrote:
> On 04.03.20 14:03, Jan Beulich wrote:
>> On 04.03.2020 13:00, Jürgen Groß wrote:
>>> On 03.03.20 17:59, Jan Beulich wrote:
On 26.02.2020 13:46, Juergen Gross wrote:
> --- /dev/null
> +++ b/xen/common/hypfs.c
> @@ -0,0 +1,349 @@
> +/**
> + *
> + * hypfs.c
> + *
> + * Simple sysfs-like file system for the hypervisor.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_COMPAT
> +#include
> +CHECK_hypfs_direntry;
> +#undef CHECK_hypfs_direntry
> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
I'm struggling to see why you need this #undef and #define.
>>>
>>> Without those I get:
>>>
>>> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
>>>from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
>>>from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
>>>from
>>> /home/gross/xen/unstable/xen/include/asm/paging.h:29,
>>>from
>>> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
>>>from
>>> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
>>>from hypfs.c:9:
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
>>> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
>>>#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>> ^
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c)
>>> \
>>> ^~~~
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>> expansion of macro ‘CHECK_NAME_’
>>>CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>> ^~~
>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>> expansion of macro ‘CHECK_FIELD_’
>>>CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>^~~~
>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
>>> expansion of macro ‘CHECK_hypfs_direntry’
>>>CHECK_hypfs_direntry; \
>>>^~~~
>>> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
>>>CHECK_hypfs_dirlistentry;
>>>^~~~
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
>>> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
>>>#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>> ^
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c)
>>> \
>>> ^~~~
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>> expansion of macro ‘CHECK_NAME_’
>>>CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>> ^~~
>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>> expansion of macro ‘CHECK_FIELD_’
>>>CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>^~~~
>>> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
>>>CHECK_hypfs_direntry;
>>
>> Which suggests to me that the explicit CHECK_hypfs_direntry invocation
>> is unneeded, as it's getting verified as part of the invocation of
>> CHECK_hypfs_dirlistentry.
>
> Ah, right. This is working. Will change.
>
>>
> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
> ulen)
> +{
> +char *buf;
> +int ret;
> +
> +if ( ulen > leaf->e.size )
> +return -ENOSPC;
> +
> +if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
> +return -EDOM;
Why the exception of string and blob? My concern about the
meaning of a partially written entry (without its size having
changed) remains.
>>>
>>> It is perfectly valid to write a shorter string into a character
>>> array. I could drop the blob here, but in the end I think allowing
>>> for a blob to change the size should be fine.
>>
>> But shouldn't this then also adjust the recorded size?
>
> No, this is the max size of the buffer (you can have a look at patch 9
> where the size is set to the provided space for custom and string
> parameters).
If I'm not mistaken it is hypfs_read_leaf() which processes
Re: [Xen-devel] [XEN PATCH v3 15/23] xen/build: have the root Makefile generates the CFLAGS
On 26.02.2020 12:33, Anthony PERARD wrote: > @@ -113,6 +115,64 @@ $(KCONFIG_CONFIG): > include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG) > $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) > SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" syncconfig > > +ifeq ($(CONFIG_DEBUG),y) > +CFLAGS += -O1 > +else > +CFLAGS += -O2 > +endif > + > +ifeq ($(CONFIG_FRAME_POINTER),y) > +CFLAGS += -fno-omit-frame-pointer > +else > +CFLAGS += -fomit-frame-pointer > +endif > + > +CFLAGS += -nostdinc -fno-builtin -fno-common > +CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith > +$(call cc-option-add,CFLAGS,CC,-Wvla) > +CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h > +CFLAGS-$(CONFIG_DEBUG_INFO) += -g > + > +ifneq ($(CONFIG_CC_IS_CLANG),y) > +# Clang doesn't understand this command line argument, and doesn't appear to > +# have an suitable alternative. The resulting compiled binary does function, > +# but has an excessively large symbol table. > +CFLAGS += -Wa,--strip-local-absolute > +endif > + > +AFLAGS += -D__ASSEMBLY__ > + > +CFLAGS += $(CFLAGS-y) I can't seem to be able to spot a similar line for AFLAGS. > @@ -107,7 +65,7 @@ $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) > $(extra-y)),$(eval $(call gend > subdir-y := $(subdir-y) $(filter %/, $(obj-y)) > obj-y:= $(patsubst %/, %/built_in.o, $(obj-y)) > > -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += > -DINIT_SECTIONS_ONLY > +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += > -DINIT_SECTIONS_ONLY While in the description you say "We can't use CFLAGS in subdirectories to add flags to particular targets, ...", it remains unclear there why that is, and hence why changes like this one are necessary. If this is a restriction that's going to remain, this also needs writing down in a prominent place. After all if (for example) special compiler options are needed, CFLAGS would be the natural thing one would want to alter. (Even better if wrong playing with CFLAGS could be detected and at least warned about, but I'm completely unclear on how feasible this would be.) > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk > index 022a3a6f82ba..e69de29bb2d1 100644 > --- a/xen/arch/arm/Rules.mk > +++ b/xen/arch/arm/Rules.mk > @@ -1,93 +0,0 @@ As per the header here you're using git. Can you please arrange for this file movement (to arch.mk, and also for x86) to actually be expressed here as a rename, i.e. such that one can see what - if anything - changes? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Fwd: [ANNOUNCE] Call for agenda items for 2020 March Community Call @ 16:00 UTC
Hi all, The proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/BiXRb0cAnVSfFjedd73D--oh/ and you can edit to add items Alternatively, you can reply to this mail directly. Agenda items appreciated a few days before the call: please put your name besides items if you edit the document. Note the following administrative conventions for the call * Unless, agreed in the pervious meeting otherwise, the call is on the 1st Thursday of each month at 16:00 British Time * I usually send out a meeting reminder a few days before with a provisional agenda * I will copy agenda items from https://cryptpad.fr/pad/#/2/pad/edit/oSj9dSFY1OmHxfX0-oZKmEFL/ to the provisional agenda with that e-mail * If you want to be CC'ed please add or remove yourself from the sign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ Best Regards George == Dial-in Information == ## Dial in details Web: https://www.gotomeet.me/GeorgeDunlap You can also dial in using your phone. Access Code: 168-682-109 China (Toll Free): 4008 811084 Germany: +49 692 5736 7317 Poland (Toll Free): 00 800 1124759 Ukraine (Toll Free): 0 800 50 1733 United Kingdom: +44 330 221 0088 United States: +1 (571) 317-3129 Spain: +34 932 75 2004 More phone numbers Australia: +61 2 9087 3604 Austria: +43 7 2081 5427 Argentina (Toll Free): 0 800 444 3375 Bahrain (Toll Free): 800 81 111 Belarus (Toll Free): 8 820 0011 0400 Belgium: +32 28 93 7018 Brazil (Toll Free): 0 800 047 4906 Bulgaria (Toll Free): 00800 120 4417 Canada: +1 (647) 497-9391 Chile (Toll Free): 800 395 150 Colombia (Toll Free): 01 800 518 4483 Czech Republic (Toll Free): 800 500448 Denmark: +45 32 72 03 82 Finland: +358 923 17 0568 France: +33 170 950 594 Greece (Toll Free): 00 800 4414 3838 Hong Kong (Toll Free): 30713169906-886-965 Hungary (Toll Free): (06) 80 986 255 Iceland (Toll Free): 800 7204 India (Toll Free): 18002669272 Indonesia (Toll Free): 007 803 020 5375 Ireland: +353 15 360 728 Israel (Toll Free): 1 809 454 830 Italy: +39 0 247 92 13 01 Japan (Toll Free): 0 120 663 800 Korea, Republic of (Toll Free): 00798 14 207 4914 Luxembourg (Toll Free): 800 85158 Malaysia (Toll Free): 1 800 81 6854 Mexico (Toll Free): 01 800 522 1133 Netherlands: +31 207 941 377 New Zealand: +64 9 280 6302 Norway: +47 21 93 37 51 Panama (Toll Free): 00 800 226 7928 Peru (Toll Free): 0 800 77023 Philippines (Toll Free): 1 800 1110 1661 Portugal (Toll Free): 800 819 575 Romania (Toll Free): 0 800 410 029 Russian Federation (Toll Free): 8 800 100 6203 Saudi Arabia (Toll Free): 800 844 3633 Singapore (Toll Free): 18007231323 South Africa (Toll Free): 0 800 555 447 Sweden: +46 853 527 827 Switzerland: +41 225 4599 78 Taiwan (Toll Free): 0 800 666 854 Thailand (Toll Free): 001 800 011 023 Turkey (Toll Free): 00 800 4488 23683 United Arab Emirates (Toll Free): 800 044 40439 Uruguay (Toll Free): 0004 019 1018 Viet Nam (Toll Free): 122 80 481 First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 14/23] xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)
On 26.02.2020 12:33, Anthony PERARD wrote:
> --- a/xen/scripts/Kbuild.include
> +++ b/xen/scripts/Kbuild.include
> @@ -10,7 +10,7 @@ DEPS_INCLUDE = $(addsuffix .d2, $(basename $(wildcard
> $(DEPS
> # as-insn: Check whether assembler supports an instruction.
> # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
> as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
> - | $(filter-out -M% %.d -include
> %/include/xen/config.h,$(1)) \
> + | $(filter-out -include %/include/xen/config.h,$(1)) \
>-c -x c -o /dev/null - 2>&1),$(4),$(3))
I'm sorry, while it was me to suggest this change - is this
correct? The variable to modify is a parameter of this macro,
i.e. things aren't limited to CFLAGS here. If we want to
disallow use with e.g. c_flags or anything derived from it,
then we should find some way to actually enforce this (like
dropping the respective parameter; I'm uncertain though whether
we wouldn't regret this if we ever got to the point where we
wanted to use a newer insn in a .S file).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support
On 04.03.20 12:45, Jan Beulich wrote:
On 26.02.2020 13:47, Juergen Gross wrote:
The functionality of XEN_SYSCTL_set_parameter is available via hypfs
now, so it can be removed.
This allows to remove the kernel_param structure for runtime parameters
by putting the now only used structure element into the hypfs node
structure of the runtime parameters.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
with one minor adjustment:
@@ -1102,7 +1086,6 @@ struct xen_sysctl {
#define XEN_SYSCTL_get_cpu_levelling_caps25
#define XEN_SYSCTL_get_cpu_featureset26
#define XEN_SYSCTL_livepatch_op 27
-#define XEN_SYSCTL_set_parameter 28
Please follow the tmem_op example here and don't outright
delete the line.
Okay.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
On 04.03.20 14:03, Jan Beulich wrote:
On 04.03.2020 13:00, Jürgen Groß wrote:
On 03.03.20 17:59, Jan Beulich wrote:
On 26.02.2020 13:46, Juergen Gross wrote:
--- /dev/null
+++ b/xen/common/hypfs.c
@@ -0,0 +1,349 @@
+/**
+ *
+ * hypfs.c
+ *
+ * Simple sysfs-like file system for the hypervisor.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_COMPAT
+#include
+CHECK_hypfs_direntry;
+#undef CHECK_hypfs_direntry
+#define CHECK_hypfs_direntry struct xen_hypfs_direntry
I'm struggling to see why you need this #undef and #define.
Without those I get:
In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
from
/home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
from
/home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
from hypfs.c:9:
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
redefinition of ‘__checkFstruct_hypfs_direntry__flags’
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry; \
^~~~
hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
CHECK_hypfs_dirlistentry;
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~
hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry;
Which suggests to me that the explicit CHECK_hypfs_direntry invocation
is unneeded, as it's getting verified as part of the invocation of
CHECK_hypfs_dirlistentry.
Ah, right. This is working. Will change.
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+char *buf;
+int ret;
+
+if ( ulen > leaf->e.size )
+return -ENOSPC;
+
+if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
+ leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
+return -EDOM;
Why the exception of string and blob? My concern about the
meaning of a partially written entry (without its size having
changed) remains.
It is perfectly valid to write a shorter string into a character
array. I could drop the blob here, but in the end I think allowing
for a blob to change the size should be fine.
But shouldn't this then also adjust the recorded size?
No, this is the max size of the buffer (you can have a look at patch 9
where the size is set to the provided space for custom and string
parameters).
+buf = xmalloc_array(char, ulen);
+if ( !buf )
+return -ENOMEM;
+
+ret = -EFAULT;
+if ( copy_from_guest(buf, uaddr, ulen) )
+goto out;
+
+ret = -EINVAL;
+if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
This should also use the != buf + ulen - 1 form imo.
I'm fine to change that, but should the hypervisor really refuse to
accept a larger buffer?
To avoid ambiguity I'd prefer if the requirement was that the
caller specify the length of the string (plus the nul char)
rather than the size of any buffer it might be using.
Okay, I don't mind
[Xen-devel] [libvirt test] 147981: regressions - FAIL
flight 147981 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/147981/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-i386-libvirt6 libvirt-buildfail REGR. vs. 146182 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 146182 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a version targeted for testing: libvirt 993f68c01ccb8326d6a374883edcf51476ea2121 baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 47 days Failing since146211 2020-01-18 04:18:52 Z 46 days 44 attempts Testing same since 147784 2020-02-29 18:02:43 Z3 days4 attempts People who touched revisions under test: Andrea Bolognani Arnaud Patard Boris Fiuczynski Christian Ehrhardt Collin Walling Daniel Henrique Barboza Daniel P. Berrangé Dario Faggioli Erik Skultety Han Han Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Marek Marczykowski-Górecki Michal Privoznik Nikolay Shirokovskiy Pavel Hrdina Pavel Mores Peter Krempa Richard W.M. Jones Rikard Falkeborn Ryan Moeller Sahid Orentino Ferdjaoui Stefan Berger Stefan Berger Thomas Huth Your Name zhenwei pi jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at
Re: [Xen-devel] [PATCH 0/5] IOMMU: restrict visibility/scope if certain variables
Hi Jan, Adding Paul in CC as he now co-maintain the IOMMU code. On 28/02/2020 12:24, Jan Beulich wrote: A number of the command line controlled variables are x86- or even x86-HVM-specific. Don't have those variables elsewhere in the first place (in some cases replace them by a #define), and as a result also don't silently accept such "iommu=" sub-options which in fact have no effect. I can confirm that all the parameters listed below are not used on Arm. 1: iommu_intremap is x86-only 2: iommu_intpost is x86/HVM-only 3: iommu_igfx is x86-only 4: iommu_qinval is x86-only 5: iommu_snoop is x86/HVM-only The series contextually depends on "AMD/IOMMU: without XT, x2APIC needs to be forced into physical mode" Jan Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 13/23] xen/build: include include/config/auto.conf in main Makefile
On 26.02.2020 12:33, Anthony PERARD wrote: > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -49,7 +49,71 @@ default: build > .PHONY: dist > dist: install > > -build install:: include/config/auto.conf > + > +ifeq ($(root-make-done),) This getting communicated between make recursion instances via ... > +# section to run before calling Rules.mk, but only once. > +# > +# To make sure we do not include .config for any of the *config targets > +# catch them early, and hand them over to tools/kconfig/Makefile > + > +clean-targets := %clean > +no-dot-config-targets := $(clean-targets) \ > + uninstall debug cloc \ > + cscope TAGS tags MAP gtags \ > + xenversion > + > +config-build:= n > +need-config := y > + > +ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),) > +ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),) > +need-config := n > +endif > +endif > + > +ifneq ($(filter %config,$(MAKECMDGOALS)),) > +config-build := y > +endif > + > +export root-make-done := y ... the environment, can we be as resilient as possible against a variable of this name already existing in the environment before the top level make invocation, by making the construct above ifneq ($(root-make-done),y) ? > +endif # root-make-done > + > +ifeq ($(config-build),y) > +# === > +# *config targets only - make sure prerequisites are updated, and descend > +# in tools/kconfig to make the *config target > + > +config: FORCE > + $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) > SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@ This, ... > + > +# Config.mk tries to include .config file, don't try to remake it > +%/.config: ; > + > +%config: FORCE > + $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) > SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@ ... this, ... > +else # !config-build > + > +ifeq ($(need-config),y) > +include include/config/auto.conf > +# Read in dependencies to all Kconfig* files, make sure to run syncconfig if > +# changes are detected. > +include include/config/auto.conf.cmd > + > +# Allow people to just run `make` as before and not force them to configure > +$(KCONFIG_CONFIG): > + $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) > SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" defconfig ... this, and ... > +# The actual configuration files used during the build are stored in > +# include/generated/ and include/config/. Update them if .config is newer > than > +# include/config/auto.conf (which mirrors .config). > +# > +# This exploits the 'multi-target pattern rule' trick. > +# The syncconfig should be executed only once to make all the targets. > +include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG) > + $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) > SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" syncconfig ... this are almost identical, pretty long lines. Can this be macroized, please, with the actual make goal as parameter? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V6] x86/altp2m: Hypercall to set altp2m view visibility
Hi,
Any thoughts on this patch are appreciated.
Thanks,
Alex
On 03.03.2020 14:23, Alexandru Stefan ISAILA wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This is done by having a separate arch.altp2m_working_eptp that is
> populated and made invalid in the same places as altp2m_eptp. This is
> written to EPTP_LIST_ADDR.
> The views are made in/visible by marking them with INVALID_MFN or
> copying them back from altp2m_eptp.
> To have consistency the visibility also applies to
> p2m_switch_domain_altp2m_by_id().
>
> Note: If altp2m mode is set to mixed the guest is able to change the view
> visibility and then call vmfunc.
>
> Signed-off-by: Alexandru Isaila
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Andrew Cooper
> CC: George Dunlap
> CC: Jan Beulich
> CC: Julien Grall
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: "Roger Pau Monné"
> CC: Jun Nakajima
> CC: Kevin Tian
> ---
> Changes since V5:
> - Change idx type from uint16_t to unsigned int
> - Add rc var and dropped the err return from p2m_get_suppress_ve().
>
> Changes since V4:
> - Move p2m specific things from hvm to p2m.c
> - Add comment for altp2m_idx bounds check
> - Add altp2m_list_lock/unlock().
>
> Changes since V3:
> - Change var name form altp2m_idx to idx to shorten line length
> - Add bounds check for idx
> - Update commit message
> - Add comment in xenctrl.h.
>
> Changes since V2:
> - Drop hap_enabled() check
> - Reduce the indentation depth in hvm.c
> - Fix assignment indentation
> - Drop pad2.
>
> Changes since V1:
> - Drop double view from title.
> ---
> tools/libxc/include/xenctrl.h | 7 +++
> tools/libxc/xc_altp2m.c | 24 +++
> xen/arch/x86/hvm/hvm.c | 14 ++
> xen/arch/x86/hvm/vmx/vmx.c | 2 +-
> xen/arch/x86/mm/hap/hap.c | 15 +++
> xen/arch/x86/mm/p2m-ept.c | 1 +
> xen/arch/x86/mm/p2m.c | 34 +++--
> xen/include/asm-x86/domain.h| 1 +
> xen/include/asm-x86/p2m.h | 4
> xen/include/public/hvm/hvm_op.h | 9 +
> 10 files changed, 108 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index fc6e57a1a0..2e6e652678 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle,
> uint32_t domid,
>xen_pfn_t new_gfn);
> int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
> uint32_t vcpuid, uint16_t *p2midx);
> +/*
> + * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
> + * Note: If altp2m mode is set to mixed the guest is able to change the view
> + * visibility and then call vmfunc.
> + */
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, bool visible);
>
> /**
>* Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 46fb725806..6987c9541f 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle,
> uint32_t domid,
> xc_hypercall_buffer_free(handle, arg);
> return rc;
> }
> +
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, bool visible)
> +{
> +int rc;
> +
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +arg->cmd = HVMOP_altp2m_set_visibility;
> +arg->domain = domid;
> +arg->u.set_visibility.altp2m_idx = view_id;
> +arg->u.set_visibility.visible = visible;
> +
> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> + HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +xc_hypercall_buffer_free(handle, arg);
> +return rc;
> +}
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index db5d7b4d30..7e631e30dd 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4564,6 +4564,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_get_mem_access:
> case HVMOP_altp2m_change_gfn:
> case HVMOP_altp2m_get_p2m_idx:
> +case HVMOP_altp2m_set_visibility:
> break;
>
> default:
> @@ -4841,6 +4842,19 @@ static int do_altp2m_op(
> break;
> }
>
> +case HVMOP_altp2m_set_visibility:
> +{
> +unsigned int idx =
[Xen-devel] [linux-4.19 test] 147953: regressions - FAIL
flight 147953 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/147953/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 142932 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142932 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142932 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 142932 test-amd64-i386-xl-pvshim12 guest-start 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 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-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-arm64-arm64-xl 13 migrate-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-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail 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-amd64-amd64-xl-qemut-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-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-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 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-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-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linuxa083db76118d20d070794ecf79af17843406c3f6 baseline version: linuxc3038e718a19fc596f7b1baba0f83d5146dc7784 Last test of basis 142932 2019-10-19 23:17:10 Z 136 days Failing since143326 2019-10-29 08:49:29 Z 127 days 22 attempts Testing same since 147738 2020-02-28 19:48:23 Z4 days4 attempts
Re: [Xen-devel] [PATCH 1/2] misc: Replace zero-length arrays with flexible array member (automatic)
On 04/03/20 15:12, Philippe Mathieu-Daudé wrote: > I'll send a fix for the dangerous code. > Do you want to drop this series, or only the change in 'struct srp_rsp' > (or in all hw/scsi/srp.h). Actually I guess it makes sense I move the > 'hw/scsi/srp.h' changes with the series cleaning dangerous code. As you prefer, it's not urgent to merge it. Paolo ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 12/23] xen/build: Move as-option-add to xen/
On 26.02.2020 12:33, Anthony PERARD wrote: > Only xen/ uses as-option-add and as-insn, so there aren't needed in > Config.mk. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 10/23] xen/build: run targets csopes, tags, .. without Rules.mk
On 26.02.2020 12:33, Anthony PERARD wrote:
> Those targets make use of $(all_sources) which depends on TARGET_ARCH,
> so we just need to set TARGET_ARCH earlier and once.
>
> XEN_TARGET_ARCH isn't expected to change during the build, so
> TARGET_SUBARCH and TARGET_ARCH aren't going to change either. Set them
> once and for all in the Xen root Makefile. This allows to run more
> targets without Rules.mk.
>
> XEN_TARGET_ARCH is actually changed in arch/x86/boot/build32.mk, but
> it doesn't use the TARGET_{,SUB}ARCH variables either, and doesn't use
> Rules.mk (it replaces it).
>
> TARGET_{,SUB}ARCH are no longer overridden because that would have
> no effect on the values that Rules.mk will use.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 07/23] xen/build: Use obj-y += subdir/ instead of subdir-y
On 27.02.2020 10:43, Jan Beulich wrote: > On 26.02.2020 12:33, Anthony PERARD wrote: >> --- a/xen/Rules.mk >> +++ b/xen/Rules.mk >> @@ -111,17 +111,14 @@ define gendep >> endef >> $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) $(extra-y)),$(eval $(call >> gendep,$(o >> >> -# Ensure each subdirectory has exactly one trailing slash. >> -subdir-n := $(patsubst %,%/,$(patsubst %/,%,$(subdir-n) $(subdir-))) >> -subdir-y := $(patsubst %,%/,$(patsubst %/,%,$(subdir-y))) >> - >> -# Add explicitly declared subdirectories to the object lists. >> -obj-y += $(patsubst %/,%/built_in.o,$(subdir-y)) >> - >> -# Add implicitly declared subdirectories (in the object lists) to the >> -# subdirectory list, and rewrite the object-list entry. >> -subdir-y += $(filter %/,$(obj-y)) >> -obj-y:= $(patsubst %/,%/built-in.o,$(obj-y)) >> +# Handle objects in subdirs >> +# >> --- >> +# o if we encounter foo/ in $(obj-y), replace it by foo/built_in.o >> +# and add the directory to the list of dirs to descend into: $(subdir-y) >> +subdir-y := $(subdir-y) $(filter %/, $(obj-y)) >> +obj-y:= $(patsubst %/, %/built_in.o, $(obj-y)) >> + >> +subdir-n := $(subdir-n) $(subdir-) $(filter %/, $(obj-n) $(obj-)) > > I'm slightly puzzled by the mismatch in blank padding on the three > lines above. I assume the last one is to match ... > >> subdir-all := $(subdir-y) $(subdir-n) > > ... this, but I think it would be better for all of them to match, > or as the 2nd best option, for subdir-n to match subdir-y. Easy > enough to do while committing I guess, but this would want your > consent. Oh, these two lines go away again in patch 9. No need for any adjustment then. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 09/23] xen/build: extract clean target from Rules.mk
On 26.02.2020 12:33, Anthony PERARD wrote: > From: Anthony PERARD > > Most of the code executed by Rules.mk isn't necessary for the clean > target, especially not the CFLAGS. This patch makes running make clean > much faster. > > The patch extract the clean target into a different Makefile, > Makefile.clean. > > Since Makefile.clean, doesn't want to include Config.mk, we need to > define the variables DEPS_INCLUDE and DEPS in a place common to > Rules.mk and Makefile.clean, this is Kbuild.include. DEPS_RM is only > needed in Makefile.clean so can be defined there. > > Even so Rules.mk includes Config.mk, it includes Kbuild.include after, > so the effective definition of DEPS_INCLUDE is "xen/" one and the > same one as used by Makefile.clean. > > This is inspired by Kbuild, with Makefile.clean partially copied from > Linux v5.4. > > Signed-off-by: Anthony PERARD Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] misc: Replace zero-length arrays with flexible array member (automatic)
On 3/4/20 2:44 PM, Paolo Bonzini wrote:
On 04/03/20 14:12, Philippe Mathieu-Daudé wrote:
hw/scsi/spapr_vscsi.c:69:29: error: field 'iu' with variable sized type
'union viosrp_iu' not at the end of a struct or class is a GNU extension
[-Werror,-Wgnu-variable-sized-type-not-at-end]
union viosrp_iu iu;
^
Yay we found a bug! Thanks Gustavo :)
union srp_iu {
struct srp_login_req login_req;
struct srp_login_rsp login_rsp;
struct srp_login_rej login_rej;
struct srp_i_logout i_logout;
struct srp_t_logout t_logout;
struct srp_tsk_mgmt tsk_mgmt;
struct srp_cmd cmd;
struct srp_rsp rsp;
uint8_t reserved[SRP_MAX_IU_LEN];
};
It's variable-sized but it's okay as long as the total size doesn't
exceed SRP_MAX_IU_LEN. So it's not a bug, but I agree it's a time bomb.
Moving the field last should work, but it would still be quite
dangerous code.
Yeah I reached the same conclusion.
I'll send a fix for the dangerous code.
Do you want to drop this series, or only the change in 'struct srp_rsp'
(or in all hw/scsi/srp.h). Actually I guess it makes sense I move the
'hw/scsi/srp.h' changes with the series cleaning dangerous code.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V6] x86/altp2m: Hypercall to set altp2m view visibility
On 04.03.2020 16:07, Jan Beulich wrote: > On 04.03.2020 14:57, Alexandru Stefan ISAILA wrote: >> Hi George, >> >> This is a kind reminder if you can take a look at this patch when you >> have the time. > > Are you perhaps not aware of the recent maintainer change on > xen/arch/x86/mm/? What you need to go hunt is ... > >> On 03.03.2020 14:23, Alexandru Stefan ISAILA wrote: >>> At this moment a guest can call vmfunc to change the altp2m view. This >>> should be limited in order to avoid any unwanted view switch. >>> >>> The new xc_altp2m_set_visibility() solves this by making views invisible >>> to vmfunc. >>> This is done by having a separate arch.altp2m_working_eptp that is >>> populated and made invalid in the same places as altp2m_eptp. This is >>> written to EPTP_LIST_ADDR. >>> The views are made in/visible by marking them with INVALID_MFN or >>> copying them back from altp2m_eptp. >>> To have consistency the visibility also applies to >>> p2m_switch_domain_altp2m_by_id(). >>> >>> Note: If altp2m mode is set to mixed the guest is able to change the view >>> visibility and then call vmfunc. >>> >>> Signed-off-by: Alexandru Isaila >>> --- >>> CC: Ian Jackson >>> CC: Wei Liu >>> CC: Andrew Cooper >>> CC: George Dunlap >>> CC: Jan Beulich >>> CC: Julien Grall >>> CC: Konrad Rzeszutek Wilk >>> CC: Stefano Stabellini >>> CC: "Roger Pau Monné" >>> CC: Jun Nakajima >>> CC: Kevin Tian >>> --- >>> Changes since V5: >>> - Change idx type from uint16_t to unsigned int >>> - Add rc var and dropped the err return from p2m_get_suppress_ve(). >>> >>> Changes since V4: >>> - Move p2m specific things from hvm to p2m.c >>> - Add comment for altp2m_idx bounds check >>> - Add altp2m_list_lock/unlock(). >>> >>> Changes since V3: >>> - Change var name form altp2m_idx to idx to shorten line length >>> - Add bounds check for idx >>> - Update commit message >>> - Add comment in xenctrl.h. >>> >>> Changes since V2: >>> - Drop hap_enabled() check >>> - Reduce the indentation depth in hvm.c >>> - Fix assignment indentation >>> - Drop pad2. >>> >>> Changes since V1: >>> - Drop double view from title. >>> --- >>>tools/libxc/include/xenctrl.h | 7 +++ >>>tools/libxc/xc_altp2m.c | 24 +++ > > ... a tool stack ack and ... > >>>xen/arch/x86/hvm/hvm.c | 14 ++ >>>xen/arch/x86/hvm/vmx/vmx.c | 2 +- > > ... and a VMX one, also for ... > >>>xen/arch/x86/mm/hap/hap.c | 15 +++ >>>xen/arch/x86/mm/p2m-ept.c | 1 + > > ... this. > Ok, tanks for this, I just saw the changes on the maintainers. Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] iommu: fix check for autotranslated hardware domain
On 04.03.2020 15:00, Roger Pau Monne wrote:
> The current position of the check_hwdom_reqs is wrong, as there's a
> is_iommu_enabled at the top of the function that will prevent getting
> to the check on systems without an IOMMU, because the hardware domain
> won't have the XEN_DOMCTL_CDF_iommu flag set.
>
> Move the position of the check so it's done before the
> is_iommu_enabled one, and thus attempts to create a translated
> hardware domain without an IOMMU can be detected.
>
> Fixes: f89f555827a ('remove late (on-demand) construction of IOMMU page
> tables')
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V6] x86/altp2m: Hypercall to set altp2m view visibility
On 04.03.2020 14:57, Alexandru Stefan ISAILA wrote: > Hi George, > > This is a kind reminder if you can take a look at this patch when you > have the time. Are you perhaps not aware of the recent maintainer change on xen/arch/x86/mm/? What you need to go hunt is ... > On 03.03.2020 14:23, Alexandru Stefan ISAILA wrote: >> At this moment a guest can call vmfunc to change the altp2m view. This >> should be limited in order to avoid any unwanted view switch. >> >> The new xc_altp2m_set_visibility() solves this by making views invisible >> to vmfunc. >> This is done by having a separate arch.altp2m_working_eptp that is >> populated and made invalid in the same places as altp2m_eptp. This is >> written to EPTP_LIST_ADDR. >> The views are made in/visible by marking them with INVALID_MFN or >> copying them back from altp2m_eptp. >> To have consistency the visibility also applies to >> p2m_switch_domain_altp2m_by_id(). >> >> Note: If altp2m mode is set to mixed the guest is able to change the view >> visibility and then call vmfunc. >> >> Signed-off-by: Alexandru Isaila >> --- >> CC: Ian Jackson >> CC: Wei Liu >> CC: Andrew Cooper >> CC: George Dunlap >> CC: Jan Beulich >> CC: Julien Grall >> CC: Konrad Rzeszutek Wilk >> CC: Stefano Stabellini >> CC: "Roger Pau Monné" >> CC: Jun Nakajima >> CC: Kevin Tian >> --- >> Changes since V5: >> - Change idx type from uint16_t to unsigned int >> - Add rc var and dropped the err return from p2m_get_suppress_ve(). >> >> Changes since V4: >> - Move p2m specific things from hvm to p2m.c >> - Add comment for altp2m_idx bounds check >> - Add altp2m_list_lock/unlock(). >> >> Changes since V3: >> - Change var name form altp2m_idx to idx to shorten line length >> - Add bounds check for idx >> - Update commit message >> - Add comment in xenctrl.h. >> >> Changes since V2: >> - Drop hap_enabled() check >> - Reduce the indentation depth in hvm.c >> - Fix assignment indentation >> - Drop pad2. >> >> Changes since V1: >> - Drop double view from title. >> --- >> tools/libxc/include/xenctrl.h | 7 +++ >> tools/libxc/xc_altp2m.c | 24 +++ ... a tool stack ack and ... >> xen/arch/x86/hvm/hvm.c | 14 ++ >> xen/arch/x86/hvm/vmx/vmx.c | 2 +- ... and a VMX one, also for ... >> xen/arch/x86/mm/hap/hap.c | 15 +++ >> xen/arch/x86/mm/p2m-ept.c | 1 + ... this. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] xen/x86: hap: Clean-up and harden hap_enable()
On 03/03/2020 13:25, Jan Beulich wrote: On 04.02.2020 14:06, Julien Grall wrote: From: Julien Grall Unlike shadow_enable(), hap_enable() can only be called once during domain creation and with the mode equal to mode equal to PG_external | PG_translate | PG_refcounts. If it were called twice, then we might have something interesting problem as the p2m tables would be re-allocated (and therefore all the mappings would be lost). Add code to sanity check the mode and that the function is only called once. Take the opportunity to an if checking that PG_translate is set. Signed-off-by: Julien Grall Acked-by: Jan Beulich preferably with the duplicate words on the second line of the description dropped. I will remove it on commit. I keep the check != 0 because this is consistent with the rest of the file. If we want to omit comparison against 0, then this should be in a separate patches converting the file. I disagree, but not enough to make the ack dependent upon the adjustment. --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -445,6 +445,13 @@ int hap_enable(struct domain *d, u32 mode) unsigned int i; int rv = 0; +if ( mode != (PG_external | PG_translate | PG_refcounts) ) +return -EINVAL; + +/* The function can only be called once */ +if ( d->arch.paging.mode != 0 ) +return -EEXIST; I think if such a comment gets added, it should be unambiguous. The function can be called once per domain, not just once in total. I will replace with "The function can only be called one per domain". Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] iommu: fix check for autotranslated hardware domain
The current position of the check_hwdom_reqs is wrong, as there's a
is_iommu_enabled at the top of the function that will prevent getting
to the check on systems without an IOMMU, because the hardware domain
won't have the XEN_DOMCTL_CDF_iommu flag set.
Move the position of the check so it's done before the
is_iommu_enabled one, and thus attempts to create a translated
hardware domain without an IOMMU can be detected.
Fixes: f89f555827a ('remove late (on-demand) construction of IOMMU page tables')
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index cab7a068aa..dac1b58fa5 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -172,6 +172,9 @@ int iommu_domain_init(struct domain *d, unsigned int opts)
struct domain_iommu *hd = dom_iommu(d);
int ret = 0;
+if ( is_hardware_domain(d) )
+check_hwdom_reqs(d); /* may modify iommu_hwdom_strict */
+
if ( !is_iommu_enabled(d) )
return 0;
@@ -188,9 +191,6 @@ int iommu_domain_init(struct domain *d, unsigned int opts)
if ( ret || is_system_domain(d) )
return ret;
-if ( is_hardware_domain(d) )
-check_hwdom_reqs(d); /* may modify iommu_hwdom_strict */
-
/*
* Use shared page tables for HAP and IOMMU if the global option
* is enabled (from which we can infer the h/w is capable) and
--
2.25.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V6] x86/altp2m: Hypercall to set altp2m view visibility
Hi George,
This is a kind reminder if you can take a look at this patch when you
have the time.
Thanks,
Alex
On 03.03.2020 14:23, Alexandru Stefan ISAILA wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This is done by having a separate arch.altp2m_working_eptp that is
> populated and made invalid in the same places as altp2m_eptp. This is
> written to EPTP_LIST_ADDR.
> The views are made in/visible by marking them with INVALID_MFN or
> copying them back from altp2m_eptp.
> To have consistency the visibility also applies to
> p2m_switch_domain_altp2m_by_id().
>
> Note: If altp2m mode is set to mixed the guest is able to change the view
> visibility and then call vmfunc.
>
> Signed-off-by: Alexandru Isaila
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Andrew Cooper
> CC: George Dunlap
> CC: Jan Beulich
> CC: Julien Grall
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: "Roger Pau Monné"
> CC: Jun Nakajima
> CC: Kevin Tian
> ---
> Changes since V5:
> - Change idx type from uint16_t to unsigned int
> - Add rc var and dropped the err return from p2m_get_suppress_ve().
>
> Changes since V4:
> - Move p2m specific things from hvm to p2m.c
> - Add comment for altp2m_idx bounds check
> - Add altp2m_list_lock/unlock().
>
> Changes since V3:
> - Change var name form altp2m_idx to idx to shorten line length
> - Add bounds check for idx
> - Update commit message
> - Add comment in xenctrl.h.
>
> Changes since V2:
> - Drop hap_enabled() check
> - Reduce the indentation depth in hvm.c
> - Fix assignment indentation
> - Drop pad2.
>
> Changes since V1:
> - Drop double view from title.
> ---
> tools/libxc/include/xenctrl.h | 7 +++
> tools/libxc/xc_altp2m.c | 24 +++
> xen/arch/x86/hvm/hvm.c | 14 ++
> xen/arch/x86/hvm/vmx/vmx.c | 2 +-
> xen/arch/x86/mm/hap/hap.c | 15 +++
> xen/arch/x86/mm/p2m-ept.c | 1 +
> xen/arch/x86/mm/p2m.c | 34 +++--
> xen/include/asm-x86/domain.h| 1 +
> xen/include/asm-x86/p2m.h | 4
> xen/include/public/hvm/hvm_op.h | 9 +
> 10 files changed, 108 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index fc6e57a1a0..2e6e652678 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle,
> uint32_t domid,
>xen_pfn_t new_gfn);
> int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
> uint32_t vcpuid, uint16_t *p2midx);
> +/*
> + * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
> + * Note: If altp2m mode is set to mixed the guest is able to change the view
> + * visibility and then call vmfunc.
> + */
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, bool visible);
>
> /**
>* Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 46fb725806..6987c9541f 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle,
> uint32_t domid,
> xc_hypercall_buffer_free(handle, arg);
> return rc;
> }
> +
> +int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, bool visible)
> +{
> +int rc;
> +
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +arg->cmd = HVMOP_altp2m_set_visibility;
> +arg->domain = domid;
> +arg->u.set_visibility.altp2m_idx = view_id;
> +arg->u.set_visibility.visible = visible;
> +
> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> + HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +xc_hypercall_buffer_free(handle, arg);
> +return rc;
> +}
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index db5d7b4d30..7e631e30dd 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4564,6 +4564,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_get_mem_access:
> case HVMOP_altp2m_change_gfn:
> case HVMOP_altp2m_get_p2m_idx:
> +case HVMOP_altp2m_set_visibility:
> break;
>
> default:
> @@ -4841,6 +4842,19 @@ static int do_altp2m_op(
> break;
> }
>
> +case HVMOP_altp2m_set_visibility:
> +{
>
Re: [Xen-devel] [PATCH v3 2/2] xenbus: req->err should be updated before req->state
Hi, On 03/03/2020 22:14, Dongli Zhang wrote: This patch adds the barrier to guarantee that req->err is always updated before req->state. Otherwise, read_reply() would not return ERR_PTR(req->err) but req->body, when process_writes()->xb_write() is failed. Signed-off-by: Dongli Zhang Reviewed-by: Julien Grall Cheers, --- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] xenbus: req->body should be updated before req->state
Hi,
On 03/03/2020 22:14, Dongli Zhang wrote:
The req->body should be updated before req->state is updated and the
order should be guaranteed by a barrier.
Otherwise, read_reply() might return req->body = NULL.
Below is sample callstack when the issue is reproduced on purpose by
reordering the updates of req->body and req->state and adding delay in
code between updates of req->state and req->body.
[ 22.356105] general protection fault: [#1] SMP PTI
[ 22.361185] CPU: 2 PID: 52 Comm: xenwatch Not tainted 5.5.0xen+ #6
[ 22.366727] Hardware name: Xen HVM domU, BIOS ...
[ 22.372245] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60
... ...
[ 22.392163] RSP: 0018:b2d64023fdf0 EFLAGS: 00010246
[ 22.395933] RAX: RBX: 75746e7562755f6d RCX:
[ 22.400871] RDX: RSI: b2d64023fdfc RDI: 75746e7562755f6d
[ 22.405874] RBP: R08: 01e8 R09: 00cdcdcd
[ 22.410945] R10: b2d6402ffe00 R11: 9d95395eaeb0 R12: 9d9535935000
[ 22.417613] R13: 9d9526d4a000 R14: 9d9526f4f340 R15: 9d9537654000
[ 22.423726] FS: () GS:9d953bc8()
knlGS:
[ 22.429898] CS: 0010 DS: ES: CR0: 80050033
[ 22.434342] CR2: 00c4206a9000 CR3: 0001ea3fc002 CR4: 001606e0
[ 22.439645] DR0: DR1: DR2:
[ 22.444941] DR3: DR6: fffe0ff0 DR7: 0400
[ 22.450342] Call Trace:
[ 22.452509] simple_strtoull+0x27/0x70
[ 22.455572] xenbus_transaction_start+0x31/0x50
[ 22.459104] netback_changed+0x76c/0xcc1 [xen_netfront]
[ 22.463279] ? find_watch+0x40/0x40
[ 22.466156] xenwatch_thread+0xb4/0x150
[ 22.469309] ? wait_woken+0x80/0x80
[ 22.472198] kthread+0x10e/0x130
[ 22.474925] ? kthread_park+0x80/0x80
[ 22.477946] ret_from_fork+0x35/0x40
[ 22.480968] Modules linked in: xen_kbdfront xen_fbfront(+) xen_netfront
xen_blkfront
[ 22.486783] ---[ end trace a9222030a747c3f7 ]---
[ 22.490424] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60
The virt_rmb() is added in the 'true' path of test_reply(). The "while"
is changed to "do while" so that test_reply() is used as a read memory
barrier.
Signed-off-by: Dongli Zhang
Reviewed-by: Julien Grall
---
Changed since v1:
- change "barrier()" to "virt_rmb()" in test_reply()
Changed since v2:
- Use "virt_rmb()" only in 'true' path
drivers/xen/xenbus/xenbus_comms.c | 2 ++
drivers/xen/xenbus/xenbus_xs.c| 9 ++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_comms.c
b/drivers/xen/xenbus/xenbus_comms.c
index d239fc3c5e3d..852ed161fc2a 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -313,6 +313,8 @@ static int process_msg(void)
req->msg.type = state.msg.type;
req->msg.len = state.msg.len;
req->body = state.body;
+ /* write body, then update state */
+ virt_wmb();
req->state = xb_req_state_got_reply;
req->cb(req);
} else
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index ddc18da61834..3a06eb699f33 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -191,8 +191,11 @@ static bool xenbus_ok(void)
static bool test_reply(struct xb_req_data *req)
{
- if (req->state == xb_req_state_got_reply || !xenbus_ok())
+ if (req->state == xb_req_state_got_reply || !xenbus_ok()) {
+ /* read req->state before all other fields */
+ virt_rmb();
return true;
+ }
/* Make sure to reread req->state each time. */
barrier();
@@ -202,7 +205,7 @@ static bool test_reply(struct xb_req_data *req)
static void *read_reply(struct xb_req_data *req)
{
- while (req->state != xb_req_state_got_reply) {
+ do {
wait_event(req->wq, test_reply(req));
if (!xenbus_ok())
@@ -216,7 +219,7 @@ static void *read_reply(struct xb_req_data *req)
if (req->err)
return ERR_PTR(req->err);
- }
+ } while (req->state != xb_req_state_got_reply);
return req->body;
}
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] misc: Replace zero-length arrays with flexible array member (automatic)
On 04/03/20 14:12, Philippe Mathieu-Daudé wrote:
>
> hw/scsi/spapr_vscsi.c:69:29: error: field 'iu' with variable sized type
> 'union viosrp_iu' not at the end of a struct or class is a GNU extension
> [-Werror,-Wgnu-variable-sized-type-not-at-end]
> union viosrp_iu iu;
> ^
>
> Yay we found a bug! Thanks Gustavo :)
>
> union srp_iu {
> struct srp_login_req login_req;
> struct srp_login_rsp login_rsp;
> struct srp_login_rej login_rej;
> struct srp_i_logout i_logout;
> struct srp_t_logout t_logout;
> struct srp_tsk_mgmt tsk_mgmt;
> struct srp_cmd cmd;
> struct srp_rsp rsp;
> uint8_t reserved[SRP_MAX_IU_LEN];
> };
It's variable-sized but it's okay as long as the total size doesn't
exceed SRP_MAX_IU_LEN. So it's not a bug, but I agree it's a time bomb.
Moving the field last should work, but it would still be quite
dangerous code.
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/6] xen/rcu: add assertions to debug build
Hi,
On 04/03/2020 06:32, Juergen Gross wrote:
diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h
index 31c8b86d13..9f6d420898 100644
--- a/xen/include/xen/rcupdate.h
+++ b/xen/include/xen/rcupdate.h
@@ -34,10 +34,40 @@
#include
#include
#include
-#include
+#include
+#include
#define __rcu
+#ifndef NDEBUG
+DECLARE_PER_CPU(unsigned int, rcu_lock_cnt);
+
+static inline void rcu_quiesce_disable(void)
+{
+this_cpu(rcu_lock_cnt)++;
+arch_lock_acquire_barrier();
I am not sure to understand the goal of this barrier. What are you
trying to protect against?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 03/11] scripts: add coccinelle script to use auto propagated errp
23.02.2020 11:55, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
does corresponding changes in code (look for details in
include/qapi/error.h)
Usage example:
spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
--macro-file scripts/cocci-macro-file.h --in-place --no-show-diff \
blockdev-nbd.c qemu-nbd.c {block/nbd*,nbd/*,include/block/nbd*}.[hc]
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
CC: Eric Blake
CC: Kevin Wolf
CC: Max Reitz
CC: Greg Kurz
CC: Stefano Stabellini
CC: Anthony Perard
CC: Paul Durrant
CC: Stefan Hajnoczi
CC: "Philippe Mathieu-Daudé"
CC: Laszlo Ersek
CC: Gerd Hoffmann
CC: Stefan Berger
CC: Markus Armbruster
CC: Michael Roth
CC: qemu-bl...@nongnu.org
CC: xen-devel@lists.xenproject.org
include/qapi/error.h | 3 +
scripts/coccinelle/auto-propagated-errp.cocci | 158 ++
2 files changed, 161 insertions(+)
create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
diff --git a/include/qapi/error.h b/include/qapi/error.h
index b9452d4806..79f8e95214 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -141,6 +141,9 @@
* ...
* }
*
+ * For mass conversion use script
+ * scripts/coccinelle/auto-propagated-errp.cocci
+ *
*
* Receive and accumulate multiple errors (first one wins):
* Error *err = NULL, *local_err = NULL;
Extra blank line.
diff --git a/scripts/coccinelle/auto-propagated-errp.cocci
b/scripts/coccinelle/auto-propagated-errp.cocci
new file mode 100644
index 00..fb03c871cb
--- /dev/null
+++ b/scripts/coccinelle/auto-propagated-errp.cocci
@@ -0,0 +1,158 @@
+// Use ERRP_AUTO_PROPAGATE (see include/qapi/error.h)
+//
+// Copyright (c) 2020 Virtuozzo International GmbH.
+//
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of the GNU General Public License as published by
+// the Free Software Foundation; either version 2 of the License, or
+// (at your option) any later version.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program. If not, see
[Xen-devel] [PATCH v2 0/4] Introducing QMP query-netdevs command
This patch series introduces a new QMP command "query-netdevs" to get
information about currently attached network devices.
Also, since the "info_str" field of "NetClientState" is now deprecated,
it has been completely removed.
The HMP command "info network" now also uses the new QMP command inside.
Usage example:
-> { "execute": "query-netdevs" }
<- { "return": [
{
"peer": "netdev0",
"netdev": "netdev0",
"perm-mac": "52:54:00:12:34:56"
"model": "virtio-net-pci",
"macaddr": "52:54:00:12:34:56",
"queues-count": 1,
"type": "nic",
"id": "net0"
},
{
"peer": "net0",
"ipv6": true,
"ipv4": true,
"host": "10.0.2.2",
"queues-count": 1,
"ipv6-dns": "fec0::3",
"ipv6-prefix": "fec0::",
"net": "10.0.2.0/255.255.255.0",
"ipv6-host": "fec0::2",
"type": "user",
"dns": "10.0.2.3",
"hostfwd": [
{
"str": "tcp::20004-:22"
}
],
"ipv6-prefixlen": 64,
"id": "netdev0",
"restrict": false
}
]
}
v2->v1:
- Rewrite HMP "info network" to get information from results of QMP command.
- Remove obsolete field "info_str" from "NetClientState".
Alexey Kirillov (4):
qapi: net: Add query-netdevs command
tests: Add tests for query-netdevs command
hmp: Use QMP query-netdevs in hmp_info_network
net: Remove field info_str of NetClientState
hw/net/allwinner_emac.c | 2 +-
hw/net/dp8393x.c | 2 +-
hw/net/e1000.c | 4 +-
hw/net/e1000e.c | 2 +-
hw/net/e1000e_core.c | 2 +-
hw/net/e1000x_common.c | 2 +-
hw/net/eepro100.c| 5 +-
hw/net/etraxfs_eth.c | 2 +-
hw/net/fsl_etsec/etsec.c | 2 +-
hw/net/ftgmac100.c | 2 +-
hw/net/i82596.c | 6 +-
hw/net/imx_fec.c | 2 +-
hw/net/lan9118.c | 4 +-
hw/net/mcf_fec.c | 2 +-
hw/net/milkymist-minimac2.c | 2 +-
hw/net/mipsnet.c | 2 +-
hw/net/ne2000-isa.c | 2 +-
hw/net/ne2000-pci.c | 2 +-
hw/net/pcnet.c | 2 +-
hw/net/rocker/rocker_fp.c| 4 +-
hw/net/rtl8139.c | 6 +-
hw/net/smc91c111.c | 2 +-
hw/net/spapr_llan.c | 6 +-
hw/net/stellaris_enet.c | 2 +-
hw/net/sungem.c | 4 +-
hw/net/sunhme.c | 2 +-
hw/net/tulip.c | 2 +-
hw/net/virtio-net.c | 8 +-
hw/net/vmxnet3.c | 4 +-
hw/net/xen_nic.c | 4 -
hw/net/xgmac.c | 2 +-
hw/net/xilinx_axienet.c | 2 +-
hw/net/xilinx_ethlite.c | 2 +-
hw/usb/dev-network.c | 2 +-
include/net/net.h| 7 +-
net/clients.h| 1 +
net/hub.c| 12 +-
net/hub.h| 2 +-
net/l2tpv3.c | 20 ++-
net/net.c| 272 +--
net/netmap.c | 13 ++
net/slirp.c | 128 ++-
net/socket.c | 93 ---
net/tap-win32.c | 9 +
net/tap.c| 107 ++--
net/vde.c| 40 -
net/vhost-user.c | 20 ++-
qapi/net.json| 89 ++
tests/qtest/Makefile.include | 2 +
tests/qtest/test-query-netdevs.c | 120 ++
50 files changed, 917 insertions(+), 119 deletions(-)
create mode 100644 tests/qtest/test-query-netdevs.c
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 3/4] hmp: Use QMP query-netdevs in hmp_info_network
Replace legacy field info_str of NetClientState with
result of QMP command query-netdevs.
Signed-off-by: Alexey Kirillov
---
include/net/net.h | 3 +-
net/clients.h | 1 +
net/hub.c | 4 +-
net/hub.h | 2 +-
net/net.c | 175 --
net/vde.c | 10 +++
6 files changed, 186 insertions(+), 9 deletions(-)
diff --git a/include/net/net.h b/include/net/net.h
index 2c8956c0b3..9df4680937 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -171,7 +171,8 @@ void qemu_check_nic_model(NICInfo *nd, const char *model);
int qemu_find_nic_model(NICInfo *nd, const char * const *models,
const char *default_model);
-void print_net_client(Monitor *mon, NetClientState *nc);
+void print_net_client(Monitor *mon, NetClientState *nc,
+ NetdevInfoList *ni_list);
void hmp_info_network(Monitor *mon, const QDict *qdict);
void net_socket_rs_init(SocketReadState *rs,
SocketReadStateFinalize *finalize,
diff --git a/net/clients.h b/net/clients.h
index a6ef267e19..f439933522 100644
--- a/net/clients.h
+++ b/net/clients.h
@@ -51,6 +51,7 @@ int net_init_l2tpv3(const Netdev *netdev, const char *name,
#ifdef CONFIG_VDE
int net_init_vde(const Netdev *netdev, const char *name,
NetClientState *peer, Error **errp);
+int net_vde_get_fd(const NetClientState *nc);
#endif
#ifdef CONFIG_NETMAP
diff --git a/net/hub.c b/net/hub.c
index 37995b5517..cce970b59d 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -252,7 +252,7 @@ NetClientState *net_hub_port_find(int hub_id)
/**
* Print hub configuration
*/
-void net_hub_info(Monitor *mon)
+void net_hub_info(Monitor *mon, NetdevInfoList *ni_list)
{
NetHub *hub;
NetHubPort *port;
@@ -263,7 +263,7 @@ void net_hub_info(Monitor *mon)
monitor_printf(mon, " \\ %s", port->nc.name);
if (port->nc.peer) {
monitor_printf(mon, ": ");
-print_net_client(mon, port->nc.peer);
+print_net_client(mon, port->nc.peer, ni_list);
} else {
monitor_printf(mon, "\n");
}
diff --git a/net/hub.h b/net/hub.h
index 66d3322fac..424658a4a2 100644
--- a/net/hub.h
+++ b/net/hub.h
@@ -19,7 +19,7 @@
NetClientState *net_hub_add_port(int hub_id, const char *name,
NetClientState *hubpeer);
NetClientState *net_hub_find_client_by_name(int hub_id, const char *name);
-void net_hub_info(Monitor *mon);
+void net_hub_info(Monitor *mon, NetdevInfoList *ninfo);
void net_hub_check_clients(void);
bool net_hub_flush(NetClientState *nc);
diff --git a/net/net.c b/net/net.c
index 01e0548295..1a8153dbf7 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1271,14 +1271,176 @@ static void netfilter_print_info(Monitor *mon,
NetFilterState *nf)
monitor_printf(mon, "\n");
}
-void print_net_client(Monitor *mon, NetClientState *nc)
+static NetdevInfo *get_netdev_info(NetdevInfoList *ni_list, char *name)
+{
+NetdevInfo *ni;
+
+while (ni_list) {
+ni = ni_list->value;
+if (g_str_equal(ni->id, name)) {
+return ni;
+}
+ni_list = ni_list->next;
+}
+
+return NULL;
+}
+
+static char *generate_info_str(NetdevInfo *ni, NetClientState *nc)
+{
+char *info_str;
+
+if (!ni) {
+return g_malloc0(1);
+}
+
+switch (ni->type) {
+case NET_CLIENT_DRIVER_NIC: {
+info_str = g_strdup_printf("model=%s,macaddr=%s",
+ ni->u.nic.model,
+ ni->u.nic.macaddr);
+break;
+}
+#ifdef CONFIG_SLIRP
+case NET_CLIENT_DRIVER_USER: {
+size_t len = strchr(ni->u.user.net, '/') - ni->u.user.net;
+char *net = g_strndup(ni->u.user.net, len);
+
+info_str = g_strdup_printf("net=%s,restrict=%s",
+ net,
+ ni->u.user.q_restrict ? "on" : "off");
+g_free(net);
+break;
+}
+#endif /* CONFIG_SLIRP */
+case NET_CLIENT_DRIVER_TAP: {
+#ifndef _WIN32
+if (ni->u.tap.has_fds) {
+char **fds = g_strsplit(ni->u.tap.fds, ":", -1);
+
+info_str = g_strdup_printf("fd=%s", fds[nc->queue_index]);
+g_strfreev(fds);
+} else if (ni->u.tap.has_helper) {
+info_str = g_strdup_printf("helper=%s", ni->u.tap.helper);
+} else {
+info_str = g_strdup_printf("ifname=%s,script=%s,downscript=%s",
+ni->u.tap.ifname,
+nc->queue_index == 0 ? ni->u.tap.script : "no",
+nc->queue_index == 0 ? ni->u.tap.downscript : "no");
+}
+#else
+info_str = g_strdup_printf("tap: ifname=%s", ni->u.tap.ifname);
+#endif /* _WIN32 */
+break;
+}
+#ifdef
[Xen-devel] [PATCH v2 4/4] net: Remove field info_str of NetClientState
Completely remove the info_str field of struct NetClientState because
it is no longer required due to the addition of the QMP query-netdevs command.
Signed-off-by: Alexey Kirillov
---
hw/net/allwinner_emac.c | 2 +-
hw/net/dp8393x.c| 2 +-
hw/net/e1000.c | 4 ++--
hw/net/e1000e.c | 2 +-
hw/net/e1000e_core.c| 2 +-
hw/net/e1000x_common.c | 2 +-
hw/net/eepro100.c | 5 +++--
hw/net/etraxfs_eth.c| 2 +-
hw/net/fsl_etsec/etsec.c| 2 +-
hw/net/ftgmac100.c | 2 +-
hw/net/i82596.c | 6 +++---
hw/net/imx_fec.c| 2 +-
hw/net/lan9118.c| 4 ++--
hw/net/mcf_fec.c| 2 +-
hw/net/milkymist-minimac2.c | 2 +-
hw/net/mipsnet.c| 2 +-
hw/net/ne2000-isa.c | 2 +-
hw/net/ne2000-pci.c | 2 +-
hw/net/pcnet.c | 2 +-
hw/net/rocker/rocker_fp.c | 4 ++--
hw/net/rtl8139.c| 6 +++---
hw/net/smc91c111.c | 2 +-
hw/net/spapr_llan.c | 6 +++---
hw/net/stellaris_enet.c | 2 +-
hw/net/sungem.c | 4 ++--
hw/net/sunhme.c | 2 +-
hw/net/tulip.c | 2 +-
hw/net/virtio-net.c | 8
hw/net/vmxnet3.c| 4 ++--
hw/net/xen_nic.c| 4
hw/net/xgmac.c | 2 +-
hw/net/xilinx_axienet.c | 2 +-
hw/net/xilinx_ethlite.c | 2 +-
hw/usb/dev-network.c| 2 +-
include/net/net.h | 3 +--
net/l2tpv3.c| 3 ---
net/net.c | 8 +---
net/slirp.c | 4
net/socket.c| 24
net/tap.c | 12
net/vde.c | 4
net/vhost-user.c| 2 --
42 files changed, 51 insertions(+), 110 deletions(-)
diff --git a/hw/net/allwinner_emac.c b/hw/net/allwinner_emac.c
index e9bbff8710..6abbdbfd4b 100644
--- a/hw/net/allwinner_emac.c
+++ b/hw/net/allwinner_emac.c
@@ -454,7 +454,7 @@ static void aw_emac_realize(DeviceState *dev, Error **errp)
qemu_macaddr_default_if_unset(>conf.macaddr);
s->nic = qemu_new_nic(_aw_emac_info, >conf,
object_get_typename(OBJECT(dev)), dev->id, s);
-qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
+qemu_update_nic_macaddr(qemu_get_queue(s->nic), s->conf.macaddr.a);
fifo8_create(>rx_fifo, RX_FIFO_SIZE);
fifo8_create(>tx_fifo[0], TX_FIFO_SIZE);
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 8a3504d962..a6f95b097b 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -982,7 +982,7 @@ static void dp8393x_realize(DeviceState *dev, Error **errp)
s->nic = qemu_new_nic(_dp83932_info, >conf,
object_get_typename(OBJECT(dev)), dev->id, s);
-qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
+qemu_update_nic_macaddr(qemu_get_queue(s->nic), s->conf.macaddr.a);
s->watchdog = timer_new_ns(QEMU_CLOCK_VIRTUAL, dp8393x_watchdog, s);
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 0b833d5a15..5ae52e37ea 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -1095,7 +1095,7 @@ mac_writereg(E1000State *s, int index, uint32_t val)
if (index == RA + 1) {
macaddr[0] = cpu_to_le32(s->mac_reg[RA]);
macaddr[1] = cpu_to_le32(s->mac_reg[RA + 1]);
-qemu_format_nic_info_str(qemu_get_queue(s->nic), (uint8_t *)macaddr);
+qemu_update_nic_macaddr(qemu_get_queue(s->nic), (uint8_t *)macaddr);
}
}
@@ -1711,7 +1711,7 @@ static void pci_e1000_realize(PCIDevice *pci_dev, Error
**errp)
d->nic = qemu_new_nic(_e1000_info, >conf,
object_get_typename(OBJECT(d)), dev->id, d);
-qemu_format_nic_info_str(qemu_get_queue(d->nic), macaddr);
+qemu_update_nic_macaddr(qemu_get_queue(d->nic), macaddr);
d->autoneg_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, e1000_autoneg_timer,
d);
d->mit_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, e1000_mit_timer, d);
diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
index a91dbdca3c..763661227d 100644
--- a/hw/net/e1000e.c
+++ b/hw/net/e1000e.c
@@ -333,7 +333,7 @@ e1000e_init_net_peer(E1000EState *s, PCIDevice *pci_dev,
uint8_t *macaddr)
trace_e1000e_mac_set_permanent(MAC_ARG(macaddr));
memcpy(s->core.permanent_mac, macaddr, sizeof(s->core.permanent_mac));
-qemu_format_nic_info_str(qemu_get_queue(s->nic), macaddr);
+qemu_update_nic_macaddr(qemu_get_queue(s->nic), macaddr);
/* Setup virtio headers */
if (s->disable_vnet) {
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index 94ea34dca5..358e90b40d 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2731,7 +2731,7 @@ e1000e_mac_setmacaddr(E1000ECore *core, int index,
uint32_t val)
macaddr[0] = cpu_to_le32(core->mac[RA]);
macaddr[1] = cpu_to_le32(core->mac[RA + 1]);
-
[Xen-devel] [PATCH v2 1/4] qapi: net: Add query-netdevs command
Add a qmp command that provides information about currently attached
network devices and their configuration.
Signed-off-by: Alexey Kirillov
---
include/net/net.h | 1 +
net/hub.c | 8 +++
net/l2tpv3.c | 19 +++
net/net.c | 91 +
net/netmap.c | 13 +
net/slirp.c | 126 ++
net/socket.c | 71 ++
net/tap-win32.c | 9
net/tap.c | 103 +++--
net/vde.c | 26 ++
net/vhost-user.c | 18 +--
qapi/net.json | 89
12 files changed, 566 insertions(+), 8 deletions(-)
diff --git a/include/net/net.h b/include/net/net.h
index e175ba9677..2c8956c0b3 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -92,6 +92,7 @@ struct NetClientState {
char *model;
char *name;
char info_str[256];
+NetdevInfo *stored_config;
unsigned receive_disabled : 1;
NetClientDestructor *destructor;
unsigned int queue_index;
diff --git a/net/hub.c b/net/hub.c
index 5795a678ed..37995b5517 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -148,6 +148,7 @@ static NetHubPort *net_hub_port_new(NetHub *hub, const char
*name,
NetHubPort *port;
int id = hub->num_ports++;
char default_name[128];
+NetdevHubPortOptions *stored;
if (!name) {
snprintf(default_name, sizeof(default_name),
@@ -160,6 +161,13 @@ static NetHubPort *net_hub_port_new(NetHub *hub, const
char *name,
port->id = id;
port->hub = hub;
+/* Store startup parameters */
+nc->stored_config = g_new0(NetdevInfo, 1);
+nc->stored_config->type = NET_CLIENT_DRIVER_HUBPORT;
+stored = >stored_config->u.hubport;
+
+stored->hubid = hub->id;
+
QLIST_INSERT_HEAD(>ports, port, next);
return port;
diff --git a/net/l2tpv3.c b/net/l2tpv3.c
index 55fea17c0f..f4e45e7b28 100644
--- a/net/l2tpv3.c
+++ b/net/l2tpv3.c
@@ -535,6 +535,7 @@ int net_init_l2tpv3(const Netdev *netdev,
struct addrinfo hints;
struct addrinfo *result = NULL;
char *srcport, *dstport;
+NetdevL2TPv3Options *stored;
nc = qemu_new_net_client(_l2tpv3_info, peer, "l2tpv3", name);
@@ -726,6 +727,24 @@ int net_init_l2tpv3(const Netdev *netdev,
l2tpv3_read_poll(s, true);
+/* Store startup parameters */
+nc->stored_config = g_new0(NetdevInfo, 1);
+nc->stored_config->type = NET_CLIENT_DRIVER_L2TPV3;
+stored = >stored_config->u.l2tpv3;
+
+memcpy(stored, l2tpv3, sizeof(NetdevL2TPv3Options));
+
+stored->src = g_strdup(l2tpv3->src);
+stored->dst = g_strdup(l2tpv3->dst);
+
+if (l2tpv3->has_srcport) {
+stored->srcport = g_strdup(l2tpv3->srcport);
+}
+
+if (l2tpv3->has_dstport) {
+stored->dstport = g_strdup(l2tpv3->dstport);
+}
+
snprintf(s->nc.info_str, sizeof(s->nc.info_str),
"l2tpv3: connected");
return 0;
diff --git a/net/net.c b/net/net.c
index 9e93c3f8a1..01e0548295 100644
--- a/net/net.c
+++ b/net/net.c
@@ -54,6 +54,7 @@
#include "sysemu/sysemu.h"
#include "net/filter.h"
#include "qapi/string-output-visitor.h"
+#include "qapi/clone-visitor.h"
/* Net bridge is currently not supported for W32. */
#if !defined(_WIN32)
@@ -128,6 +129,12 @@ char *qemu_mac_strdup_printf(const uint8_t *macaddr)
void qemu_format_nic_info_str(NetClientState *nc, uint8_t macaddr[6])
{
+g_assert(nc->stored_config);
+
+g_free(nc->stored_config->u.nic.macaddr);
+nc->stored_config->u.nic.macaddr = g_strdup_printf(MAC_FMT,
+ MAC_ARG(macaddr));
+
snprintf(nc->info_str, sizeof(nc->info_str),
"model=%s,macaddr=%02x:%02x:%02x:%02x:%02x:%02x",
nc->model,
@@ -283,6 +290,7 @@ NICState *qemu_new_nic(NetClientInfo *info,
NetClientState **peers = conf->peers.ncs;
NICState *nic;
int i, queues = MAX(1, conf->peers.queues);
+NetLegacyNicOptions *stored;
assert(info->type == NET_CLIENT_DRIVER_NIC);
assert(info->size >= sizeof(NICState));
@@ -298,6 +306,27 @@ NICState *qemu_new_nic(NetClientInfo *info,
nic->ncs[i].queue_index = i;
}
+/* Store startup parameters */
+nic->ncs[0].stored_config = g_new0(NetdevInfo, 1);
+nic->ncs[0].stored_config->type = NET_CLIENT_DRIVER_NIC;
+stored = >ncs[0].stored_config->u.nic;
+
+/* Read-only in runtime */
+nic->ncs[0].stored_config->has_perm_mac = true;
+nic->ncs[0].stored_config->perm_mac = g_strdup_printf(MAC_FMT,
+MAC_ARG(conf->macaddr.a));
+
+if (peers[0]) {
+stored->has_netdev = true;
+stored->netdev = g_strdup(peers[0]->name);
+}
+
+stored->has_macaddr = true;
+stored->macaddr = g_strdup_printf(MAC_FMT, MAC_ARG(conf->macaddr.a));
+
+stored->has_model = true;
+stored->model = g_strdup(model);
+
return nic;
}
@@ -344,6 +373,7 @@ static
[Xen-devel] [PATCH v2 2/4] tests: Add tests for query-netdevs command
Signed-off-by: Alexey Kirillov
---
tests/qtest/Makefile.include | 2 +
tests/qtest/test-query-netdevs.c | 120 +++
2 files changed, 122 insertions(+)
create mode 100644 tests/qtest/test-query-netdevs.c
diff --git a/tests/qtest/Makefile.include b/tests/qtest/Makefile.include
index e769c1ad70..6924843ef9 100644
--- a/tests/qtest/Makefile.include
+++ b/tests/qtest/Makefile.include
@@ -9,6 +9,7 @@ check-qtest-generic-y += qmp-cmd-test
check-qtest-generic-y += qom-test
check-qtest-generic-$(CONFIG_MODULES) += modules-test
check-qtest-generic-y += test-hmp
+check-qtest-generic-$(CONFIG_SLIRP) += test-query-netdevs
check-qtest-pci-$(CONFIG_RTL8139_PCI) += rtl8139-test
check-qtest-pci-$(CONFIG_VGA) += display-vga-test
@@ -303,6 +304,7 @@ tests/qtest/tpm-crb-test$(EXESUF):
tests/qtest/tpm-crb-test.o tests/qtest/tpm-em
tests/qtest/tpm-tis-swtpm-test$(EXESUF): tests/qtest/tpm-tis-swtpm-test.o
tests/qtest/tpm-emu.o \
tests/qtest/tpm-util.o tests/qtest/tpm-tests.o $(test-io-obj-y)
tests/qtest/tpm-tis-test$(EXESUF): tests/qtest/tpm-tis-test.o
tests/qtest/tpm-emu.o $(test-io-obj-y)
+tests/qtest/test-query-netdevs$(EXESUF): tests/qtest/test-query-netdevs.o
# QTest rules
diff --git a/tests/qtest/test-query-netdevs.c b/tests/qtest/test-query-netdevs.c
new file mode 100644
index 00..e077358a50
--- /dev/null
+++ b/tests/qtest/test-query-netdevs.c
@@ -0,0 +1,120 @@
+/*
+ * QTest testcase for the query-netdevs
+ *
+ * Copyright Yandex N.V., 2019
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+
+#include "libqtest.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qlist.h"
+
+/*
+ * Events can get in the way of responses we are actually waiting for.
+ */
+GCC_FMT_ATTR(2, 3)
+static QObject *wait_command(QTestState *who, const char *command, ...)
+{
+va_list ap;
+QDict *response;
+QObject *result;
+
+va_start(ap, command);
+qtest_qmp_vsend(who, command, ap);
+va_end(ap);
+
+response = qtest_qmp_receive(who);
+
+result = qdict_get(response, "return");
+g_assert(result);
+qobject_ref(result);
+qobject_unref(response);
+
+return result;
+}
+
+static void qmp_query_netdevs_no_error(QTestState *qts,
+ size_t netdevs_count)
+{
+QObject *resp;
+QList *netdevs;
+
+resp = wait_command(qts, "{'execute': 'query-netdevs'}");
+
+netdevs = qobject_to(QList, resp);
+g_assert(netdevs);
+g_assert(qlist_size(netdevs) == netdevs_count);
+
+qobject_unref(resp);
+}
+
+static void test_query_netdevs(void)
+{
+const char *arch = qtest_get_arch();
+size_t correction = 0;
+QObject *resp;
+QTestState *state;
+
+/* Archs which still have a netdev despite of -nodefaults */
+if (g_str_equal(arch, "cris") ||
+g_str_equal(arch, "microblaze") ||
+g_str_equal(arch, "microblazeel") ||
+g_str_equal(arch, "sparc")) {
+correction = 1;
+}
+
+if (g_str_equal(arch, "arm") ||
+g_str_equal(arch, "aarch64")) {
+state = qtest_init(
+"-nodefaults "
+"-M virt "
+"-netdev user,id=slirp0");
+} else if (g_str_equal(arch, "tricore")) {
+state = qtest_init(
+"-nodefaults "
+"-M tricore_testboard "
+"-netdev user,id=slirp0");
+} else {
+state = qtest_init(
+"-nodefaults "
+"-netdev user,id=slirp0");
+}
+g_assert(state);
+
+qmp_query_netdevs_no_error(state, 1 + correction);
+
+resp = wait_command(state,
+"{'execute': 'netdev_add', 'arguments': {"
+" 'id': 'slirp1',"
+" 'type': 'user'}}");
+qobject_unref(resp);
+
+qmp_query_netdevs_no_error(state, 2 + correction);
+
+resp = wait_command(state,
+"{'execute': 'netdev_del', 'arguments': {"
+" 'id': 'slirp1'}}");
+qobject_unref(resp);
+
+qmp_query_netdevs_no_error(state, 1 + correction);
+
+qtest_quit(state);
+}
+
+int main(int argc, char **argv)
+{
+int ret = 0;
+g_test_init(, , NULL);
+
+qtest_add_func("/net/qapi/query_netdevs",
+test_query_netdevs);
+
+ret = g_test_run();
+
+return ret;
+}
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] misc: Replace zero-length arrays with flexible array member (automatic)
On 3/4/20 1:51 AM, Philippe Mathieu-Daudé wrote:
Description copied from Linux kernel commit from Gustavo A. R. Silva
(see [3]):
--v-- description start --v--
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
declare variable-length types such as these ones is a flexible
array member [1], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler
warning in case the flexible array does not occur last in the
structure, which will help us prevent some kind of undefined
behavior bugs from being unadvertenly introduced [2] to the
Linux codebase from now on.
--^-- description end --^--
Do the similar housekeeping in the QEMU codebase (which uses
C99 since commit 7be41675f7cb).
All these instances of code were found with the help of the
following Coccinelle script:
@@
identifier s, a;
type T;
@@
struct s {
...
- T a[0];
+ T a[];
};
@@
identifier s, a;
type T;
@@
struct s {
...
- T a[0];
+ T a[];
} QEMU_PACKED;
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1
Inspired-by: Gustavo A. R. Silva
Signed-off-by: Philippe Mathieu-Daudé
---
bsd-user/qemu.h | 2 +-
contrib/libvhost-user/libvhost-user.h | 2 +-
hw/m68k/bootinfo.h| 2 +-
hw/scsi/srp.h | 6 +++---
hw/xen/xen_pt.h | 2 +-
include/hw/acpi/acpi-defs.h | 12 ++--
include/hw/arm/smmu-common.h | 2 +-
include/hw/i386/intel_iommu.h | 3 ++-
include/hw/virtio/virtio-iommu.h | 2 +-
include/sysemu/cryptodev.h| 2 +-
include/tcg/tcg.h | 2 +-
pc-bios/s390-ccw/bootmap.h| 2 +-
pc-bios/s390-ccw/sclp.h | 2 +-
tests/qtest/libqos/ahci.h | 2 +-
block/linux-aio.c | 2 +-
hw/acpi/nvdimm.c | 6 +++---
hw/dma/soc_dma.c | 2 +-
hw/i386/x86.c | 2 +-
hw/misc/omap_l4.c | 2 +-
hw/nvram/eeprom93xx.c | 2 +-
hw/rdma/vmw/pvrdma_qp_ops.c | 4 ++--
hw/usb/dev-network.c | 2 +-
hw/usb/dev-smartcard-reader.c | 4 ++--
hw/virtio/virtio.c| 4 ++--
net/queue.c | 2 +-
25 files changed, 38 insertions(+), 37 deletions(-)
[...]
diff --git a/hw/scsi/srp.h b/hw/scsi/srp.h
index d27f31d2d5..54c954badd 100644
--- a/hw/scsi/srp.h
+++ b/hw/scsi/srp.h
@@ -112,7 +112,7 @@ struct srp_direct_buf {
struct srp_indirect_buf {
struct srp_direct_buftable_desc;
uint32_t len;
-struct srp_direct_bufdesc_list[0];
+struct srp_direct_bufdesc_list[];
} QEMU_PACKED;
enum {
@@ -211,7 +211,7 @@ struct srp_cmd {
uint8_treserved4;
uint8_tadd_cdb_len;
uint8_tcdb[16];
-uint8_tadd_data[0];
+uint8_tadd_data[];
} QEMU_PACKED;
enum {
@@ -241,7 +241,7 @@ struct srp_rsp {
uint32_t data_in_res_cnt;
uint32_t sense_data_len;
uint32_t resp_data_len;
-uint8_tdata[0];
+uint8_tdata[];
} QEMU_PACKED;
hw/scsi/spapr_vscsi.c:69:29: error: field 'iu' with variable sized type
'union viosrp_iu' not at the end of a struct or class is a GNU extension
[-Werror,-Wgnu-variable-sized-type-not-at-end]
union viosrp_iu iu;
^
Yay we found a bug! Thanks Gustavo :)
union srp_iu {
struct srp_login_req login_req;
struct srp_login_rsp login_rsp;
struct srp_login_rej login_rej;
struct srp_i_logout i_logout;
struct srp_t_logout t_logout;
struct srp_tsk_mgmt tsk_mgmt;
struct srp_cmd cmd;
struct srp_rsp rsp;
uint8_t reserved[SRP_MAX_IU_LEN];
};
union viosrp_iu {
union srp_iu srp;
union mad_iu mad;
};
typedef struct vscsi_req {
vscsi_crq crq;
union viosrp_iu iu;
/* SCSI request tracking */
SCSIRequest *sreq;
uint32_tqtag; /* qemu tag != srp tag */
boolactive;
boolwriting;
booldma_error;
uint32_tdata_len;
uint32_tsenselen;
uint8_t sense[SCSI_SENSE_BUF_SIZE];
/* RDMA related bits */
uint8_t dma_fmt;
uint16_tlocal_desc;
uint16_ttotal_desc;
uint16_tcdb_offset;
uint16_tcur_desc_num;
uint16_t
Re: [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem
On 04.03.2020 13:06, Jürgen Groß wrote: > On 04.03.20 11:49, Jan Beulich wrote: >> On 26.02.2020 13:47, Juergen Gross wrote: >>> +config_data.o: config.gz >> >> Is this really needed? You need to add config.gz as a >> dependency ... >> >>> +config_data.S: $(XEN_ROOT)/xen/tools/binfile >> >> ... here anyway afaict, and then preferably use ... > > Why? config_data.S will look always the same, even if config.gz has > changed. It is just the name of the file which will be put into the > generated source, not its contents. Its the .o file which wants to > be built again if config.gz changes, not the .S file. Oh, right, I forgot this uses the .include directive. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 148059: tolerable all pass - PUSHED
flight 148059 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/148059/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 0d99c909d7e1cbe69329a00f7772946f10a7865b baseline version: xen 0c35d446047aa632ec3a03221814ad5a6a37af97 Last test of basis 148031 2020-03-04 02:26:32 Z0 days Testing same since 148059 2020-03-04 11:01:52 Z0 days1 attempts People who touched revisions under test: Doug Goldstein Paweł Marczewski Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 0c35d44604..0d99c909d7 0d99c909d7e1cbe69329a00f7772946f10a7865b -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
On 04.03.2020 13:00, Jürgen Groß wrote:
> On 03.03.20 17:59, Jan Beulich wrote:
>> On 26.02.2020 13:46, Juergen Gross wrote:
>>> --- /dev/null
>>> +++ b/xen/common/hypfs.c
>>> @@ -0,0 +1,349 @@
>>> +/**
>>> + *
>>> + * hypfs.c
>>> + *
>>> + * Simple sysfs-like file system for the hypervisor.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#ifdef CONFIG_COMPAT
>>> +#include
>>> +CHECK_hypfs_direntry;
>>> +#undef CHECK_hypfs_direntry
>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>
>> I'm struggling to see why you need this #undef and #define.
>
> Without those I get:
>
> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
> from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
> from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
> from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
> from
> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
> from
> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
> from hypfs.c:9:
> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
> ^
> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
> definition of macro ‘CHECK_FIELD_COMMON_’
> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
> expansion of macro ‘CHECK_NAME_’
> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
> ^~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
> expansion of macro ‘CHECK_FIELD_’
> CHECK_FIELD_(struct, hypfs_direntry, flags); \
> ^~~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
> expansion of macro ‘CHECK_hypfs_direntry’
> CHECK_hypfs_direntry; \
> ^~~~
> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
> CHECK_hypfs_dirlistentry;
> ^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
> ^
> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
> definition of macro ‘CHECK_FIELD_COMMON_’
> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
> expansion of macro ‘CHECK_NAME_’
> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
> ^~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
> expansion of macro ‘CHECK_FIELD_’
> CHECK_FIELD_(struct, hypfs_direntry, flags); \
> ^~~~
> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
> CHECK_hypfs_direntry;
Which suggests to me that the explicit CHECK_hypfs_direntry invocation
is unneeded, as it's getting verified as part of the invocation of
CHECK_hypfs_dirlistentry.
>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
>>> ulen)
>>> +{
>>> +char *buf;
>>> +int ret;
>>> +
>>> +if ( ulen > leaf->e.size )
>>> +return -ENOSPC;
>>> +
>>> +if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>> +return -EDOM;
>>
>> Why the exception of string and blob? My concern about the
>> meaning of a partially written entry (without its size having
>> changed) remains.
>
> It is perfectly valid to write a shorter string into a character
> array. I could drop the blob here, but in the end I think allowing
> for a blob to change the size should be fine.
But shouldn't this then also adjust the recorded size?
>>> +buf = xmalloc_array(char, ulen);
>>> +if ( !buf )
>>> +return -ENOMEM;
>>> +
>>> +ret = -EFAULT;
>>> +if ( copy_from_guest(buf, uaddr, ulen) )
>>> +goto out;
>>> +
>>> +ret = -EINVAL;
>>> +if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
>>
>> This should also use the != buf + ulen - 1 form imo.
>
> I'm fine to change that, but should the hypervisor really refuse to
> accept a larger buffer?
To avoid ambiguity I'd prefer if the requirement was that the
caller specify the length of the string (plus the nul char)
rather than the
Re: [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem
On 04.03.20 11:49, Jan Beulich wrote: On 26.02.2020 13:47, Juergen Gross wrote: Add the /buildinfo/config entry to the hypervisor filesystem. This entry contains the .config file used to build the hypervisor. Signed-off-by: Juergen Gross --- V3: - store data in gzip format - use binfile mechanism to create data file - move code to kernel.c V6: - add config item for the /buildinfo/config (Jan Beulich) - make config related variables const in kernel.h (Jan Beulich) --- .gitignore | 2 ++ docs/misc/hypfs-paths.pandoc | 4 xen/common/Kconfig | 10 ++ xen/common/Makefile | 12 xen/common/kernel.c | 15 +++ xen/include/xen/kernel.h | 3 +++ 6 files changed, 46 insertions(+) diff --git a/.gitignore b/.gitignore index fd5610718d..bc8e053ccb 100644 --- a/.gitignore +++ b/.gitignore @@ -297,6 +297,8 @@ xen/arch/*/efi/boot.c xen/arch/*/efi/compat.c xen/arch/*/efi/efi.h xen/arch/*/efi/runtime.c +xen/common/config_data.S +xen/common/config.gz xen/include/headers*.chk xen/include/asm xen/include/asm-*/asm-offsets.h diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc index e392feff27..1faebcccbc 100644 --- a/docs/misc/hypfs-paths.pandoc +++ b/docs/misc/hypfs-paths.pandoc @@ -133,6 +133,10 @@ Information about the compile domain. The compiler used to build Xen. + /buildinfo/config = STRING + +The contents of the `xen/.config` file at the time of the hypervisor build. Perhaps add "..., if enabled at build time"? Yes. --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -1,6 +1,7 @@ obj-$(CONFIG_ARGO) += argo.o obj-y += bitmap.o obj-y += bsearch.o +obj-$(CONFIG_HYPFS_CONFIG) += config_data.o obj-$(CONFIG_CORE_PARKING) += core_parking.o obj-y += cpu.o obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o @@ -73,3 +74,14 @@ subdir-$(CONFIG_UBSAN) += ubsan subdir-$(CONFIG_NEEDS_LIBELF) += libelf subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt + +config.gz: ../.config I think this wants to use $(KCONFIG_CONFIG) now. Okay. + gzip -c $< >$@ We'll want to make sure to switch this to $(if_changed ...) once available (by Anthony's series). Yes. +config_data.o: config.gz Is this really needed? You need to add config.gz as a dependency ... +config_data.S: $(XEN_ROOT)/xen/tools/binfile ... here anyway afaict, and then preferably use ... Why? config_data.S will look always the same, even if config.gz has changed. It is just the name of the file which will be put into the generated source, not its contents. Its the .o file which wants to be built again if config.gz changes, not the .S file. + $(XEN_ROOT)/xen/tools/binfile $@ config.gz xen_config_data ... $< here. +clean:: + rm config_data.S config.gz 2>/dev/null || true Instead of the "|| true" elsewhere we use "rm -f". Okay. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
On 03.03.20 17:59, Jan Beulich wrote:
On 26.02.2020 13:46, Juergen Gross wrote:
--- /dev/null
+++ b/xen/common/hypfs.c
@@ -0,0 +1,349 @@
+/**
+ *
+ * hypfs.c
+ *
+ * Simple sysfs-like file system for the hypervisor.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_COMPAT
+#include
+CHECK_hypfs_direntry;
+#undef CHECK_hypfs_direntry
+#define CHECK_hypfs_direntry struct xen_hypfs_direntry
I'm struggling to see why you need this #undef and #define.
Without those I get:
In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
from
/home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
from
/home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
from hypfs.c:9:
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
redefinition of ‘__checkFstruct_hypfs_direntry__flags’
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry; \
^~~~
hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
CHECK_hypfs_dirlistentry;
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~
hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry;
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+char *buf;
+int ret;
+
+if ( ulen > leaf->e.size )
+return -ENOSPC;
+
+if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
+ leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
+return -EDOM;
Why the exception of string and blob? My concern about the
meaning of a partially written entry (without its size having
changed) remains.
It is perfectly valid to write a shorter string into a character
array. I could drop the blob here, but in the end I think allowing
for a blob to change the size should be fine.
+buf = xmalloc_array(char, ulen);
+if ( !buf )
+return -ENOMEM;
+
+ret = -EFAULT;
+if ( copy_from_guest(buf, uaddr, ulen) )
+goto out;
+
+ret = -EINVAL;
+if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
This should also use the != buf + ulen - 1 form imo.
I'm fine to change that, but should the hypervisor really refuse to
accept a larger buffer?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support
On 26.02.2020 13:47, Juergen Gross wrote:
> The functionality of XEN_SYSCTL_set_parameter is available via hypfs
> now, so it can be removed.
>
> This allows to remove the kernel_param structure for runtime parameters
> by putting the now only used structure element into the hypfs node
> structure of the runtime parameters.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
with one minor adjustment:
> @@ -1102,7 +1086,6 @@ struct xen_sysctl {
> #define XEN_SYSCTL_get_cpu_levelling_caps25
> #define XEN_SYSCTL_get_cpu_featureset26
> #define XEN_SYSCTL_livepatch_op 27
> -#define XEN_SYSCTL_set_parameter 28
Please follow the tmem_op example here and don't outright
delete the line.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
On 26.02.2020 13:47, Juergen Gross wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
> static bool __read_mostly opt_ept_pml = true;
> static s8 __read_mostly opt_ept_ad = -1;
> int8_t __read_mostly opt_ept_exec_sp = -1;
> +static char opt_ept_setting[16];
I don't think this is quite big enough.
> +static void update_ept_param_append(const char *str, int val)
> +{
> +char *pos = opt_ept_setting + strlen(opt_ept_setting);
> +
> +snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
> + ",%s=%d", str, val);
> +}
> +
> +static void update_ept_param(void)
> +{
> +snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d",
> opt_ept_pml);
> +if ( opt_ept_ad >= 0 )
> +update_ept_param_append("ad", opt_ept_ad);
This won't correctly reflect reality: If you look at
vmx_init_vmcs_config(), even a negative value means "true" here,
unless on a specific Atom model. I think init_ept_param() wants
to have that erratum workaround logic moved there, such that
you can then assme the value to be non-negative here.
> +if ( opt_ept_exec_sp >= 0 )
> +update_ept_param_append("exec-sp", opt_ept_exec_sp);
I agree for this one - if the value is still -1, it has neither
been set nor is its value of any interest.
> +static void __init init_ept_param(struct param_hypfs *par)
> +{
> +custom_runtime_set_var(par, opt_ept_setting);
> +update_ept_param();
> +}
>
> static int __init parse_ept_param(const char *s)
> {
> @@ -93,6 +117,8 @@ static int __init parse_ept_param(const char *s)
> s = ss + 1;
> } while ( *ss );
>
> +update_ept_param();
Isn't this redundant with the use in init_ept_param() (or the
other way around - there should be clear ordering between the
command line parsing functions and the param-init ones, I would
suppose)?
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -20,8 +20,27 @@ static __read_mostly enum {
> PCID_OFF,
> PCID_ALL,
> PCID_XPTI,
> -PCID_NOXPTI
> +PCID_NOXPTI,
> +PCID_END
> } opt_pcid = PCID_XPTI;
> +static const char *opt_pcid_2_string[PCID_END] = {
You either want another const here, or (more space efficient) you
want to use const char[PCID_END][7].
> +[PCID_OFF] = "off",
> +[PCID_ALL] = "on",
> +[PCID_XPTI] = "xpti",
> +[PCID_NOXPTI] = "noxpti"
> +};
> +static char opt_pcid_val[7];
> +
> +static void update_opt_pcid(void)
> +{
> +strlcpy(opt_pcid_val, opt_pcid_2_string[opt_pcid], sizeof(opt_pcid_val));
Instead of copying, couldn't you make the hypfs entry point
into the array above, by using custom_runtime_set_var() here?
> @@ -55,9 +74,12 @@ static int parse_pcid(const char *s)
> break;
> }
>
> +if ( !rc )
> +update_opt_pcid();
Personally I'd avoid the if() here - there's no harm updating
the hypfs entry anyway.
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -85,8 +85,10 @@ struct grant_table {
> struct grant_table_arch arch;
> };
>
> -static int parse_gnttab_limit(const char *param, const char *arg,
> - unsigned int *valp)
> +#define GRANT_CUSTOM_VAL_SZ 12
> +
> +static int parse_gnttab_limit(const char *arg, unsigned int *valp,
> + char *parval)
> {
> const char *e;
> unsigned long val;
> @@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const
> char *arg,
> return -ERANGE;
>
> *valp = val;
> +snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
>
> return 0;
> }
>
> unsigned int __read_mostly opt_max_grant_frames = 64;
> +static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
> +
> +static void __init gnttab_max_frames_init(struct param_hypfs *par)
> +{
> +custom_runtime_set_var(par, opt_max_grant_frames_val);
You still use a custom string buffer here. Can this "set-var"
operation record that the variable (for presentation purposes)
is simply of UINT type, handing a pointer to the actual
variable?
> --- a/xen/common/hypfs.c
> +++ b/xen/common/hypfs.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
> return 0;
> }
>
> +int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
> ulen)
> +{
> +struct param_hypfs *p;
> +char *buf;
> +int ret;
> +
> +buf = xzalloc_array(char, ulen);
> +if ( !buf )
> +return -ENOMEM;
> +
> +ret = -EFAULT;
> +if ( copy_from_guest(buf, uaddr, ulen) )
> +goto out;
> +
> +ret = -EDOM;
> +if ( !memchr(buf, 0, ulen) )
Once again " != buf + ulen - 1"? (EDOM also looks like an odd
error code to use in this case, but I guess there's no really
good one.)
>
Re: [Xen-devel] [PATCH 0/2] misc: Replace zero-length arrays with flexible array member
On 04/03/20 01:51, Philippe Mathieu-Daudé wrote:
> This is a tree-wide cleanup inspired by a Linux kernel commit
> (from Gustavo A. R. Silva).
>
> --v-- description start --v--
>
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to
> declare variable-length types such as these ones is a flexible
> array member [1], introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler
> warning in case the flexible array does not occur last in the
> structure, which will help us prevent some kind of undefined
> behavior bugs from being unadvertenly introduced [2] to the
> Linux codebase from now on.
>
> --^-- description end --^--
>
> Do the similar housekeeping in the QEMU codebase (which uses
> C99 since commit 7be41675f7cb).
>
> The first patch is done with the help of a coccinelle semantic
> patch. However Coccinelle does not recognize:
>
> struct foo {
> int stuff;
> struct boo array[];
> } QEMU_PACKED;
>
> but does recognize:
>
> struct QEMU_PACKED foo {
> int stuff;
> struct boo array[];
> };
>
> I'm not sure why, neither it is worth refactoring all QEMU
> structures to use the attributes before the structure name,
> so I did the 2nd patch manually.
>
> Anyway this is annoying, because many structures are not handled
> by coccinelle. Maybe this needs to be reported to upstream
> coccinelle?
>
> I used spatch 1.0.8 with:
>
> -I include --include-headers \
> --macro-file scripts/cocci-macro-file.h \
> --keep-comments --indent 4
>
> Regards,
>
> Phil.
>
> Philippe Mathieu-Daudé (2):
> misc: Replace zero-length arrays with flexible array member
> (automatic)
> misc: Replace zero-length arrays with flexible array member (manual)
>
> docs/interop/vhost-user.rst | 4 ++--
> block/qed.h | 2 +-
> bsd-user/qemu.h | 2 +-
> contrib/libvhost-user/libvhost-user.h | 2 +-
> hw/m68k/bootinfo.h| 2 +-
> hw/scsi/srp.h | 6 +++---
> hw/xen/xen_pt.h | 2 +-
> include/hw/acpi/acpi-defs.h | 16
> include/hw/arm/smmu-common.h | 2 +-
> include/hw/boards.h | 2 +-
> include/hw/i386/intel_iommu.h | 3 ++-
> include/hw/s390x/event-facility.h | 2 +-
> include/hw/s390x/sclp.h | 8
> include/hw/virtio/virtio-iommu.h | 2 +-
> include/sysemu/cryptodev.h| 2 +-
> include/tcg/tcg.h | 2 +-
> pc-bios/s390-ccw/bootmap.h| 2 +-
> pc-bios/s390-ccw/sclp.h | 2 +-
> tests/qtest/libqos/ahci.h | 2 +-
> block/linux-aio.c | 2 +-
> block/vmdk.c | 2 +-
> hw/acpi/nvdimm.c | 6 +++---
> hw/char/sclpconsole-lm.c | 2 +-
> hw/char/sclpconsole.c | 2 +-
> hw/dma/soc_dma.c | 2 +-
> hw/i386/x86.c | 2 +-
> hw/misc/omap_l4.c | 2 +-
> hw/nvram/eeprom93xx.c | 2 +-
> hw/rdma/vmw/pvrdma_qp_ops.c | 4 ++--
> hw/s390x/virtio-ccw.c | 2 +-
> hw/usb/dev-network.c | 2 +-
> hw/usb/dev-smartcard-reader.c | 4 ++--
> hw/virtio/virtio.c| 4 ++--
> net/queue.c | 2 +-
> target/s390x/ioinst.c | 2 +-
> 35 files changed, 54 insertions(+), 53 deletions(-)
>
Queued (minus the qed part).
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/dom0: improve PVH initrd and metadata placement
On Tue, Mar 03, 2020 at 06:47:35PM +, Andrew Cooper wrote:
> On 03/03/2020 11:52, Roger Pau Monne wrote:
> > Don't assume there's going to be enough space at the tail of the
> > loaded kernel and instead try to find a suitable memory area where the
> > initrd and metadata can be loaded.
> >
> > Reported-by: Andrew Cooper
> > Signed-off-by: Roger Pau Monné
>
> I can confirm that this fixes the "failed to boot PVH" on my Rome system.
>
> Tested-by: Andrew Cooper
Thanks!
> We've still got the excessive-time-to-construct issues to look at, but
> this definitely brings things to a better position.
Well, PV is always going to be faster to construct, since you only
need to allocate memory and create the initial page tables that cover
the kernel, the metadata and optionally the initrd IIRC.
On PVH we need to populate the full p2m, so I think it's safe to say
that PVH build time is always going to be worse than PV. That doesn't
mean we can't make it faster.
I have to
Since I also have an AMD box that I can play with, how much memory are
you assigning to dom0?
> > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> > index eded87eaf5..33520ec1bc 100644
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
> > #undef MB1_PAGES
> > }
> >
> > +static paddr_t find_memory(const struct domain *d, const struct elf_binary
> > *elf,
> > + size_t size)
> > +{
> > +paddr_t kernel_start = (paddr_t)elf->dest_base;
> > +paddr_t kernel_end = (paddr_t)(elf->dest_base + elf->dest_size);
> > +unsigned int i;
> > +
> > +for ( i = 0; i < d->arch.nr_e820; i++ )
> > +{
> > +paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
> > +
> > +/* Don't use memory below 1MB, as it could overwrite the BDA/EBDA.
> > */
>
> The BDA is in mfn 0 so is special for other reasons*. The EBDA and IBFT
> are the problem datastructures.
Sure. Sorry I haven't added it to the comment.
> ~Andrew
>
> [*] Thinking about it, how should a PVH hardware domain reconcile its
> paravirtualised boot with finding itself on a BIOS or EFI system...
I guess the same applies to PV which also boots using a PV path but
has access to firmware.
I have to admit I never looked closely at how Linux does that, for
FreeBSD it's fairly easy because at least when booting from BIOS the
kernel won't try to make any calls into the BIOS, and instead expect
the data it requires to be provided by the loader as part of the
metadata blob, together with the modules
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem
On 26.02.2020 13:47, Juergen Gross wrote: > Add the /buildinfo/config entry to the hypervisor filesystem. This > entry contains the .config file used to build the hypervisor. > > Signed-off-by: Juergen Gross > --- > V3: > - store data in gzip format > - use binfile mechanism to create data file > - move code to kernel.c > > V6: > - add config item for the /buildinfo/config (Jan Beulich) > - make config related variables const in kernel.h (Jan Beulich) > --- > .gitignore | 2 ++ > docs/misc/hypfs-paths.pandoc | 4 > xen/common/Kconfig | 10 ++ > xen/common/Makefile | 12 > xen/common/kernel.c | 15 +++ > xen/include/xen/kernel.h | 3 +++ > 6 files changed, 46 insertions(+) > > diff --git a/.gitignore b/.gitignore > index fd5610718d..bc8e053ccb 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -297,6 +297,8 @@ xen/arch/*/efi/boot.c > xen/arch/*/efi/compat.c > xen/arch/*/efi/efi.h > xen/arch/*/efi/runtime.c > +xen/common/config_data.S > +xen/common/config.gz > xen/include/headers*.chk > xen/include/asm > xen/include/asm-*/asm-offsets.h > diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc > index e392feff27..1faebcccbc 100644 > --- a/docs/misc/hypfs-paths.pandoc > +++ b/docs/misc/hypfs-paths.pandoc > @@ -133,6 +133,10 @@ Information about the compile domain. > > The compiler used to build Xen. > > + /buildinfo/config = STRING > + > +The contents of the `xen/.config` file at the time of the hypervisor build. Perhaps add "..., if enabled at build time"? > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -1,6 +1,7 @@ > obj-$(CONFIG_ARGO) += argo.o > obj-y += bitmap.o > obj-y += bsearch.o > +obj-$(CONFIG_HYPFS_CONFIG) += config_data.o > obj-$(CONFIG_CORE_PARKING) += core_parking.o > obj-y += cpu.o > obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o > @@ -73,3 +74,14 @@ subdir-$(CONFIG_UBSAN) += ubsan > > subdir-$(CONFIG_NEEDS_LIBELF) += libelf > subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt > + > +config.gz: ../.config I think this wants to use $(KCONFIG_CONFIG) now. > + gzip -c $< >$@ We'll want to make sure to switch this to $(if_changed ...) once available (by Anthony's series). > +config_data.o: config.gz Is this really needed? You need to add config.gz as a dependency ... > +config_data.S: $(XEN_ROOT)/xen/tools/binfile ... here anyway afaict, and then preferably use ... > + $(XEN_ROOT)/xen/tools/binfile $@ config.gz xen_config_data ... $< here. > +clean:: > + rm config_data.S config.gz 2>/dev/null || true Instead of the "|| true" elsewhere we use "rm -f". Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/sched: fix cpu offlining with core scheduling
On 04.03.20 10:53, Jan Beulich wrote:
On 03.03.2020 18:39, Juergen Gross wrote:
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2299,6 +2299,10 @@ void sched_context_switched(struct vcpu *vprev, struct
vcpu *vnext)
rcu_read_unlock(_res_rculock);
}
+/*
+ * Switch to a new context or keep the current one running.
+ * On x86 it won't return, so it will drop the still held sched_res_rculock.
+ */
static void sched_context_switch(struct vcpu *vprev, struct vcpu *vnext,
bool reset_idle_unit, s_time_t now)
{
I don't follow the comment: There's
return continue_running(vprev);
in the function which afaict can happen on all architectures.
The lock gets dropped there too. I see no path through this
function where the lock would not get dropped.
It was meant as reasoning: due to the fact that sched_context_switch()
won't return on x86, it is required that it will drop sched_res_rculock.
@@ -2408,6 +2412,9 @@ static struct vcpu *sched_force_context_switch(struct
vcpu *vprev,
* zero do_schedule() is called and the rendezvous counter for leaving
* context_switch() is set. All other members will wait until the counter is
* becoming zero, dropping the schedule lock in between.
+ * Either returns the new unit to run, or NULL if no context switch is
+ * required or (on ARM) has already been performed. If NULL is returned
+ * sched_res_rculock has been dropped.
I guess official Arm folks would like Arm to not be spelled all
upper case anymore.
Okay.
@@ -2482,6 +2490,21 @@ static struct sched_unit
*sched_wait_rendezvous_in(struct sched_unit *prev,
atomic_set(>next_task->rendezvous_out_cnt, 0);
prev->rendezvous_in_cnt = 0;
}
+
+/*
+ * Check for scheduling resourced switched. This happens when we are
+ * moved away from our cpupool and cpus are subject of the idle
+ * scheduler now.
+ */
The 'd' on both "resourced" and "switched" are odd to read at
least to me, and hence make me uncertain whether I actually
correctly understand what is meant here.
Should be "resources", of course.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 148055: all pass - PUSHED
flight 148055 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/148055/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 0c35d446047aa632ec3a03221814ad5a6a37af97 baseline version: xen 9649cef3b3a7eaca1347154ea7f274586d48bc29 Last test of basis 147811 2020-03-01 09:31:33 Z3 days Testing same since 148055 2020-03-04 09:22:19 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Dario Faggioli Jan Beulich Juergen Gross Julien Grall Julien Grall Konrad Rzeszutek Wilk Paul Durrant Roger Pau Monné Stefano Stabellini Tony Luck jobs: coverity-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 9649cef3b3..0c35d44604 0c35d446047aa632ec3a03221814ad5a6a37af97 -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] x86/dom0: improve PVH initrd and metadata placement
On Wed, Mar 04, 2020 at 11:31:23AM +0100, Jan Beulich wrote:
> On 04.03.2020 11:25, Roger Pau Monne wrote:
> > Don't assume there's going to be enough space at the tail of the
> > loaded kernel and instead try to find a suitable memory area where the
> > initrd and metadata can be loaded.
> >
> > Reported-by: Andrew Cooper
> > Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Jan Beulich
> preferably with, as Andrew suggested, ...
>
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
> > #undef MB1_PAGES
> > }
> >
> > +static paddr_t find_memory(const struct domain *d, const struct elf_binary
> > *elf,
> > + size_t size)
> > +{
> > +paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> > +paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size,
> > + PAGE_SIZE);
> > +unsigned int i;
> > +
> > +/*
> > + * The memory map is sorted and all RAM regions starts and sizes are
> > + * aligned to page boundaries.
> > + */
> > +for ( i = 0; i < d->arch.nr_e820; i++ )
> > +{
> > +paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
> > +
> > +/* Don't use memory below 1MB, as it could overwrite the BDA/EBDA.
> > */
>
> ... IBFT added here (I'm not worried so much about whether BDA remains
> here or gets dropped). This could of course be done while committing.
Sure, thanks.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] x86/dom0: improve PVH initrd and metadata placement
On 04.03.2020 11:25, Roger Pau Monne wrote:
> Don't assume there's going to be enough space at the tail of the
> loaded kernel and instead try to find a suitable memory area where the
> initrd and metadata can be loaded.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
preferably with, as Andrew suggested, ...
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
> #undef MB1_PAGES
> }
>
> +static paddr_t find_memory(const struct domain *d, const struct elf_binary
> *elf,
> + size_t size)
> +{
> +paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
> +paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size,
> + PAGE_SIZE);
> +unsigned int i;
> +
> +/*
> + * The memory map is sorted and all RAM regions starts and sizes are
> + * aligned to page boundaries.
> + */
> +for ( i = 0; i < d->arch.nr_e820; i++ )
> +{
> +paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
> +
> +/* Don't use memory below 1MB, as it could overwrite the BDA/EBDA. */
... IBFT added here (I'm not worried so much about whether BDA remains
here or gets dropped). This could of course be done while committing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxenstat: fixed Makefile for building python-bindings
Hi Jonas
Thanks for this patch.
On Mon, Mar 02, 2020 at 06:53:38PM +0100, jonas.li...@fem.tu-ilmenau.de wrote:
> Fixes the libxenstat Makefile to determine the correct paths
> of python includes when building python-bindings.
> Also replaces the -lxenstat linking to correct object files
> and use the libdir variable for installing.
>
> Signed-off-by: Jonas Licht
> ---
> tools/xenstat/libxenstat/Makefile | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/tools/xenstat/libxenstat/Makefile
> b/tools/xenstat/libxenstat/Makefile
> index 03cb212e3b..4a02d2e563 100644
> --- a/tools/xenstat/libxenstat/Makefile
> +++ b/tools/xenstat/libxenstat/Makefile
> @@ -114,18 +114,17 @@ $(BINDINGS): $(SHLIB) $(SHLIB_LINKS) src/xenstat.h
> SWIG_FLAGS=-module xenstat -Isrc
>
> # Python bindings
> -PYTHON_VERSION=$(PYTHON:python%=%)
> -PYTHON_FLAGS=-I/usr/include/python$(PYTHON_VERSION)
> -lpython$(PYTHON_VERSION)
> +PYTHON_FLAGS=`$(PYTHON) -c 'import distutils.sysconfig; print("-I" +
A better approach would be to use python-config here.
> distutils.sysconfig.get_python_inc(True) + " " +
> distutils.sysconfig.get_config_var("BLDLIBRARY"))'`
> $(PYMOD): $(PYSRC)
> $(PYSRC): bindings/swig/xenstat.i
> swig -python $(SWIG_FLAGS) -outdir $(@D) -o $(PYSRC) $<
>
> $(PYLIB): $(PYSRC)
> - $(CC) $(CFLAGS) $(LDFLAGS) $(PYTHON_FLAGS) $(SHLIB_LDFLAGS)
> -lxenstat -o $@ $< $(APPEND_LDFLAGS)
> + $(CC) $(CFLAGS) $(LDFLAGS) $(PYTHON_FLAGS) $(SHLIB_LDFLAGS) -o $@ $<
> $(SHLIB) $(LDLIBS-y) $(APPEND_LDFLAGS)
>
> python-bindings: $(PYLIB) $(PYMOD)
>
> -pythonlibdir=$(prefix)/lib/python$(PYTHON_VERSION)/site-packages
> +pythonlibdir=`$(PYTHON) -c 'import distutils.sysconfig;
And here.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-credit2
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-credit2 testid guest-start Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 98d54f81e36ba3bf92172791eba5ca5bd813989b Bug not present: d6d5df1db6e9d7f8f76d2911707f7d5877251b02 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/148053/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-credit2.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-credit2.guest-start --summary-out=tmp/148053.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-amd64-amd64-xl-credit2 guest-start Searching for failure / basis pass: 147912 fail [host=chardonnay1] / 143848 [host=huxelrebe0] 143581 [host=fiano0] 143450 [host=debina0] 143363 [host=pinot0] 143277 [host=debina1] 143242 ok. Failure / basis pass flights: 147912 / 143242 (tree with no url: minios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 98d54f81e36ba3bf92172791eba5ca5bd813989b c530a75c1e6a472b0eb9558310b518f0dfcd8860 70911f1f4aee0366b6122f2b90d367ec0f066beb d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 76551856b28d227cb0386a1ab0e774329b941f7d e465fecbfdb865c75f762055c0396bc617005748 Basis pass d6d5df1db6e9d7f8f76d2911707f7d5877251b02 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6996ec88a244a2428beb81d126ee55d152f62a07 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 120996f147131eca8af90e30c900bc14bc824d9f 518c935fac4d30b3ec35d4b6add82b17b7d7aca3 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#d6d5df1db6e9d7f8f76d2911707f7d5877251b02-98d54f81e36ba3bf92172791eba5ca5bd813989b git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#6996ec88a244a2428beb81d126ee55d152f62a07-70911f1f4aee0366b6122f2b90d367ec0f066beb git://xenbits.xen.org/qemu-xen-traditional.\ git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/osstest/seabios.git#120996f147131eca8af90e30c900bc14bc824d9f-76551856b28d227cb0386a1ab0e774329b941f7d git://xenbits.xen.org/xen.git#518c935fac4d30b3ec35d4b6add82b17b7d7aca3-e465fecbfdb865c75f762055c0396bc617005748 adhoc-revtuple-generator: tree discontiguous: linux-2.6 Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Loaded 8216 nodes in revision graph Searching for test results: 143169 [host=albana1] 143202 [host=elbling0] 143242 pass d6d5df1db6e9d7f8f76d2911707f7d5877251b02 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6996ec88a244a2428beb81d126ee55d152f62a07 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 120996f147131eca8af90e30c900bc14bc824d9f 518c935fac4d30b3ec35d4b6add82b17b7d7aca3 143277 [host=debina1] 143363 [host=pinot0] 143450 [host=debina0] 143581 [host=fiano0] 143848 [host=huxelrebe0] 146850 [] 146904 fail irrelevant 146972 fail irrelevant 147029 fail irrelevant 147082 fail irrelevant 147236 fail irrelevant 147157 fail irrelevant 147320 fail irrelevant 147410 fail irrelevant 147541 fail irrelevant 147480 fail irrelevant 147640 fail irrelevant 147706 fail irrelevant 147798 fail irrelevant 147782 pass d6d5df1db6e9d7f8f76d2911707f7d5877251b02 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6996ec88a244a2428beb81d126ee55d152f62a07 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef
Re: [Xen-devel] [XEN PATCH v4] libxl: wait for console path before firing console_available
On Tue, Mar 03, 2020 at 03:51:04PM +, Anthony PERARD wrote: > On Tue, Mar 03, 2020 at 02:28:20PM +0100, Paweł Marczewski wrote: > > If the path doesn't become available after LIBXL_INIT_TIMEOUT > > seconds, fail the domain creation. > > > > If we skip the bootloader, the TTY path will be set by xenconsoled. > > However, there is no guarantee that this will happen by the time we > > want to call the console_available callback, so we have to wait. > > > > Signed-off-by: Paweł Marczewski > > Reviewed-by: Marek Marczykowski-Górecki > > Reviewed-by: Anthony PERARD Applied. Thanks. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3] x86/dom0: improve PVH initrd and metadata placement
Don't assume there's going to be enough space at the tail of the
loaded kernel and instead try to find a suitable memory area where the
initrd and metadata can be loaded.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Simplify checks since the kernel used memory must always be a
subset of a RAM region.
- Fix comment grammar.
- Align the loaded kernel area to page boundaries.
- For safety assert that all RAM regions in the memory map are
page aligned.
Changes since v1:
- Calculate end of e820 entry earlier.
- Only check if the end of the region is < 1MB.
- Check for range overlaps with the kernel region.
- Check the region is of type RAM.
- Fix off-by-one checks in range overlaps.
- Add a comment about why initrd and metadata is placed together.
- Add parentheses around size calculations.
---
xen/arch/x86/hvm/dom0_build.c | 58 ++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index eded87eaf5..cc719a0208 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
#undef MB1_PAGES
}
+static paddr_t find_memory(const struct domain *d, const struct elf_binary
*elf,
+ size_t size)
+{
+paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
+paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size,
+ PAGE_SIZE);
+unsigned int i;
+
+/*
+ * The memory map is sorted and all RAM regions starts and sizes are
+ * aligned to page boundaries.
+ */
+for ( i = 0; i < d->arch.nr_e820; i++ )
+{
+paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
+
+/* Don't use memory below 1MB, as it could overwrite the BDA/EBDA. */
+if ( end <= MB(1) || d->arch.e820[i].type != E820_RAM )
+continue;
+
+start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
+
+ASSERT(IS_ALIGNED(start, PAGE_SIZE) && IS_ALIGNED(end, PAGE_SIZE));
+
+if ( end <= kernel_start || start >= kernel_end )
+; /* No overlap, nothing to do. */
+/* Deal with the kernel already being loaded in the region. */
+else if ( kernel_start - start > end - kernel_end )
+end = kernel_start;
+else
+start = kernel_end;
+
+if ( end - start >= size )
+return start;
+}
+
+return INVALID_PADDR;
+}
+
static int __init pvh_load_kernel(struct domain *d, const module_t *image,
unsigned long image_headroom,
module_t *initrd, void *image_base,
@@ -546,7 +585,24 @@ static int __init pvh_load_kernel(struct domain *d, const
module_t *image,
return rc;
}
-last_addr = ROUNDUP(parms.virt_kend - parms.virt_base, PAGE_SIZE);
+/*
+ * Find a RAM region big enough (and that doesn't overlap with the loaded
+ * kernel) in order to load the initrd and the metadata. Note it could be
+ * split into smaller allocations, done as a single region in order to
+ * simplify it.
+ */
+last_addr = find_memory(d, , sizeof(start_info) +
+(initrd ? ROUNDUP(initrd->mod_end, PAGE_SIZE) +
+ sizeof(mod)
+: 0) +
+(cmdline ? ROUNDUP(strlen(cmdline) + 1,
+ elf_64bit() ? 8 : 4)
+ : 0));
+if ( last_addr == INVALID_PADDR )
+{
+printk("Unable to find a memory region to load initrd and metadata\n");
+return -ENOMEM;
+}
if ( initrd != NULL )
{
--
2.25.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: Untangle Invariant TSC handling
On 03.03.2020 19:24, Andrew Cooper wrote: > ITSC being visible to the guest is currently implicit with the toolstack > unconditionally asking for it, and Xen clipping it based on the vTSC and/or > XEN_DOMCTL_disable_migrate settings. > > This is problematic for several reasons. > > First, the implicit vTSC behaviour manifests as a real bug on migration to a > host with a different frequency, with ITSC but without TSC scaling > capabilities, whereby the ITSC feature becomes advertised to the guest. ITSC > will disappear again if the guest migrates to server with the same frequency > as the original, or to one with TSC scaling support. > > Secondly, disallowing ITSC unless the guest doesn't migrate is conceptually > wrong. It is common to have migration pools of identical hardware, at which > point the TSC frequency is the same, This statement is too broad: Pools of identical hardware may have the same nominal frequencies, but two distinct systems are hardly ever going to have the exact same actual (measured or even real) frequencies. Recall Olaf's vTSC-tolerance patch that still hasn't landed anywhere? > and more modern hardware has TSC scaling > support anyway. In both cases, it is safe to advertise ITSC and migrate the > guest. > > Remove all implicit logic logic in Xen, and make ITSC part of the max CPUID > policies for guests. Plumb an itsc parameter into xc_cpuid_apply_policy() and > have libxl__cpuid_legacy() fill in the two cases where it can reasonably > expect ITSC to be safe for the guest to see. > > This is a behaviour change for TSC_MODE_NATIVE, where the ITSC will now > reliably not appear, and for the case where the user explicitly requests ITSC, > in which case it will appear even if the guest isn't marked as nomigrate. How sensible is it to allow the user to request something like ITSC with no respective support underneath? Shouldn't we translate such a request into enabling vTSC if there's no ITSC on the platform? Actually looking at the change to libxl__cpuid_legacy() I wonder whether you don't instead mean "requests vTSC" here. > Signed-off-by: Andrew Cooper Assuming I understand the tools side changes correctly, hypervisor side Reviewed-by: Jan Beulich > --- a/tools/libxl/libxl_cpuid.c > +++ b/tools/libxl/libxl_cpuid.c > @@ -418,6 +418,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, > int i; > char *cpuid_res[4]; > bool pae = true; > +bool itsc; > > /* > * For PV guests, PAE is Xen-controlled (it is the 'p' that > differentiates > @@ -432,7 +433,22 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, > if (info->type == LIBXL_DOMAIN_TYPE_HVM) > pae = libxl_defbool_val(info->u.hvm.pae); > > -xc_cpuid_apply_policy(ctx->xch, domid, NULL, 0, pae); > +/* > + * Advertising Invariant TSC to a guest means that the TSC frequency > won't > + * change at any point in the future. > + * > + * We do not have enough information about potential migration > + * destinations to know whether advertising ITSC is safe, but if the > guest > + * isn't going to migrate, then the current hardware is all that matters. > + * > + * Alternatively, an internal property of vTSC is that the values read > are > + * invariant. Advertise ITSC when we know the domain will have emualted > + * TSC everywhere it goes. > + */ > +itsc = (libxl_defbool_val(info->disable_migrate) || > +info->tsc_mode == LIBXL_TSC_MODE_ALWAYS_EMULATE); > + > +xc_cpuid_apply_policy(ctx->xch, domid, NULL, 0, pae, itsc); What's the implication of this on non- or partly-libxl-based tool stacks? Won't a change like this be needed there, too? In particular, is libvirt using this function, such that we won't have a perceived regression again? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/dom0: improve PVH initrd and metadata placement
On Wed, Mar 04, 2020 at 11:00:18AM +0100, Jan Beulich wrote:
> On 04.03.2020 10:53, Roger Pau Monné wrote:
> > On Tue, Mar 03, 2020 at 04:40:36PM +0100, Jan Beulich wrote:
> >> On 03.03.2020 12:52, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/hvm/dom0_build.c
> >>> +++ b/xen/arch/x86/hvm/dom0_build.c
> >>> @@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
> >>> #undef MB1_PAGES
> >>> }
> >>>
> >>> +static paddr_t find_memory(const struct domain *d, const struct
> >>> elf_binary *elf,
> >>> + size_t size)
> >>> +{
> >>> +paddr_t kernel_start = (paddr_t)elf->dest_base;
> >>> +paddr_t kernel_end = (paddr_t)(elf->dest_base + elf->dest_size);
> >>> +unsigned int i;
> >>> +
> >>> +for ( i = 0; i < d->arch.nr_e820; i++ )
> >>> +{
> >>> +paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
> >>> +
> >>> +/* Don't use memory below 1MB, as it could overwrite the
> >>> BDA/EBDA. */
> >>> +if ( end <= MB(1) || d->arch.e820[i].type != E820_RAM )
> >>> +continue;
> >>> +
> >>> +start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
> >>> +
> >>> +if ( end <= kernel_start || start >= kernel_end )
> >>> +; /* No overlap, nothing to do. */
> >>> +/* Deal with the kernel already being loaded in the region. */
> >>> +else if ( kernel_start <= start && kernel_end > start )
> >>
> >> Since, according to your reply on v1, [kernel_start,kernel_end) is
> >> a subset of [start,end), I understand that the <= could equally
> >> well be == - do you agree? From this then ...
> >>
> >>> +/* Truncate the start of the region. */
> >>> +start = ROUNDUP(kernel_end, PAGE_SIZE);
> >>> +else if ( kernel_start <= end && kernel_end > end )
> >>
> >> ... it follows that you now have two off-by-1s here, as you changed
> >> the right side of the && instead of the left one (the right side
> >> could, as per above, use == again). Using == in both places would,
> >> in lieu of a comment, imo make more visible to the reader that
> >> there is this sub-range relationship between both ranges.
> >
> > Right, I agree to both the above and have adjusted the conditions.
> >
> >>> +/* Truncate the end of the region. */
> >>> +end = kernel_start;
> >>> +/* Pick the biggest of the split regions. */
> >>
> >> Then again - wouldn't this part suffice? if start == kernel_start
> >> or end == kernel_end, one side of the "split" region would simply
> >> be empty.
> >
> > That's why it's using an else if construct, so that we only get
> > here if the kernel is loaded in the middle of the region, and there
> > are two regions left as part of the split.
>
> But my question is - do we really need the earlier parts of
> this if/else-if chain? Won't this latter part deal find with
> zero-sized ranges at head or tail of the region?
Oh, I misread your reply sorry. Yes you are right, I can achieve the
same just with this last part.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/dom0: improve PVH initrd and metadata placement
On 04.03.2020 10:53, Roger Pau Monné wrote:
> On Tue, Mar 03, 2020 at 04:40:36PM +0100, Jan Beulich wrote:
>> On 03.03.2020 12:52, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>> @@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
>>> #undef MB1_PAGES
>>> }
>>>
>>> +static paddr_t find_memory(const struct domain *d, const struct elf_binary
>>> *elf,
>>> + size_t size)
>>> +{
>>> +paddr_t kernel_start = (paddr_t)elf->dest_base;
>>> +paddr_t kernel_end = (paddr_t)(elf->dest_base + elf->dest_size);
>>> +unsigned int i;
>>> +
>>> +for ( i = 0; i < d->arch.nr_e820; i++ )
>>> +{
>>> +paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
>>> +
>>> +/* Don't use memory below 1MB, as it could overwrite the BDA/EBDA.
>>> */
>>> +if ( end <= MB(1) || d->arch.e820[i].type != E820_RAM )
>>> +continue;
>>> +
>>> +start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
>>> +
>>> +if ( end <= kernel_start || start >= kernel_end )
>>> +; /* No overlap, nothing to do. */
>>> +/* Deal with the kernel already being loaded in the region. */
>>> +else if ( kernel_start <= start && kernel_end > start )
>>
>> Since, according to your reply on v1, [kernel_start,kernel_end) is
>> a subset of [start,end), I understand that the <= could equally
>> well be == - do you agree? From this then ...
>>
>>> +/* Truncate the start of the region. */
>>> +start = ROUNDUP(kernel_end, PAGE_SIZE);
>>> +else if ( kernel_start <= end && kernel_end > end )
>>
>> ... it follows that you now have two off-by-1s here, as you changed
>> the right side of the && instead of the left one (the right side
>> could, as per above, use == again). Using == in both places would,
>> in lieu of a comment, imo make more visible to the reader that
>> there is this sub-range relationship between both ranges.
>
> Right, I agree to both the above and have adjusted the conditions.
>
>>> +/* Truncate the end of the region. */
>>> +end = kernel_start;
>>> +/* Pick the biggest of the split regions. */
>>
>> Then again - wouldn't this part suffice? if start == kernel_start
>> or end == kernel_end, one side of the "split" region would simply
>> be empty.
>
> That's why it's using an else if construct, so that we only get
> here if the kernel is loaded in the middle of the region, and there
> are two regions left as part of the split.
But my question is - do we really need the earlier parts of
this if/else-if chain? Won't this latter part deal find with
zero-sized ranges at head or tail of the region?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/dom0: improve PVH initrd and metadata placement
On Tue, Mar 03, 2020 at 04:40:36PM +0100, Jan Beulich wrote:
> On 03.03.2020 12:52, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -490,6 +490,45 @@ static int __init pvh_populate_p2m(struct domain *d)
> > #undef MB1_PAGES
> > }
> >
> > +static paddr_t find_memory(const struct domain *d, const struct elf_binary
> > *elf,
> > + size_t size)
> > +{
> > +paddr_t kernel_start = (paddr_t)elf->dest_base;
> > +paddr_t kernel_end = (paddr_t)(elf->dest_base + elf->dest_size);
> > +unsigned int i;
> > +
> > +for ( i = 0; i < d->arch.nr_e820; i++ )
> > +{
> > +paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
> > +
> > +/* Don't use memory below 1MB, as it could overwrite the BDA/EBDA.
> > */
> > +if ( end <= MB(1) || d->arch.e820[i].type != E820_RAM )
> > +continue;
> > +
> > +start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
> > +
> > +if ( end <= kernel_start || start >= kernel_end )
> > +; /* No overlap, nothing to do. */
> > +/* Deal with the kernel already being loaded in the region. */
> > +else if ( kernel_start <= start && kernel_end > start )
>
> Since, according to your reply on v1, [kernel_start,kernel_end) is
> a subset of [start,end), I understand that the <= could equally
> well be == - do you agree? From this then ...
>
> > +/* Truncate the start of the region. */
> > +start = ROUNDUP(kernel_end, PAGE_SIZE);
> > +else if ( kernel_start <= end && kernel_end > end )
>
> ... it follows that you now have two off-by-1s here, as you changed
> the right side of the && instead of the left one (the right side
> could, as per above, use == again). Using == in both places would,
> in lieu of a comment, imo make more visible to the reader that
> there is this sub-range relationship between both ranges.
Right, I agree to both the above and have adjusted the conditions.
> > +/* Truncate the end of the region. */
> > +end = kernel_start;
> > +/* Pick the biggest of the split regions. */
>
> Then again - wouldn't this part suffice? if start == kernel_start
> or end == kernel_end, one side of the "split" region would simply
> be empty.
That's why it's using an else if construct, so that we only get
here if the kernel is loaded in the middle of the region, and there
are two regions left as part of the split.
>
> > +else if ( kernel_start - start > end - kernel_end )
> > +end = kernel_start;
> > +else
> > +start = ROUNDUP(kernel_end, PAGE_SIZE);
> > +
> > +if ( end - start >= size )
> > +return start;
> > +}
> > +
> > +return INVALID_PADDR;
> > +}
> > +
> > static int __init pvh_load_kernel(struct domain *d, const module_t *image,
> >unsigned long image_headroom,
> >module_t *initrd, void *image_base,
> > @@ -546,7 +585,24 @@ static int __init pvh_load_kernel(struct domain *d,
> > const module_t *image,
> > return rc;
> > }
> >
> > -last_addr = ROUNDUP(parms.virt_kend - parms.virt_base, PAGE_SIZE);
> > +/*
> > + * Find a RAM region big enough (and that doesn't overlap with the
> > loaded
> > + * kernel) in order to load the initrd and the metadata. Note it could
> > be
> > + * split into smaller allocations, done it as a single region in order
> > to
> > + * simplify it.
>
> I guess either "done" without "it" or "doing it"?
Fixed, thanks.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
