Re: [Xen-devel] Save/Restore is not working properly
I used save without any option when my VM was in running state, save won't work if I pause a VM. On Sat, Aug 13, 2016 at 11:04 AM, Cendrin Sa wrote: > >- I'm using Xen unstable 4.8 manually compiled on debian , I create a >debian netinst guest using the following config file and then just use >save/restore, after restoring a machine *kernel hangout task happens*. > > >- We've test it With Xen 4.7 manually compiled on ubuntu 14.04 and >the same thing happened. the guest VM was ubuntu 14.04 with GUI, after >restoring we were able to move the mouse but the VM was crashed. > > >- Also, the same *kernel hangout task *happened on CentOS (also its >kernel is 2.6...) and with Xen 4.2. > > These is important to note that after creating VMs using a raw image file > created with both "qemu-img" and "dd" the problem solved and save/restore > is working properly. > It seems there is a problem related to LVM. > > >1. >2. builder = "hvm" >3. memory = 1024 >4. vcpus = 2 >5. name = "debian64" >6. vif = [ 'bridge=xenbr0' ] >7. disk = [ >8. 'file:/dev/vg0/debian64_clone.img,xvda,rw', >9. > 'file:/home/lisbeth/src/debian-8.5.0-amd64-netinst.iso,xvdc:cdrom,r' >10.] >11. >12. boot = "c" > > > On Thu, Aug 11, 2016 at 7:48 PM, Wei Liu wrote: > >> On Wed, Aug 10, 2016 at 02:24:09PM +0100, George Dunlap wrote: >> > On Wed, Aug 10, 2016 at 12:11 PM, Roger Pau Monné >> wrote: >> > > On Sun, Aug 07, 2016 at 07:51:14PM +0430, Cendrin Sa wrote: >> > >> Hi, >> > >> I was searching a way to clone a machine using both memory and disk >> > >> approach. >> > >> I checked xen save/restore but after restoring, I can only work some >> > >> seconds with my machine and it will crash with >> the_kernel_task_hang_up. >> > >> using an script* to clone a machine is not working either. >> > >> so is it a bug or something or I'm cloning the wrong way? >> > > >> > > Hello, >> > > >> > > I've not tried to perform cloning myself, but I have a little script >> to >> > > perform VM checkpoints (so that you can restore the VM to any given >> point in >> > > time). It's based on FreeBSD so it uses ZFS, but it should work with >> LVM >> > > also if you replace it with the appropriate runes. AFAICT it should >> be quite >> > > easy to expand it to also do VM cloning. This is transparent from a >> VM point >> > > of view. >> > >> > FWIW on a recent version of Xen-unstable, "xl save -c" appears to be >> > broken, at least with me CentOS 6 VM. If I do "xl save" then "xl >> > restore", everything works fine; but if I do "xl save -c", then the >> > save appears to work as normal, and after it's done the guest console >> > has output similar to the output it has when restoring, but processes >> > which access the disk hang, and in 2 minutes I get "hung process" >> > output as Cendrin described. >> > >> > I do get some warning messages though: >> > >> > Using NULL legacy PIC >> > WARNING: g.e. still in use! >> > WARNING: leaking g.e. and page still in use! >> > WARNING: g.e. still in use! >> > WARNING: leaking g.e. and page still in use! >> > WARNING: g.e. still in use! >> > WARNING: leaking g.e. and page still in use! >> > Changing capacity of (202, 0) to 4194288 sectors >> > >> > This is the stock CentOS 6.6 kernel: 2.6.32-504.16.2.el6.x86_64 >> > >> >> It looks like the guest kernel is trying to free up all the grant >> references. >> >> In the case of xl save -c my impression is that it shouldn't be doing >> that because the suspend is supposed to be canceled from guest's PoV. >> >> See comment in xenctrl.h for xc_domain_resume. >> >> Also related: 8903a7a5f6a47cc40c1c204a1cc28b0030b04486 >> >> Wei. >> >> > -George >> > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 100470: regressions - FAIL
flight 100470 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100470/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100431 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100431 build-amd64-rumpuserxen 6 xen-buildfail like 100431 build-i386-rumpuserxen6 xen-buildfail like 100431 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100431 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100431 test-amd64-amd64-xl-rtds 9 debian-install fail like 100431 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100431 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100431 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen a55ad65d3a30d5b3a026a7481ce05f28065920f0 baseline version: xen 072e6709978143145a1c1b98c7f014dc4d87907f Last test of basis 100431 2016-08-12 07:34:23 Z0 days Failing since100466 2016-08-12 15:15:07 Z0 days2 attempts Testing same since 100470 2016-08-12 23:44:27 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Razvan Cojocaru Tamas K Lengyel Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt
Re: [Xen-devel] Save/Restore is not working properly
- I'm using Xen unstable 4.8 manually compiled on debian , I create a debian netinst guest using the following config file and then just use save/restore, after restoring a machine *kernel hangout task happens*. - We've test it With Xen 4.7 manually compiled on ubuntu 14.04 and the same thing happened. the guest VM was ubuntu 14.04 with GUI, after restoring we were able to move the mouse but the VM was crashed. - Also, the same *kernel hangout task *happened on CentOS (also its kernel is 2.6...) and with Xen 4.2. These is important to note that after creating VMs using a raw image file created with both "qemu-img" and "dd" the problem solved and save/restore is working properly. It seems there is a problem related to LVM. 1. 2. builder = "hvm" 3. memory = 1024 4. vcpus = 2 5. name = "debian64" 6. vif = [ 'bridge=xenbr0' ] 7. disk = [ 8. 'file:/dev/vg0/debian64_clone.img,xvda,rw', 9. 'file:/home/lisbeth/src/debian-8.5.0-amd64-netinst.iso,xvdc:cdrom,r' 10.] 11. 12. boot = "c" On Thu, Aug 11, 2016 at 7:48 PM, Wei Liu wrote: > On Wed, Aug 10, 2016 at 02:24:09PM +0100, George Dunlap wrote: > > On Wed, Aug 10, 2016 at 12:11 PM, Roger Pau Monné > wrote: > > > On Sun, Aug 07, 2016 at 07:51:14PM +0430, Cendrin Sa wrote: > > >> Hi, > > >> I was searching a way to clone a machine using both memory and disk > > >> approach. > > >> I checked xen save/restore but after restoring, I can only work some > > >> seconds with my machine and it will crash with > the_kernel_task_hang_up. > > >> using an script* to clone a machine is not working either. > > >> so is it a bug or something or I'm cloning the wrong way? > > > > > > Hello, > > > > > > I've not tried to perform cloning myself, but I have a little script to > > > perform VM checkpoints (so that you can restore the VM to any given > point in > > > time). It's based on FreeBSD so it uses ZFS, but it should work with > LVM > > > also if you replace it with the appropriate runes. AFAICT it should be > quite > > > easy to expand it to also do VM cloning. This is transparent from a VM > point > > > of view. > > > > FWIW on a recent version of Xen-unstable, "xl save -c" appears to be > > broken, at least with me CentOS 6 VM. If I do "xl save" then "xl > > restore", everything works fine; but if I do "xl save -c", then the > > save appears to work as normal, and after it's done the guest console > > has output similar to the output it has when restoring, but processes > > which access the disk hang, and in 2 minutes I get "hung process" > > output as Cendrin described. > > > > I do get some warning messages though: > > > > Using NULL legacy PIC > > WARNING: g.e. still in use! > > WARNING: leaking g.e. and page still in use! > > WARNING: g.e. still in use! > > WARNING: leaking g.e. and page still in use! > > WARNING: g.e. still in use! > > WARNING: leaking g.e. and page still in use! > > Changing capacity of (202, 0) to 4194288 sectors > > > > This is the stock CentOS 6.6 kernel: 2.6.32-504.16.2.el6.x86_64 > > > > It looks like the guest kernel is trying to free up all the grant > references. > > In the case of xl save -c my impression is that it shouldn't be doing > that because the suspend is supposed to be canceled from guest's PoV. > > See comment in xenctrl.h for xc_domain_resume. > > Also related: 8903a7a5f6a47cc40c1c204a1cc28b0030b04486 > > Wei. > > > -George > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 66974: regressions - FAIL
This run is configured for baseline tests only. flight 66974 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66974/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 10 guest-start fail REGR. vs. 66966 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66966 test-amd64-amd64-amd64-pvgrub 10 guest-start fail like 66966 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: qemuu28b874429ba16e71e0caa46453f3a3e31efb3c51 baseline version: qemuu2bb15bddf2607110820d5ce5aa43baac27292fb3 Last test of basis66966 2016-08-11 01:50:59 Z2 days Testing same since66974 2016-08-12 09:50:38 Z0 days1 attempts People who touched revisions under test: Amit Shah Cao jin Cornelia Huck Cédric Le Goater Daniel P. Berrange David Gibson Denis V. Lunev Evgeny Yakovlev Gonglei Ilya Maximets Kevin Wolf Laurent Vivier Liang Li Marc-André Lureau Michael S. Tsirkin Paolo Bonzini Peter Maydell Pranith Kumar Prerna Saxena Radim KrÄmáŠStefan Hajnoczi Thomas Huth jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386
Re: [Xen-devel] Unable to add disk on ARM64
Hi Julien, Roger On Fri, Aug 12, 2016 at 04:57:06PM +0200, Roger Pau Monné wrote: >On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote: >> On 12/08/2016 14:24, Peng Fan wrote: >> > Hi, >> >> Hello Peng, >> >> I have CCed Roger who is more familiar than me with the hotplug scripts. >> >> > I am using xen master branch on i.MX8 ARM64. >> > >> > My xl configuration: >> > >> > kernel = "/root/xen/Image" >> > memory = "128" >> > name = "DomU" >> > vcpus = 1 >> > serial="pty" >> > disk = [ 'phy:/dev/loop0,xvda,w' ] >> > extra = "console=hvc0 root=/dev/xvda debug=/bin/sh" >> > >> > >> > And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux. >> > >> > But I met the following error: >> > libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to >> > execute: /etc/xen/scripts/block add ^M^M >> > Device /dev/loop0 is mounted in the privileged domain,^M^M >> > and so cannot be mounted by a guest.^M^M >> > libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: >> > /etc/xen/scripts/block add [800] exited with error status 1^M^M >> > libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch >> > w=0xfee100: deregister unregistered^M^M >> > libxl: error: libxl_devi >> > ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is >> > mounted in the privileged domain,^M^M >> > and so cannot be mounted by a guest.^M^M >> >> From my understanding, you have mounted /dev/loop0 in Dom0, is that correct? >> However, we don't support sharing the same mounting point by default (Roger >> can you confirm). No I only do "losetup /dev/loop0 DomU-rootfs". And I not mount it. > >It seems like the hotplug script has detected that you have the device >already attached to Dom0, can you paste the output of `xenstore-ls -fp` >when this happens? I add xenstore-ls -fp in /etc/xen/scripts/block. " test -b "$dev" || fatal "$dev is not a block device." xenstore-ls -fp ---> Here claim_lock "block" check_device_sharing "$dev" "$mode" ---> seems fail in this function " I use busybox, not sure whether it supports the xen scripts well or not. such as "losetup -a" is not supported by busybox. Log: device_hotplug: calling hotplug script: /etc/xen/scripts/block add libxl: debug: libxl_device.c:1135:device_hotplug: extra args: libxl: debug: libxl_device.c:1143:device_hotplug: env: libxl: debug: libxl_device.c:1150:device_hotplug: script: /etc/xen/scripts/block libxl: debug: libxl_device.c:1150:device_hotplug: XENBUS_TYPE: vbd libxl: debug: libxl_device.c:1150:device_hotplug: XENBUS_PATH: backend/vbd/1/51712 libxl: debug: libxl_device.c:1150:device_hotplug: XENBUS_BASE_PATH: backend libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /etc/xen/scripts/block add /tool = "" (n0) /tool/xenstored = "" (n0) /local = "" (n0) /local/domain = "" (n0) /local/domain/0 = "" (n0) /local/domain/0/domid = "0" (n0) /local/domain/0/name = "Domain-0" (n0) /local/domain/0/backend = "" (n0) /local/domain/0/backend/vbd = "" (n0) /local/domain/0/backend/vbd/1 = "" (n0) /local/domain/0/backend/vbd/1/51712 = "" (n0,r1) /local/domain/0/backend/vbd/1/51712/frontend = "/local/domain/1/device/vbd/51712" (n0,r1) /local/domain/0/backend/vbd/1/51712/params = "/dev/loop0" (n0,r1) /local/domain/0/backend/vbd/1/51712/script = "/etc/xen/scripts/block" (n0,r1) /local/domain/0/backend/vbd/1/51712/frontend-id = "1" (n0,r1) /local/domain/0/backend/vbd/1/51712/online = "1" (n0,r1) /local/domain/0/backend/vbd/1/51712/removable = "0" (n0,r1) /local/domain/0/backend/vbd/1/51712/bootable = "1" (n0,r1) /local/domain/0/backend/vbd/1/51712/state = "2" (n0,r1) /local/domain/0/backend/vbd/1/51712/dev = "xvda" (n0,r1) /local/domain/0/backend/vbd/1/51712/type = "phy" (n0,r1) /local/domain/0/backend/vbd/1/51712/mode = "w" (n0,r1) /local/domain/0/backend/vbd/1/51712/device-type = "disk" (n0,r1) /local/domain/0/backend/vbd/1/51712/discard-enable = "1" (n0,r1) /local/domain/1 = "" (n0,r1) /local/domain/1/vm = "/vm /63997893-f587-4bdc-9bf3-dd5c7614bb51" (n0,r1) /local/domain/1/name = "DomU" (n0,r1) /local/domain/1/cpu = "" (n0,r1) /local/domain/1/cpu/0 = "" (n0,r1) /local/domain/1/cpu/0/availability = "online" (n0,r1) /local/domain/1/memory = "" (n0,r1) /local/domain/1/memory/static-max = "131072" (n0,r1) /local/domain/1/memory/target = "131072" (n0,r1) /local/domain/1/memory/videoram = "0" (n0,r1) /local/domain/1/device = "" (n0,r1) /local/domain/1/device/suspend = "" (n0,r1) /local/domain/1/device/suspend/event-channel = "" (n1) /local/domain/1/device/vbd = "" (n0,r1) /local/domain/1/device/vbd/51712 = "" (n1,r0) /local/domain/1/device/vbd/51712/backend = "/local/domain/0/backend/vbd/1/51712" (n1,r0) /local/domain/1/device/vbd/51712/backend-id = "0" (n1,r0) /local/domain/1/device/vbd/51712/state = "1" (n1,r0) /local/domain/1/device/vbd/51712/virtual-devi
[Xen-devel] [PULL 1/2] Xen: fix converity warning of xen_pt_config_init()
From: Cao jin emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect. Since the remaining message is enough for debugging, so just remove it. Also tweaked the message a little. Signed-off-by: Cao jin Signed-off-by: Stefano Stabellini Acked-by: Stefano Stabellini --- hw/xen/xen_pt_config_init.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c index 9869ffd..6f18366 100644 --- a/hw/xen/xen_pt_config_init.c +++ b/hw/xen/xen_pt_config_init.c @@ -2049,9 +2049,8 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp) for (j = 0; regs->size != 0; j++, regs++) { xen_pt_config_reg_init(s, reg_grp_entry, regs, &err); if (err) { -error_append_hint(&err, "Failed to initialize %d/%zu" -" reg 0x%x in grp_type = 0x%x (%d/%zu)", -j, ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs), +error_append_hint(&err, "Failed to init register %d" +" offsets 0x%x in grp_type = 0x%x (%d/%zu)", j, regs->offset, xen_pt_emu_reg_grps[i].grp_type, i, ARRAY_SIZE(xen_pt_emu_reg_grps)); error_propagate(errp, err); -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PULL 2/2] xen: handle inbound migration of VMs without ioreq server pages
From: Paul Durrant VMs created on older versions on Xen will not have been provisioned with pages to support creation of non-default ioreq servers. In this case the ioreq server API is not supported and QEMU's only option is to fall back to using the default ioreq server pages as it did prior to commit 3996e85c ("Xen: Use the ioreq-server API when available"). This patch therefore changes the code in xen_common.h to stop considering a failure of xc_hvm_create_ioreq_server() as a hard failure but simply as an indication that the guest is too old to support the ioreq server API. Instead a boolean is set to cause reversion to old behaviour such that the default ioreq server is then used. Signed-off-by: Paul Durrant Signed-off-by: Stefano Stabellini Acked-by: Anthony PERARD Acked-by: Stefano Stabellini --- include/hw/xen/xen_common.h | 125 +++- trace-events| 1 + xen-hvm.c | 6 +-- 3 files changed, 92 insertions(+), 40 deletions(-) diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h index 640c31e..bd39287 100644 --- a/include/hw/xen/xen_common.h +++ b/include/hw/xen/xen_common.h @@ -107,6 +107,44 @@ static inline int xen_get_vmport_regs_pfn(xc_interface *xc, domid_t dom, #endif +static inline int xen_get_default_ioreq_server_info(xc_interface *xc, +domid_t dom, +xen_pfn_t *ioreq_pfn, +xen_pfn_t *bufioreq_pfn, +evtchn_port_t +*bufioreq_evtchn) +{ +unsigned long param; +int rc; + +rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); +if (rc < 0) { +fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n"); +return -1; +} + +*ioreq_pfn = param; + +rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); +if (rc < 0) { +fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n"); +return -1; +} + +*bufioreq_pfn = param; + +rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN, + ¶m); +if (rc < 0) { +fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n"); +return -1; +} + +*bufioreq_evtchn = param; + +return 0; +} + /* Xen before 4.5 */ #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450 @@ -154,10 +192,9 @@ static inline void xen_unmap_pcidev(xc_interface *xc, domid_t dom, { } -static inline int xen_create_ioreq_server(xc_interface *xc, domid_t dom, - ioservid_t *ioservid) +static inline void xen_create_ioreq_server(xc_interface *xc, domid_t dom, + ioservid_t *ioservid) { -return 0; } static inline void xen_destroy_ioreq_server(xc_interface *xc, domid_t dom, @@ -171,35 +208,8 @@ static inline int xen_get_ioreq_server_info(xc_interface *xc, domid_t dom, xen_pfn_t *bufioreq_pfn, evtchn_port_t *bufioreq_evtchn) { -unsigned long param; -int rc; - -rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); -if (rc < 0) { -fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n"); -return -1; -} - -*ioreq_pfn = param; - -rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); -if (rc < 0) { -fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n"); -return -1; -} - -*bufioreq_pfn = param; - -rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN, - ¶m); -if (rc < 0) { -fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n"); -return -1; -} - -*bufioreq_evtchn = param; - -return 0; +return xen_get_default_ioreq_server_info(xc, dom, ioreq_pfn, bufioreq_pfn, + bufioreq_evtchn); } static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom, @@ -212,6 +222,8 @@ static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom, /* Xen 4.5 */ #else +static bool use_default_ioreq_server; + static inline void xen_map_memory_section(xc_interface *xc, domid_t dom, ioservid_t ioservid, MemoryRegionSection *section) @@ -220,6 +232,10 @@ static inline void xen_map_memory_section(xc_interface *xc, domid_t dom, ram_addr_t size = int128_get64(section->size); hwaddr end_addr = start_addr + size - 1; +if (use_default_ioreq_server) { +return; +} + trace_xen_map_mmio_range(ioservid, start_addr, end_addr); xc_hvm_map_io_range_to_ioreq_server(xc, dom, ioservid, 1, star
[Xen-devel] [PULL 0/2] xen-20160812-tag-2
The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51: Merge remote-tracking branch 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 17:53:35 +0100) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag-2 for you to fetch changes up to b7665c6027c972c23668ee74b878b5c617218514: xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 16:38:30 -0700) Xen 2016/08/12, fixed commit message Cao jin (1): Xen: fix converity warning of xen_pt_config_init() Paul Durrant (1): xen: handle inbound migration of VMs without ioreq server pages hw/xen/xen_pt_config_init.c | 5 +- include/hw/xen/xen_common.h | 125 +++- trace-events| 1 + xen-hvm.c | 6 +-- 4 files changed, 94 insertions(+), 43 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PULL 0/2] xen-20160812-tag
Sorry, please disregard this pull request, I forgot to add my acked-by to one of the commits. I'll resend shortly. On Fri, 12 Aug 2016, Stefano Stabellini wrote: > The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51: > > Merge remote-tracking branch > 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 > 17:53:35 +0100) > > are available in the git repository at: > > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag > > for you to fetch changes up to f7ca8a4fdcb478fdb0503c2d39b0b85160c913d9: > > xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 > 15:16:15 -0700) > > > Xen 2016/08/12 > > > Cao jin (1): > Xen: fix converity warning of xen_pt_config_init() > > Paul Durrant (1): > xen: handle inbound migration of VMs without ioreq server pages > > hw/xen/xen_pt_config_init.c | 5 +- > include/hw/xen/xen_common.h | 125 > +++- > trace-events| 1 + > xen-hvm.c | 6 +-- > 4 files changed, 94 insertions(+), 43 deletions(-) > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PULL 0/2] xen-20160812-tag
The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51: Merge remote-tracking branch 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 17:53:35 +0100) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag for you to fetch changes up to f7ca8a4fdcb478fdb0503c2d39b0b85160c913d9: xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 15:16:15 -0700) Xen 2016/08/12 Cao jin (1): Xen: fix converity warning of xen_pt_config_init() Paul Durrant (1): xen: handle inbound migration of VMs without ioreq server pages hw/xen/xen_pt_config_init.c | 5 +- include/hw/xen/xen_common.h | 125 +++- trace-events| 1 + xen-hvm.c | 6 +-- 4 files changed, 94 insertions(+), 43 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PULL 1/2] Xen: fix converity warning of xen_pt_config_init()
From: Cao jin emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect. Since the remaining message is enough for debugging, so just remove it. Also tweaked the message a little. Signed-off-by: Cao jin --- hw/xen/xen_pt_config_init.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c index 9869ffd..6f18366 100644 --- a/hw/xen/xen_pt_config_init.c +++ b/hw/xen/xen_pt_config_init.c @@ -2049,9 +2049,8 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp) for (j = 0; regs->size != 0; j++, regs++) { xen_pt_config_reg_init(s, reg_grp_entry, regs, &err); if (err) { -error_append_hint(&err, "Failed to initialize %d/%zu" -" reg 0x%x in grp_type = 0x%x (%d/%zu)", -j, ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs), +error_append_hint(&err, "Failed to init register %d" +" offsets 0x%x in grp_type = 0x%x (%d/%zu)", j, regs->offset, xen_pt_emu_reg_grps[i].grp_type, i, ARRAY_SIZE(xen_pt_emu_reg_grps)); error_propagate(errp, err); -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PULL 2/2] xen: handle inbound migration of VMs without ioreq server pages
From: Paul Durrant VMs created on older versions on Xen will not have been provisioned with pages to support creation of non-default ioreq servers. In this case the ioreq server API is not supported and QEMU's only option is to fall back to using the default ioreq server pages as it did prior to commit 3996e85c ("Xen: Use the ioreq-server API when available"). This patch therefore changes the code in xen_common.h to stop considering a failure of xc_hvm_create_ioreq_server() as a hard failure but simply as an indication that the guest is too old to support the ioreq server API. Instead a boolean is set to cause reversion to old behaviour such that the default ioreq server is then used. Signed-off-by: Paul Durrant Signed-off-by: Stefano Stabellini Acked-by: Anthony PERARD Acked-by: Stefano Stabellini --- include/hw/xen/xen_common.h | 125 +++- trace-events| 1 + xen-hvm.c | 6 +-- 3 files changed, 92 insertions(+), 40 deletions(-) diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h index 640c31e..bd39287 100644 --- a/include/hw/xen/xen_common.h +++ b/include/hw/xen/xen_common.h @@ -107,6 +107,44 @@ static inline int xen_get_vmport_regs_pfn(xc_interface *xc, domid_t dom, #endif +static inline int xen_get_default_ioreq_server_info(xc_interface *xc, +domid_t dom, +xen_pfn_t *ioreq_pfn, +xen_pfn_t *bufioreq_pfn, +evtchn_port_t +*bufioreq_evtchn) +{ +unsigned long param; +int rc; + +rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); +if (rc < 0) { +fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n"); +return -1; +} + +*ioreq_pfn = param; + +rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); +if (rc < 0) { +fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n"); +return -1; +} + +*bufioreq_pfn = param; + +rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN, + ¶m); +if (rc < 0) { +fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n"); +return -1; +} + +*bufioreq_evtchn = param; + +return 0; +} + /* Xen before 4.5 */ #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450 @@ -154,10 +192,9 @@ static inline void xen_unmap_pcidev(xc_interface *xc, domid_t dom, { } -static inline int xen_create_ioreq_server(xc_interface *xc, domid_t dom, - ioservid_t *ioservid) +static inline void xen_create_ioreq_server(xc_interface *xc, domid_t dom, + ioservid_t *ioservid) { -return 0; } static inline void xen_destroy_ioreq_server(xc_interface *xc, domid_t dom, @@ -171,35 +208,8 @@ static inline int xen_get_ioreq_server_info(xc_interface *xc, domid_t dom, xen_pfn_t *bufioreq_pfn, evtchn_port_t *bufioreq_evtchn) { -unsigned long param; -int rc; - -rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); -if (rc < 0) { -fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n"); -return -1; -} - -*ioreq_pfn = param; - -rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); -if (rc < 0) { -fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n"); -return -1; -} - -*bufioreq_pfn = param; - -rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN, - ¶m); -if (rc < 0) { -fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n"); -return -1; -} - -*bufioreq_evtchn = param; - -return 0; +return xen_get_default_ioreq_server_info(xc, dom, ioreq_pfn, bufioreq_pfn, + bufioreq_evtchn); } static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom, @@ -212,6 +222,8 @@ static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom, /* Xen 4.5 */ #else +static bool use_default_ioreq_server; + static inline void xen_map_memory_section(xc_interface *xc, domid_t dom, ioservid_t ioservid, MemoryRegionSection *section) @@ -220,6 +232,10 @@ static inline void xen_map_memory_section(xc_interface *xc, domid_t dom, ram_addr_t size = int128_get64(section->size); hwaddr end_addr = start_addr + size - 1; +if (use_default_ioreq_server) { +return; +} + trace_xen_map_mmio_range(ioservid, start_addr, end_addr); xc_hvm_map_io_range_to_ioreq_server(xc, dom, ioservid, 1, star
[Xen-devel] [xen-unstable test] 100466: regressions - FAIL
flight 100466 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100466/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 7 host-ping-check-xen fail REGR. vs. 100431 test-amd64-amd64-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail REGR. vs. 100431 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 100431 build-i386-rumpuserxen6 xen-buildfail like 100431 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100431 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100431 test-amd64-amd64-xl-rtds 9 debian-install fail like 100431 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100431 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100431 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 20aa9381db781ee050355635efd14a9a37e1d94d baseline version: xen 072e6709978143145a1c1b98c7f014dc4d87907f Last test of basis 100431 2016-08-12 07:34:23 Z0 days Testing same since 100466 2016-08-12 15:15:07 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern
Re: [Xen-devel] [PATCH] xen: handle inbound migration of VMs without ioreq server pages
On Fri, 12 Aug 2016, Paul Durrant wrote: > > -Original Message- > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: 11 August 2016 21:07 > > To: Paul Durrant > > Cc: Anthony Perard; xen-de...@lists.xenproject.org; qemu- > > de...@nongnu.org; Stefano Stabellini > > Subject: RE: [PATCH] xen: handle inbound migration of VMs without ioreq > > server pages > > > > On Tue, 9 Aug 2016, Paul Durrant wrote: > > > > -Original Message- > > > > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > > > > Sent: 09 August 2016 16:19 > > > > To: Paul Durrant > > > > Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano > > > > Stabellini > > > > Subject: Re: [PATCH] xen: handle inbound migration of VMs without > > ioreq > > > > server pages > > > > > > > > On Mon, Aug 01, 2016 at 10:16:25AM +0100, Paul Durrant wrote: > > > > > VMs created on older versions on Xen will not have been provisioned > > with > > > > > pages to support creation of non-default ioreq servers. In this case > > > > > the ioreq server API is not supported and QEMU's only option is to > > > > > fall > > > > > back to using the default ioreq server pages as it did prior to > > > > > commit 3996e85c ("Xen: Use the ioreq-server API when available"). > > > > > > > > > > This patch therefore changes the code in xen_common.h to stop > > > > considering > > > > > a failure of xc_hvm_create_ioreq_server() as a hard failure but simply > > > > > as an indication that the guest is too old to support the ioreq server > > > > > API. Instead a boolean is set to cause reversion to old behaviour such > > > > > that the default ioreq server is then used. > > > > > > > > > > Signed-off-by: Paul Durrant > > > > > Cc: Stefano Stabellini > > > > > Cc: Anthony Perard > > > > > > > > There are just two lines too long: > > > > > > > > WARNING: line over 80 characters > > > > #31: FILE: include/hw/xen/xen_common.h:110: > > > > +static inline int xen_get_default_ioreq_server_info(xc_interface *xc, > > > > domid_t dom, > > > > > > > > WARNING: line over 80 characters > > > > #34: FILE: include/hw/xen/xen_common.h:113: > > > > +evtchn_port_t > > > > *bufioreq_evtchn) > > > > > > > > With that fixed: Acked-by: Anthony PERARD > > > > > > > > > > Thanks, > > > > > > > > > > Ok, I'll post v2 with those fixes and your ack. Thanks, > > > > Thank you for fixing this bug and Thanks Anthony for the review. > > > > I was about to commit it but my sense of style rebelled: I really don't > > like all the if statements. Too many! Sorry for coming in so late in > > commenting on a patch, I realize that it is unfair. > > > > Would you be up for rewriting the fix so that instead of introducing > > > > if (use_default_ioreq_server) { > > return; > > } > > > > in many functions, we turn xc_hvm_* calls into function pointers calls > > that get set to the right behavior depending on the success of > > xc_hvm_create_ioreq_server? > > > > > > The call sites would be something like: > > > > ioreq_server->unmap_io_range_from_ioreq_server(xc, dom, ioservid, 0, > > start_addr, end_addr); > > > > At boot time, if xc_hvm_create_ioreq_server returns error: > > > > ioreq_server = empty_stubs_functions; > > > > else > > > > ioreq_server = useful_functions; > > > > > > What do you guys think? > > Personally I don't think it's worth it. This is not a performance critical > codepath but if you insist I will re-factor the code. All right, given that Anthony already acked it, it's two vs. one. I'll commit it as is. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file
On Fri, 12 Aug 2016, Lars Kurth wrote: > COPYING file: > The motivation of this change is to make it easier for new > contributors to conduct a license and patent review, WITHOUT > changing any licenses. > - Remove references to BSD-style licenses as we have more > common license exceptions and replace with "other license > stanzas" > - List the most common situations under which code is licensed > under licenses other than GPLv2 (section "Licensing Exceptions") > - List the most common non-GPLv2 licenses that are in use in > this repository based on a recent FOSSology scan (section > "Licensing Exceptions") > - List other license related conventions within the project > to make it easier to conduct a license review. > - Clarify the incoming license as its omission has confused > past contributors (section "Contributions") > > CONTRIBUTION file: > The motivation of this file is to make it easier for contributors > to find contribution related resources. Add information on existing > license related conventions to avoid unintentional future licensing > issues. Provide templates for copyright headers for the most commonly > used licenses in this repository. > > Signed-off-by: Lars Kurth Acked-by: Stefano Stabellini > Changed since v1: > * Fixed typos > * Used GPL / LGPL license header spelling out version instead of v > > --- > CONTRIBUTING | 210 > +++ > COPYING | 64 ++ > 2 files changed, 260 insertions(+), 14 deletions(-) > create mode 100644 CONTRIBUTING > > diff --git a/CONTRIBUTING b/CONTRIBUTING > new file mode 100644 > index 000..67ecdb7 > --- /dev/null > +++ b/CONTRIBUTING > @@ -0,0 +1,210 @@ > + > +CONTRIBUTING > + > + > +INBOUND LICENSE > +--- > + > +Contributions are governed by the license that applies to relevant > +specific file or by the license specified in the COPYING file, that > +governs the license of its containing directory and its subdirectories. > + > +Most of the Xen Project code is licensed under GPLv2, but a number of > +directories are primarily licensed under different licenses. > + > +Most notably: > + - tools/blktap2 : BSD-Modified > + - tools/libxc: LGPL v2.1 > + - tools/libxl: LGPL v2.1 > + - xen/include/public : MIT license > + > +When creating new components and directories that contain a > +significant amount of files that are licensed under licenses other > +than GPLv2 or the license specified in the COPYING file, please > +create a new COPYING file in that directory containing a copy of the > +license text and a rationale for using a different license. This helps > +ensure that the license of this new component/directory is maintained > +consistently with the original intention. > + > +When importing code from other upstream projects into this repository, > +please create a README.source file in the directory the code is imported > +to, listing the original source of the code. An example can be found at > +m4/README.source > + > +The COMMON COPYRIGHT NOTICES section of this document contains > +sample copyright notices for the most common licenses used within > +this repository. > + > +Developer's Certificate of Origin > +- > + > +All patches to the Xen Project code base must include the line > +"Signed-off-by: your_name " at the end of the change > +description. This is required and indicates that you certify the patch > +under the "Developer's Certificate of Origin" which states: > + > + Developer's Certificate of Origin 1.1 > + > + By making a contribution to this project, I certify that: > + > + (a) The contribution was created in whole or in part by me and I > + have the right to submit it under the open source license > + indicated in the file; or > + > + (b) The contribution is based upon previous work that, to the best > + of my knowledge, is covered under an appropriate open source > + license and I have the right under that license to submit that > + work with modifications, whether created in whole or in part > + by me, under the same open source license (unless I am > + permitted to submit under a different license), as indicated > + in the file; or > + > + (c) The contribution was provided directly to me by some other > + person who certified (a), (b) or (c) and I have not modified > + it. > + > + (d) I understand and agree that this project and the contribution > + are public and that a record of the contribution (including all > + personal information I submit with it, including my sign-off) is > + maintained indefinitely and may be redistributed consistent with > + this project or the open source license(s) involved. > + > +GOVERNANCE AND WORKFLOW > +--- > + > +The following documents provide a general overview of governance and > +contribution guidelines
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
On Fri, Aug 12, 2016 at 10:23:34PM +0200, Greg KH wrote: > On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: > > Alright, how's this new description: > > > > diff --git a/init/Kconfig b/init/Kconfig > > index cac3f096050d..73e4890c24c4 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -53,6 +53,34 @@ config CROSS_COMPILE > > need to set this unless you want the configured kernel build > > directory to select the cross-compiler automatically. > > > > +config BUILD_AVOID_BITROT > > + bool "Always force building specially annotated targets" > > + default n > > + help > > + If enabled then the the special table-* Makefile targets will always > > + be forced to be compiled even if their respective CONFIG_ option has > > + been disabled, but its objects will only be linked in if the same > > + respective CONFIG_ option has been enabled. This helps avoid code > > + bit rot issues, use for these targets should be carefully considred > > + by maintainers. You can safely enable this option at the expense of > > + increasing compile time. Enabling this option helps avoid code bit > > + rot by taking advantage of the facilities provided and enabled by > > + using linker tables documented under: > > As a kernel developer I have _no_ idea what this is trying to say at > all, sorry. Hmm, wow OK, sorry, and I thought I was being too verbose... OK so first, linker tables allow for the ability to help simplify initialization sequences so that you no longer have to add the respective static inline in header files to do nothing, instead you simply get your init routine for your feature pegged into the linker table or not at link time. If enabling your feature does not require structural changes, you could then safely enable compiling this feature all the time, and only allow linking when the feature was enabled. We don't have an easy way to express this in our build system, the new targets added lets you accomplish this. > What is a "specially annotated target"? The ones listed below, table-obj-y and table-lib-y > Who is forcing it to be built? It would be up to maintainers for each subsystem/feature to decide if they want to use the new targets or not within their subsystem. > What does it mean if it isn't built? If you have CONFIG_BUILD_AVOID_BITROT enabled and some code using the special targets do not get built it means the dependencies it has were not met. > > + > > + include/linux/tables.h > > + > > + The special targets supported are: > > + > > + o table-obj-y > > + o table-lib-y > > What does this mean to me as a developer? It mean you can count on a bit more build test coverage by CONFIG_BUILD_AVOID_BITROT users. Using table-obj-y is functionally equivalent to doing: extra-y += foo.o obj-y += foo.o The above new targets are just short hand annotations for the same. We could actually use another shorthand prefix other than table-, however linker tables help making more of these type of targets possible. For instance, on initialiation sequences you no longer have to add each line for each feature onto a set routine, rather you just get the initialization routine linked in or not. This lets us avoid cluttering C code and header code with #idefs, and as a side consequences also allows more targets to be compiled without implicating functionality. As a developer you should take care to to use table-obj-y, or table-lib-y only if you are certain the target does not require structural changes. > What does it mean to a user > who wants to figure out if it should be enabled or not? It depends on their build system capability and their goals. If they wish to be able to report build bugs and have a decent build system they can enable this. Otherwise they should disable it. > > + Say Y if you have a decent build machine and would like to help test > > + building code for more subsystems. Say N if you do you not have a > > + good build machine or only want to compile what you've enabled for > > + your kernel. > > How does this test different subsystems? By enabling this feature you compile kconfig symbols that typically are disabled by most users and which have been identified by maintainers as needing more build testing love. The extra kconfig symbols built are only built if the dependencies for them are met. Maintainers for subsystems would have to identify if they have key pieces of software that typically get disabled, and that enabling them would not incur or require structural changes, which can use more build test love. > How does disabling it not test them? By disabling this feature you only compile kconfig symbols you have enabled for your kernel. > Why would I care either way? You would care if you aware of certain kconfig symbols that do not get much build test love. > > + > > + Enabling this option never increases the size of your kernel. > > Then what does it do?
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On Fri, 12 Aug 2016, Jan Beulich wrote: > > +Let me express this as an algorithm. > > + > > + treshhold=2/3; > > + active='number of active members'; (7 for the Hypervisor project; > > IanC is inactive) > > + favour='number of +1 and +2 votes' > > + against='number of -1 and -2 votes' > > + strong-against='number -2 votes'; just added this as a sanity check > > + > > +One open question is what to do with 0-votes. We could introduce a > > rule discounting > > +0 votes (let's call it 0-rule). If someone votes 0, we assume they > > really don't care > > +about the outcome and are considered inactive for the purpose of the > > vote. > > + > > +In that case: > > + > > + active -= 0-votes; > > + > > +Without the 0-rule: > > +- to pass: favour/active >= treshhold > > + to pass: with active==7, favour >= 5 > > + in other words, 3 (0,-1,-2)-votes block the proposal as we cant > > achieve favour>=5 > > + > > +With the 0-rule, let's consider 1, 2 or 3 0-votes > > +1=>6: to pass: favour >=4 > > + in other words, 3 (-1,-2)-votes block the proposal > > +2=>5: to pass: favour >=4 > > + in other words, 2 (-1,-2)-vote blocks the proposal > > +3=>4: to pass: favour >=3 > > + in other words, 2 (-1,-2)-vote blocks the proposal > > + > > +Looking at the arithmetic, it does probably make sense to go for the > > 0-rule. If we > > +do, there ought to be more votes in favour of a proposal, than 0-votes. > > + > > +On the other hand, not having the 0-rule forces everyone to form an > > opinion, > > +otherise we will find it hard to make decisions. But in some cases, > > forming an > > +opinion costs significant mental capacity. > > + > > +It would also allow us to remove the complexity of differentiating > > between > > +active and non-active leadership team members by assuming that no > > vote, equals > > +a "0" vote. > > + > > +Opinions? > > I'm in favor of the "with 0-rule" variant. I am also in favor of the 0-rule ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-jessie test] 66973: tolerable all pass
flight 66973 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66973/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail never pass test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail never pass baseline version: flight 66922 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub pass test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub pass test-amd64-amd64-i386-jessie-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [seabios baseline-only test] 66971: tolerable FAIL
This run is configured for baseline tests only. flight 66971 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66971/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66956 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66956 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66956 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: seabios 19e8ea6312f3f60c34c2c20f95fb81306b320f74 baseline version: seabios 8bc6d9f8e9bd1c211660f9ec91c237821d7f4089 Last test of basis66956 2016-08-09 19:20:46 Z3 days Testing same since66971 2016-08-11 20:26:15 Z1 days1 attempts People who touched revisions under test: Kevin O'Connor Stefan Berger jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 19e8ea6312f3f60c34c2c20f95fb81306b320f74 Author: Kevin O'Connor Date: Tue Aug 9 13:24:51 2016 -0400 tpm: Append to TPM2 log the hashes used for PCR extension Modify the function that writes the TPM logs to take the same digest passed to tpm_extend. Update the tpm2 acpi log header to describe the digest format. Signed-off-by: Stefan Berger Signed-off-by: Kevin O'Connor commit a99de5c35df0419ed630437c31031e145351dbc8 Author: Stefan Berger Date: Fri Aug 5 11:07:11 2016 -0400 tpm: Extend tpm20_extend to support extending to multiple PCR banks Extend the tpm20_extend function to support extending a hash to multiple PCR banks. The sha1 hash that's being extended into the sha256 bank for example, will be filled with zero-bytes to the size of a sha256 hash. Signed-off-by: Stefan Berger Signed-off-by: Kevin O'Connor commit 3b97efad61e39cf430286b6cb85db64069c0a951 Author: Stefan Berger Date: Fri Aug 5 11:07:10 2016 -0400 tpm: Refactor tpml_digest_values_sha1 structure Refactor the tpml_digest_values_sha1 structure so we can later cast it to the more general tpml_digest_values structure. Move the count member into this structure. Signed-off-by: Stefan Berger commit 0fb23c327d553049500d251ae9376c3e2ce1f2d1 Author: Stefan Berger Date: Fri Aug 5 11:07:09 2016 -0400 tpm: Restructure tpm20_extend to use buffer and take hash as parameter Restructure the tpm20_extend function to use a buffer for the command to send to the TPM. The size of the buffer is calculated from the size of tpm2_req_extend structure
Re: [Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file
On Fri, 12 Aug 2016, Lars Kurth wrote: > On 11/08/2016 19:59, "Stefano Stabellini" wrote: > > >On Thu, 11 Aug 2016, Lars Kurth wrote: > >> On 11/08/2016 01:51, "Stefano Stabellini" > >>wrote: > >> > >> >> +Developer's Certificate of Origin > >> >> +- > >> >> + > >> >> +All patches to the Xen Project code base must include the the line > >> > ^ double > >>"the" > >> > >> Thanks: will fix. And also fixed in the wiki page where I copied this > >>from. > >> > >> > >> >> +GOVERNANCE AND WORKFLOW > >> >> +--- > >> >> + > >> >> +The following documents provide a general overview of governance and > >> >> +contribution guidelines for the Xen Project: > >> >> + - https://xenproject.org/governance.html > >> >> + - https://xenproject.org/help/contribution-guidelines.html > >> > > >> >It might be worth considering importing the governance as a file in the > >> >Xen repository. > >> > >> After discussing with a few committers, I think storing this in a git > >>repo > >> is a good idea: possibly as markup. It should not be in xen.git though, > >> but probably in a new governance.git tree, for which I am maintainer. > > > >That's a good idea. It would make far easier to review changes to it in > >the future. I'd suggest markdown, which is actually quite nice to use > >and has already been used for a few design docs, including pv calls and > >xsplice. > > See > https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg01667.html > Lars That was quick! Well done! ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 66972: all pass
This run is configured for baseline tests only. flight 66972 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66972/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 926059304e8377fc37bb848d06d9419f419d93ff baseline version: ovmf af90df3cb099ed8e009579b7b55e7142dc0fc410 Last test of basis66965 2016-08-10 21:19:32 Z2 days Testing same since66972 2016-08-11 23:52:02 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Laszlo Ersek Liming Gao Thomas Huth 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. (No revision log; it would be 491 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Very RFC PATCH 3/3] livepatch: Initial ARM32/64 support.
On Fri, Aug 12, 2016 at 05:00:47PM +0200, Julien Grall wrote: > Hi Konrad, > > On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote: > > The initial support for ARM64 - and livepatching > > works: > > As it is a very RFC I only gave a quick look. I have few comments on it (see > below). > > > > > (XEN) livepatch: xen_hello_world: Applying 1 functions > > (XEN) hi_func: Hi! (called 1 times) > > (XEN) Hook executing. > > (XEN) livepatch: xen_hello_world finished APPLY with rc=0 > > (XEN) livepatch.c:1687: livepatch: load_payload_fnc: rc=0 (p->rc=0) > > (XEN) livepatch: Hello World > > (XEN) 'x' pressed - Dumping all livepatch patches > > (XEN) build-id: e144bafc4ee8635eee5bed8e3988b484765c46c8 > > (XEN) name=xen_hello_world state=APPLIED(2) 00318000 > > (.data=00319000, .rodata=0031a000) using 3 pages. > > (XEN) xen_extra_version patch 00233fac(12) with > > 00318000 (16) > > (XEN) build-id=c4b842c276be43adbe4db788598b1e11bce04dc6 > > (XEN) depend-on=9affa110481e8e13606c61b21e5f6a357a3c8ef9 > > > > ARM32 still has some issues. > > > > The are some TODOs left to be done: > > > > General: > > - Bubble ALT_ORIG_PTR macro for both x86/ARM. > > - Unify the ELF RELA checks - they are the same on x86/ARM[32,64]. > > - Makefile generating .livepatch.depends needs to ingest the > > -O argument based on architecture > > - Test cases should move to common/ ? [Needs Jan's Ack] > > In general, I would be in favor of sharing as much as possible the code. > > > ARM32 issues: > > - vm_init_type: Assertion 'is_xen_heap_mfn(ma >> PAGE_SHIFT)' failed at > > xen/include/asm/mm.h:23 > > xen/include/asm/mm.h:23 points to the beginning of struct page_info. Did you > mean to write instead 233? Probably. > > This would point to maddr_virt. This would mean someone is trying to get the > virtual address of MFN that is not in the xenheap (only the xenheap is > mapped on ARM32). Do you have the full call stack? No :-( I need to rebuild it and put it on the board. Maybe in a week? > > [...] > > > > > Signed-off-by: Konrad Rzeszutek Wilk > > [...] > > > diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c > > index aba1320..67749ed 100644 > > --- a/xen/arch/arm/livepatch.c > > +++ b/xen/arch/arm/livepatch.c > > @@ -6,66 +6,100 @@ > > #include > > #include > > #include > > +#include > > +#include "livepatch.h" > > + > > +#include > > + > > +void *vmap_of_xen_text; > > > > void arch_livepatch_quiesce(void) > > { > > +mfn_t text_mfn; > > +unsigned int text_order; > > + > > +if ( vmap_of_xen_text ) > > +return; > > + > > +text_mfn = _mfn(virt_to_mfn(_stext)); > > +text_order = get_order_from_bytes(_end - _start); > > + > > +/* > > + * The text section is read-only. So re-map Xen to be able to patch > > + * the code. > > + */ > > +vmap_of_xen_text = __vmap(&text_mfn, 1 << text_order, 1, 1, > > PAGE_HYPERVISOR, > > + VMAP_DEFAULT); > > Shouldn't we return an error if we fail to re-map the region? > > Otherwise the patch may silently be ignored (see arch_livepatch_apply_jmp). We do actually bail out of patching if vmap_of_xen_text is NULL. But let me add a return (-ENOMEM) to this so that we don't attempt to do any patching and print a nice message. > > > } > > > > void arch_livepatch_revive(void) > > { > > +/* Nuke the instruction cache */ > > +invalidate_icache(); > > I was about to say that this is not enough. But you called > clean_and_invalidate_* every time you rewrite the jump. It might be worth to > add a comment here, explain that the cache has been cleaned before hand. > > However, I can't find any data cache flush for the payload. Did I miss > anything? No just didn't occur to me - as we patch the .text not the .data. I will take a look at the existing code and see if I can find out how to do the data cache flush. > > Lastly, before I forgot, you will need to invalidate the branch predictor > for ARMv7 as it may be architecturally visible to the software (see B2.2.4 > in ARM DDI 0406C.b). OK. > > > + > > +if ( vmap_of_xen_text ) > > +vunmap(vmap_of_xen_text); > > + > > +vmap_of_xen_text = NULL; > > } > > > > int arch_livepatch_verify_func(const struct livepatch_func *func) > > { > > -return -ENOSYS; > > -} > > +/* No NOP patching yet. */ > > +if ( !func->new_size ) > > +return -EOPNOTSUPP; > > > > -void arch_livepatch_apply_jmp(struct livepatch_func *func) > > -{ > > -} > > +if ( func->old_size < PATCH_INSN_SIZE ) > > +return -EINVAL; > > > > -void arch_livepatch_revert_jmp(const struct livepatch_func *func) > > -{ > > +return 0; > > } > > > > void arch_livepatch_post_action(void) > > { > > +/* arch_livepatch_revive has nuked the instruction cache. */ > > } > > > > void arch_livepatch_mask(void) > > { > > +/* TODO: No NMI on ARM? */ > > All interrupts can be masked on ARM so
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
On Fri, 12 Aug 2016, Greg KH wrote: > > + Enabling this option never increases the size of your kernel. > > Then what does it do? Just burn electricity for no reason? I think that this whole thing could be without loss of generality reformulated in a "allows for participating in compile-testing code efforts, without actually having to have all the compile-tested code present in the resulting kernel". -- Jiri Kosina SUSE Labs ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] build-id: fix minor quirks
On Fri, Aug 12, 2016 at 08:45:02AM -0600, Jan Beulich wrote: > The initial size check in xen_build_id_check() came too late (after the > first access to the structure), but was mostly redundant with checks > done in all callers; convert it to a properly placed ASSERT(). The > "mostly" part being addressed too: xen_build_init() was off by one. > > And then there was a stray semicolon. > > Signed-off-by: Jan Beulich Reviewed-by: Konrad Rzeszutek Wilk ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: > Alright, how's this new description: > > diff --git a/init/Kconfig b/init/Kconfig > index cac3f096050d..73e4890c24c4 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -53,6 +53,34 @@ config CROSS_COMPILE > need to set this unless you want the configured kernel build > directory to select the cross-compiler automatically. > > +config BUILD_AVOID_BITROT > + bool "Always force building specially annotated targets" > + default n > + help > + If enabled then the the special table-* Makefile targets will always > + be forced to be compiled even if their respective CONFIG_ option has > + been disabled, but its objects will only be linked in if the same > + respective CONFIG_ option has been enabled. This helps avoid code > + bit rot issues, use for these targets should be carefully considred > + by maintainers. You can safely enable this option at the expense of > + increasing compile time. Enabling this option helps avoid code bit > + rot by taking advantage of the facilities provided and enabled by > + using linker tables documented under: As a kernel developer I have _no_ idea what this is trying to say at all, sorry. What is a "specially annotated target"? Who is forcing it to be built? What does it mean if it isn't built? > + > + include/linux/tables.h > + > + The special targets supported are: > + > + o table-obj-y > + o table-lib-y What does this mean to me as a developer? What does it mean to a user who wants to figure out if it should be enabled or not? > + > + Say Y if you have a decent build machine and would like to help test > + building code for more subsystems. Say N if you do you not have a > + good build machine or only want to compile what you've enabled for > + your kernel. How does this test different subsystems? How does disabling it not test them? Why would I care either way? > + > + Enabling this option never increases the size of your kernel. Then what does it do? Just burn electricity for no reason? totally confused... greg k-h ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.14 baseline-only test] 66970: tolerable FAIL
This run is configured for baseline tests only. flight 66970 linux-3.14 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66970/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 66862 build-amd64-rumpuserxen 6 xen-buildfail like 66862 build-i386-rumpuserxen6 xen-buildfail like 66862 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66862 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66862 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66862 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linuxb8b6a72089869dee41bd9f29e86bbcf6501e5524 baseline version: linuxda99423b3cd3e48c42c0d64b79aba58d828f9648 Last test of basis66862 2016-07-29 20:17:38 Z 13 days Testing same since66970 2016-08-11 09:50:48 Z1 days1 attempts People who touched revisions under test: Alexander Klein Alexey Brodkin Alexey Brodkin Amr Bekhit Andrew Morton Andrey Grodzovsky Benjamin Herrenschmidt Brian King Cameron Gutman David S. Miller David Vrabel Dmitri Epshtein Dmitry Torokhov Greg Kroah-Hartman Ilya Dryomov Jeff Mahoney Jiri Slaby Kangjie Lu Kangjie Lu Linus Torvalds Linus Walleij Marc Kleine-Budde Marcin Wojtas Martin K. Petersen Oliver Hartkopp Ping Cheng Ping Cheng Ryusuke Konishi Takashi Iwai Taras Kondratiuk Theodore Ts'o Tony Lindgren Torsten Hilbrich Tyler Hicks Ulf Hansson Ursula Braun Vegard Nossum Vineet Gupta Willy Tarreau Wolfgang Grandegger 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64
[Xen-devel] [qemu-mainline test] 100454: tolerable FAIL - PUSHED
flight 100454 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100454/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 100421 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100421 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100421 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass version targeted for testing: qemuu60ac136102098a70b97ab0c07bc7bf53131c baseline version: qemuu28b874429ba16e71e0caa46453f3a3e31efb3c51 Last test of basis 100421 2016-08-11 19:44:22 Z1 days Testing same since 100454 2016-08-12 12:41:10 Z0 days1 attempts People who touched revisions under test: Peter Maydell Pranith Kumar jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhv
Re: [Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999
Friday, August 12, 2016, 7:29:37 PM, you wrote: > Hi, > On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote : >> L.S., >> >> I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV >> guests and dom0 are uneffected). The clock is always set to 31/12/1999 on >> boot >> of the guest, instead of the system clock time. >> >> Bisecting seems to point out commit: >> 463a86304cae92e10277b47180ac59cf93982e5b char/genrtc: x86: remove remnants >> of asm/rtc.h >> > Isn't that solved by http://patchwork.ozlabs.org/patch/657465/ ? Ah yes that solves it (i only looked in your git-tree to see if there was a patch already), sorry for the noise ! -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
Just some minor typos in descriptions I noticed below... On Fri, Aug 12, 2016 at 10:35 AM, Borislav Petkov wrote: > On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: >> Alright, how's this new description: >> >> diff --git a/init/Kconfig b/init/Kconfig >> index cac3f096050d..73e4890c24c4 100644 >> --- a/init/Kconfig >> +++ b/init/Kconfig >> @@ -53,6 +53,34 @@ config CROSS_COMPILE >> need to set this unless you want the configured kernel build >> directory to select the cross-compiler automatically. >> >> +config BUILD_AVOID_BITROT >> + bool "Always force building specially annotated targets" >> + default n >> + help >> + If enabled then the the special table-* Makefile targets will always "the the" -> "the" >> + be forced to be compiled even if their respective CONFIG_ option has > > "will always be compiled" is already absolute. > >> + been disabled, but its objects will only be linked in if the same >> + respective CONFIG_ option has been enabled. This helps avoid code >> + bit rot issues, use for these targets should be carefully considred "considered" > > s/This helps avoid code bit rot issues, u/U/ > > The bit-rot thing comes again below. > >> + by maintainers. You can safely enable this option at the expense of >> + increasing compile time. Enabling this option helps avoid code bit >> + rot by taking advantage of the facilities provided and enabled by >> + using linker tables documented under: >> + >> + include/linux/tables.h >> + >> + The special targets supported are: >> + >> + o table-obj-y >> + o table-lib-y >> + >> + Say Y if you have a decent build machine and would like to help test >> + building code for more subsystems. Say N if you do you not have a >> + good build machine or only want to compile what you've enabled for >> + your kernel. >> + >> + Enabling this option never increases the size of your kernel. >> + > > Other than those minor formulation nits, yeah, nice! > > Thanks. > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > -- -Kees -- Kees Cook Nexus Security ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 100468: tolerable all pass - PUSHED
flight 100468 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100468/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen a55ad65d3a30d5b3a026a7481ce05f28065920f0 baseline version: xen 20aa9381db781ee050355635efd14a9a37e1d94d Last test of basis 100457 2016-08-12 13:01:26 Z0 days Testing same since 100468 2016-08-12 16:00:59 Z0 days1 attempts People who touched revisions under test: Jan Beulich Razvan Cojocaru Tamas K Lengyel Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass 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 : + branch=xen-unstable-smoke + revision=a55ad65d3a30d5b3a026a7481ce05f28065920f0 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke a55ad65d3a30d5b3a026a7481ce05f28065920f0 + branch=xen-unstable-smoke + revision=a55ad65d3a30d5b3a026a7481ce05f28065920f0 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-4.7-testing + '[' xa55ad65d3a30d5b3a026a7481ce05f28065920f0 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: > Alright, how's this new description: > > diff --git a/init/Kconfig b/init/Kconfig > index cac3f096050d..73e4890c24c4 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -53,6 +53,34 @@ config CROSS_COMPILE > need to set this unless you want the configured kernel build > directory to select the cross-compiler automatically. > > +config BUILD_AVOID_BITROT > + bool "Always force building specially annotated targets" > + default n > + help > + If enabled then the the special table-* Makefile targets will always > + be forced to be compiled even if their respective CONFIG_ option has "will always be compiled" is already absolute. > + been disabled, but its objects will only be linked in if the same > + respective CONFIG_ option has been enabled. This helps avoid code > + bit rot issues, use for these targets should be carefully considred s/This helps avoid code bit rot issues, u/U/ The bit-rot thing comes again below. > + by maintainers. You can safely enable this option at the expense of > + increasing compile time. Enabling this option helps avoid code bit > + rot by taking advantage of the facilities provided and enabled by > + using linker tables documented under: > + > + include/linux/tables.h > + > + The special targets supported are: > + > + o table-obj-y > + o table-lib-y > + > + Say Y if you have a decent build machine and would like to help test > + building code for more subsystems. Say N if you do you not have a > + good build machine or only want to compile what you've enabled for > + your kernel. > + > + Enabling this option never increases the size of your kernel. > + Other than those minor formulation nits, yeah, nice! Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999
Hi, On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote : > L.S., > > I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV > guests and dom0 are uneffected). The clock is always set to 31/12/1999 on > boot > of the guest, instead of the system clock time. > > Bisecting seems to point out commit: > 463a86304cae92e10277b47180ac59cf93982e5b char/genrtc: x86: remove remnants of > asm/rtc.h > Isn't that solved by http://patchwork.ozlabs.org/patch/657465/ ? -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/4] [STUBDOM] Added COPYING files and README.source files
Added a COPYING file as a boilerplate to explain license oddities in this directory Added a vtpm/COPYING file which contains MIT licensed files only Added a vtpmmgr/README.source file which contains many BSD-3-Clause files that originally came from tools/vtpm_manager Signed-off-by: Lars Kurth --- stubdom/COPYING | 31 +++ stubdom/vtpm/COPYING | 26 ++ stubdom/vtpmmgr/README.source | 23 +++ 3 files changed, 80 insertions(+) create mode 100644 stubdom/COPYING create mode 100644 stubdom/vtpm/COPYING create mode 100644 stubdom/vtpmmgr/README.source diff --git a/stubdom/COPYING b/stubdom/COPYING new file mode 100644 index 000..a5071b3 --- /dev/null +++ b/stubdom/COPYING @@ -0,0 +1,31 @@ +Most files in this directory are covered by version 2 of the +GNU General Public License except where explicitly stated. +See the main COPYING file in xen.git for more information. + +Notable exceptions are in the following directories + +vtpm + +Exclusively contains code licensed under a MIT license +Also see vtpm/COPYING + +vtpmmgr +=== +Contains a significant portion of files which are licensed +under a BSD-3-Clause license. These files were imported from +elsewhere and are copyrighted as follows: + +Copyright (c) 2005, Intel Corp. +All rights reserved. + +See README.source for a complete list of files + +Otherwise, this directory contains several files licensed under +GPLv2+, or without copyright headers. + +*.patch and *.diff files + +This directory contains a number of *.patch and *.diff files. +These files describe changes to source files and are thus +licensed under the license from which the *.patch and *.diff +were generated. diff --git a/stubdom/vtpm/COPYING b/stubdom/vtpm/COPYING new file mode 100644 index 000..80780b8 --- /dev/null +++ b/stubdom/vtpm/COPYING @@ -0,0 +1,26 @@ +This copyright applies to all files within this subdirectory and its +subdirectories, unless explicitly stated otherwise within individual +source files. + +All other files in the Xen source distribution are covered by version +2 of the GNU General Public License except where explicitly stated. +See the main COPYING file in xen.git for more information. + += + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to +deal in the Software without restriction, including without limitation the +rights to use, copy, modify, merge, publish, distribute, sublicense, and/or +sell copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT +ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES +INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS +FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT ARE HEREBY +DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE +SOFTWARE. \ No newline at end of file diff --git a/stubdom/vtpmmgr/README.source b/stubdom/vtpmmgr/README.source new file mode 100644 index 000..1b45997 --- /dev/null +++ b/stubdom/vtpmmgr/README.source @@ -0,0 +1,23 @@ +About += +This documents the upstream sources for files in this directory. + +The following files are based off of the original +tools/vtpm_manager code base in xen.git, which has since been +deleted: + +init.c +log.c +log.h +marshal.h +tcg.h +tpm.c +tpm.h +tpm2.c +tpm2.h +tpm2_marshal.h +uuid.h +vtpm_cmd_handler.c +vtpm_manager.h +vtpmmgr.c +vtpmmgr.h \ No newline at end of file -- 2.5.4 (Apple Git-61) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/4] Clarify License information : m4, stubdom, tools/blktap2, xen/crypto
This series contains some of the easier license clean-up cases, which can be fixed by adding COPYING files or README.source files. The series specially contains: xen/crypto and xen/include/crypto Added a README.source file Does not need a COPYING file: all files are imported m4 Updated README.source to include ax_compare_version.m4 Does not need a COPYING file: all files are GPLv2 Exceptions are exclusively from imported files: GPLv2+ and Laurikari (https://enterprise.dejacode.com/license_library/Demo/laurikari/) stubdom Added a COPYING file as a boilerplate to explain license oddities in this directory Added a vtpm/COPYING file which contains MIT licensed files only Added a vtpmmgr/README.source file which contains many BSD-3-Clause files only, that originally came from tools/vtpm_manager tools/blktap2 Added a COPYING file There is some complexity here, but I believe it is not necessary to fix this at this stage, as for some time we were discussing to remove blktap2. -- 2.5.4 (Apple Git-61) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] Added source of ax_compare_version.m4 to import log
In addition: - fixed a reference, which was incorrect Signed-off-by: Lars Kurth --- m4/README.source | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/m4/README.source b/m4/README.source index 21850a6..be7bc5a 100644 --- a/m4/README.source +++ b/m4/README.source @@ -3,6 +3,13 @@ About This documents the upstream sources for the different slew of different m4 sources we have picked up or developed. +ax_compare_version.m4 += +This file was fetched from +http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_compare_version.m4 + +Also see http://www.gnu.org/software/autoconf-archive/ax_compare_version.html + pkg.m4 == The pkg-config m4 macro library comes from the upstream pkg-config @@ -13,7 +20,7 @@ on how to use this read the pkg-config(1) man page. Do not modify this file yourself, if you want to evolve it send patches upstream and then synch back here. -Tree: git://anongit.freedesktop.org/pkg-config +[0]: git://anongit.freedesktop.org/pkg-config The last synch was from commit: -- 2.5.4 (Apple Git-61) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/4] blktap2: Added COPYING file
Blktap2 has some complexity, as some files do not have (c) headers and the directory did not have a COPYING file. At this stage, we have not verified the intention of (c) holders. We may do this in future, if the need arises. Signed-off-by: Lars Kurth --- tools/blktap2/COPYING | 72 +++ 1 file changed, 72 insertions(+) create mode 100644 tools/blktap2/COPYING diff --git a/tools/blktap2/COPYING b/tools/blktap2/COPYING new file mode 100644 index 000..f3d7a10 --- /dev/null +++ b/tools/blktap2/COPYING @@ -0,0 +1,72 @@ +Most files in this directory are covered by a BSD-3-Clause +license as stated in the text below, unless explicitly otherwise +stated. + +New contributions to existing files in this directory are +governed by the license that applies to the relevant specific +file. New contributions to the files listed in [1] are to be +taken under a BSD-3-Clause license. We believe that most +(if not all) of the existing copyright holders intended +to make their contribution under BSD-3 even for the files +with no copyright headers. But this has not been verified. + +New files are to be taken under BSD-3-Clause, unless otherwise +explicitly stated in the copyright header. + +If you want to deal in this code you may do so under GPLv2, +at least. + +Files without (c) headers += +The following source files did not have a (c) notice at the +time this COPYING notice was added to the source tree: + +[1] +./drivers/aes.h +./drivers/blk_linux.c +./drivers/blk_netbsd.c +./drivers/block-remus.c +./drivers/bswap.h +./drivers/check_gcrypt +./drivers/md5.h +./drivers/xmsnap +./include/list.h + +QCOW files +== +The following files are dually licensed under an MIT and GPLv2 +license + +[2] +./drivers/img2qcow.c +./drivers/qcow2raw.c +./drivers/qcow-create.c + += + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + +2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + +3. Neither the name of the copyright holder Inc. nor the names of its + contributors may be used to endorse or promote products derived + from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- 2.5.4 (Apple Git-61) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] Add information on sources for vmac.* and rijndael.*
I added these, as I came across the sources during a license scan. Signed-off-by: Lars Kurth --- xen/crypto/README.source | 17 + xen/include/crypto/README.source | 17 + 2 files changed, 34 insertions(+) create mode 100644 xen/crypto/README.source create mode 100644 xen/include/crypto/README.source diff --git a/xen/crypto/README.source b/xen/crypto/README.source new file mode 100644 index 000..894045d --- /dev/null +++ b/xen/crypto/README.source @@ -0,0 +1,17 @@ +About += +This documents the upstream sources for files in this directory. + +rijndael.c +== +This file comes from +http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/ + +vmac.c +== +This file was developed by Ted Krovetz and Wei Dai (more details +are in the files). + +See +- https://en.wikipedia.org/wiki/VMAC +- http://www.fastcrypto.org/vmac/vmac.c diff --git a/xen/include/crypto/README.source b/xen/include/crypto/README.source new file mode 100644 index 000..68de1cd --- /dev/null +++ b/xen/include/crypto/README.source @@ -0,0 +1,17 @@ +About += +This documents the upstream sources for files in this directory. + +rijndael.h +== +This file comes from +http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/ + +vmac.h +== +This file was developed by Ted Krovetz and Wei Dai (more details +are in the files). + +See +- https://en.wikipedia.org/wiki/VMAC +- http://www.fastcrypto.org/vmac/vmac.h -- 2.5.4 (Apple Git-61) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999
L.S., I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV guests and dom0 are uneffected). The clock is always set to 31/12/1999 on boot of the guest, instead of the system clock time. Bisecting seems to point out commit: 463a86304cae92e10277b47180ac59cf93982e5b char/genrtc: x86: remove remnants of asm/rtc.h -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
On Fri, Aug 12, 2016 at 05:51:21PM +0200, Borislav Petkov wrote: > On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote: > > Even so, you don't link the compiled extra code so the only penalty > > here is when compiling, nothing more. And if you are compiling typically > > the cost here is just a few seconds. > > Yeah, so let's make it clear that this is similar to COMPILE_TEST and > people with fast machines and who don't mind building a couple more > seconds longer, should enable it. Sure, I'll also move it under COMPILE_TEST, and default it to n. > You don't want to be doing bit-rotting tests on small, weak machines, > which barely get done with the build as it is. I have a 32-bit atom > which takes hours to build a kernel. Enabling that there is not making > the kernel build any more fun. > > > > ... or you simply don't want to have stuff which is forcibly enabled on > > > you even > > > if you're never going to need it > > > ... > > > > Which seems to be the same as the reason I noted ? > > No, the reason is we don't force stuff down people's throats just > because we think we know better. Other people do that. > > Instead, we help them make an informed decision by describing the > feature as precisely as possible. > > > I can remove the grumpy maintainer description :) > > Yap :-) Alright, how's this new description: diff --git a/init/Kconfig b/init/Kconfig index cac3f096050d..73e4890c24c4 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default n + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under: + + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-y + + Say Y if you have a decent build machine and would like to help test + building code for more subsystems. Say N if you do you not have a + good build machine or only want to compile what you've enabled for + your kernel. + + Enabling this option never increases the size of your kernel. + config COMPILE_TEST bool "Compile also drivers which will not load" depends on !UML ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote: > Even so, you don't link the compiled extra code so the only penalty > here is when compiling, nothing more. And if you are compiling typically > the cost here is just a few seconds. Yeah, so let's make it clear that this is similar to COMPILE_TEST and people with fast machines and who don't mind building a couple more seconds longer, should enable it. You don't want to be doing bit-rotting tests on small, weak machines, which barely get done with the build as it is. I have a 32-bit atom which takes hours to build a kernel. Enabling that there is not making the kernel build any more fun. > > ... or you simply don't want to have stuff which is forcibly enabled on you > > even > > if you're never going to need it > > ... > > Which seems to be the same as the reason I noted ? No, the reason is we don't force stuff down people's throats just because we think we know better. Other people do that. Instead, we help them make an informed decision by describing the feature as precisely as possible. > I can remove the grumpy maintainer description :) Yap :-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)
On Fri, Aug 12, 2016 at 09:51:39AM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote: > > On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote: > > > Hey Ross, > > > > > > I am running in a symbol dependency issue that I am not exactly > > > sure how to solve. > > > > > > I have an payload that introduces a new function (xen_foobar) which > > > will patch over xen_extra_version(). > > > > > snip > > > > > > As livepatch_symbols_lookup_by_name only looks for symbols that > > > have the ->new_symbol set. And xen_foobar does not. So the loading is > > > aborted. > > > > > > Which makes sense - we don't want to match the symbols as they haven't > > > really been "finally loaded" in. > > > > > > But what if the xen_foobar is applied. In that case we should > > > change the xen_foobar to be new_symbol=1? > > > > I think you're confused about the purpose of new_symbol. The purpose is to > > ensure that you link against the correct symbol from the base hypervisor or > > the live patch that first introduced it. So, new_symbol=0 is when a symbol > > overrides an existing symbol. new_symbol=1 is set when a symbol is new > > But it does not (overrides the existing symbol). > > The patch (xen_foobar) introduces a new function called xen_foobar > which is patching xen_extra_version. > > That is: > > static char foobar_patch_this_fnc[] = "xen_extra_version"; > > struct livepatch_func __section(".livepatch.funcs") livepatch_xen_foobar = { > .version = LIVEPATCH_PAYLOAD_VERSION, > .name = foobar_patch_this_fnc, > .new_addr = xen_foobar, > .old_addr = xen_extra_version, > .new_size = NEW_CODE_SZ, > .old_size = OLD_CODE_SZ, > }; > > > introduced in a live patch. > > And this loop: > > for ( j = 0; j < payload->nfuncs; j++ ) > { > > if ( symtab[i].value == (unsigned long)payload->funcs[j].new_addr > ) > { > > found = 1; > > break; > > } > > } > > Will force new_symbol=0 for xen_foobar. > > > > > Since all the linking happens during load and not apply, it is perfectly OK > > to link against a symbol that hasn't been applied -- the dependencies are > > there to ensure that you can't apply a patch which links against unapplied > > symbols. > > > > The assumption is that when overriding an existing symbol, the symbol in the > > payload has the same name as the one it is overriding. You're having issues > > above because you're breaking this assumption. > > Yes :-) > > > > > > > > > This following patch does that, but I am wondering if there is a better > > > way? > > > > The patch is misusing new_symbol for something completely different from how > > it was intended so I hope there is a better way :-P > > Well for my use-case I think I can just s/xen_foobar/xen_extra_version/ and we > should be OK. Ah no. It does work for xen_foo (so it replaces xen_extra_version with its own 'xen_extra_version'. But when I introduce xen_foobar_nop and it tries to look for 'xen_extra_version' it picks the hypervisor one (which has been patched over) instead of the livepatched version. This may require some extra lookup in the applied_list for the symbols before consulting and trying to match up the symbols in the built-in list. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support
On Fri, Aug 12, 2016 at 09:25:07AM +0200, Borislav Petkov wrote: > On Fri, Aug 12, 2016 at 08:50:11AM +0200, Luis R. Rodriguez wrote: > > On Fri, Aug 12, 2016 at 07:23:03AM +0200, Borislav Petkov wrote: > > > On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote: > > > > OK I've added CONFIG_BUILD_AVOID_BITROT. > > > > > > What does that do? > > > > > > Enabling it allows the forced compilation chosen by maintainers. > > Otherwise forced compilations with the new special targets are > > ignored. > > Nice. > > > I've gone with table-obj-y and table-lib-y as we have > > to support both lib-y and obj-y respective targets. > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index 33e2966dd741..7893e3b8da82 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -1895,6 +1895,30 @@ config PROVIDE_OHCI1394_DMA_INIT > > > > See Documentation/debugging-via-ohci1394.txt for more information. > > > > +config BUILD_AVOID_BITROT > > + bool "Always force building specially annotated" > > ...annotated targets" > > > + default y > > + help > > + If enabled then the the special table-* Makefile targets will always > > + be forced to be compiled even if their respective CONFIG_ option has > > + been disabled, but its objects will only be linked in if the same > > + respective CONFIG_ option has been enabled. This helps avoid code > > + bit rot issues, use for these targets should be carefully considred > > + by maintainers. You can safely enable this option at the expense of > > + increasing compile time slightly. Enabling this option helps avoid > > s/slightly// > > :-) > > > + code bit rot by taking advantage of the facilities provided and > > + enabled by using linker tables documented under: > > + > > + include/linux/tables.h > > + > > + The special targets supported are: > > + > > + o table-obj-y > > + o table-lib-y > > + > > + Say Y unless you are a grumpy maintainer and don't trust other > > + maintainer's judgements on what code should always get compiled. > > ... or you're running a tiny-config setup Even so, you don't link the compiled extra code so the only penalty here is when compiling, nothing more. And if you are compiling typically the cost here is just a few seconds. > ... or you're an embedded, resource-constrained person For the compilation of th kernel ? > ... or you simply don't want to have stuff which is forcibly enabled on you > even > if you're never going to need it > ... Which seems to be the same as the reason I noted ? > I got a million o'those :-) I can remove the grumpy maintainer description :) Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script
On 12/08/16 16:21, Jan Beulich wrote: On 12.08.16 at 17:02, wrote: >> On 12/08/16 15:47, Jan Beulich wrote: >>> Besides being more logical this also allows verifying correct recording >>> of alignments in .o files. >>> >>> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable >>> value (as it now verifies correct tool chain behavior), but I've left >>> it in nevertheless. >>> >>> Signed-off-by: Jan Beulich >>> >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re >>> */ >>> #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE) >>> unsigned long __section(".bss.page_aligned") >>> +__attribute__((aligned(PAGE_SIZE))) >> Can I talk you into introducing #define __aligned(x) >> __attribute__((aligned(x))) in compiler.h ? > Sure, I was on the edge of introducing it while putting this together > anyway, but then thought it's maybe not worth it. I have been meaning to do it for a while, and clean up the existing opencoded uses in the tree. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script
>>> On 12.08.16 at 17:02, wrote: > On 12/08/16 15:47, Jan Beulich wrote: >> Besides being more logical this also allows verifying correct recording >> of alignments in .o files. >> >> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable >> value (as it now verifies correct tool chain behavior), but I've left >> it in nevertheless. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re >> */ >> #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE) >> unsigned long __section(".bss.page_aligned") >> +__attribute__((aligned(PAGE_SIZE))) > > Can I talk you into introducing #define __aligned(x) > __attribute__((aligned(x))) in compiler.h ? Sure, I was on the edge of introducing it while putting this together anyway, but then thought it's maybe not worth it. > Otherwise, Reviewed-by: Andrew Cooper Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: credit1: fix a race when picking initial pCPU for a vCPU
On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote: > On 12/08/16 05:07, Dario Faggioli wrote: > Let me know if you want me to check this in as-is or if you think you > might send a follow-up patch adding an ASSERT. > Done, and it actually explodes like this: (XEN) [4.870128] Xen call trace: (XEN) [4.870130][] spinlock.c#check_lock+0x42/0x46 (XEN) [4.870133][] _spin_is_locked+0x11/0x4d (XEN) [4.870139][] sched_credit.c#_csched_cpu_pick+0x1a9/0x632 (XEN) [4.870142][] sched_credit.c#csched_tick+0x1fd/0x385 (XEN) [4.870146][] timer.c#execute_timer+0x47/0x62 (XEN) [4.870148][] timer.c#timer_softirq_action+0xdb/0x22c (XEN) [4.870151][] softirq.c#__do_softirq+0x7f/0x8a (XEN) [4.870153][] do_softirq+0x13/0x15 (XEN) [4.870157][] entry.o#process_softirqs+0x21/0x30 (XEN) [4.870159] (XEN) [5.619096] (XEN) [5.621085] (XEN) [5.626536] Panic on CPU 0: (XEN) [5.629826] Xen BUG at spinlock.c:48 (XEN) [5.633895] And if I look at csched_tick(), it indeed is the case that we call csched_vcpu_acct() **without** holding the runq lock. It in turns calls things like burn_credits(), accesses current, and other stuff, which I'm having a little bit of an hard time convincing myself it is safe... Although it must be, if there have been no issues after all these years. :-O csched_runq_sort(), called later, still by csched_tick(), acquires the lock by itself, and we can't acquire it in csched_tick(), because __csched_vcpu_acct_start() acquires the private lock, and we'd violate the nesting rule. In summary, this is looking more complicated than it seemed, and I'll have to look at this again on Tuesday (it's public holiday, here, on Monday). Gosh, how much I hate this scheduler!! :-/ Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON
On Fri, Aug 12, 2016 at 04:02:11PM +0200, Samuel Thibault wrote: > Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote: > > BUILD_BUG_ON should not appear in a public-facing header, otherwise it > > risks clashing with macro with the same name in other code bases. I > > encountered such issue when trying to add BUILD_BUG_ON to a private > > header in Xen's gnttab library. > > > > Ideally BUILD_BUG_ON should be moved to a private header, but there is > > actually no user of it in mini-os tree, just remove it. > > > > Signed-off-by: Wei Liu > > Acked-by: Samuel Thibault > Actually some stuff in stubdom depends on mini-os leaking BUILD_BUG_ON, while some actively work around the leaking of some other macros. I will hold off putting in this patch for now. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 100457: tolerable all pass - PUSHED
flight 100457 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100457/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen 20aa9381db781ee050355635efd14a9a37e1d94d baseline version: xen 072e6709978143145a1c1b98c7f014dc4d87907f Last test of basis 100417 2016-08-11 15:01:47 Z1 days Testing same since 100457 2016-08-12 13:01:26 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass 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 : + branch=xen-unstable-smoke + revision=20aa9381db781ee050355635efd14a9a37e1d94d + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 20aa9381db781ee050355635efd14a9a37e1d94d + branch=xen-unstable-smoke + revision=20aa9381db781ee050355635efd14a9a37e1d94d + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-4.7-testing + '[' x20aa9381db781ee050355635efd14a9a37e1d94d = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']' +++ echo 'git://cache:9
[Xen-devel] [PATCH v2 2/2] x86emul: introduce SrcImm16
... and use it for RET, LRET, and ENTER processing to limit the amount of "manual" insn bytes fetching. Note that for the RET and LRET paths the change utilizes that SrcImplicit (aka SrcNone) table entries leave src.val as zero. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -39,6 +39,7 @@ #define SrcMem16(4<<3) /* Memory operand (16-bit). */ #define SrcImm (5<<3) /* Immediate operand. */ #define SrcImmByte (6<<3) /* 8-bit sign-extended immediate operand. */ +#define SrcImm16(7<<3) /* 16-bit zero-extended immediate operand. */ #define SrcMask (7<<3) /* Generic ModRM decode. */ #define ModRM (1<<6) @@ -143,11 +144,11 @@ static uint8_t opcode_table[256] = { DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, /* 0xC0 - 0xC7 */ ByteOp|DstMem|SrcImm|ModRM, DstMem|SrcImmByte|ModRM, -ImplicitOps, ImplicitOps, +DstImplicit|SrcImm16, ImplicitOps, DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov, ByteOp|DstMem|SrcImm|ModRM|Mov, DstMem|SrcImm|ModRM|Mov, /* 0xC8 - 0xCF */ -ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps, +DstImplicit|SrcImm16, ImplicitOps, DstImplicit|SrcImm16, ImplicitOps, ImplicitOps, DstImplicit|SrcImmByte, ImplicitOps, ImplicitOps, /* 0xD0 - 0xD7 */ ByteOp|DstMem|SrcImplicit|ModRM, DstMem|SrcImplicit|ModRM, @@ -1996,6 +1997,11 @@ x86_emulate( case 4: src.val = insn_fetch_type(int32_t); break; } break; +case SrcImm16: +src.type = OP_IMM; +src.bytes = 2; +src.val = insn_fetch_type(uint16_t); +break; } /* Decode and fetch the destination operand: register or memory. */ @@ -2788,16 +2794,14 @@ x86_emulate( break; case 0xc2: /* ret imm16 (near) */ -case 0xc3: /* ret (near) */ { -int offset = (b == 0xc2) ? insn_fetch_type(uint16_t) : 0; +case 0xc3: /* ret (near) */ op_bytes = ((op_bytes == 4) && mode_64bit()) ? 8 : op_bytes; -if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + offset), +if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val), &dst.val, op_bytes, ctxt, ops)) != 0 || (rc = ops->insn_fetch(x86_seg_cs, dst.val, NULL, 0, ctxt)) ) goto done; _regs.eip = dst.val; break; -} case 0xc4: /* les */ { unsigned long sel; @@ -2819,7 +2823,6 @@ x86_emulate( goto les; case 0xc8: /* enter imm16,imm8 */ { -uint16_t size = insn_fetch_type(uint16_t); uint8_t depth = insn_fetch_type(uint8_t) & 31; int i; @@ -2848,7 +2851,7 @@ x86_emulate( goto done; } -sp_pre_dec(size); +sp_pre_dec(src.val); break; } @@ -2876,17 +2879,15 @@ x86_emulate( break; case 0xca: /* ret imm16 (far) */ -case 0xcb: /* ret (far) */ { -int offset = (b == 0xca) ? insn_fetch_type(uint16_t) : 0; +case 0xcb: /* ret (far) */ if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes), &dst.val, op_bytes, ctxt, ops)) || - (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + offset), + (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val), &src.val, op_bytes, ctxt, ops)) || (rc = load_seg(x86_seg_cs, src.val, 1, &cs, ctxt, ops)) || (rc = commit_far_branch(&cs, dst.val)) ) goto done; break; -} case 0xcc: /* int3 */ src.val = EXC_BP; x86emul: introduce SrcImm16 ... and use it for RET, LRET, and ENTER processing to limit the amount of "manual" insn bytes fetching. Note that for the RET and LRET paths the change utilizes that SrcImplicit (aka SrcNone) table entries leave src.val as zero. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -39,6 +39,7 @@ #define SrcMem16(4<<3) /* Memory operand (16-bit). */ #define SrcImm (5<<3) /* Immediate operand. */ #define SrcImmByte (6<<3) /* 8-bit sign-extended immediate operand. */ +#define SrcImm16(7<<3) /* 16-bit zero-extended immediate operand. */ #define SrcMask (7<<3) /* Generic ModRM decode. */ #define ModRM (1<<6) @@ -143,11 +144,11 @@ static uint8_t opcode_table[256] = { DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, /* 0xC0 - 0xC7 */ ByteOp|DstMem|SrcImm|ModRM, DstMem|SrcImmByte|ModRM, -ImplicitOps, ImplicitOps, +DstImplicit|SrcImm16, ImplicitOps, DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov, ByteOp|DstMem|SrcImm|ModRM|Mov, DstMem|SrcImm|ModRM|Mov, /* 0xC8 - 0xCF */ -ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps, +DstImplicit|SrcI
[Xen-devel] [PATCH v2 1/2] x86emul: fold SrcImmByte fetching
There's no need for having identical code spelled out twice. Signed-off-by: Jan Beulich --- v2: Add braces (with quite a bit of reluctance). --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1979,9 +1979,14 @@ x86_emulate( goto done; break; case SrcImm: +if ( !(d & ByteOp) ) +src.bytes = op_bytes != 8 ? op_bytes : 4; +else +{ +case SrcImmByte: +src.bytes = 1; +} src.type = OP_IMM; -src.bytes = (d & ByteOp) ? 1 : op_bytes; -if ( src.bytes == 8 ) src.bytes = 4; /* NB. Immediates are sign-extended as necessary. */ switch ( src.bytes ) { @@ -1990,11 +1995,6 @@ x86_emulate( case 4: src.val = insn_fetch_type(int32_t); break; } break; -case SrcImmByte: -src.type = OP_IMM; -src.bytes = 1; -src.val = insn_fetch_type(int8_t); -break; } /* Decode and fetch the destination operand: register or memory. */ x86emul: fold SrcImmByte fetching There's no need for having identical code spelled out twice. Signed-off-by: Jan Beulich --- v2: Add braces (with quite a bit of reluctance). --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1979,9 +1979,14 @@ x86_emulate( goto done; break; case SrcImm: +if ( !(d & ByteOp) ) +src.bytes = op_bytes != 8 ? op_bytes : 4; +else +{ +case SrcImmByte: +src.bytes = 1; +} src.type = OP_IMM; -src.bytes = (d & ByteOp) ? 1 : op_bytes; -if ( src.bytes == 8 ) src.bytes = 4; /* NB. Immediates are sign-extended as necessary. */ switch ( src.bytes ) { @@ -1990,11 +1995,6 @@ x86_emulate( case 4: src.val = insn_fetch_type(int32_t); break; } break; -case SrcImmByte: -src.type = OP_IMM; -src.bytes = 1; -src.val = insn_fetch_type(int8_t); -break; } /* Decode and fetch the destination operand: register or memory. */ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case
On Fri, Aug 12, 2016 at 08:51:14AM -0600, Tamas K Lengyel wrote: > On Aug 12, 2016 05:24, "Julien Grall" wrote: > > > > Hello Tamas, > > > > > > On 10/08/2016 17:00, Tamas K Lengyel wrote: > >> > >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > >> index ef614be..97948fd 100644 > >> --- a/tools/libxl/libxl_types.idl > >> +++ b/tools/libxl/libxl_types.idl > >> @@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [ > >> ("policy", libxl_rdm_reserve_policy), > >> ]) > >> > >> +# Consistent with the values defined for HVM_PARAM_ALTP2M > >> +libxl_altp2m_mode = Enumeration("altp2m_mode", [ > >> +(0, "disabled"), > >> +(1, "mixed"), > >> +(2, "external_only"), > >> +], init_val = "LIBXL_ALTP2M_MODE_DISABLED") > >> + > >> libxl_domain_build_info = Struct("domain_build_info",[ > >> ("max_vcpus", integer), > >> ("avail_vcpus", libxl_bitmap), > >> @@ -512,7 +519,7 @@ libxl_domain_build_info = > Struct("domain_build_info",[ > >> ("mmio_hole_memkb", MemKB), > >> ("timer_mode", > libxl_timer_mode), > >> ("nested_hvm", > libxl_defbool), > >> - ("altp2m", > libxl_defbool), > >> + ("altp2m", > libxl_altp2m_mode), > > > > > > Should we move altp2m directly outside of the structure "hvm" to avoid > yet another change when altp2m will be supported on ARM? (see [1]) > > > > Regards, > > > > [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00147.html > > > > -- > > Julien Grall > > Hi Julien, > We can do that here if preferred by the tools maintainers though I'm on the > opinion that it should be adjusted in the ARM altp2m series once it > actually becomes available there. > I agree. We shouldn't mix things together. Wei. > Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script
On 12/08/16 15:47, Jan Beulich wrote: > Besides being more logical this also allows verifying correct recording > of alignments in .o files. > > The cpu0_stack related ASSERT() in xen.lds.S is now of questionable > value (as it now verifies correct tool chain behavior), but I've left > it in nevertheless. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re > */ > #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE) > unsigned long __section(".bss.page_aligned") > +__attribute__((aligned(PAGE_SIZE))) Can I talk you into introducing #define __aligned(x) __attribute__((aligned(x))) in compiler.h ? Otherwise, Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Very RFC PATCH 3/3] livepatch: Initial ARM32/64 support.
Hi Konrad, On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote: The initial support for ARM64 - and livepatching works: As it is a very RFC I only gave a quick look. I have few comments on it (see below). (XEN) livepatch: xen_hello_world: Applying 1 functions (XEN) hi_func: Hi! (called 1 times) (XEN) Hook executing. (XEN) livepatch: xen_hello_world finished APPLY with rc=0 (XEN) livepatch.c:1687: livepatch: load_payload_fnc: rc=0 (p->rc=0) (XEN) livepatch: Hello World (XEN) 'x' pressed - Dumping all livepatch patches (XEN) build-id: e144bafc4ee8635eee5bed8e3988b484765c46c8 (XEN) name=xen_hello_world state=APPLIED(2) 00318000 (.data=00319000, .rodata=0031a000) using 3 pages. (XEN) xen_extra_version patch 00233fac(12) with 00318000 (16) (XEN) build-id=c4b842c276be43adbe4db788598b1e11bce04dc6 (XEN) depend-on=9affa110481e8e13606c61b21e5f6a357a3c8ef9 ARM32 still has some issues. The are some TODOs left to be done: General: - Bubble ALT_ORIG_PTR macro for both x86/ARM. - Unify the ELF RELA checks - they are the same on x86/ARM[32,64]. - Makefile generating .livepatch.depends needs to ingest the -O argument based on architecture - Test cases should move to common/ ? [Needs Jan's Ack] In general, I would be in favor of sharing as much as possible the code. ARM32 issues: - vm_init_type: Assertion 'is_xen_heap_mfn(ma >> PAGE_SHIFT)' failed at xen/include/asm/mm.h:23 xen/include/asm/mm.h:23 points to the beginning of struct page_info. Did you mean to write instead 233? This would point to maddr_virt. This would mean someone is trying to get the virtual address of MFN that is not in the xenheap (only the xenheap is mapped on ARM32). Do you have the full call stack? [...] Signed-off-by: Konrad Rzeszutek Wilk [...] diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c index aba1320..67749ed 100644 --- a/xen/arch/arm/livepatch.c +++ b/xen/arch/arm/livepatch.c @@ -6,66 +6,100 @@ #include #include #include +#include +#include "livepatch.h" + +#include + +void *vmap_of_xen_text; void arch_livepatch_quiesce(void) { +mfn_t text_mfn; +unsigned int text_order; + +if ( vmap_of_xen_text ) +return; + +text_mfn = _mfn(virt_to_mfn(_stext)); +text_order = get_order_from_bytes(_end - _start); + +/* + * The text section is read-only. So re-map Xen to be able to patch + * the code. + */ +vmap_of_xen_text = __vmap(&text_mfn, 1 << text_order, 1, 1, PAGE_HYPERVISOR, + VMAP_DEFAULT); Shouldn't we return an error if we fail to re-map the region? Otherwise the patch may silently be ignored (see arch_livepatch_apply_jmp). } void arch_livepatch_revive(void) { +/* Nuke the instruction cache */ +invalidate_icache(); I was about to say that this is not enough. But you called clean_and_invalidate_* every time you rewrite the jump. It might be worth to add a comment here, explain that the cache has been cleaned before hand. However, I can't find any data cache flush for the payload. Did I miss anything? Lastly, before I forgot, you will need to invalidate the branch predictor for ARMv7 as it may be architecturally visible to the software (see B2.2.4 in ARM DDI 0406C.b). + +if ( vmap_of_xen_text ) +vunmap(vmap_of_xen_text); + +vmap_of_xen_text = NULL; } int arch_livepatch_verify_func(const struct livepatch_func *func) { -return -ENOSYS; -} +/* No NOP patching yet. */ +if ( !func->new_size ) +return -EOPNOTSUPP; -void arch_livepatch_apply_jmp(struct livepatch_func *func) -{ -} +if ( func->old_size < PATCH_INSN_SIZE ) +return -EINVAL; -void arch_livepatch_revert_jmp(const struct livepatch_func *func) -{ +return 0; } void arch_livepatch_post_action(void) { +/* arch_livepatch_revive has nuked the instruction cache. */ } void arch_livepatch_mask(void) { +/* TODO: No NMI on ARM? */ All interrupts can be masked on ARM so far. Although, local_irq_disable will only mask IRQ (i.e interrupt from the interrupt controller). We may want to mask SError (System Error) via local_abort_{disable,enable} to avoid receiving asynchronous abort whilst patching Xen. The interrupt will stay pending until it will be re-enabled in arch_livepatch_unmask. } void arch_livepatch_unmask(void) { +/* TODO: No NMI on ARM? */ } -int arch_livepatch_verify_elf(const struct livepatch_elf *elf) +int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type type) { -return -ENOSYS; -} +unsigned long start = (unsigned long)va; +unsigned int flags; -int arch_livepatch_perform_rel(struct livepatch_elf *elf, - const struct livepatch_elf_sec *base, - const struct livepatch_elf_sec *rela) -{ -return -ENOSYS; -} +ASSERT(va); +ASSERT(pages); -int arch_livepatch_perform_rela(struct livepatch_elf *el
[Xen-devel] [PATCH v2 0/2] x86emul: remaining misc small adjustments
1: fold SrcImmByte fetching 2: introduce SrcImm16 Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable baseline-only test] 66968: tolerable FAIL
This run is configured for baseline tests only. flight 66968 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66968/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-buildfail like 66957 build-amd64-rumpuserxen 6 xen-buildfail like 66957 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66957 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66957 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 7f5c8075364776eb139bbd421ad443ae9e4465dc baseline version: xen 8e370ef503e8df249c3e3dd2ea17b3f100d4f20a Last test of basis66957 2016-08-09 20:48:30 Z2 days Testing same since66968 2016-08-11 03:48:07 Z1 days1 attempts People who touched revisions under test: George Dunlap Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops
Re: [Xen-devel] Unable to add disk on ARM64
On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote: > On 12/08/2016 14:24, Peng Fan wrote: > > Hi, > > Hello Peng, > > I have CCed Roger who is more familiar than me with the hotplug scripts. > > > I am using xen master branch on i.MX8 ARM64. > > > > My xl configuration: > > > > kernel = "/root/xen/Image" > > memory = "128" > > name = "DomU" > > vcpus = 1 > > serial="pty" > > disk = [ 'phy:/dev/loop0,xvda,w' ] > > extra = "console=hvc0 root=/dev/xvda debug=/bin/sh" > > > > > > And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux. > > > > But I met the following error: > > libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to > > execute: /etc/xen/scripts/block add ^M^M > > Device /dev/loop0 is mounted in the privileged domain,^M^M > > and so cannot be mounted by a guest.^M^M > > libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: > > /etc/xen/scripts/block add [800] exited with error status 1^M^M > > libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch > > w=0xfee100: deregister unregistered^M^M > > libxl: error: libxl_devi > > ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is > > mounted in the privileged domain,^M^M > > and so cannot be mounted by a guest.^M^M > > From my understanding, you have mounted /dev/loop0 in Dom0, is that correct? > However, we don't support sharing the same mounting point by default (Roger > can you confirm). It seems like the hotplug script has detected that you have the device already attached to Dom0, can you paste the output of `xenstore-ls -fp` when this happens? It could be that there's some garbage in xenstore from a device that hasn't been properly detached. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case
On Aug 12, 2016 05:24, "Julien Grall" wrote: > > Hello Tamas, > > > On 10/08/2016 17:00, Tamas K Lengyel wrote: >> >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl >> index ef614be..97948fd 100644 >> --- a/tools/libxl/libxl_types.idl >> +++ b/tools/libxl/libxl_types.idl >> @@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [ >> ("policy", libxl_rdm_reserve_policy), >> ]) >> >> +# Consistent with the values defined for HVM_PARAM_ALTP2M >> +libxl_altp2m_mode = Enumeration("altp2m_mode", [ >> +(0, "disabled"), >> +(1, "mixed"), >> +(2, "external_only"), >> +], init_val = "LIBXL_ALTP2M_MODE_DISABLED") >> + >> libxl_domain_build_info = Struct("domain_build_info",[ >> ("max_vcpus", integer), >> ("avail_vcpus", libxl_bitmap), >> @@ -512,7 +519,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ >> ("mmio_hole_memkb", MemKB), >> ("timer_mode", libxl_timer_mode), >> ("nested_hvm", libxl_defbool), >> - ("altp2m", libxl_defbool), >> + ("altp2m", libxl_altp2m_mode), > > > Should we move altp2m directly outside of the structure "hvm" to avoid yet another change when altp2m will be supported on ARM? (see [1]) > > Regards, > > [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00147.html > > -- > Julien Grall Hi Julien, We can do that here if preferred by the tools maintainers though I'm on the opinion that it should be adjusted in the ARM altp2m series once it actually becomes available there. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/EFI: use less crude way of generating the build ID
Recent enough binutils support --build-id also for COFF/PE output, and hence we should use that in favor of the original hack when possible. This gets complicated by the linker requiring at least one COFF object file to attach the .buildid section to. Hence the patch introduces a buildid.ihex (in order to avoid introducing binary files into the repo) which then gets converted to a binary minimal COFF object (no sections, no symbols). Also (to avoid both code fragment going out of sync) remove an unneeded ALIGN() from xen.lds.S: Adding an equivalent of it to the .buildid section would cause the _erodata symbol to become associated with the wrong section again (see commit 0970299de5 ["x86/EFI + Live Patch: avoid symbol address truncation"]). And it's pointless because the alignment already gets properly set by the input section(s). Signed-off-by: Jan Beulich --- Question of course is whether consumers of the build ID other than Xen itself need to be taught how to find it in an EFI binary. --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -158,24 +158,30 @@ $(TARGET).efi: VIRT_BASE = 0x$(shell $(N $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A ALT_START$$,,p') # Don't use $(wildcard ...) here - at least make 3.80 expands this too early! $(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:) + ifneq ($(build_id_linker),) -$(TARGET).efi: note.o +ifeq ($(call ld-ver-build-id,$(LD) $(EFI_LDFLAGS)),y) +CFLAGS += -DBUILD_ID_EFI +EFI_LDFLAGS += $(build_id_linker) +note_file := efi/buildid.o +else note_file := note.o +endif else note_file := endif -$(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbols-dummy.o efi/mkreloc +$(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbols-dummy.o efi/mkreloc $(foreach base, $(VIRT_BASE) $(ALT_BASE), \ $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< efi/relocs-dummy.o \ - $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).$(base).0 &&) : + $(BASEDIR)/common/symbols-dummy.o $(note_file) -o $(@D)/.$(@F).$(base).0 &&) : $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \ | $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort >$(@D)/.$(@F).0s.S $(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o $(foreach base, $(VIRT_BASE) $(ALT_BASE), \ $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \ - $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o -o $(@D)/.$(@F).$(base).1 &&) : + $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o $(note_file) -o $(@D)/.$(@F).$(base).1 &&) : $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \ | $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort >$(@D)/.$(@F).1s.S @@ -185,8 +191,8 @@ $(TARGET).efi: prelink-efi.o efi.lds efi if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi rm -f $(@D)/.$(@F).[0-9]* -efi/boot.init.o efi/runtime.o efi/compat.o: $(BASEDIR)/arch/x86/efi/built_in.o -efi/boot.init.o efi/runtime.o efi/compat.o: ; +efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: $(BASEDIR)/arch/x86/efi/built_in.o +efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: ; asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c $(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $< --- a/xen/arch/x86/efi/Makefile +++ b/xen/arch/x86/efi/Makefile @@ -9,6 +9,9 @@ efi := $(if $(efi),$(shell $(CC) $(filte efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 2>disabled && echo y)) efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); $(call create,runtime.o))) -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o +extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o + +%.o: %.ihex + $(OBJCOPY) -I ihex -O binary $< $@ stub.o: $(extra-y) --- /dev/null +++ b/xen/arch/x86/efi/buildid.ihex @@ -0,0 +1,3 @@ +:100064864D8DAD57140014 +:04001000EC +:0001FF --- a/xen/arch/x86/efi/mkreloc.c +++ b/xen/arch/x86/efi/mkreloc.c @@ -342,6 +342,7 @@ int main(int argc, char *argv[]) */ if ( memcmp(sec1[i].name, ".initcal", sizeof(sec1[i].name)) == 0 || memcmp(sec1[i].name, ".init.se", sizeof(sec1[i].name)) == 0 || + memcmp(sec1[i].name, ".buildid", sizeof(sec1[i].name)) == 0 || memcmp(sec1[i].name, ".lockpro", sizeof(sec1[i].name)) == 0 ) continue; --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -91,7 +91,7 @@ SECTIONS *(
[Xen-devel] [PATCH 2/2] make use of .startof.() and .sizeof.() assembler expressions
Section start symbols frequently obscure the actual symbol name living at the start of the section. Eliminate them where they can be replaced by linker resolved .startof.* symbols. (Section end symbols may have the same undesirable effect, but they're less easy to eliminate, as they'd need to be represented by the sum of .startof. and .sizeof.). Along those lines use .sizeof.* where section sizes get calculated from the difference of section and and section start symbols. Note that this would be nice for the build-id section too, but: - The generated (by ld) section names differ between ELF and COFF/PE (ELF: .note.gnu.build-id; COFF/PE[2.26+]: .buildid), yet we compile version.c just once (and hence can use only either of the necessary .startof./.sizeof. forms). - The ELF section name needs to be quoted in the .startof./.sizeof. expressions, yet that quoting is supported only by gas 2.26+. Signed-off-by: Jan Beulich --- a/xen/arch/arm/arm32/head.S +++ b/xen/arch/arm/arm32/head.S @@ -184,10 +184,10 @@ hyp:PRINT("- Xen starting in Hyp mod bne skip_bss PRINT("- Zero BSS -\r\n") -ldr r0, =__bss_start /* Load start & end of bss */ -ldr r1, =__bss_end +ldr r0, =.startof.(.bss) /* Load start & size of bss */ +ldr r1, =.sizeof.(.bss) add r0, r0, r10/* Apply physical offset */ -add r1, r1, r10 +add r1, r1, r0 /* Calculate end of bss */ mov r2, #0 1: str r2, [r0], #4 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -318,10 +318,10 @@ el2:PRINT("- Xen starting at EL2 -\r cbnz x22, skip_bss PRINT("- Zero BSS -\r\n") -ldr x0, =__bss_start /* Load start & end of bss */ -ldr x1, =__bss_end +ldr x0, =.startof.(.bss) /* Load start & size of bss */ +ldr x1, =.sizeof.(.bss) add x0, x0, x20/* Apply physical offset */ -add x1, x1, x20 +add x1, x1, x0 /* Calculate end of .bss */ 1: str xzr, [x0], #8 cmp x0, x1 --- a/xen/arch/arm/device.c +++ b/xen/arch/arm/device.c @@ -21,8 +21,8 @@ #include #include -extern const struct device_desc _sdevice[], _edevice[]; -extern const struct acpi_device_desc _asdevice[], _aedevice[]; +extern const struct device_desc _sdevice[] asm(".startof.(.dev.info)"); +extern const struct device_desc _edevice[]; int __init device_init(struct dt_device_node *dev, enum device_class class, const void *data) @@ -51,6 +51,11 @@ int __init device_init(struct dt_device_ return -EBADF; } +#ifdef CONFIG_ACPI + +extern const struct acpi_device_desc _asdevice[] asm(".startof.(.adev.info)"); +extern const struct acpi_device_desc _aedevice[]; + int __init acpi_device_init(enum device_class class, const void *data, int class_type) { const struct acpi_device_desc *desc; @@ -68,6 +73,8 @@ int __init acpi_device_init(enum device_ return -EBADF; } +#endif + enum device_class device_get_class(const struct dt_device_node *dev) { const struct device_desc *desc; --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -2058,7 +2058,7 @@ static void __init find_gnttab_region(st * enough space for a large grant table */ kinfo->gnttab_start = __pa(_stext); -kinfo->gnttab_size = (_etext - _stext) & PAGE_MASK; +kinfo->gnttab_size = _sizeof_text & PAGE_MASK; /* Make sure the grant table will fit in the region */ if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames ) --- a/xen/arch/arm/platform.c +++ b/xen/arch/arm/platform.c @@ -22,7 +22,8 @@ #include #include -extern const struct platform_desc _splatform[], _eplatform[]; +extern const struct platform_desc _splatform[] asm(".startof.(.arch.info)"); +extern const struct platform_desc _eplatform[]; /* Pointer to the current platform description */ static const struct platform_desc *platform; --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -31,7 +31,6 @@ SECTIONS . = XEN_VIRT_START; _start = .; .text : /* XXX should be AT ( XEN_PHYS_START ) */ { -_stext = .;/* Text section */ *(.text) *(.text.cold) *(.text.unlikely) @@ -42,7 +41,6 @@ SECTIONS . = ALIGN(PAGE_SIZE); .rodata : { -_srodata = .; /* Read-only data */ /* Bug frames table */ __start_bug_frames = .; *(.bug_frames.0) @@ -104,21 +102,18 @@ SECTIONS . = ALIGN(8); .arch.info : { - _splatform = .; *(.arch.info) _eplatform = .; } :text . = ALIGN(8); .dev.info : { - _sdevice = .; *(.dev.info) _edevice = .; } :text . = ALIGN(8); .adev.info : { - _asdevice = .; *(.adev.info) _aedevice = .; } :text @@ -126,7 +121,6 @@ SECTIONS . = ALIGN(PAGE_SIZE); /* Init code and dat
[Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script
Besides being more logical this also allows verifying correct recording of alignments in .o files. The cpu0_stack related ASSERT() in xen.lds.S is now of questionable value (as it now verifies correct tool chain behavior), but I've left it in nevertheless. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re */ #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE) unsigned long __section(".bss.page_aligned") +__attribute__((aligned(PAGE_SIZE))) hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG]; /* Xen command-line option to enable HAP */ --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -125,7 +125,8 @@ #include /* Mapping of the fixmap space needed early. */ -l1_pgentry_t __section(".bss.page_aligned") l1_fixmap[L1_PAGETABLE_ENTRIES]; +l1_pgentry_t __section(".bss.page_aligned") __attribute__((aligned(PAGE_SIZE))) +l1_fixmap[L1_PAGETABLE_ENTRIES]; #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING , _f "\n" , ## _a) @@ -588,7 +589,8 @@ static inline void guest_get_eff_kern_l1 TOGGLE_MODE(); } -const char __section(".bss.page_aligned.const") zero_page[PAGE_SIZE]; +const char __section(".bss.page_aligned.const") +__attribute__((aligned(PAGE_SIZE))) zero_page[PAGE_SIZE]; static void invalidate_shadow_ldt(struct vcpu *v, int flush) { --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -105,7 +105,8 @@ unsigned long __read_mostly xen_virt_end DEFINE_PER_CPU(struct tss_struct, init_tss); -char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE]; +char __section(".bss.stack_aligned") __attribute__((aligned(STACK_SIZE))) +cpu0_stack[STACK_SIZE]; struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 0, 0, -1 }; --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -222,7 +222,6 @@ SECTIONS } :text .data : {/* Data */ - . = ALIGN(PAGE_SIZE); *(.data.page_aligned) *(.data) *(.data.rel) @@ -231,10 +230,8 @@ SECTIONS } :text .bss : { /* BSS */ - . = ALIGN(STACK_SIZE); __bss_start = .; *(.bss.stack_aligned) - . = ALIGN(PAGE_SIZE); *(.bss.page_aligned*) *(.bss) . = ALIGN(SMP_CACHE_BYTES); x86: force suitable alignment in sources rather than in linker script Besides being more logical this also allows verifying correct recording of alignments in .o files. The cpu0_stack related ASSERT() in xen.lds.S is now of questionable value (as it now verifies correct tool chain behavior), but I've left it in nevertheless. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re */ #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE) unsigned long __section(".bss.page_aligned") +__attribute__((aligned(PAGE_SIZE))) hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG]; /* Xen command-line option to enable HAP */ --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -125,7 +125,8 @@ #include /* Mapping of the fixmap space needed early. */ -l1_pgentry_t __section(".bss.page_aligned") l1_fixmap[L1_PAGETABLE_ENTRIES]; +l1_pgentry_t __section(".bss.page_aligned") __attribute__((aligned(PAGE_SIZE))) +l1_fixmap[L1_PAGETABLE_ENTRIES]; #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING , _f "\n" , ## _a) @@ -588,7 +589,8 @@ static inline void guest_get_eff_kern_l1 TOGGLE_MODE(); } -const char __section(".bss.page_aligned.const") zero_page[PAGE_SIZE]; +const char __section(".bss.page_aligned.const") +__attribute__((aligned(PAGE_SIZE))) zero_page[PAGE_SIZE]; static void invalidate_shadow_ldt(struct vcpu *v, int flush) { --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -105,7 +105,8 @@ unsigned long __read_mostly xen_virt_end DEFINE_PER_CPU(struct tss_struct, init_tss); -char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE]; +char __section(".bss.stack_aligned") __attribute__((aligned(STACK_SIZE))) +cpu0_stack[STACK_SIZE]; struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 0, 0, -1 }; --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -222,7 +222,6 @@ SECTIONS } :text .data : {/* Data */ - . = ALIGN(PAGE_SIZE); *(.data.page_aligned) *(.data) *(.data.rel) @@ -231,10 +230,8 @@ SECTIONS } :text .bss : { /* BSS */ - . = ALIGN(STACK_SIZE); __bss_start = .; *(.bss.stack_aligned) - . = ALIGN(PAGE_SIZE); *(.bss.page_aligned*) *(.bss) . = ALIGN(SMP_CACHE_BYTES); ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] build-id: fix minor quirks
The initial size check in xen_build_id_check() came too late (after the first access to the structure), but was mostly redundant with checks done in all callers; convert it to a properly placed ASSERT(). The "mostly" part being addressed too: xen_build_init() was off by one. And then there was a stray semicolon. Signed-off-by: Jan Beulich --- a/xen/common/version.c +++ b/xen/common/version.c @@ -1,6 +1,7 @@ #include #include #include +#include #include #include #include @@ -90,12 +91,11 @@ int xen_build_id_check(const Elf_Note *n const void **p, unsigned int *len) { /* Check if we really have a build-id. */ +ASSERT(n_sz > sizeof(*n)); + if ( NT_GNU_BUILD_ID != n->type ) return -ENODATA; -if ( n_sz <= sizeof(*n) ) -return -EINVAL; - if ( n->namesz + n->descsz < n->namesz ) return -EINVAL; @@ -127,8 +127,8 @@ static int __init xen_build_init(void) return -ENODATA; /* Check for full Note header. */ -if ( &n[1] > __note_gnu_build_id_end ) -return -ENODATA;; +if ( &n[1] >= __note_gnu_build_id_end ) +return -ENODATA; sz = (void *)__note_gnu_build_id_end - (void *)n; build-id: fix minor quirks The initial size check in xen_build_id_check() came too late (after the first access to the structure), but was mostly redundant with checks done in all callers; convert it to a properly placed ASSERT(). The "mostly" part being addressed too: xen_build_init() was off by one. And then there was a stray semicolon. Signed-off-by: Jan Beulich --- a/xen/common/version.c +++ b/xen/common/version.c @@ -1,6 +1,7 @@ #include #include #include +#include #include #include #include @@ -90,12 +91,11 @@ int xen_build_id_check(const Elf_Note *n const void **p, unsigned int *len) { /* Check if we really have a build-id. */ +ASSERT(n_sz > sizeof(*n)); + if ( NT_GNU_BUILD_ID != n->type ) return -ENODATA; -if ( n_sz <= sizeof(*n) ) -return -EINVAL; - if ( n->namesz + n->descsz < n->namesz ) return -EINVAL; @@ -127,8 +127,8 @@ static int __init xen_build_init(void) return -ENODATA; /* Check for full Note header. */ -if ( &n[1] > __note_gnu_build_id_end ) -return -ENODATA;; +if ( &n[1] >= __note_gnu_build_id_end ) +return -ENODATA; sz = (void *)__note_gnu_build_id_end - (void *)n; ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] eliminate some section start symbols
Section start symbols frequently obscure the actual symbol name living at the start of the section. Eliminate them where they can be replaced by linker resolved .startof.* symbols. (Section end symbols may have the same undesirable effect, but they're less easy to eliminate, as they'd need to be represented by the sum of .startof. and .sizeof.). 1: x86: force suitable alignment in sources rather than in linker script 2: make use of .startof.() and .sizeof.() assembler expressions Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] build-id adjustments
1: build-id: fix minor quirks 2: x86/EFI: use less crude way of generating the build ID Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 100452: all pass - PUSHED
flight 100452 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100452/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 62b8b5be713dd1f801cd44e4eb28f68585a9bd85 baseline version: ovmf 82df618711c596d3b6164e790572c795b7ea4dcc Last test of basis 100433 2016-08-12 07:46:05 Z0 days Testing same since 100452 2016-08-12 12:15:55 Z0 days1 attempts People who touched revisions under test: Star Zeng 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 : + branch=ovmf + revision=62b8b5be713dd1f801cd44e4eb28f68585a9bd85 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 62b8b5be713dd1f801cd44e4eb28f68585a9bd85 + branch=ovmf + revision=62b8b5be713dd1f801cd44e4eb28f68585a9bd85 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.7-testing + '[' x62b8b5be713dd1f801cd44e4eb28f68585a9bd85 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']' +++ echo 'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]' ++ : 'git://cache:941
Re: [Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON
Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote: > BUILD_BUG_ON should not appear in a public-facing header, otherwise it > risks clashing with macro with the same name in other code bases. I > encountered such issue when trying to add BUILD_BUG_ON to a private > header in Xen's gnttab library. > > Ideally BUILD_BUG_ON should be moved to a private header, but there is > actually no user of it in mini-os tree, just remove it. > > Signed-off-by: Wei Liu Acked-by: Samuel Thibault > --- > include/lib.h | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/include/lib.h b/include/lib.h > index 39d6a18..e7155e2 100644 > --- a/include/lib.h > +++ b/include/lib.h > @@ -54,15 +54,6 @@ > #include > #include "gntmap.h" > > -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) > -#define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); }) > -#define BUILD_BUG_ON_ZERO(cond) \ > -sizeof(struct { _Static_assert(!(cond), "!(" #cond ")"); }) > -#else > -#define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); }) > -#define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond)) > -#endif > - > #ifdef HAVE_LIBC > #include > #include > -- > 2.1.4 > -- Samuel (03:13:14) bon (03:13:19) il est tard :p (03:13:25) c'est l'heure de manger (03:13:38) hm j'ai mangé à 1h moi, j'ai des horaires raisonnables ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON
BUILD_BUG_ON should not appear in a public-facing header, otherwise it risks clashing with macro with the same name in other code bases. I encountered such issue when trying to add BUILD_BUG_ON to a private header in Xen's gnttab library. Ideally BUILD_BUG_ON should be moved to a private header, but there is actually no user of it in mini-os tree, just remove it. Signed-off-by: Wei Liu --- include/lib.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/lib.h b/include/lib.h index 39d6a18..e7155e2 100644 --- a/include/lib.h +++ b/include/lib.h @@ -54,15 +54,6 @@ #include #include "gntmap.h" -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) -#define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); }) -#define BUILD_BUG_ON_ZERO(cond) \ -sizeof(struct { _Static_assert(!(cond), "!(" #cond ")"); }) -#else -#define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); }) -#define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond)) -#endif - #ifdef HAVE_LIBC #include #include -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 100431: regressions - FAIL
flight 100431 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100431/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 100424 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 7 host-ping-check-xenfail pass in 100424 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 100424 build-i386-rumpuserxen6 xen-buildfail like 100424 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100424 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100424 test-amd64-amd64-xl-rtds 9 debian-install fail like 100424 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100424 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100424 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 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-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 100424 never pass test-amd64-amd64-libvirt12 migrate-support-check fail in 100424 never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail in 100424 never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail in 100424 never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 100424 never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail in 100424 never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 072e6709978143145a1c1b98c7f014dc4d87907f baseline version: xen 072e6709978143145a1c1b98c7f014dc4d87907f Last test of basis 100431 2016-08-12 07:34:23 Z0 days Testing same since0 1970-01-01 00:00:00 Z 17025 days0 attempts jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass buil
Re: [Xen-devel] [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path
I'll try to test this, but I have one comment inline... On 08/11/2016 10:17 PM, Dave Young wrote: On 08/10/16 at 05:09pm, Hidehiro Kawai wrote: Daniel Walker reported problems which happens when crash_kexec_post_notifiers kernel option is enabled (https://lkml.org/lkml/2015/6/24/44). In that case, smp_send_stop() is called before entering kdump routines which assume other CPUs are still online. As the result, kdump routines fail to save other CPUs' registers. Additionally for MIPS OCTEON, it misses to stop the watchdog timer. To fix this problem, call a new kdump friendly function, crash_smp_send_stop(), instead of the smp_send_stop() when crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a weak function, and it just call smp_send_stop(). Architecture codes should override it so that kdump can work appropriately. This patch provides MIPS version. Reported-by: Daniel Walker Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option) Signed-off-by: Hidehiro Kawai Cc: Ralf Baechle Cc: David Daney Cc: Aaro Koskinen Cc: "Steven J. Hill" Cc: Corey Minyard --- I'm not familiar with MIPS, and I don't have a test environment and just did build tests only. Please don't apply this patch until someone does enough tests, otherwise simply drop this patch. --- arch/mips/cavium-octeon/setup.c | 14 ++ arch/mips/include/asm/kexec.h|1 + arch/mips/kernel/crash.c | 18 +- arch/mips/kernel/machine_kexec.c |1 + 4 files changed, 33 insertions(+), 1 deletion(-) diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c index cb16fcc..5537f95 100644 --- a/arch/mips/cavium-octeon/setup.c +++ b/arch/mips/cavium-octeon/setup.c @@ -267,6 +267,17 @@ static void octeon_crash_shutdown(struct pt_regs *regs) default_machine_crash_shutdown(regs); } +#ifdef CONFIG_SMP +void octeon_crash_smp_send_stop(void) +{ + int cpu; + + /* disable watchdogs */ + for_each_online_cpu(cpu) + cvmx_write_csr(CVMX_CIU_WDOGX(cpu_logical_map(cpu)), 0); +} +#endif + #endif /* CONFIG_KEXEC */ #ifdef CONFIG_CAVIUM_RESERVE32 @@ -911,6 +922,9 @@ void __init prom_init(void) _machine_kexec_shutdown = octeon_shutdown; _machine_crash_shutdown = octeon_crash_shutdown; _machine_kexec_prepare = octeon_kexec_prepare; +#ifdef CONFIG_SMP + _crash_smp_send_stop = octeon_crash_smp_send_stop; +#endif #endif octeon_user_io_init(); diff --git a/arch/mips/include/asm/kexec.h b/arch/mips/include/asm/kexec.h index ee25ebb..493a3cc 100644 --- a/arch/mips/include/asm/kexec.h +++ b/arch/mips/include/asm/kexec.h @@ -45,6 +45,7 @@ extern const unsigned char kexec_smp_wait[]; extern unsigned long secondary_kexec_args[4]; extern void (*relocated_kexec_smp_wait) (void *); extern atomic_t kexec_ready_to_reboot; +extern void (*_crash_smp_send_stop)(void); #endif #endif diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c index 610f0f3..1723b17 100644 --- a/arch/mips/kernel/crash.c +++ b/arch/mips/kernel/crash.c @@ -47,9 +47,14 @@ static void crash_shutdown_secondary(void *passed_regs) static void crash_kexec_prepare_cpus(void) { + static int cpus_stopped; unsigned int msecs; + unsigned int ncpus; - unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */ + if (cpus_stopped) + return; Wouldn't you want an atomic operation and some special handling here to ensure that only one CPU does this? So if a CPU comes in here and another CPU is already in the process stopping the CPUs it won't result in a deadlock. -corey + + ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */ dump_send_ipi(crash_shutdown_secondary); smp_wmb(); @@ -64,6 +69,17 @@ static void crash_kexec_prepare_cpus(void) cpu_relax(); mdelay(1); } + + cpus_stopped = 1; +} + +/* Override the weak function in kernel/panic.c */ +void crash_smp_send_stop(void) +{ + if (_crash_smp_send_stop) + _crash_smp_send_stop(); + + crash_kexec_prepare_cpus(); } #else /* !defined(CONFIG_SMP) */ diff --git a/arch/mips/kernel/machine_kexec.c b/arch/mips/kernel/machine_kexec.c index 50980bf3..5972520 100644 --- a/arch/mips/kernel/machine_kexec.c +++ b/arch/mips/kernel/machine_kexec.c @@ -25,6 +25,7 @@ void (*_machine_crash_shutdown)(struct pt_regs *regs) = NULL; #ifdef CONFIG_SMP void (*relocated_kexec_smp_wait) (void *); atomic_t kexec_ready_to_reboot = ATOMIC_INIT(0); +void (*_crash_smp_send_stop)(void) = NULL; #endif int Can any mips people review this patch and have a test? Thanks Dave ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] dependences for backporting to 4.6 [was: Re: [PATCH 2/3] xen: Have schedulers revise initial placement]
>>> On 12.08.16 at 03:59, wrote: > On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote: >> I'd really like to have those backported, but I have to ask one >> of you to identify which prereq-s are needed on 4.6 and 4.5 >> (I'll revert them from 4.5 right away, but I'll wait for an osstest >> flight to confirm the same issue exists on 4.6). >> > So, for 4.6, I think the only prerequisite would be this: > > 6b53bb4ab3c9bd5eccde88a5175cf72589ba6d52 > "sched: better handle (not) inserting idle vCPUs in runqueues" > > That, however, does not apply cleanly. The important part of it is the > last hunk: > > diff --git a/xen/common/schedule.c b/xen/common/schedule.c > index 92057eb..c195129 100644 > --- a/xen/common/schedule.c > +++ b/xen/common/schedule.c > @@ -240,20 +240,22 @@ int sched_init_vcpu(struct vcpu *v, unsigned int > processor) > init_timer(&v->poll_timer, poll_timer_fn, > v, v->processor); > > -/* Idle VCPUs are scheduled immediately. */ > +v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv); > +if ( v->sched_priv == NULL ) > +return 1; > + > +TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id); > + > +/* Idle VCPUs are scheduled immediately, so don't put them in runqueue. > */ > if ( is_idle_domain(d) ) > { > per_cpu(schedule_data, v->processor).curr = v; > v->is_running = 1; > } > - > -TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id); > - > -v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv); > -if ( v->sched_priv == NULL ) > -return 1; > - > -SCHED_OP(DOM2OP(d), insert_vcpu, v); > +else > +{ > +SCHED_OP(DOM2OP(d), insert_vcpu, v); > +} > > return 0; > } > > With this only applied, things works for me. The hunk is actually the > core of the patch, the only real functionality change. The other hunks > are refactoring and cleanups (made possible by it). > > So, I'm not sure whether the best route here is: > - fully backport 6b53bb4ab3c9b; > - backport only the last hunk of 6b53bb4ab3c9b as its own patch; > - fold the last hunk of 6b53bb4ab3c9b in the backport of George's >patch (I mean, what was 83dff3992a89 in staging-4.6); > > Thoughts? First of all - thanks a lot for helping out here. With above extra commit things are indeed back to normal again for me. Since the adjustments to that commit to make it apply were mostly mechanical, I think I'd prefer taking the entire backport. Same for 4.5 then, were the backport adjusted for 4.6 then applied cleanly. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)
On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote: > On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote: > > Hey Ross, > > > > I am running in a symbol dependency issue that I am not exactly > > sure how to solve. > > > > I have an payload that introduces a new function (xen_foobar) which > > will patch over xen_extra_version(). > > > snip > > > > As livepatch_symbols_lookup_by_name only looks for symbols that > > have the ->new_symbol set. And xen_foobar does not. So the loading is > > aborted. > > > > Which makes sense - we don't want to match the symbols as they haven't > > really been "finally loaded" in. > > > > But what if the xen_foobar is applied. In that case we should > > change the xen_foobar to be new_symbol=1? > > I think you're confused about the purpose of new_symbol. The purpose is to > ensure that you link against the correct symbol from the base hypervisor or > the live patch that first introduced it. So, new_symbol=0 is when a symbol > overrides an existing symbol. new_symbol=1 is set when a symbol is new But it does not (overrides the existing symbol). The patch (xen_foobar) introduces a new function called xen_foobar which is patching xen_extra_version. That is: static char foobar_patch_this_fnc[] = "xen_extra_version"; struct livepatch_func __section(".livepatch.funcs") livepatch_xen_foobar = { .version = LIVEPATCH_PAYLOAD_VERSION, .name = foobar_patch_this_fnc, .new_addr = xen_foobar, .old_addr = xen_extra_version, .new_size = NEW_CODE_SZ, .old_size = OLD_CODE_SZ, }; > introduced in a live patch. And this loop: for ( j = 0; j < payload->nfuncs; j++ ) { if ( symtab[i].value == (unsigned long)payload->funcs[j].new_addr ) { found = 1; break; } } Will force new_symbol=0 for xen_foobar. > > Since all the linking happens during load and not apply, it is perfectly OK > to link against a symbol that hasn't been applied -- the dependencies are > there to ensure that you can't apply a patch which links against unapplied > symbols. > > The assumption is that when overriding an existing symbol, the symbol in the > payload has the same name as the one it is overriding. You're having issues > above because you're breaking this assumption. Yes :-) > > > > > This following patch does that, but I am wondering if there is a better > > way? > > The patch is misusing new_symbol for something completely different from how > it was intended so I hope there is a better way :-P Well for my use-case I think I can just s/xen_foobar/xen_extra_version/ and we should be OK. > Let's have a discussion about this and the symbol issues here at the Xen > Summit in a couple of weeks time. /me nods. > > -- > Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-wheezy test] 66969: all pass
flight 66969 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66969/ Perfect :-) All tests in this flight passed as required baseline version: flight 66914 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass test-amd64-i386-i386-wheezy-netboot-pvgrub pass test-amd64-i386-amd64-wheezy-netboot-pygrub pass test-amd64-amd64-i386-wheezy-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output
On Fri, Aug 12, 2016 at 10:51:37AM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting > output"): > > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote: > > > We don't care when xenconsoled closes the logfile. We care about when > > > it last calls write() (with a nonempty buffer). > > > > In logfile mode, no console client is spawned, because it is not > > reliable -- that's why we use logfile mode in the first place. > > > > And I would rather just add a bodge (wait 1 or 2 seconds) > > That would increase the duration of each test by that 1 or 2 seconds. > I suppose you could conclude the logfile is complete if it contains > the expected end-of-run message from the vm, and only poll if not. > > But, it's worse: > > I went to read the xenconsoled source code, and it can handle a domain > death event before finishing reading all of the data out of a domain's > ring. > > Maybe this will be mitigated by XTF's printf waiting for the > xenconsoled ring pointer to catch up ? > I think so. Under normal circumstance (micro VM doesn't crash), we're sure that all output is consumed by xenconsoled before the VM shuts down itself. > xenconsoled advances the ring pointer before writing to the logfile, > but (assuming there's no overflow), the write will happen before it > goes back into the event loop, so it won't be lost. > Correct. > > than to rely on sophisticated hack. > > To my mind polling the logfile looking for the final message from the > vm is something of a hack. > > But indeed I can't see another way to wait for xenconsoled, than > going behind libxl's back with something like > * spawn xl create -p -F > * look for the console tty in xenstore > * open the console tty > * unpause > * wait for the console tty to get eof > > This is not a logfile mode at all, of course. It probably wouldn't be > easily adaptable to other toolstacks (eg XenServer). > Andrew, what is your opinion? Wei. > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xl cpupool-numa-split: don't try to bring any dom0 vCPUs online
Since commit a9dd01431a799b6743193a75f4f1ce2fdfdb7296, main_cpupoolnumasplit wants to ensure that dom0 doesn't have more online vCPUs than the number of pCPUs in a NUMA node. However, if dom0 already has fewer online vCPUs than the number of pCPUs in a NUMA node, this will cause some to be made online. Furthermore, if dom0's maximum number of vCPUs is less than the number of pCPUs, this will result in an error like the following: libxl: error: libxl.c:5564:libxl_set_vcpuonline: Requested 24 VCPUs, however maxcpus is 12!: Function not implemented error on removing vcpus for Domain-0 Instead, make main_cpupoolnumasplit only reduce the number of vCPUs dom0 has online, and don't try to add any more. This incurs an extra call to libxl_domain_info to find out the current number of dom0 vCPUs. Conveniently, there is already an initialised libxl_dominfo that we can use. Signed-off-by: Jonathan Davies --- tools/libxl/xl_cmdimpl.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 7f961e3..d5df20d 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -8614,12 +8614,19 @@ int main_cpupoolnumasplit(int argc, char **argv) goto out; } +if (libxl_domain_info(ctx, &info, 0)) { +fprintf(stderr, "error on getting info for Domain-0\n"); +goto out; +} + n = 0; for (c = 0; c < n_cpus; c++) { if (topology[c].node == node) { topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY; -libxl_bitmap_set(&cpumap, n); -n++; +if (n < info.vcpu_online) { +libxl_bitmap_set(&cpumap, n); +n++; +} } } if (libxl_domain_info(ctx, &info, 0)) { -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning
Wei Liu, on Fri 12 Aug 2016 13:48:09 +0100, wrote: > ---8<--- > From d72510368cdc3c73af3c8918a404a8137f40bd9c Mon Sep 17 00:00:00 2001 > From: Wei Liu > Date: Fri, 12 Aug 2016 11:32:57 +0100 > Subject: [PATCH] x86/arch_mm.h: move p2m_chk_pfn to x86/mm.c > > Making that function inlined won't buy us much and is causing error in > vtpm manager stubdom build. > > Signed-off-by: Wei Liu Acked-by: Samuel Thibault > --- > arch/x86/mm.c | 9 + > include/x86/arch_mm.h | 11 +++ > 2 files changed, 12 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/mm.c b/arch/x86/mm.c > index 8fa3b4c..88a928d 100644 > --- a/arch/x86/mm.c > +++ b/arch/x86/mm.c > @@ -608,6 +608,15 @@ static void clear_bootstrap(void) > printk("Unable to unmap NULL page. rc=%d\n", rc); > } > > +void p2m_chk_pfn(unsigned long pfn) > +{ > +if ( (pfn >> L3_P2M_SHIFT) > 0 ) > +{ > +printk("Error: Too many pfns.\n"); > +do_exit(); > +} > +} > + > void arch_init_p2m(unsigned long max_pfn) > { > unsigned long *l2_list = NULL, *l3_list; > diff --git a/include/x86/arch_mm.h b/include/x86/arch_mm.h > index e5d9c57..690a919 100644 > --- a/include/x86/arch_mm.h > +++ b/include/x86/arch_mm.h > @@ -190,14 +190,9 @@ typedef unsigned long pgentry_t; > #define L2_P2M_IDX(pfn) (((pfn) >> L1_P2M_SHIFT) & P2M_MASK) > #define L3_P2M_IDX(pfn) (((pfn) >> L2_P2M_SHIFT) & P2M_MASK) > #define INVALID_P2M_ENTRY (~0UL) > -static inline void p2m_chk_pfn(unsigned long pfn) > -{ > -if ( (pfn >> L3_P2M_SHIFT) > 0 ) > -{ > -printk("Error: Too many pfns.\n"); > -do_exit(); > -} > -} > + > +void p2m_chk_pfn(unsigned long pfn); > + > static inline unsigned long p2m_pages(unsigned long pages) > { > return (pages + P2M_ENTRIES - 1) >> L1_P2M_SHIFT; > -- > 2.1.4 > -- Samuel "How should I know if it works? That's what beta testers are for. I only coded it." (Attributed to Linus Torvalds, somewhere in a posting) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
>>> On 12.08.16 at 14:53, wrote: > On 12/08/2016 13:41, "Jan Beulich" wrote: > On 12.08.16 at 01:13, wrote: >>> +### Lazy Consensus {#lazyconsensus} >>> + >>> +Lazy Consensus is a useful technique to make decisions for specific >>>proposals >>> +which are not covered by the Review Then Commit Policy or do not >>>require a more >>> +formal decison (see below). Lazy Consensus is extremely useful, when >>>you don't >>> +anticipate any objections, or to gage whether there are objections to >>>a >>> +proposal. To make use of it, post something like the following on the >>>project's >>> +mailing list (or some other communication channel): >>> >>> >>>- >>> >>> -ISSUES TO BE ADDRESSED LATER: >>> -- The "Consensus Decision Making" section is totally wrong. It >>>does not describe >>> - "Lazy Consensus" >>> +Should we set a fixed time-frame? If so what? >>> >>>- >>> >>> >>> -Sub-projects or teams hosted on Xenproject.org are normally >>>auto-governing and >>> -driven by the people who volunteer for the job. This functions well >>>for most >>> -cases. When more formal decision making and coordination is required, >>>decisions >>> -are taken with a lazy consensus approach: a few positive votes with no >>>negative >>> -vote are enough to get going. >>> +> I am assuming we are agreed on X and am going to assume lazy >>>consensus: < >>> +> if there are no objections within the next seven days. >>> < >>> + >>> +You should however ensure that all relevant stake-holders which may >>>object are >>> +explicitly CC'ed, such as relevant maintainers or committers, ensure >>>that >>> +**lazy consensus** is in the body of your message (this helps set up >>>mail >>> +filters) and choose a reasonable time-frame. If it is unclear who the >>>relevant >>> +stake-holders are, the project leadership can nominate a group of >>>stake-holders >>> +to decide, or may choose to own the decision collectively and resolve >>>it. >>> + >>> +Objections by stake-holders should be expressed using the [conventions >>> +above](#expressingopinion) to make disagreements easily identifiable. >>> + >>> +__Passed/Failed:__ >>> + >>> +- Failed: A single **-2** by a stake-holder whose approval is >>>necessary >>> +- Failed: **-1**'s by all stake-holder whose approval is necessary >>> +- Passed: In all other situations >> >>Hmm, that means all -1's except a single 0 would already be a pass? > > That is not the intention. If we have only -1's and 0's it should be a > fail. > Let me fix this in the next revisions. > > How about: > +- Failed: Only **-1** or **0** votes by all stake-holder whose approval > is necessary That would still leave 10 -1's overruled by a single +1. > Although maybe someone can come up with a clearer way to express this. Maybe when there are no +2's, simply take the sum of all votes, and require it to be non-negative? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to add disk on ARM64
On 12/08/2016 14:24, Peng Fan wrote: Hi, Hello Peng, I have CCed Roger who is more familiar than me with the hotplug scripts. I am using xen master branch on i.MX8 ARM64. My xl configuration: kernel = "/root/xen/Image" memory = "128" name = "DomU" vcpus = 1 serial="pty" disk = [ 'phy:/dev/loop0,xvda,w' ] extra = "console=hvc0 root=/dev/xvda debug=/bin/sh" And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux. But I met the following error: libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /etc/xen/scripts/block add ^M^M Device /dev/loop0 is mounted in the privileged domain,^M^M and so cannot be mounted by a guest.^M^M libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block add [800] exited with error status 1^M^M libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: deregister unregistered^M^M libxl: error: libxl_devi ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is mounted in the privileged domain,^M^M and so cannot be mounted by a guest.^M^M From my understanding, you have mounted /dev/loop0 in Dom0, is that correct? However, we don't support sharing the same mounting point by default (Roger can you confirm). libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: deregister unregistered^M^M libxl: error: libxl_create.c:1244:domcreate_launch_dm: unable to add disk devices Then I change disk to "disk = [ 'format=raw, vdev=xvda, access=rw, target=/root/DomU-rootfs' ]" But met other errors: " /etc/xen/scripts/block failed; error detected. " Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On 12/08/2016 13:41, "Jan Beulich" wrote: On 12.08.16 at 01:13, wrote: >> +### Lazy Consensus {#lazyconsensus} >> + >> +Lazy Consensus is a useful technique to make decisions for specific >>proposals >> +which are not covered by the Review Then Commit Policy or do not >>require a more >> +formal decison (see below). Lazy Consensus is extremely useful, when >>you don't >> +anticipate any objections, or to gage whether there are objections to >>a >> +proposal. To make use of it, post something like the following on the >>project's >> +mailing list (or some other communication channel): >> >> >>- >> >> -ISSUES TO BE ADDRESSED LATER: >> -- The "Consensus Decision Making" section is totally wrong. It >>does not describe >> - "Lazy Consensus" >> +Should we set a fixed time-frame? If so what? >> >>- >> >> >> -Sub-projects or teams hosted on Xenproject.org are normally >>auto-governing and >> -driven by the people who volunteer for the job. This functions well >>for most >> -cases. When more formal decision making and coordination is required, >>decisions >> -are taken with a lazy consensus approach: a few positive votes with no >>negative >> -vote are enough to get going. >> +> I am assuming we are agreed on X and am going to assume lazy >>consensus: < >> +> if there are no objections within the next seven days. >> < >> + >> +You should however ensure that all relevant stake-holders which may >>object are >> +explicitly CC'ed, such as relevant maintainers or committers, ensure >>that >> +**lazy consensus** is in the body of your message (this helps set up >>mail >> +filters) and choose a reasonable time-frame. If it is unclear who the >>relevant >> +stake-holders are, the project leadership can nominate a group of >>stake-holders >> +to decide, or may choose to own the decision collectively and resolve >>it. >> + >> +Objections by stake-holders should be expressed using the [conventions >> +above](#expressingopinion) to make disagreements easily identifiable. >> + >> +__Passed/Failed:__ >> + >> +- Failed: A single **-2** by a stake-holder whose approval is >>necessary >> +- Failed: **-1**'s by all stake-holder whose approval is necessary >> +- Passed: In all other situations > >Hmm, that means all -1's except a single 0 would already be a pass? That is not the intention. If we have only -1's and 0's it should be a fail. Let me fix this in the next revisions. How about: +- Failed: Only **-1** or **0** votes by all stake-holder whose approval is necessary Although maybe someone can come up with a clearer way to express this. >> +Let me express this as an algorithm. >> + >> + treshhold=2/3; >> + active='number of active members'; (7 for the Hypervisor >>project; IanC is inactive) >> + favour='number of +1 and +2 votes' >> + against='number of -1 and -2 votes' >> + strong-against='number -2 votes'; just added this as a sanity >>check >> + >> +One open question is what to do with 0-votes. We could introduce a >>rule discounting >> +0 votes (let's call it 0-rule). If someone votes 0, we assume they >>really don't care >> +about the outcome and are considered inactive for the purpose of >>the vote. >> + >> +In that case: >> + >> + active -= 0-votes; >> + >> +Without the 0-rule: >> +- to pass: favour/active >= treshhold >> + to pass: with active==7, favour >= 5 >> + in other words, 3 (0,-1,-2)-votes block the proposal as we cant >>achieve favour>=5 >> + >> +With the 0-rule, let's consider 1, 2 or 3 0-votes >> +1=>6: to pass: favour >=4 >> + in other words, 3 (-1,-2)-votes block the proposal >> +2=>5: to pass: favour >=4 >> + in other words, 2 (-1,-2)-vote blocks the proposal >> +3=>4: to pass: favour >=3 >> + in other words, 2 (-1,-2)-vote blocks the proposal >> + >> +Looking at the arithmetic, it does probably make sense to go for >>the 0-rule. If we >> +do, there ought to be more votes in favour of a proposal, than >>0-votes. >> + >> +On the other hand, not having the 0-rule forces everyone to form >>an opinion, >> +otherise we will find it hard to make decisions. But in some >>cases, forming an >> +opinion costs significant mental capacity. >> + >> +It would also allow us to remove the complexity of differentiating >>between >> +active and non-active leadership team members by assuming that no >>vote, equals >> +a "0" vote. >> + >> +Opinions? > >I'm in favor of the "with 0-rule" variant. That's what I assumed most people would go for and which is (hopefully correctly) implemented in the rules above the comment section. Regards Lars ___ Xen-devel mailing list Xen-devel@lists.x
Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning
On Fri, Aug 12, 2016 at 12:42:31PM +0100, Wei Liu wrote: > On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote: > > Support ballooning Mini-OS automatically up in case of memory shortage. > > > > Do some cleanups, a small correction and add some basic features to > > lay groundwork for support of ballooning in Mini-OS (patches 1-14). > > > > The main visible change is the virtual memory layout: to be able to > > add memory to the running Mini-OS we need to have some spare areas > > especially after the 1:1 mapping of physical memory. > > > > Then add the ballooning functionality: the p2m map must be expanded, > > the page allocator's bitmap must be expanded and we must get new > > memory from the hypervisor. > > > > In case of a detected memory shortage the domain will balloon up until > > either enough memory is available or the upper limit has been reached. > > > > Ballooning has been tested with a xenstore stubdom. > > Regression tests have been done with: > > - pure mini-os > > - ioemu stubdom > > - pvgrub 64 bit > > > > Unfortunately vtmpmgr stubdom build failed. :-/ > And that's probably because vtpmmgr uses printk or whatever... Here is a patch that seems to fix the build: ---8<--- From d72510368cdc3c73af3c8918a404a8137f40bd9c Mon Sep 17 00:00:00 2001 From: Wei Liu Date: Fri, 12 Aug 2016 11:32:57 +0100 Subject: [PATCH] x86/arch_mm.h: move p2m_chk_pfn to x86/mm.c Making that function inlined won't buy us much and is causing error in vtpm manager stubdom build. Signed-off-by: Wei Liu --- arch/x86/mm.c | 9 + include/x86/arch_mm.h | 11 +++ 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/arch/x86/mm.c b/arch/x86/mm.c index 8fa3b4c..88a928d 100644 --- a/arch/x86/mm.c +++ b/arch/x86/mm.c @@ -608,6 +608,15 @@ static void clear_bootstrap(void) printk("Unable to unmap NULL page. rc=%d\n", rc); } +void p2m_chk_pfn(unsigned long pfn) +{ +if ( (pfn >> L3_P2M_SHIFT) > 0 ) +{ +printk("Error: Too many pfns.\n"); +do_exit(); +} +} + void arch_init_p2m(unsigned long max_pfn) { unsigned long *l2_list = NULL, *l3_list; diff --git a/include/x86/arch_mm.h b/include/x86/arch_mm.h index e5d9c57..690a919 100644 --- a/include/x86/arch_mm.h +++ b/include/x86/arch_mm.h @@ -190,14 +190,9 @@ typedef unsigned long pgentry_t; #define L2_P2M_IDX(pfn) (((pfn) >> L1_P2M_SHIFT) & P2M_MASK) #define L3_P2M_IDX(pfn) (((pfn) >> L2_P2M_SHIFT) & P2M_MASK) #define INVALID_P2M_ENTRY (~0UL) -static inline void p2m_chk_pfn(unsigned long pfn) -{ -if ( (pfn >> L3_P2M_SHIFT) > 0 ) -{ -printk("Error: Too many pfns.\n"); -do_exit(); -} -} + +void p2m_chk_pfn(unsigned long pfn); + static inline unsigned long p2m_pages(unsigned long pages) { return (pages + P2M_ENTRIES - 1) >> L1_P2M_SHIFT; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
>>> On 12.08.16 at 01:13, wrote: > +### Lazy Consensus {#lazyconsensus} > + > +Lazy Consensus is a useful technique to make decisions for specific > proposals > +which are not covered by the Review Then Commit Policy or do not require a > more > +formal decison (see below). Lazy Consensus is extremely useful, when you > don't > +anticipate any objections, or to gage whether there are objections to a > +proposal. To make use of it, post something like the following on the > project's > +mailing list (or some other communication channel): > > > - > -ISSUES TO BE ADDRESSED LATER: > -- The "Consensus Decision Making" section is totally wrong. It does not > describe > - "Lazy Consensus" > +Should we set a fixed time-frame? If so what? > > - > > -Sub-projects or teams hosted on Xenproject.org are normally auto-governing > and > -driven by the people who volunteer for the job. This functions well for most > -cases. When more formal decision making and coordination is required, > decisions > -are taken with a lazy consensus approach: a few positive votes with no > negative > -vote are enough to get going. > +> I am assuming we are agreed on X and am going to assume lazy > consensus: < > +> if there are no objections within the next seven days. > < > + > +You should however ensure that all relevant stake-holders which may object > are > +explicitly CC'ed, such as relevant maintainers or committers, ensure that > +**lazy consensus** is in the body of your message (this helps set up mail > +filters) and choose a reasonable time-frame. If it is unclear who the > relevant > +stake-holders are, the project leadership can nominate a group of > stake-holders > +to decide, or may choose to own the decision collectively and resolve it. > + > +Objections by stake-holders should be expressed using the [conventions > +above](#expressingopinion) to make disagreements easily identifiable. > + > +__Passed/Failed:__ > + > +- Failed: A single **-2** by a stake-holder whose approval is necessary > +- Failed: **-1**'s by all stake-holder whose approval is necessary > +- Passed: In all other situations Hmm, that means all -1's except a single 0 would already be a pass? > +Let me express this as an algorithm. > + > + treshhold=2/3; > + active='number of active members'; (7 for the Hypervisor project; IanC > is inactive) > + favour='number of +1 and +2 votes' > + against='number of -1 and -2 votes' > + strong-against='number -2 votes'; just added this as a sanity check > + > +One open question is what to do with 0-votes. We could introduce a rule > discounting > +0 votes (let's call it 0-rule). If someone votes 0, we assume they > really don't care > +about the outcome and are considered inactive for the purpose of the > vote. > + > +In that case: > + > + active -= 0-votes; > + > +Without the 0-rule: > +- to pass: favour/active >= treshhold > + to pass: with active==7, favour >= 5 > + in other words, 3 (0,-1,-2)-votes block the proposal as we cant > achieve favour>=5 > + > +With the 0-rule, let's consider 1, 2 or 3 0-votes > +1=>6: to pass: favour >=4 > + in other words, 3 (-1,-2)-votes block the proposal > +2=>5: to pass: favour >=4 > + in other words, 2 (-1,-2)-vote blocks the proposal > +3=>4: to pass: favour >=3 > + in other words, 2 (-1,-2)-vote blocks the proposal > + > +Looking at the arithmetic, it does probably make sense to go for the > 0-rule. If we > +do, there ought to be more votes in favour of a proposal, than 0-votes. > + > +On the other hand, not having the 0-rule forces everyone to form an > opinion, > +otherise we will find it hard to make decisions. But in some cases, > forming an > +opinion costs significant mental capacity. > + > +It would also allow us to remove the complexity of differentiating > between > +active and non-active leadership team members by assuming that no vote, > equals > +a "0" vote. > + > +Opinions? I'm in favor of the "with 0-rule" variant. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Unable to add disk on ARM64
Hi, I am using xen master branch on i.MX8 ARM64. My xl configuration: kernel = "/root/xen/Image" memory = "128" name = "DomU" vcpus = 1 serial="pty" disk = [ 'phy:/dev/loop0,xvda,w' ] extra = "console=hvc0 root=/dev/xvda debug=/bin/sh" And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux. But I met the following error: libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /etc/xen/scripts/block add ^M^M Device /dev/loop0 is mounted in the privileged domain,^M^M and so cannot be mounted by a guest.^M^M libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block add [800] exited with error status 1^M^M libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: deregister unregistered^M^M libxl: error: libxl_devi ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is mounted in the privileged domain,^M^M and so cannot be mounted by a guest.^M^M libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: deregister unregistered^M^M libxl: error: libxl_create.c:1244:domcreate_launch_dm: unable to add disk devices Then I change disk to "disk = [ 'format=raw, vdev=xvda, access=rw, target=/root/DomU-rootfs' ]" But met other errors: " /etc/xen/scripts/block failed; error detected. " Any ideas? Thanks, Peng. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL
>>> On 12.08.16 at 12:35, wrote: > The undefined behaviour sanitiser shows that it really is NULL via the > pre_initcall path. > > (XEN) > > (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66 > (XEN) member access within null pointer of type 'struct processor_pminfo' > (XEN) [ Xen-4.8-unstable x86_64 debug=y Not tainted ] > > (XEN)[] cpufreq_add_cpu+0x161/0xdc0 > (XEN)[] cpufreq.c#cpu_callback+0x20/0x30 > (XEN)[] cpufreq.c#cpufreq_presmp_init+0x2d/0x50 > (XEN)[] do_presmp_initcalls+0x22/0x30 > (XEN)[] __start_xen+0x378d/0x42f0 > (XEN)[] __high_start+0x53/0x60 > > Fix two other occurances of the same buggy logic. > > The processor_pminfo[] objects are only allocated as a result of > XENPF_set_processor_pminfo hypercalls, which means that this early cpu > callback will always hit the early NULL check, and is therefore pointless. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/boot: Align e820 and video data in the boot trampoline
>>> On 12.08.16 at 12:35, wrote: > The undefined behaviour sanitiser in Clang 3.8 identifies that these are all > misaigned when used in __start_xen(). > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only
>>> On 12.08.16 at 12:03, wrote: > On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote: >> >>> On 11.08.16 at 11:17, wrote: >> > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long > mbi_p) >> > if ( !opt_smep ) >> > setup_clear_cpu_cap(X86_FEATURE_SMEP); >> > if ( cpu_has_smep ) >> > +{ >> > set_in_cr4(X86_CR4_SMEP); >> > +if ( smep_hvm_only ) >> > +write_cr4(read_cr4() & ~X86_CR4_SMEP); >> > +} >> >> So that'll clear CR4.SMEP right here, but won't help with CR4 loads >> from mmu_cr4_features (as e.g. happens indirectly during VM exits, >> since the HOST_CR4 field gets set from this variable). >> >> Did you in fact test your change, including validation of the features >> correctly remaining off over the lifetime of the system? >> >> Further, considering that you don't clear the two flags from Xen's >> internal feature bitmap, and taken together with the internal feature >> bitmap driving alternative instruction patching, I'd assume pointless >> (and performance wise perhaps harmful) patching to now take place. >> > Let me see whether I understand this correctly... > > Regarding alternative instruction patching, if enabling SMAP for HVM but > disabling it for Xen, SMAP bit must be set in x86_capability feature > bitmap and cleared in mmu_cr4_features, which means instruction patching > would take place and a #UD may occur (since SMAP is disable in Xen, but > STAC/CLAC are patched and called). No #UD would occur (hence I only said "performance wise perhaps harmful"), as per the SDM. > A little dirty solution I can think of now is to temperarily clear SMAP > bit in x86_capability before patching instruction and then set it back > when instruction patching finish, like: > > ``` > if ( opt_smap == SMAP_HVM_ONLY ) > setup_clear_cpu_cap(X86_FEATURE_SMAP); > > alternative_instructions(); > > if ( opt_smap == SMAP_HVM_ONLY ) > __set_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability); > ``` Except that this would need further adjustment (e.g. using just __clear_bit() instead of setup_clear_cpu_cap(), or else you'd break CPU hotplug). I'm not against "a little dirty" solutions, as long as it doesn't end in plain hackery, and as long as the end result indeed meets all requirements. > Appreciate it if you have a better solution. Well, if I had a reasonably good solution, I could have gone and simply implemented it. It is the need to consider all resulting cases properly which makes this involved, and hence we've turned to you (Intel) for assistance. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses
On 12/08/16 11:58, Jan Beulich wrote: On 11.08.16 at 20:10, wrote: >> On 09/08/16 11:40, Jan Beulich wrote: >>> --- a/xen/arch/x86/cpu/mtrr/main.c >>> +++ b/xen/arch/x86/cpu/mtrr/main.c >>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >>> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) { >>> printk(KERN_WARNING >>>"mtrr: your processor doesn't support >>> write-combining\n"); >>> - return -ENOSYS; >>> + return -EOPNOTSUPP; >> Will this break the classic-xen MTRR code? ISTR it was very picky, from >> the cpuid work. > There are no -ENOSYS checks in there afaics, and I also can't > otherwise see any way for this change to break it. > >> Also, as some further cleanup, that printk should >> become a print-once. > Well, for a message that presumably would never actually get > issued (as I'm unaware of 64-bit capable CPUs not supporting > WC) I don't think this sort of cleanup has a really high priority. > Certainly not in this patch. Agreed. This was a TODO note, rather than a request for this patch. I have noticed a few other printk()'s which should become print once. Sorry for the confusion. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
>>> On 12.08.16 at 11:44, wrote: > On 09/08/16 12:30, Jan Beulich wrote: > On 09.08.16 at 12:48, wrote: >>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >>> depriv)"): Actually, having thought about this some more, and taking this together with the expectations to the privcmd driver previously outlined, I think this part is problematic: If all the driver is to know is the position (within the interface structure) of the target domain ID, then any guest handles embedded in the interface structure (XEN_HVMCTL_track_dirty_vram only for now) couldn't get validated, and hence user mode code would have a way to access or modify kernel memory. >>> >>> Could the hypervisor know the difference between user and kernel >>> memory, in principle ? >> >> Not without further new hypercalls, as the guest kernel would need >> to tell Xen what address ranges are kernel vs user (and that implies >> that any OS wishing to be able to act as Dom0 has a uniform >> separation of address spaces). > > Couldn't Xen tell from the guest pagetables whether the memory being > accessed was user-mode or kernel mode? That would be possible, but would feel like adding heuristics instead of a proper distinction. Clearly we'd already be in some trouble if there were cases where some structure doesn't get written to (and hence could live in user-r/o mapped space), but others would need to be verified to be user-r/w mapped. A lot of special casing, that is, and hence of lot of things to be got wrong. And then there is the problem of calling code being in rings 1 or 2: Page tables don't guard ring 0 against such, and we don't even have the notion of selectors (and hence address ranges) bounding accessible regions. We can't even say we assume all of them to be %ds-relative, as it would certainly be legitimate for such a structure to e.g. live on the stack. Of course an option would be to require the kernel driver to not allow requests from other than ring 3. Plus finally - how would we tell interface structures coming from a kernel invoked hypercall from those originating from user mode? There would need to be at least some kind of flag then, which the privcmd driver set, but normal hypercalls originating in the kernel don't. Or would you envision to allow this DMOP hypercall to only be made by user mode tools? If so, does stubdom run its qemu in ring 3 or rather in ring 0? [breaking the order of quoting] > And unless we're positive the guest kernel will never need these > hypercalls, we probably need a flag that allows kernel-mode pointers. Ah, you actually mention that already. >>> (Would it be sufficient to check the starts, or would >>> the ends need to be checked too?) >> >> Both would need to be checked, so the size field(s) would need to >> be locatable too. > > We could have the "fixed" part of the structure contain domid and an > array of which the privcmd driver could check. I don't think > that would be terrible. Doable, yes, but not really nice, especially for the party invoking the hypercall as well as the backing implementation in Xen (as opposed to the privcmd driver, for which such a model would likely work quite well), as they then can't use the normal, simple reading of structure fields, but instead would need to populate array elements in the right order. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning
On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote: > Support ballooning Mini-OS automatically up in case of memory shortage. > > Do some cleanups, a small correction and add some basic features to > lay groundwork for support of ballooning in Mini-OS (patches 1-14). > > The main visible change is the virtual memory layout: to be able to > add memory to the running Mini-OS we need to have some spare areas > especially after the 1:1 mapping of physical memory. > > Then add the ballooning functionality: the p2m map must be expanded, > the page allocator's bitmap must be expanded and we must get new > memory from the hypervisor. > > In case of a detected memory shortage the domain will balloon up until > either enough memory is available or the upper limit has been reached. > > Ballooning has been tested with a xenstore stubdom. > Regression tests have been done with: > - pure mini-os > - ioemu stubdom > - pvgrub 64 bit > Unfortunately vtmpmgr stubdom build failed. :-/ Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/7] x86emul: don't special case fetching unsigned 8-bit immediates
On 12/08/16 11:50, Jan Beulich wrote: On 11.08.16 at 19:38, wrote: >> On 11/08/16 17:44, Jan Beulich wrote: >> On 11.08.16 at 18:32, wrote: On 11/08/16 13:06, Jan Beulich wrote: > @@ -2893,7 +2894,6 @@ x86_emulate( > goto swint; > > case 0xcd: /* int imm8 */ > -src.val = insn_fetch_type(uint8_t); > swint_type = x86_swint_int; > swint: > rc = inject_swint(swint_type, src.val, I would be tempted to and an explicit (uint8_t) here, so that injection doesn't break if the prototype of inject_swint() changes. >>> I guess I'll leave it that way, for two reasons: >>> - One shouldn't change prototypes without checking whether callers >>> cope. >> Indeed, but that doesn't alter the fact that you, I, and others we have >> reviewed code from have managed to do precisely this, and break things. > Well, okay, will do that then. > >>> - Here you basically suggest the opposite of what you wish done to >>> the earlier patch for the jmp_rel() invocations. >> jmp_rel() is a macro not a function, but in hindsight, I rescind that >> request. > As that was the only change request to that other patch, may I > translate that to an ack / R-b for it then? Yes. Sorry for the confusion. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 100433: all pass - PUSHED
flight 100433 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100433/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 82df618711c596d3b6164e790572c795b7ea4dcc baseline version: ovmf 753cf34e29c52bb45d25eb0580e04145f19cd83d Last test of basis 100427 2016-08-12 04:44:41 Z0 days Testing same since 100433 2016-08-12 07:46:05 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi 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 : + branch=ovmf + revision=82df618711c596d3b6164e790572c795b7ea4dcc + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 82df618711c596d3b6164e790572c795b7ea4dcc + branch=ovmf + revision=82df618711c596d3b6164e790572c795b7ea4dcc + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.7-testing + '[' x82df618711c596d3b6164e790572c795b7ea4dcc = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']' +++ echo 'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]' ++ :
Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case
Hello Tamas, On 10/08/2016 17:00, Tamas K Lengyel wrote: diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index ef614be..97948fd 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [ ("policy", libxl_rdm_reserve_policy), ]) +# Consistent with the values defined for HVM_PARAM_ALTP2M +libxl_altp2m_mode = Enumeration("altp2m_mode", [ +(0, "disabled"), +(1, "mixed"), +(2, "external_only"), +], init_val = "LIBXL_ALTP2M_MODE_DISABLED") + libxl_domain_build_info = Struct("domain_build_info",[ ("max_vcpus", integer), ("avail_vcpus", libxl_bitmap), @@ -512,7 +519,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("mmio_hole_memkb", MemKB), ("timer_mode", libxl_timer_mode), ("nested_hvm", libxl_defbool), - ("altp2m", libxl_defbool), + ("altp2m", libxl_altp2m_mode), Should we move altp2m directly outside of the structure "hvm" to avoid yet another change when altp2m will be supported on ARM? (see [1]) Regards, [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00147.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] 答复: xen does not support the 8G large bar
>>> On 12.08.16 at 05:18, wrote: > Hi Jan, > Thanks for your reply. > Qemu-xen seems that has problem for support 8G large Bar. > I think this patch is not perfect: > https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commitdiff;h=aabc8530c7ba2b > e89e21463f051056ad7c255e6e > Because I found upper 32bit bar of 8G large bar was not register. > xen_pt_config_init.c:456 xen_pt_bar_reg_write > > case XEN_PT_BAR_FLAG_UPPER: > bar_emu_mask = XEN_PT_BAR_ALLF; > bar_ro_mask = r_size ? r_size - 1 : 0; > break; > r_size is always 0. So, bar_sz_upper is always 0x, regardless of > whether 64 bit BAR size is larger than 4G. Depending on how qemu sets things up, the issue may simply be on of wrong types being used: r->size is of type pcibus_t (which I sincerely hope is a 64-bit type), yet r_size is uint32_t. But then again r->size being pcibus_t suggests that d->io_regions[] fields for the upper halves of 64-bit BARs may not get populated at all (in which case a possible fix would likely be more involved). I'm not a qemu expert, so I can't easily tell. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses
>>> On 12.08.16 at 12:34, wrote: > On 11/08/16 19:10, Andrew Cooper wrote: >> On 09/08/16 11:40, Jan Beulich wrote: >>> --- a/xen/arch/x86/cpu/mtrr/main.c >>> +++ b/xen/arch/x86/cpu/mtrr/main.c >>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >>> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) { >>> printk(KERN_WARNING >>>"mtrr: your processor doesn't support >>> write-combining\n"); >>> - return -ENOSYS; >>> + return -EOPNOTSUPP; >> >> Will this break the classic-xen MTRR code? ISTR it was very picky, from >> the cpuid work. Also, as some further cleanup, that printk should >> become a print-once. >> >> The others look ok. > > That does bring up a good general point though -- the return value is > part of the ABI. Are you reasonably confident that none of the callers > will be confused when this return value changes? If so, a note in the > commit message justifying this confidence would be helpful I think. I don't think specific return values can be considered part of the ABI, or else we couldn't e.g. change the order in which certain checks get performed. And then please also consider a hypothetical future hypervisor with the MTRR operations simply ripped out - that would return -ENOSYS or -EOPNOTSUPP then too, without a way for the caller to tell that more generic error condition from the more specific one here. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses
>>> On 11.08.16 at 20:10, wrote: > On 09/08/16 11:40, Jan Beulich wrote: >> --- a/xen/arch/x86/cpu/mtrr/main.c >> +++ b/xen/arch/x86/cpu/mtrr/main.c >> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) { >> printk(KERN_WARNING >> "mtrr: your processor doesn't support >> write-combining\n"); >> -return -ENOSYS; >> +return -EOPNOTSUPP; > > Will this break the classic-xen MTRR code? ISTR it was very picky, from > the cpuid work. There are no -ENOSYS checks in there afaics, and I also can't otherwise see any way for this change to break it. > Also, as some further cleanup, that printk should > become a print-once. Well, for a message that presumably would never actually get issued (as I'm unaware of 64-bit capable CPUs not supporting WC) I don't think this sort of cleanup has a really high priority. Certainly not in this patch. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/7] x86emul: don't special case fetching unsigned 8-bit immediates
>>> On 11.08.16 at 19:38, wrote: > On 11/08/16 17:44, Jan Beulich wrote: > On 11.08.16 at 18:32, wrote: >>> On 11/08/16 13:06, Jan Beulich wrote: @@ -2893,7 +2894,6 @@ x86_emulate( goto swint; case 0xcd: /* int imm8 */ -src.val = insn_fetch_type(uint8_t); swint_type = x86_swint_int; swint: rc = inject_swint(swint_type, src.val, >>> I would be tempted to and an explicit (uint8_t) here, so that injection >>> doesn't break if the prototype of inject_swint() changes. >> I guess I'll leave it that way, for two reasons: >> - One shouldn't change prototypes without checking whether callers >> cope. > > Indeed, but that doesn't alter the fact that you, I, and others we have > reviewed code from have managed to do precisely this, and break things. Well, okay, will do that then. >> - Here you basically suggest the opposite of what you wish done to >> the earlier patch for the jmp_rel() invocations. > > jmp_rel() is a macro not a function, but in hindsight, I rescind that > request. As that was the only change request to that other patch, may I translate that to an ack / R-b for it then? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL
The undefined behaviour sanitiser shows that it really is NULL via the pre_initcall path. (XEN) (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66 (XEN) member access within null pointer of type 'struct processor_pminfo' (XEN) [ Xen-4.8-unstable x86_64 debug=y Not tainted ] (XEN)[] cpufreq_add_cpu+0x161/0xdc0 (XEN)[] cpufreq.c#cpu_callback+0x20/0x30 (XEN)[] cpufreq.c#cpufreq_presmp_init+0x2d/0x50 (XEN)[] do_presmp_initcalls+0x22/0x30 (XEN)[] __start_xen+0x378d/0x42f0 (XEN)[] __high_start+0x53/0x60 Fix two other occurances of the same buggy logic. The processor_pminfo[] objects are only allocated as a result of XENPF_set_processor_pminfo hypercalls, which means that this early cpu callback will always hit the early NULL check, and is therefore pointless. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/drivers/cpufreq/cpufreq.c | 28 +--- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c index f19b403..fd82ef5 100644 --- a/xen/drivers/cpufreq/cpufreq.c +++ b/xen/drivers/cpufreq/cpufreq.c @@ -126,7 +126,7 @@ int __init cpufreq_register_governor(struct cpufreq_governor *governor) int cpufreq_limit_change(unsigned int cpu) { -struct processor_performance *perf = &processor_pminfo[cpu]->perf; +struct processor_performance *perf; struct cpufreq_policy *data; struct cpufreq_policy policy; @@ -134,6 +134,8 @@ int cpufreq_limit_change(unsigned int cpu) !processor_pminfo[cpu]) return -ENODEV; +perf = &processor_pminfo[cpu]->perf; + if (perf->platform_limit >= perf->state_count) return -EINVAL; @@ -155,12 +157,15 @@ int cpufreq_add_cpu(unsigned int cpu) struct cpufreq_dom *cpufreq_dom = NULL; struct cpufreq_policy new_policy; struct cpufreq_policy *policy; -struct processor_performance *perf = &processor_pminfo[cpu]->perf; +struct processor_performance *perf; /* to protect the case when Px was not controlled by xen */ -if (!processor_pminfo[cpu] || -!(perf->init & XEN_PX_INIT) || -!cpu_online(cpu)) +if ( !processor_pminfo[cpu] || !cpu_online(cpu) ) +return -EINVAL; + +perf = &processor_pminfo[cpu]->perf; + +if ( !(perf->init & XEN_PX_INIT) ) return -EINVAL; if (!cpufreq_driver) @@ -310,12 +315,15 @@ int cpufreq_del_cpu(unsigned int cpu) struct list_head *pos; struct cpufreq_dom *cpufreq_dom = NULL; struct cpufreq_policy *policy; -struct processor_performance *perf = &processor_pminfo[cpu]->perf; +struct processor_performance *perf; /* to protect the case when Px was not controlled by xen */ -if (!processor_pminfo[cpu] || -!(perf->init & XEN_PX_INIT) || -!cpu_online(cpu)) +if ( !processor_pminfo[cpu] || !cpu_online(cpu) ) +return -EINVAL; + +perf = &processor_pminfo[cpu]->perf; + +if ( !(perf->init & XEN_PX_INIT) ) return -EINVAL; if (!per_cpu(cpufreq_cpu_policy, cpu)) @@ -637,8 +645,6 @@ static struct notifier_block cpu_nfb = { static int __init cpufreq_presmp_init(void) { -void *cpu = (void *)(long)smp_processor_id(); -cpu_callback(&cpu_nfb, CPU_ONLINE, cpu); register_cpu_notifier(&cpu_nfb); return 0; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/boot: Align e820 and video data in the boot trampoline
The undefined behaviour sanitiser in Clang 3.8 identifies that these are all misaigned when used in __start_xen(). Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/boot/mem.S | 1 + xen/arch/x86/boot/video.S | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/arch/x86/boot/mem.S b/xen/arch/x86/boot/mem.S index 820aea9..602ab2c 100644 --- a/xen/arch/x86/boot/mem.S +++ b/xen/arch/x86/boot/mem.S @@ -67,6 +67,7 @@ get_memory_map: ret +.align 4 GLOBAL(e820map) .fill E820MAX*20,1,0 GLOBAL(e820nr) diff --git a/xen/arch/x86/boot/video.S b/xen/arch/x86/boot/video.S index b238bf3..2aafbeb 100644 --- a/xen/arch/x86/boot/video.S +++ b/xen/arch/x86/boot/video.S @@ -994,6 +994,7 @@ force_size: .word 0 # Use this size instead of the one in BIOS vars vesa_size: .word 0,0,0 # width x depth x height /* If we don't run at all, assume basic video mode 3 at 80x25. */ +.align 2 GLOBAL(boot_vid_mode) .word VIDEO_80x25 GLOBAL(boot_vid_info) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses
On 11/08/16 19:10, Andrew Cooper wrote: > On 09/08/16 11:40, Jan Beulich wrote: >> --- a/xen/arch/x86/cpu/mtrr/main.c >> +++ b/xen/arch/x86/cpu/mtrr/main.c >> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) { >> printk(KERN_WARNING >> "mtrr: your processor doesn't support >> write-combining\n"); >> -return -ENOSYS; >> +return -EOPNOTSUPP; > > Will this break the classic-xen MTRR code? ISTR it was very picky, from > the cpuid work. Also, as some further cleanup, that printk should > become a print-once. > > The others look ok. That does bring up a good general point though -- the return value is part of the ABI. Are you reasonably confident that none of the callers will be confused when this return value changes? If so, a note in the commit message justifying this confidence would be helpful I think. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only
On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote: > >>> On 11.08.16 at 11:17, wrote: > > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long > > mbi_p) > > if ( !opt_smep ) > > setup_clear_cpu_cap(X86_FEATURE_SMEP); > > if ( cpu_has_smep ) > > +{ > > set_in_cr4(X86_CR4_SMEP); > > +if ( smep_hvm_only ) > > +write_cr4(read_cr4() & ~X86_CR4_SMEP); > > +} > > So that'll clear CR4.SMEP right here, but won't help with CR4 loads > from mmu_cr4_features (as e.g. happens indirectly during VM exits, > since the HOST_CR4 field gets set from this variable). > > Did you in fact test your change, including validation of the features > correctly remaining off over the lifetime of the system? > > Further, considering that you don't clear the two flags from Xen's > internal feature bitmap, and taken together with the internal feature > bitmap driving alternative instruction patching, I'd assume pointless > (and performance wise perhaps harmful) patching to now take place. > Let me see whether I understand this correctly... Regarding alternative instruction patching, if enabling SMAP for HVM but disabling it for Xen, SMAP bit must be set in x86_capability feature bitmap and cleared in mmu_cr4_features, which means instruction patching would take place and a #UD may occur (since SMAP is disable in Xen, but STAC/CLAC are patched and called). A little dirty solution I can think of now is to temperarily clear SMAP bit in x86_capability before patching instruction and then set it back when instruction patching finish, like: ``` if ( opt_smap == SMAP_HVM_ONLY ) setup_clear_cpu_cap(X86_FEATURE_SMAP); alternative_instructions(); if ( opt_smap == SMAP_HVM_ONLY ) __set_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability); ``` Appreciate it if you have a better solution. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output
Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"): > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote: > > We don't care when xenconsoled closes the logfile. We care about when > > it last calls write() (with a nonempty buffer). > > In logfile mode, no console client is spawned, because it is not > reliable -- that's why we use logfile mode in the first place. > > And I would rather just add a bodge (wait 1 or 2 seconds) That would increase the duration of each test by that 1 or 2 seconds. I suppose you could conclude the logfile is complete if it contains the expected end-of-run message from the vm, and only poll if not. But, it's worse: I went to read the xenconsoled source code, and it can handle a domain death event before finishing reading all of the data out of a domain's ring. Maybe this will be mitigated by XTF's printf waiting for the xenconsoled ring pointer to catch up ? xenconsoled advances the ring pointer before writing to the logfile, but (assuming there's no overflow), the write will happen before it goes back into the event loop, so it won't be lost. > than to rely on sophisticated hack. To my mind polling the logfile looking for the final message from the vm is something of a hack. But indeed I can't see another way to wait for xenconsoled, than going behind libxl's back with something like * spawn xl create -p -F * look for the console tty in xenstore * open the console tty * unpause * wait for the console tty to get eof This is not a logfile mode at all, of course. It probably wouldn't be easily adaptable to other toolstacks (eg XenServer). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: credit1: fix a race when picking initial pCPU for a vCPU
On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote: > On 12/08/16 05:07, Dario Faggioli wrote: > > > > Reported-by: Andrew Cooper > > Signed-off-by: Dario Faggioli > It might be nice if we could add an ASSERT() that the appropriate > runqueue was locked, to make sure we don't get caught out again like > this in the future, but I think that would probably require turning > it > into a static inline (which probably wouldn't be so bad anyway). > Mmm... good point. > But in any case: > > Acked-by: George Dunlap > > Let me know if you want me to check this in as-is or if you think you > might send a follow-up patch adding an ASSERT. > Yes, I'll send a new patch. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
On 09/08/16 12:30, Jan Beulich wrote: On 09.08.16 at 12:48, wrote: >> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >> depriv)"): >>> Actually, having thought about this some more, and taking this >>> together with the expectations to the privcmd driver previously >>> outlined, I think this part is problematic: If all the driver is to know >>> is the position (within the interface structure) of the target domain >>> ID, then any guest handles embedded in the interface structure >>> (XEN_HVMCTL_track_dirty_vram only for now) couldn't get >>> validated, and hence user mode code would have a way to access >>> or modify kernel memory. >> >> Could the hypervisor know the difference between user and kernel >> memory, in principle ? > > Not without further new hypercalls, as the guest kernel would need > to tell Xen what address ranges are kernel vs user (and that implies > that any OS wishing to be able to act as Dom0 has a uniform > separation of address spaces). Couldn't Xen tell from the guest pagetables whether the memory being accessed was user-mode or kernel mode? >> Alternatively, would it be possible for the ABI to specify somehow >> what parameters are guest handles, so that the privcmd driver could >> check them ? > > We could presumably invent something, but I'm afraid it would end > up quite ugly. > >> (Would it be sufficient to check the starts, or would >> the ends need to be checked too?) > > Both would need to be checked, so the size field(s) would need to > be locatable too. We could have the "fixed" part of the structure contain domid and an array of which the privcmd driver could check. I don't think that would be terrible. Alternately, the "fixed" part of the hypercall could contain a range, which if non-zero, Xen should use to check any pointer contained in the struct -- that would be more flexible probably. Or we could do as Jan hints at above -- have some way to have dom0 communicate the kernel address range to Xen (either via hypercall, or maybe via the shared info page) so that Xen just knows the address layout for any individual domain. And unless we're positive the guest kernel will never need these hypercalls, we probably need a flag that allows kernel-mode pointers. It's worth pointing out that the problem Xen has distinguishing user/kernel mode pointers is the same even if we use the alternate suggestion of per-process XSM labels. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file
COPYING file: The motivation of this change is to make it easier for new contributors to conduct a license and patent review, WITHOUT changing any licenses. - Remove references to BSD-style licenses as we have more common license exceptions and replace with "other license stanzas" - List the most common situations under which code is licensed under licenses other than GPLv2 (section "Licensing Exceptions") - List the most common non-GPLv2 licenses that are in use in this repository based on a recent FOSSology scan (section "Licensing Exceptions") - List other license related conventions within the project to make it easier to conduct a license review. - Clarify the incoming license as its omission has confused past contributors (section "Contributions") CONTRIBUTION file: The motivation of this file is to make it easier for contributors to find contribution related resources. Add information on existing license related conventions to avoid unintentional future licensing issues. Provide templates for copyright headers for the most commonly used licenses in this repository. Signed-off-by: Lars Kurth --- Changed since v1: * Fixed typos * Used GPL / LGPL license header spelling out version instead of v --- CONTRIBUTING | 210 +++ COPYING | 64 ++ 2 files changed, 260 insertions(+), 14 deletions(-) create mode 100644 CONTRIBUTING diff --git a/CONTRIBUTING b/CONTRIBUTING new file mode 100644 index 000..67ecdb7 --- /dev/null +++ b/CONTRIBUTING @@ -0,0 +1,210 @@ + +CONTRIBUTING + + +INBOUND LICENSE +--- + +Contributions are governed by the license that applies to relevant +specific file or by the license specified in the COPYING file, that +governs the license of its containing directory and its subdirectories. + +Most of the Xen Project code is licensed under GPLv2, but a number of +directories are primarily licensed under different licenses. + +Most notably: + - tools/blktap2 : BSD-Modified + - tools/libxc: LGPL v2.1 + - tools/libxl: LGPL v2.1 + - xen/include/public : MIT license + +When creating new components and directories that contain a +significant amount of files that are licensed under licenses other +than GPLv2 or the license specified in the COPYING file, please +create a new COPYING file in that directory containing a copy of the +license text and a rationale for using a different license. This helps +ensure that the license of this new component/directory is maintained +consistently with the original intention. + +When importing code from other upstream projects into this repository, +please create a README.source file in the directory the code is imported +to, listing the original source of the code. An example can be found at +m4/README.source + +The COMMON COPYRIGHT NOTICES section of this document contains +sample copyright notices for the most common licenses used within +this repository. + +Developer's Certificate of Origin +- + +All patches to the Xen Project code base must include the line +"Signed-off-by: your_name " at the end of the change +description. This is required and indicates that you certify the patch +under the "Developer's Certificate of Origin" which states: + + Developer's Certificate of Origin 1.1 + + By making a contribution to this project, I certify that: + + (a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + + (b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + + (c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + + (d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. + +GOVERNANCE AND WORKFLOW +--- + +The following documents provide a general overview of governance and +contribution guidelines for the Xen Project: + - https://xenproject.org/governance.html + - https://xenproject.org/help/contribution-guidelines.html + +For more information on contributing to this repository, see + - CODING_STYLE file in this directory + - https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches + -