[Xen-devel] [libvirt test] 95419: regressions - FAIL
flight 95419 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/95419/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 95358 Tests which did not succeed, but are not blocking: 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-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 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-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 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass version targeted for testing: libvirt 4fce3671880ea020fddb1e62975b4a638851618d baseline version: libvirt 1b5f1884a29cbd6d1db0d1e6b781c2b770e32a0c Last test of basis95358 2016-06-07 04:24:54 Z2 days Testing same since95419 2016-06-08 04:23:27 Z1 days1 attempts People who touched revisions under test: Daniel P. Berrange John Ferlan Jovanka Gulicoska Ján Tomko Martin Kletzander Peter Krempa Philipp Hahn 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 618 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 95406: regressions - FAIL
flight 95406 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/95406/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 94728 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 94728 Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-buildfail like 94728 build-amd64-rumpuserxen 6 xen-buildfail like 94728 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94728 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 94728 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 94728 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-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-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-amd64-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-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-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 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 version targeted for testing: linuxb5076139991c6b12c62346d9880eec1d4227d99f baseline version: linux3b6aa07b936b09d38c1bfcee1e06845b968df475 Last test of basis94728 2016-05-23 21:45:21 Z 16 days Testing same since95406 2016-06-08 00:46:40 Z1 days1 attempts People who touched revisions under test: "Kirill A. Shutemov" Adrian Hunter Alan Stern Andreas Noever Andreas Werner Andrew Jeffery Andrew Morton Arnd Bergmann Artem Bityutskiy Axel Lin Bjorn Helgaas Brian Norris Catalin Marinas Catalin Vasile Chen Yu Chris Bainbridge Christoffer Dall Damien Wyart Daniel Lezcano Daniel Vetter Dave Chinner Dave Chinner Dave Gerlach David Sterba David Vrabel Dmitry Torokhov Eric Sandeen Ezequiel Garcia Felipe Balbi Felipe Balbi Fengwei Yin Gavin Shan Geert Uytterhoeven Greg Kroah-Hartman Grygorii Strashko H. Nikolaus Schaller Hans-Christoph Schemmel Hari Bathini Herbert Xu Ingo Molnar Itai Handler J. Bruce Fields James Hogan Jan Kara Jani Nikula Jeff Layton Jiang Liu Jiri Slaby Johan Hovold Johannes Thumshirn Joseph Salisbury Kalle Valo Kalle Valo Kirill A. Shutemov Konstantin Shkolnyy Krzysztof Kozl
Re: [Xen-devel] HEADS UP: Imported Xen 4.7: no blkback
On Fri, 3 Jun 2016, Roger Pau Monné wrote: > One of the more relevant changes in 4.7 regarding FreeBSD is the support for > block hotplug scripts. This means that we now have the option to use > backends different than simple block or regular files, provided that someone > writes the proper hotplug scripts to attach them (I've heard there are some > iSCSI hotplug scripts around). This however requires changes in blkback, so > if you plan to use the Xen 4.7 port, please make sure that you are running a > kernel that contains revision r301269 (or any later version). The same also I am running it with r301685 and the HVM guests have some trouble with block devices. SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD from, after chaging to "hda" I get up to the kernel mountroot prompt (Xen block devices seem to be detected in dmesg). What used to be Windows 2016 domU with /dev/zvol/zroot/windows0,raw,hda,w ends up in the Tianocore UEFI shell. Block devices seem to be available, I can even list the fs0: partition, but no booting further possible. Marcin # more freebsd.cfg builder = "hvm" name = "FreeBSD" disk = [ '/dev/zvol/zroot/freebsd1,raw,xvda,w', '/dev/zvol/zroot/freebsd2,raw,xvdb,w' ] boot = "c" #usbdevice = 'tablet' #nographics = 1 serial = [ "file:/tmp/boot.log" ] vnc = 1 #vnclisten = '0.0.0.0' vif = ['bridge=bridge0,mac=00:02:04:08:fd:f0'] memory=2048 vcpus=1 vga = "cirrus" videoram = 16 # more windows-run.cfg builder = "hvm" memory = 4096 vcpus = 2 name = "Windows2016" disk = [ '/dev/zvol/zroot/windows0,raw,hda,w', '/dev/zvol/zroot/vs2013,raw,hdb,w', #'/root/win/install.iso,raw,hdc:cdrom,r' ] boot = "c" # Boot to hard disk image vnc = 2 #vnclisten = "0.0.0.0" usbdevice = 'tablet' on_poweroff = 'destroy' on_reboot = 'restart' #on_crash = 'restart' on_crash = 'destroy' acpi = 1 bios = 'ovmf' vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ] videoram=16 vga = "stdvga" ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce libxl__qmp_query_cpus
On Wed, 2016-06-08 at 15:28 +0100, Wei Liu wrote: > It interrogates QEMU for CPUs and update the bitmap accordingly. > > Signed-off-by: Wei Liu > Reviewed-by: Dario Faggioli 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 http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] libxl: update vcpus bitmap in retrieved guest config
On Wed, 2016-06-08 at 15:28 +0100, Wei Liu wrote: > ... because the available vcpu bitmap can change during domain life > time > due to cpu hotplug and unplug. > > For QEMU upstream, we interrogate QEMU for the number of vcpus. For > others, we look directly into xenstore for information. > > Reported-by: Jan Beulich > Signed-off-by: Wei Liu > Reviewed-by: Dario Faggioli 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 http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm/domain: allocate pages according to the order of struct domain size
On 06/08/16 04:26, Julien Grall wrote:
> Hello Jiandi,
>
> On 08/06/2016 07:54, Jiandi An wrote:
>> As the number of CPUs supported on the system grows, number of
>> GIC redistributors and mmio handlers increase. We need to increase
>> MAX_RDIST_COUNT and MAX_IO_HANDLER which makes size of struct domain
>> bigger than one page.
>
> With this change, the memory footprint of a domain will increase by 4KB even
> if they don't use GICv3.
>
> What is the size of the domain structure with your patch?
>
> I would much prefer to allocate separate memory for the vGIC redistributors
> if it takes too much space.
>
Hi Julien, the intent of this patch is in preparation for introducing the patch
to support
redistributor parsing from GICC subtable, which is tied to number of CPUs on
the system.
Current MAX_RDIST_COUNT and MAX_IO_HANDLER are not enough and it drives the
domain struct size bigger.
I do see the better way is to leave the domain struct alone and allocate memory
for vGIC redistributors
separately and dynamically based on number of CPU interfaces from GICC subtable.
Thanks for your sugguestion. We'll bundle the dynanmic memory allocation for
redistributors
and io handlers in the patch that's coming in for supporting redistributor
parsing from GICC subtable.
>>
>> Remove the BUILD_BUG_ON check for if size of struct domain is greater
>> than PAGE_SIZE. And allocate xenheap pages according to the order of
>> the size of struct domain.
>>
>> Signed-off-by: Jiandi An
>> ---
>> xen/arch/arm/domain.c | 5 +++--
>> xen/include/asm-arm/gic.h | 2 +-
>> xen/include/asm-arm/mmio.h | 2 +-
>> 3 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 1365b4a..7f69236 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -438,8 +438,9 @@ void startup_cpu_idle_loop(void)
>> struct domain *alloc_domain_struct(void)
>> {
>> struct domain *d;
>> -BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>> -d = alloc_xenheap_pages(0, 0);
>> +unsigned int order = get_order_from_bytes(sizeof(*d));
>> +
>> +d = alloc_xenheap_pages(order, 0);
>> if ( d == NULL )
>> return NULL;
>>
>> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
>> index cd97bb2..8165de6 100644
>> --- a/xen/include/asm-arm/gic.h
>> +++ b/xen/include/asm-arm/gic.h
>> @@ -20,7 +20,7 @@
>>
>> #define NR_GIC_LOCAL_IRQS NR_LOCAL_IRQS
>> #define NR_GIC_SGI 16
>> -#define MAX_RDIST_COUNT4
>> +#define MAX_RDIST_COUNT64
>
> How many re-distributor regions does your platform have?
It's more than the current cap of 4.
>
>>
>> #define GICD_CTLR (0x000)
>> #define GICD_TYPER (0x004)
>> diff --git a/xen/include/asm-arm/mmio.h b/xen/include/asm-arm/mmio.h
>> index da1cc2e..798d373 100644
>> --- a/xen/include/asm-arm/mmio.h
>> +++ b/xen/include/asm-arm/mmio.h
>> @@ -23,7 +23,7 @@
>> #include
>> #include
>>
>> -#define MAX_IO_HANDLER 16
>> +#define MAX_IO_HANDLER 32
>
> The vGICv3 driver is allocating one I/O handler per redistributor region. So
> if you bump MAX_RDIST_COUNT to 64, you at least need to bump MAX_IO_HANDLER
> to 80.
>
> However, I am bit concerned of the performance impact in long-term because
> the lookup is linear.
Agreed that this also needs to be figured out and allocated dynamically.
>
> Regards,
>
--
Jiandi An
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 95408: regressions - FAIL
flight 95408 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/95408/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 94729 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 94729 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 94729 build-i386-rumpuserxen6 xen-buildfail like 94729 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 94729 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail like 94729 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 94729 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94729 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 94729 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94729 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 94729 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 94729 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 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass 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 test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 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-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass version targeted for testing: linux888172862fa78505c4e4674c205a06586443d83f baseline version: linuxe429f243df2823451c92227317e5fce5f310b674 Last test of basis94729 2016-05-23 21:47:14 Z 16 days Testing same since95408 2016-06-08 00:46:24 Z0 days1 attempts People who touched revisions under test: Adrian Hunter Akshay Bhat Alan Stern Alexander Shishkin Andreas Noever Andreas Werner Andrew Jeffery Andrew Morton Andy Shevchenko Anilkumar Kolli Arnd Bergmann Aurelien Jarno Axel Lin Bjorn Helgaas Brian Bloniarz Catalin Marinas Catalin Vasile Chen Yu Chris Bainbridge Christoffer Dall Damien Wyart Daniel Lezcano Daniel Vetter Darrick J. Wong Dave Chinner Dave Chinner Dave Gerlach David Henningsson David Müller David Sterba David Vrabel Dmitry Torokhov Eric Sandeen Ezequiel Garcia Felipe Balbi Felipe Balbi Gavin Shan Geert Uytterhoeven Greg Kroah-Hartman Grygorii Strashko Guenter Roeck Guilherme G. Piccoli H Hartley Sweeten H. Nikolaus Schaller Hans Verkuil Hans-C
[Xen-devel] Question about device tree block
Hi i have a question about device tree block area In the function setup_mm xen copy original device tree block to the end of xen heap space Original device tree block area seems useless during domain0 creation but xen discard it with kernel modules after dom0 memory allocation finished Is there any special reason?? +) what is the job of kernel module? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] HEADS UP: Imported Xen 4.7 and blkback changes - domU respawning on_crash
On Wed, 8 Jun 2016, Marcin Cieslak wrote: > On Fri, 3 Jun 2016, Roger Pau Monné wrote: > > > Hello, > > > > First of all, this message is only relevant to those that use FreeBSD as > > Dom0 (host), not as a DomU (guest), so don't panic. > > > > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's > > still not the final version, but it's quite close, so we better start > > testing it to make sure it works fine with FreeBSD. One issue maybe unrelated to FreeBSD: This domain: builder = "hvm" memory = 4096 vcpus = 2 name = "Windows2016" disk = [ '/dev/zvol/zroot/windows0,raw,hda,w', '/dev/zvol/zroot/vs2013,raw,hdb,w', #'/root/win/install.iso,raw,hdc:cdrom,r' ] boot = "c" # Boot to hard disk image vnc = 2 #vnclisten = "0.0.0.0" usbdevice = 'tablet' on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' acpi = 1 bios = 'ovmf' vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ] videoram=16 vga = "stdvga" crashes because I didn't have ovmf image: (d203) HVM Loader (d203) Detected Xen v4.7.0-rc (d203) Xenbus rings @0xfeffc000, event channel 1 (d203) Unknown BIOS ovmf, no ROM image found (d203) *** HVMLoader bug at hvmloader.c:229 (d203) *** HVMLoader crashed. But I seem unable to kill it with "xl destroy" - it keeps respawning again: Windows2016211 4079 1 --p--- 0.0 Windows2016213 4096 1 --psc- 0.0 (disappears) Windows2016221 4096 1 --psc- 0.0 (null) 221 147 1 --psc- 0.0 ... ... I have finally managed to snatch it by issuing this a few times, after changing the "on_crash" to 'destroy': # xl config-update Windows2016 xen/windows-run.cfg WARNING: xl now has better capability to manage domain configuration, avoid using this command when possible setting dom243 configuration Marcin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] HEADS UP: Imported Xen 4.7 and blkback changes
On Fri, 3 Jun 2016, Roger Pau Monné wrote: > Hello, > > First of all, this message is only relevant to those that use FreeBSD as > Dom0 (host), not as a DomU (guest), so don't panic. > > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's > still not the final version, but it's quite close, so we better start > testing it to make sure it works fine with FreeBSD. Thank you Roger, this is excellent. Are xen-tools-devel 4.5 now? Looks confusing. I have also tried building xen-tools (4.7) without python and qemu configure reported this. Also got this: ===> Registering installation for xen-tools-4.7.0 (xen-tools-4.7.0) /usr/ports/sysutils/xen-tools/work/stage//usr/local/lib/python2.7/site-packages/xen/lowlevel/xc.so - required shared library libxenctrl.so.4.5 not found (xen-tools-4.7.0) /usr/ports/sysutils/xen-tools/work/stage//usr/local/lib/python2.7/site-packages/xen/lowlevel/xc.so - required shared library libxenguest.so.4.5 not found (xen-tools-4.7.0) /usr/ports/sysutils/xen-tools/work/stage//usr/local/lib/xen/bin/qemu-system-i386 - required shared library libxenctrl.so.4.5 not found (xen-tools-4.7.0) /usr/ports/sysutils/xen-tools/work/stage//usr/local/lib/xen/bin/qemu-system-i386 - required shared library libxenguest.so.4.5 not found Installing xen-tools-4.7.0... Adding Python manually and rebuilding seems to fix those issues. It seems to work, I only wish we've had ports from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192012 committed... Marcin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
On 06/07/2016 11:41 AM, Jan Beulich wrote:
On 07.06.16 at 17:17, wrote:
>> On 06/07/2016 10:12 AM, Jan Beulich wrote:
>> On 07.06.16 at 16:02, wrote:
On 06/07/2016 02:06 AM, Jan Beulich wrote:
On 06.06.16 at 19:31, wrote:
>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>> On 06.04.16 at 03:25, wrote:
With this flags set guests will not try to set up SCI.
>>> I've just read through the respective ACPI spec section again, and
>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>> ACPI"). Can you clarify this connection please. Also there are other
>>> consequences of setting that flag, so in order to understand the
>>> reasons behind this change in case of future problems I think the
>>> description here will need to be significantly extended, despite the
>>> change being so small.
>> My understanding is that hardware-reduced platforms don't use ACPI
>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>> model is disabled (no SCIs are generated) ..."
> In the sum of all the non-explicit wording I can only convince myself
> that SCI is a prereq for the event model. Yet I could see this being
> an if-and-only-if, just that I couldn't find any place saying so.
Not sure how I should interpret this: do you (reluctantly, possibly)
agree that we can use HW-reduced flag to indicate that SCI is not there?
>>> I really think we need to get confirmation on this from ACPI folks.
>> Who should those people be? linux-acpi?
> That may yield valuable, but not dependable input. I'd rather think of
> folks actually working on / contributing to the spec. I'm sure Intel can
> name a few of their employees ...
>
>>> And I think (and I said so before) we need to understand all the
>>> other implications from setting that flag (i.e. we _cannot_ use this
>>> flag _just_ to indicate there's no SCI).
>> FWIW, the Microsoft's reading is
>> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-req
>>
>> uirements-for-soc-based-platforms
>>
>> ACPI fixed hardware features such as the following are not required:
>> Power Management (PM) timer
>> Real Time Clock (RTC) wake alarm
>> System Control Interrupt (SCI)
>> Fixed Hardware register set (PMx_* event/control/status registers)
>> GPE block registers (GPEx_* event/control/status registers)
>> Embedded controller
>>
>> Also, from ACPICA perpective, HW-reduced mode appears to be the only way
>> to prevent initialization of SCI.
> Well, we could of course start out with HW-reduced mode, but we'd
> then need to settle on all aspects before any of this becomes fully
> supported.
So it looks like we can avoid needing this mode in Linux by simply
allocating an irq descriptor for the SCI. We shouldn't receive anything
on that interrupt in PVH anyway.
I don't know whether this will work for other OSs (i.e. FreeBSD).
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.14 test] 95407: regressions - FAIL
flight 95407 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/95407/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 95164 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 95164 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 95164 Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-buildfail like 95164 build-amd64-rumpuserxen 6 xen-buildfail like 95164 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 95164 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95164 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95164 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95164 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-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: linux022aafd04696a3c6b7ad47ab83a9650646287bf8 baseline version: linuxf06cb456a442c7df95a4ba6e2f3a341cf925d7cf Last test of basis95164 2016-06-01 19:46:34 Z7 days Testing same since95407 2016-06-08 00:46:14 Z0 days1 attempts People who touched revisions under test: Andrew Morton Ben Hutchings Bjorn Helgaas Daniel Lezcano Daniel Vetter Dave Chinner Dave Chinner Dave Gerlach David Vrabel Dmitry Torokhov Greg Kroah-Hartman Hari Bathini Itai Handler J. Bruce Fields James Hogan Jeff Layton Joseph Salisbury Kalle Valo Kalle Valo Larry Finger Linus Torvalds Lyude Mahesh Salgaonkar Martin K. Petersen Matthias Schiffer Michael Ellerman Nicolai Stange Patrik Jakobsson Paul Burton Prarit Bhargava Rafael J. Wysocki Raghava Aditya Renukunta Ralf Baechle Ricky Liang Ross Lagerwall Shyam Kaushik Theodore Ts'o Tomáš Trnka Ville Syrjälä Wang YanQing 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
Re: [Xen-devel] BUG: NOW() seems to (sometimes) go backwards!
On 06/08/2016 02:43 PM, Dario Faggioli wrote:
> On Wed, 2016-06-08 at 04:42 -0600, Jan Beulich wrote:
> On 07.06.16 at 17:54, wrote:
>>> So, it looks to me that the TSC is actually ok, and it could be the
>>> local_tsc_stamp and scale_delta() magic done in get_s_time_fixed()
>>> (which, AFAICUI, is there to convert cycles to time) that does not
>>> guarantee the result to be monotonic, even if the input is...
>>> Thoughts?
>> Indeed this smells like an issue in the scaling. However, the scaling
>> values vary only when !CONSTANT_TSC. Can you check that this
>> flag is actually set on that system?
>>
> Checked. I do have it. I instrumented the code to print stuff if it
> finds it, and it prints.
>
> Also:
> root@Zhaman:~# xl debug-keys s
> (XEN) [ 406.719464] TSC marked as reliable, warp = 0 (count=3)
> (XEN) [ 406.719467] dom1(hvm):
> mode=0,ofs=0xd9279716c276,khz=2394069,inc=4,vtsc count: 195367 kernel, 0
> user
>
>> (I hope you're not running a
>> strange Dom0 setup with FREQCTL_dom0_kernel in effect.)
>>
> I've no idea what this is. I've been running 4.1.0, built myself, and
> stock Debian unstable 4.5.0, and I'm seeing the issue in both cases.
>
> Looking FREQCTL_dom0_kernel up, I guess you mean what happens when one
> passes cpufreq="dom0-kernel" to xen on boot command line. In which
> case, no, I'm not doing that.
>
>> And
>> at the same time that it's time_calibration_tsc_rendezvous() that
>> is in use?
>>
> The code you're referring to should be this:
>
> /* If we have constant-rate TSCs then scale factor can be shared. */
> if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
> {
> /* If TSCs are not marked as 'reliable', re-sync during rendezvous. */
> if ( !boot_cpu_has(X86_FEATURE_TSC_RELIABLE) )
> time_calibration_rendezvous_fn = time_calibration_tsc_rendezvous;
> }
>
> And I have both X86_FEATURE_CONSTANT_TSC and X86_FEATURE_TSC_RELIABLE.
>
> I've again instrumented the code in order to check whether it is
> time_calibration_tsc_rendezvous() or time_calibration_std_rendezvous()
> that is being used, and it's the latter:
>
> (XEN) [1.795916] TSC reliable. Yay!! Using 82d080198362 for
> rendevousez
>
> [dario@Solace xen.git] $ objdump -D xen/xen-syms |grep 82d080198362
> 82d080198362 :
>
> which looks correct to me.
Probably one other codepath that you would be interested is on
local_time_calibration() commenting the chunk on this conditional:
if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC )
{
...
}
And with that you rarely see time going backwards since the scaling would be
adjusted to each cpu calibration error - but it would be a (very very close)
approximation on software not exactly guaranteed as hardware TSC. But trying
this out
would be just for experimentation - doesn't look to be a correct way of
addressing this.
>
>> Yet when the scaling values get set only once at boot, monotonic
>> (cross-CPU) TSC means monotonic (cross-CPU) returns from NOW().
>>
> Yep. And at this point, this is what needs to be verified, I guess...
I think get_s_time_fixed doesn't guarantee monotonicity across CPUs being it
different socket or (SMT) siblings. local_tsc_stamp is seeded differently on
each CPU
i.e. rdtsc() right after doing the platform time read on the calibration
rendezvous.
Plus stime_local_stamp is seeded with values taken from platform timer (HPET,
ACPI,
PIT) on local_time_calibration which means that get_s_time isn't solely based
on TSC
and that there will always be a gap between stime_local_stamp and
local_tsc_stamp.
TSC is indeed monotonic on a TSC invariant box, but the delta that is computed
differs from cpu to cpu according to when time calibration happens on each CPU
- thus
not guaranteeing the desired monotonicity property. Having stime_local_stamp be
based
on the same timestamp that of the local_tsc_stamp plus having a single
local_tsc_stamp as reference would address this behaviour - see also below.
>
>> In any event - could you try to exclude C- and P-state effects? Of
>> course that makes sense only if you can reasonably repro the
>> problem situation (and hence can tell from its absence over a certain
>> period of time that whatever change was done did have some
>> positive effect).
>>
> It's actually quite hard *NOT* to reproduce the problem... it happens
> all the time, and if the load is high enough, I see the "Time went
> backwards?" printk several times per second!
>
> So, trying to do what you suggest in an online fashion, i.e., issueing:
>
> # xenpm set-max-cstate 0
> # xenpm set-scaling-governor all performance
>
> did not change the situation (I still see the printks).
>
> I've then tried passing both cpufreq="none" and max_cstate=0 to xen at
> boot, but they made no difference at all either.
>
> Most of the time, we're speaking of very small skews, e.g.:
>
> (XEN) [ 59.59] WARNING: __update_runq_load: Time went backwards? now
> 5946079 llu 5946085
> (XEN) [ 1
[Xen-devel] [xen-unstable-smoke test] 95449: tolerable all pass - PUSHED
flight 95449 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95449/
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 74a7ec196f819271dff2676a79ef916c50d88342
baseline version:
xen 62b4d4769ca39fd5263da20d786a7b9a80a22d9a
Last test of basis95443 2016-06-08 16:01:49 Z0 days
Testing same since95449 2016-06-08 18:16:35 Z0 days1 attempts
People who touched revisions under test:
Doug Goldstein
Ian Jackson
Konrad Rzeszutek Wilk
Konrad Rzeszutek Wilk
Wei Chen
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=74a7ec196f819271dff2676a79ef916c50d88342
+ . ./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
74a7ec196f819271dff2676a79ef916c50d88342
+ branch=xen-unstable-smoke
+ revision=74a7ec196f819271dff2676a79ef916c50d88342
+ . ./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
+ '[' x74a7ec196f819271dff2676a79ef916c50d88342 = 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://ca
[Xen-devel] [qemu-mainline test] 95397: regressions - FAIL
flight 95397 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/95397/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 94856 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 94856 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 94856 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. vs. 94856 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 94856 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94856 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-localmigrate fail REGR. vs. 94856 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 94856 test-amd64-amd64-xl-rtds 9 debian-install fail like 94856 Tests which did not succeed, but are not blocking: 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-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-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-libvirt-xsm 12 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-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-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-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 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-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-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-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-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 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-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 version targeted for testing: qemuu6ed5546fa7bf12c5b87ef76bafb86e1d77ed6e85 baseline version: qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe Last test of basis94856 2016-05-27 20:14:49 Z 11 days Failing since 94983 2016-05-31 09:40:12 Z8 days 14 attempts Testing same since95397 2016-06-07 20:49:10 Z0 days1 attempts People who touched revisions under test: Alberto Garcia Alex Bennée Alexander Graf Alexey Kardashevskiy Alistair Francis Anthony PERARD Ard Biesheuvel Benjamin Herrenschmidt Bharata B Rao Cao jin Changlong Xie Chen Fan Christian Borntraeger Cole Robinson Corey Minyard Cornelia Huck Cédric Le Goater David Gibson Denis V. Lunev Dmitry Fleytman Dmitry Fleytman Dmitry Osipenko Drew Jones Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Blake Fam Zheng Gerd Hoffmann Greg Kurz Gu Zheng Igor Mammedov James Clarke Jan Vesely Jason Wang Jean-Christophe Dubois Jens Wiklander Kevin Wolf Laurent Vivier Leonid Bloch Li Zhijian
Re: [Xen-devel] [PATCH v3 09/16] xen/arm: Introduce alternative runtime patching
On Wed, Jun 08, 2016 at 07:22:45PM +0100, Julien Grall wrote: > Hi Konrad, > > On 08/06/16 19:17, Konrad Rzeszutek Wilk wrote: > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S > index 1f010bd..495f9d8 100644 > --- a/xen/arch/arm/xen.lds.S > +++ b/xen/arch/arm/xen.lds.S > @@ -129,6 +129,9 @@ SECTIONS > _sinittext = .; > *(.init.text) > _einittext = .; > +#ifdef CONFIG_ALTERNATIVE > + *(.altinstr_replacement) > +#endif > >>> > >>>This is outside the _einittext? x86 looks to have .altinstr_replacement > >>>inside the _einittext. > >> > >>Yes, I looked at the x86 code when I did the implement and I did not find > >>any good reason to keep .altinstr_replace inside the inittext. > >> > >>altinstr_replacement contains replacement instructions. Anything inside the > >>inittext region will be mark executable, which is not what we want here. > > > >Right, but we don't this code after the bootup (as in we patch the > >.text and we can eject the .altinstr_replacement). > > I don't see any problem, .altinstr_replacement is within __init_begin and > __init_end. So it will be free when free_init_memory will be called. > > _sinittex and _einittext are used to know which page will be executable. Aaah, right! In that case, pls disregard my question. > > Regards, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 95410: trouble: blocked/broken
flight 95410 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95410/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3863 host-install(3) broken REGR. vs. 80927 build-amd64 3 host-install(3) broken REGR. vs. 80927 build-i386-pvops 3 host-install(3) broken REGR. vs. 80927 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pv 1 build-check(1) blocked n/a version targeted for testing: qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1 baseline version: qemuu10c1b763c26feb645627a1639e722515f3e1e876 Last test of basis80927 2016-02-06 13:30:02 Z 123 days Testing same since93977 2016-05-10 11:09:16 Z 29 days 118 attempts People who touched revisions under test: Gerd Hoffmann Stefano Stabellini jobs: build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-credit2 blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpublocked test-amd64-amd64-pairblo
Re: [Xen-devel] [PATCH v3 09/16] xen/arm: Introduce alternative runtime patching
Hi Konrad, On 08/06/16 19:17, Konrad Rzeszutek Wilk wrote: diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index 1f010bd..495f9d8 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -129,6 +129,9 @@ SECTIONS _sinittext = .; *(.init.text) _einittext = .; +#ifdef CONFIG_ALTERNATIVE + *(.altinstr_replacement) +#endif This is outside the _einittext? x86 looks to have .altinstr_replacement inside the _einittext. Yes, I looked at the x86 code when I did the implement and I did not find any good reason to keep .altinstr_replace inside the inittext. altinstr_replacement contains replacement instructions. Anything inside the inittext region will be mark executable, which is not what we want here. Right, but we don't this code after the bootup (as in we patch the .text and we can eject the .altinstr_replacement). I don't see any problem, .altinstr_replacement is within __init_begin and __init_end. So it will be free when free_init_memory will be called. _sinittex and _einittext are used to know which page will be executable. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/16] xen/arm: Introduce alternative runtime patching
> >>diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S > >>index 1f010bd..495f9d8 100644 > >>--- a/xen/arch/arm/xen.lds.S > >>+++ b/xen/arch/arm/xen.lds.S > >>@@ -129,6 +129,9 @@ SECTIONS > >>_sinittext = .; > >>*(.init.text) > >>_einittext = .; > >>+#ifdef CONFIG_ALTERNATIVE > >>+ *(.altinstr_replacement) > >>+#endif > > > >This is outside the _einittext? x86 looks to have .altinstr_replacement > >inside the _einittext. > > Yes, I looked at the x86 code when I did the implement and I did not find > any good reason to keep .altinstr_replace inside the inittext. > > altinstr_replacement contains replacement instructions. Anything inside the > inittext region will be mark executable, which is not what we want here. Right, but we don't this code after the bootup (as in we patch the .text and we can eject the .altinstr_replacement). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 0/2] Test booting hvm guest with empty cdrom drive
On Tue, Jun 07, 2016 at 05:29:14PM +0100, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 02:58:05PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH OSSTEST v2 0/2] Test booting hvm guest with empty
> > cdrom drive"):
> > > This can only go in after the bug is fixed and possibly backported to all
> > > the
> > > trees we care about. It won't pass osstest self pushgate otherwise.
> >
> > I pushed these but they broke, but only with XSM. See, for example:
> >
> > From: osstest service owner
> > To:
> > Subject: [osstest test] 95322: regressions - FAIL
> > Date: Mon, 6 Jun 2016 19:29:51 +
> >
> > flight 95322 osstest real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/95322/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9
> > debian-hvm-install fail REGR. vs. 93413
> >test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9
> > debian-hvm-install fail REGR. vs. 93413
> >
> > I haven't had a chance to look at why, yet. For now, I have dropped
> > these patches from the osstest push gate.
> >
>
> I would say it is more related to stubdom.
>
> libxl: error: libxl_dm.c:1967:stubdom_xswait_cb: Stubdom 4 for 3 startup:
> startup timed out
> libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
> w=0x219b2d8: deregister unregistered
> libxl: error: libxl_create.c:1422:domcreate_devmodel_started: device model
> did not start: -9
>
> I've put this on my list and will investigate further.
I know why.
The backend for empty CDROM is always in state 1. Mini-OS blkfront
refuses to move forward unless the backend status turns 4. See
mini-os.git blkfront.c:init_blkfront.
I'm not entirely sure how to fix it though.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] Revert "libxl: No emulated disk driver for xvdX disk"
On Wed, Jun 08, 2016 at 06:17:55PM +0200, Olaf Hering wrote: > On Wed, Jun 08, George Dunlap wrote: > > > CC'ing Olaf and Konrad for their information. :-) > > I'm fine with the revert. Me too! Thanks! > > Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 95443: tolerable all pass - PUSHED
flight 95443 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95443/
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 62b4d4769ca39fd5263da20d786a7b9a80a22d9a
baseline version:
xen 6439d23319986d37a6ea843c98b329218c3ac231
Last test of basis95438 2016-06-08 13:02:51 Z0 days
Testing same since95443 2016-06-08 16:01:49 Z0 days1 attempts
People who touched revisions under test:
Ian Jackson
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=62b4d4769ca39fd5263da20d786a7b9a80a22d9a
+ . ./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
62b4d4769ca39fd5263da20d786a7b9a80a22d9a
+ branch=xen-unstable-smoke
+ revision=62b4d4769ca39fd5263da20d786a7b9a80a22d9a
+ . ./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
+ '[' x62b4d4769ca39fd5263da20d786a7b9a80a22d9a = 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.
Re: [Xen-devel] [PATCH v5 1/6] build: convert debug to Kconfig
On 6/8/16 12:53 PM, Julien Grall wrote:
> Hi Doug,
>
> On 24/05/16 14:56, Doug Goldstein wrote:
>> diff --git a/xen/Rules.mk b/xen/Rules.mk
>> index 961d533..da2f490 100644
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -20,13 +20,14 @@ include $(XEN_ROOT)/Config.mk
>> ifeq ($(debug),y)
>> verbose := y
>> frame_pointer := y
>> -else
>> -CFLAGS += -DNDEBUG
>> endif
>> ifeq ($(perfc_arrays),y)
>> perfc := y
>> endif
>>
>> +ifeq ($(origin debug),command line)
>> +$(warning "You must use 'make menuconfig' to enable/disable debug now.")
>
> While building Xen with "debug=.." on the command Line, I got the
> warning because I have to use Kconfig now. This warning is lost among
> compilation logs.
>
> As this is a warning, I would expect debug=... to work as previously.
> However debug= is just ignored. So I think we should replace the warning
> by an error to avoiding people spending time to understanding why debug
> has not been enabled.
>
> Any opinions?
>
> Regards,
>
Julien,
Yes it needs to become an error. Right now its a warning because its
actually set at the top level. Jan suggested dropping it from the top
level and converting this to an error. But before that we need to give
the tools directory an --{enable,disable}-debug. I've got that written
but I'm at the OpenXT Summit and my dev box is off at home.
I apologize that you got bit by this.
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 95386: regressions - trouble: broken/fail/pass
flight 95386 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95386/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 95235 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 95235 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 95235 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 95235 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 95235 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95235 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95235 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95235 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-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 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-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 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-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-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 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 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 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass version targeted for testing: xen 08d0ba6ed17eb80c529ff17e1cbdb493c0ac236a baseline version: xen f354fb4670132c9811b433ba34fb8edd46f7 Last test of basis95235 2016-06-03 10:55:03 Z5 days Failing since 95328 2016-06-06 13:42:21 Z2 days3 attempts Testing same since95386 2016-06-07 17:01:35 Z0 days1 attempts People who touched revisions under test: Ian Jackson Vitaly Kuznetsov 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-prev pass build-i386-pr
Re: [Xen-devel] [PATCH v5 1/6] build: convert debug to Kconfig
Hi Doug, On 24/05/16 14:56, Doug Goldstein wrote: diff --git a/xen/Rules.mk b/xen/Rules.mk index 961d533..da2f490 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -20,13 +20,14 @@ include $(XEN_ROOT)/Config.mk ifeq ($(debug),y) verbose := y frame_pointer := y -else -CFLAGS += -DNDEBUG endif ifeq ($(perfc_arrays),y) perfc := y endif +ifeq ($(origin debug),command line) +$(warning "You must use 'make menuconfig' to enable/disable debug now.") While building Xen with "debug=.." on the command Line, I got the warning because I have to use Kconfig now. This warning is lost among compilation logs. As this is a warning, I would expect debug=... to work as previously. However debug= is just ignored. So I think we should replace the warning by an error to avoiding people spending time to understanding why debug has not been enabled. Any opinions? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] Revert "libxl: No emulated disk driver for xvdX disk"
On Wed, Jun 08, George Dunlap wrote: > CC'ing Olaf and Konrad for their information. :-) I'm fine with the revert. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] Revert "libxl: No emulated disk driver for xvdX disk"
On 08/06/16 16:52, Wei Liu wrote:
> On Wed, Jun 08, 2016 at 04:32:13PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("[PATCH for-4.7] Revert "libxl: No emulated disk driver for
>> xvdX disk""):
>>> This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
>>>
>>> That commit causes regression on the semantics of our diskspec.
>>> See [0] for more information.
>>>
>>> [0] http://lists.xen.org/archives/html/xen-devel/2016-05/msg02876.html
>>>
>>> Signed-off-by: Wei Liu
>>> ---
>>> Please review carefully about this patch. There are one commit that is
>>> of interest: ef6cb76026628e26e3d1ae53c50ccde1c3c78b1b
>>>
>>> I believe the reverting the snippet in question won't cause security
>>> issue as described in XSA-142, because the code to create IDE disk still
>>> checks if the disk is read-only.
>>
>> Acked-by: Ian Jackson
>>
>> I think this is the right answer for 4.7. In 4.8 we should do
>> something like one of the proposals being discussed in this thread.
>>
>
> Thanks. And Anthony said on IRC this patch looked good to him.
>
> I've queued this for committing to both unstable and 4.7.
CC'ing Olaf and Konrad for their information. :-)
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda
On Wed, Jun 08, 2016 at 01:13:03PM +0200, Olaf Hering wrote: > On Wed, Jun 08, George Dunlap wrote: > > > We definitely don't want to be putting this new stuff we're discussing > > in 4.7.0. I'd be OK with reverting the original change for the release. > > I'm fine with delaying a change to address the (theoretical) breakage > introduced by c0c099d. > > What I just learned a few minutes ago is the fact that c0c099d went > silently into our 4.5 and 4.4 based packages along with XSA-142 fa30003. > That happend already end of last year. Since I heard no reports about > non-booting HVM guest after applying the dom0 updates I think its safe There were. Boris and I reported it a couple of times. Ah, you meant via internal SuSE bugs! > to assume that there are very few (if any) domU.cfg outthere which have > vdev=xvda. Oracle by default in their product (OVS) has that hard-coded for all guest configurations it creates. Granted we are still using Xend and migrating a guest from xm to xl so we have some other issues to address as well. > > So from this perspective its enough to mention the impact of c0c099d in > the 4.7 release-note. > > Olaf > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] Revert "libxl: No emulated disk driver for xvdX disk"
On Wed, Jun 08, 2016 at 04:32:13PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] Revert "libxl: No emulated disk driver for
> xvdX disk""):
> > This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
> >
> > That commit causes regression on the semantics of our diskspec.
> > See [0] for more information.
> >
> > [0] http://lists.xen.org/archives/html/xen-devel/2016-05/msg02876.html
> >
> > Signed-off-by: Wei Liu
> > ---
> > Please review carefully about this patch. There are one commit that is
> > of interest: ef6cb76026628e26e3d1ae53c50ccde1c3c78b1b
> >
> > I believe the reverting the snippet in question won't cause security
> > issue as described in XSA-142, because the code to create IDE disk still
> > checks if the disk is read-only.
>
> Acked-by: Ian Jackson
>
> I think this is the right answer for 4.7. In 4.8 we should do
> something like one of the proposals being discussed in this thread.
>
Thanks. And Anthony said on IRC this patch looked good to him.
I've queued this for committing to both unstable and 4.7.
Wei.
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Embedded-pv-devel] Xen Project Developer Summit : program Published
Hi Lars, On Wed, Jun 8, 2016 at 9:02 AM, Lars Kurth wrote: > We recently announced the program and speakers [1] for our Xen Project > Developer Summit [2] happening in Toronto, Canada from August 25-26, 2016. > The event will be co-located with LinuxCon North America [3]. > > The Xen Project hypervisor powers the new needs of computing and > virtualization through a rich ecosystem of community members that focus on > everything from security, embedded, and web-scale environments. The Summit is > an opportunity for developers and software engineers to collaborate and > discuss the latest advancements of Xen Project software, and better > understand what’s next for Xen Project technology, virtualization and cloud > computing. > > In addition to presentations, we will be running a half-day hackathon > alongside the Summit on the last day. Xen Project hackathons have evolved in > format into a series of structured problem-solving sessions that scale up to > 50 people. I'm wondering if it's possible to record the hackathon into a video or audio, which will be really helpful for people who cannot make the summit. :-) Thanks, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] Revert "libxl: No emulated disk driver for xvdX disk"
Wei Liu writes ("[PATCH for-4.7] Revert "libxl: No emulated disk driver for
xvdX disk""):
> This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
>
> That commit causes regression on the semantics of our diskspec.
> See [0] for more information.
>
> [0] http://lists.xen.org/archives/html/xen-devel/2016-05/msg02876.html
>
> Signed-off-by: Wei Liu
> ---
> Please review carefully about this patch. There are one commit that is
> of interest: ef6cb76026628e26e3d1ae53c50ccde1c3c78b1b
>
> I believe the reverting the snippet in question won't cause security
> issue as described in XSA-142, because the code to create IDE disk still
> checks if the disk is read-only.
Acked-by: Ian Jackson
I think this is the right answer for 4.7. In 4.8 we should do
something like one of the proposals being discussed in this thread.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.7] Revert "libxl: No emulated disk driver for xvdX disk"
This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
That commit causes regression on the semantics of our diskspec.
See [0] for more information.
[0] http://lists.xen.org/archives/html/xen-devel/2016-05/msg02876.html
Signed-off-by: Wei Liu
---
Please review carefully about this patch. There are one commit that is
of interest: ef6cb76026628e26e3d1ae53c50ccde1c3c78b1b
I believe the reverting the snippet in question won't cause security
issue as described in XSA-142, because the code to create IDE disk still
checks if the disk is read-only.
---
tools/libxl/libxl_dm.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 155a653..6ff05c3 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1422,12 +1422,6 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
format,
&disks[i],
colo_mode);
-} else if (strncmp(disks[i].vdev, "xvd", 3) == 0) {
-/*
- * Do not add any emulated disk when PV disk are
- * explicitly asked for.
- */
-continue;
} else if (disk < 6 && b_info->u.hvm.hdtype ==
LIBXL_HDTYPE_AHCI) {
if (!disks[i].readwrite) {
LOG(ERROR, "qemu-xen doesn't support read-only AHCI
disk drivers");
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Fix NULL pointer due to XSA-178 fix wrong XS nodename
Wei Liu writes ("Re: [PATCH] libxl: Fix NULL pointer due to XSA-178 fix wrong
XS nodename"):
> Reviewed-by: Wei Liu
Thanks. As per discussion on irc, I have now pushed this to all the
affected branches.
I think we should issue an update to XSA-178. Given that we warned in
the advisory that the XSA-178 patches were being tested, I think we
can afford to wait until we see another set of test results.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Fix NULL pointer due to XSA-178 fix wrong XS nodename
On Wed, Jun 08, 2016 at 03:56:36PM +0100, Ian Jackson wrote:
> In "libxl: Do not trust backend for disk eject vdev" (c69871a2fb26 on
> xen.git#staging) we changed libxl_evenable_disk_eject to read the
> device vdev out of xenstore from the /libxl path, rather than the
> backend path, and to read it during setup rather than on each event.
>
> However, the patch has a mistake:
> -GCSPRINTF("%s/dev", backend), NULL);
> +GCSPRINTF("%s/vdev", libxl_path), &configured_vdev);
>^
> Spot the extra "v". This causes configured_vdev always to be NULL.
> configured_vdev is passed to [libxl__]strdup.
>
> In Xen 4.6 and later libxl__strdup is used and tolerates NULL.
> evg->vdev is set to NULL. This propagates to the `vdev' field in the
> generated event. This may or may not cause further trouble, depending
> on the calling application. In our osstest test cases it does not
> cause any trouble, so the bug goes undetected.
>
> In Xen 4.5 and earlier, the strdup does not tolerate NULL, and libxl
> crashes immediately. This has been detected by osstest as a
> regression in Xen 4.5.
>
> IMO this patch should be applied immediately to
> xen.git#staging-4.5 (to check that it fixes the osstest regression)
> xen.git#staging (to check that it does not break master
>
> Subject to passes, it should then be propagated to all supported
> stable trees and also be mentioned in an update to XSA-178.
>
> Signed-off-by: Ian Jackson
> CC: secur...@xenproject.org
> CC: Jan Beulich
> CC: Wei Liu
Reviewed-by: Wei Liu
> ---
> tools/libxl/libxl.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 006b83f..7584966 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1399,7 +1399,7 @@ int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t
> guest_domid,
>
> const char *configured_vdev;
> rc = libxl__xs_read_checked(gc, XBT_NULL,
> -GCSPRINTF("%s/vdev", libxl_path), &configured_vdev);
> +GCSPRINTF("%s/dev", libxl_path), &configured_vdev);
> if (rc) goto out;
>
> evg->vdev = libxl__strdup(NOGC, configured_vdev);
> --
> 1.7.10.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] libxl: only issue cpu-add call to QEMU for not present CPU
>>> On 08.06.16 at 16:28, wrote: > Calculate the final bitmap for CPUs to add to avoid having annoying > error messages complaining those CPUs are already present. Ah, nice - I had noticed these odd errors too, but didn't dare to complain about such a cosmetic issue at the same time. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxl: Fix NULL pointer due to XSA-178 fix wrong XS nodename
In "libxl: Do not trust backend for disk eject vdev" (c69871a2fb26 on
xen.git#staging) we changed libxl_evenable_disk_eject to read the
device vdev out of xenstore from the /libxl path, rather than the
backend path, and to read it during setup rather than on each event.
However, the patch has a mistake:
-GCSPRINTF("%s/dev", backend), NULL);
+GCSPRINTF("%s/vdev", libxl_path), &configured_vdev);
^
Spot the extra "v". This causes configured_vdev always to be NULL.
configured_vdev is passed to [libxl__]strdup.
In Xen 4.6 and later libxl__strdup is used and tolerates NULL.
evg->vdev is set to NULL. This propagates to the `vdev' field in the
generated event. This may or may not cause further trouble, depending
on the calling application. In our osstest test cases it does not
cause any trouble, so the bug goes undetected.
In Xen 4.5 and earlier, the strdup does not tolerate NULL, and libxl
crashes immediately. This has been detected by osstest as a
regression in Xen 4.5.
IMO this patch should be applied immediately to
xen.git#staging-4.5 (to check that it fixes the osstest regression)
xen.git#staging (to check that it does not break master
Subject to passes, it should then be propagated to all supported
stable trees and also be mentioned in an update to XSA-178.
Signed-off-by: Ian Jackson
CC: secur...@xenproject.org
CC: Jan Beulich
CC: Wei Liu
---
tools/libxl/libxl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 006b83f..7584966 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1399,7 +1399,7 @@ int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t
guest_domid,
const char *configured_vdev;
rc = libxl__xs_read_checked(gc, XBT_NULL,
-GCSPRINTF("%s/vdev", libxl_path), &configured_vdev);
+GCSPRINTF("%s/dev", libxl_path), &configured_vdev);
if (rc) goto out;
evg->vdev = libxl__strdup(NOGC, configured_vdev);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 95438: tolerable all pass - PUSHED
flight 95438 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95438/
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 6439d23319986d37a6ea843c98b329218c3ac231
baseline version:
xen ba98196b54b27262ffe3d3463358eb4cff18b28d
Last test of basis95426 2016-06-08 10:02:31 Z0 days
Testing same since95438 2016-06-08 13:02:51 Z0 days1 attempts
People who touched revisions under test:
Daniel De Graaf
Daniel Kiper
Doug Goldstein
Euan Harris
Jan Beulich
Julien Grall
Kevin Tian
Suravee Suthikulpanit
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=6439d23319986d37a6ea843c98b329218c3ac231
+ . ./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
6439d23319986d37a6ea843c98b329218c3ac231
+ branch=xen-unstable-smoke
+ revision=6439d23319986d37a6ea843c98b329218c3ac231
+ . ./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.6-testing
+ '[' x6439d23319986d37a6ea843c98b329218c3ac231 = 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 $!;
[Xen-devel] [OSSTEST PATCH 1/2] mg-debian-installer-update: Allow optional suite argument
Signed-off-by: Ian Jackson --- mg-debian-installer-update-all |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mg-debian-installer-update-all b/mg-debian-installer-update-all index 4e76a69..d88ebf5 100755 --- a/mg-debian-installer-update-all +++ b/mg-debian-installer-update-all @@ -1,6 +1,6 @@ #!/bin/bash # usage -# ./mg-debian-installer-update-all +# ./mg-debian-installer-update-all [] # This is part of "osstest", an automated testing framework for Xen. # Copyright (C) 2015 Citrix Inc. @@ -22,7 +22,11 @@ set -e -o posix . ./cri-getconfig -suite=`getconfig DebianSuite` +suite=$1 +if [ "x$suite" = x ]; then +suite=`getconfig DebianSuite` +fi + fws=`getconfig DebianNonfreeFirmware` arches="arm64 armhf amd64 i386" -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 03/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping (top level ones)
>>> On 08.06.16 at 10:58, wrote:
> From: Quan Xu
>
> Signed-off-by: Quan Xu
> Acked-by: Kevin Tian
>
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Kevin Tian
> CC: Feng Wu
> CC: Jan Beulich
> CC: Andrew Cooper
CC: Suravee Suthikulpanit
> v7: just drop 'Reviewed-by: Jan Beulich ',
> as I haven't added __must_check annotation to iommu_unmap_page()
> in previous v6.
> ---
> xen/drivers/passthrough/arm/smmu.c| 2 +-
> xen/drivers/passthrough/vtd/iommu.c | 15 ---
> xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
> xen/include/xen/iommu.h | 2 +-
> 4 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/xen/drivers/passthrough/arm/smmu.c
> b/xen/drivers/passthrough/arm/smmu.c
> index 54a03a6..1ce4ddf 100644
> --- a/xen/drivers/passthrough/arm/smmu.c
> +++ b/xen/drivers/passthrough/arm/smmu.c
> @@ -2774,7 +2774,7 @@ static int arm_smmu_map_page(struct domain *d, unsigned
> long gfn,
> return guest_physmap_add_entry(d, gfn, mfn, 0, t);
> }
>
> -static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
> +static int __must_check arm_smmu_unmap_page(struct domain *d, unsigned long
> gfn)
> {
> /*
>* This function should only be used by gnttab code when the domain
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index db83949..4844193 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -609,7 +609,7 @@ static void intel_iommu_iotlb_flush_all(struct domain *d)
> }
>
> /* clear one page's page table */
> -static void dma_pte_clear_one(struct domain *domain, u64 addr)
> +static int __must_check dma_pte_clear_one(struct domain *domain, u64 addr)
> {
> struct domain_iommu *hd = dom_iommu(domain);
> struct dma_pte *page = NULL, *pte = NULL;
> @@ -621,7 +621,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
> addr)
> if ( pg_maddr == 0 )
> {
> spin_unlock(&hd->arch.mapping_lock);
> -return;
> +return 0;
> }
>
> page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
> @@ -631,7 +631,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
> addr)
> {
> spin_unlock(&hd->arch.mapping_lock);
> unmap_vtd_domain_page(page);
> -return;
> +return 0;
> }
>
> dma_clear_pte(*pte);
> @@ -642,6 +642,8 @@ static void dma_pte_clear_one(struct domain *domain, u64
> addr)
> __intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
>
> unmap_vtd_domain_page(page);
> +
> +return 0;
> }
>
> static void iommu_free_pagetable(u64 pt_maddr, int level)
> @@ -1739,15 +1741,14 @@ static int intel_iommu_map_page(
> return 0;
> }
>
> -static int intel_iommu_unmap_page(struct domain *d, unsigned long gfn)
> +static int __must_check intel_iommu_unmap_page(struct domain *d,
> + unsigned long gfn)
> {
> /* Do nothing if hardware domain and iommu supports pass thru. */
> if ( iommu_passthrough && is_hardware_domain(d) )
> return 0;
>
> -dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
> -
> -return 0;
> +return dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
> }
>
> void iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
> diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
> b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
> index 9c51172..57b6cc1 100644
> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
> @@ -53,7 +53,7 @@ int amd_iommu_update_ivrs_mapping_acpi(void);
> /* mapping functions */
> int amd_iommu_map_page(struct domain *d, unsigned long gfn, unsigned long
> mfn,
> unsigned int flags);
> -int amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
> +int __must_check amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
> u64 amd_iommu_get_next_table_from_pte(u32 *entry);
> int amd_iommu_reserve_domain_unity_map(struct domain *domain,
> u64 phys_addr, unsigned long size,
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index eaa2c77..f45fa5a 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -168,7 +168,7 @@ struct iommu_ops {
> void (*teardown)(struct domain *d);
> int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
> unsigned int flags);
> -int (*unmap_page)(struct domain *d, unsigned long gfn);
> +int __must_check (*unmap_page)(struct domain *d, unsigned long gfn);
> void (*free_page_table)(struct page_info *);
> #ifdef CONFIG_X86
> void (*update_ire_from_apic)(unsigned int apic, unsigned int reg,
> unsigned int value);
> --
> 1.9.1
___
Xen-devel ma
[Xen-devel] [OSSTEST PATCH 2/2] production-config, -cambridge: Update TftpDiVersion_wheezy
There is a new d-i kernel for wheezy. I have set it the new d-i in Cambridge and Massachusetts using mg-debian-installer-update-all. Use it. Signed-off-by: Ian Jackson --- production-config |2 +- production-config-cambridge |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/production-config b/production-config index 6d25fd8..d4037f9 100644 --- a/production-config +++ b/production-config @@ -87,7 +87,7 @@ TftpPxeTemplatesReal pxelinux.cfg/%ipaddrhex% TftpPxeGroup osstest # Update with ./mg-debian-installer-update(-all) -TftpDiVersion_wheezy 2015-09-07 +TftpDiVersion_wheezy 2016-06-08 TftpDiVersion_jessie 2016-01-24 # For ISO installs diff --git a/production-config-cambridge b/production-config-cambridge index 41cd8aa..b12f1ba 100644 --- a/production-config-cambridge +++ b/production-config-cambridge @@ -69,7 +69,7 @@ TftpPxeTemplates %name%/pxelinux.cfg TftpPxeTemplatesReal pxelinux.cfg/%ipaddrhex% TftpPxeGroup osstest -TftpDiVersion_wheezy 2015-09-07 +TftpDiVersion_wheezy 2016-06-08 TftpDiVersion_jessie 2016-01-24 # For ISO installs -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 07/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending (top level ones)
>>> On 08.06.16 at 10:59, wrote:
> @@ -169,6 +203,7 @@ static int enter_state(u32 state)
Right above here we have
if ( (error = device_power_down()) )
which is now wrong as long as SAVED_ALL is not zero.
> {
> printk(XENLOG_ERR "Some devices failed to power down.");
> system_state = SYS_STATE_resume;
> +device_power_up(error);
> goto done;
For the goto you need to adjust "error", or else you return
something meaningless (a sort of random positive number) to your
caller.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/3] libxl: update vcpus bitmap in retrieved guest config
... because the available vcpu bitmap can change during domain life time
due to cpu hotplug and unplug.
For QEMU upstream, we interrogate QEMU for the number of vcpus. For
others, we look directly into xenstore for information.
Reported-by: Jan Beulich
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c | 87 +
1 file changed, 87 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 006b83f..02706ab 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -7222,6 +7222,53 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
libxl_mac *src)
(*dst)[i] = (*src)[i];
}
+static int libxl__update_avail_vcpus_qmp(libxl__gc *gc, uint32_t domid,
+ unsigned int max_vcpus,
+ libxl_bitmap *map)
+{
+int rc;
+
+/* For QEMU upstream we always need to return the number
+ * of cpus present to QEMU whether they are online or not;
+ * otherwise QEMU won't accept the saved state.
+ */
+rc = libxl__qmp_query_cpus(gc, domid, map);
+if (rc) {
+LOG(ERROR, "fail to get number of cpus for domain %d", domid);
+goto out;
+}
+
+rc = 0;
+out:
+return rc;
+}
+
+static int libxl__update_avail_vcpus_xenstore(libxl__gc *gc, uint32_t domid,
+ unsigned int max_vcpus,
+ libxl_bitmap *map)
+{
+int rc;
+unsigned int i;
+const char *dompath;
+
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+for (i = 0; i < max_vcpus; i++) {
+const char *path = GCSPRINTF("%s/cpu/%u/availability", dompath, i);
+const char *content = libxl__xs_read(gc, XBT_NULL, path);
+if (!strncmp(content, "online", strlen("online")))
+libxl_bitmap_set(map, i);
+}
+
+rc = 0;
+out:
+return rc;
+}
+
int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
libxl_domain_config *d_config)
{
@@ -7270,6 +7317,46 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx,
uint32_t domid,
libxl_dominfo_dispose(&info);
}
+/* VCPUs */
+{
+libxl_bitmap *map = &d_config->b_info.avail_vcpus;
+unsigned int max_vcpus = d_config->b_info.max_vcpus;
+
+libxl_bitmap_dispose(map);
+libxl_bitmap_init(map);
+libxl_bitmap_alloc(CTX, map, max_vcpus);
+libxl_bitmap_set_none(map);
+
+switch (d_config->b_info.type) {
+case LIBXL_DOMAIN_TYPE_HVM:
+switch (d_config->b_info.device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+rc = libxl__update_avail_vcpus_qmp(gc, domid,
+ max_vcpus, map);
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+rc = libxl__update_avail_vcpus_xenstore(gc, domid,
+max_vcpus, map);
+break;
+default:
+abort();
+}
+break;
+case LIBXL_DOMAIN_TYPE_PV:
+rc = libxl__update_avail_vcpus_xenstore(gc, domid,
+max_vcpus, map);
+break;
+default:
+abort();
+}
+
+if (rc) {
+LOG(ERROR, "fail to update available cpu map for domain %d",
domid);
+goto out;
+}
+}
+
/* Memory limits:
*
* Currently there are three memory limits:
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/3] libxl: libxl: update available vcpus map in retrieve configuration function
Patch 3 is not really related to the bug, but something we can fix when after having first patch. Wei Liu (3): libxl: introduce libxl__qmp_query_cpus libxl: update vcpus bitmap in retrieved guest config libxl: only issue cpu-add call to QEMU for not present CPU tools/libxl/libxl.c | 126 +++ tools/libxl/libxl_internal.h | 3 ++ tools/libxl/libxl_qmp.c | 37 + 3 files changed, 156 insertions(+), 10 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/3] libxl: introduce libxl__qmp_query_cpus
It interrogates QEMU for CPUs and update the bitmap accordingly.
Signed-off-by: Wei Liu
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_qmp.c | 37 +
2 files changed, 40 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ae16c25..e9a3cf0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1794,6 +1794,9 @@ _hidden int libxl__qmp_set_global_dirty_log(libxl__gc
*gc, int domid, bool enabl
_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const
libxl_device_disk *disk);
/* Add a virtual CPU */
_hidden int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int index);
+/* Query the number of CPUs */
+_hidden int libxl__qmp_query_cpus(libxl__gc *gc, int domid,
+ libxl_bitmap *map);
/* Start NBD server */
_hidden int libxl__qmp_nbd_server_start(libxl__gc *gc, int domid,
const char *host, const char *port);
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 3eb279a..23eac92 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -979,6 +979,43 @@ int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int idx)
return qmp_run_command(gc, domid, "cpu-add", args, NULL, NULL);
}
+static int query_cpus_callback(libxl__qmp_handler *qmp,
+ const libxl__json_object *response,
+ void *opaque)
+{
+libxl_bitmap *map = opaque;
+unsigned int i;
+const libxl__json_object *cpu = NULL;
+int rc;
+GC_INIT(qmp->ctx);
+
+libxl_bitmap_set_none(map);
+for (i = 0; (cpu = libxl__json_array_get(response, i)); i++) {
+unsigned int idx;
+const libxl__json_object *o;
+
+o = libxl__json_map_get("CPU", cpu, JSON_INTEGER);
+if (!o) {
+LOG(ERROR, "Failed to retreive CPU index.");
+goto out;
+}
+
+idx = libxl__json_object_get_integer(o);
+libxl_bitmap_set(map, idx);
+}
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+int libxl__qmp_query_cpus(libxl__gc *gc, int domid, libxl_bitmap *map)
+{
+return qmp_run_command(gc, domid, "query-cpus", NULL,
+ query_cpus_callback, map);
+}
+
int libxl__qmp_nbd_server_start(libxl__gc *gc, int domid,
const char *host, const char *port)
{
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/3] libxl: only issue cpu-add call to QEMU for not present CPU
Calculate the final bitmap for CPUs to add to avoid having annoying
error messages complaining those CPUs are already present.
We can also properly handle error from QMP now.
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 02706ab..62a7ade 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5740,19 +5740,38 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc,
uint32_t domid,
libxl_bitmap *cpumap,
const libxl_dominfo *info)
{
-int i;
+int i, rc;
+libxl_bitmap current_map, final_map;
+
+libxl_bitmap_init(¤t_map);
+libxl_bitmap_init(&final_map);
+
+libxl_bitmap_alloc(CTX, ¤t_map, info->vcpu_max_id + 1);
+libxl_bitmap_set_none(¤t_map);
+rc = libxl__qmp_query_cpus(gc, domid, ¤t_map);
+if (rc) {
+LOG(ERROR, "failed to query cpus for domain %d", domid);
+goto out;
+}
+
+libxl_bitmap_copy_alloc(CTX, &final_map, cpumap);
-for (i = 0; i <= info->vcpu_max_id; i++) {
-if (libxl_bitmap_test(cpumap, i)) {
-/* Return value is ignore because it does not tell anything useful
- * on the completion of the command.
- * (For instance, "CPU already plugged-in" give the same return
- * value as "command not supported".)
- */
-libxl__qmp_cpu_add(gc, domid, i);
+libxl_for_each_set_bit(i, current_map)
+libxl_bitmap_reset(&final_map, i);
+
+libxl_for_each_set_bit(i, final_map) {
+rc = libxl__qmp_cpu_add(gc, domid, i);
+if (rc) {
+LOG(ERROR, "failed to add cpu %d to domain %d", i, domid);
+goto out;
}
}
-return 0;
+
+rc = 0;
+out:
+libxl_bitmap_dispose(¤t_map);
+libxl_bitmap_dispose(&final_map);
+return rc;
}
int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.6-testing test] 95389: regressions - trouble: broken/fail/pass
flight 95389 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95389/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 3 host-install(3) broken REGR. vs. 93974 test-amd64-amd64-xl-pvh-amd 3 host-install(3) broken REGR. vs. 93974 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 93974 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 93923 test-armhf-armhf-xl-vhd 9 debian-di-install fail REGR. vs. 93974 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 93974 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93974 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 93974 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-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-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-xsm 12 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-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-vhd 11 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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-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 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: qemuuaa38966b6fb6008c290f1c6af97af24906ee5159 baseline version: qemuu14a60f98e0cd16e2636afb136129ed7f11cbfce0 Last test of basis93974 2016-05-10 10:29:46 Z 29 days Testing same since95389 2016-06-07 17:14:21 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Gerd Hoffmann Ian Jackson 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-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 t
Re: [Xen-devel] [PATCH 1/2] xen-blkfront: don't call talk_to_blkback when already connected to blkback
On Wed, Jun 08, 2016 at 02:46:38PM +0800, Bob Liu wrote: > > On 06/07/2016 11:25 PM, Konrad Rzeszutek Wilk wrote: > > On Wed, Jun 01, 2016 at 01:49:23PM +0800, Bob Liu wrote: > >> > >> On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote: > >>> On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrote: > Sometimes blkfont may receive twice blkback_changed() notification after > migration, then talk_to_blkback() will be called twice too and confused > xen-blkback. > >>> > >>> Could you enlighten the patch description by having some form of > >>> state transition here? I am curious how you got the frontend > >>> to get in XenbusStateConnected (via blkif_recover right) and then > >>> the backend triggering the update once more? > >>> > >>> Or is just a simple race - the backend moves from XenbusStateConnected-> > >>> XenbusStateConnected - which retriggers the frontend to hit in > >>> blkback_changed the XenbusStateConnected state and go in there? > >>> (That would be in conenct_ring changing the state). But I don't > >>> see how the frontend_changed code get there as we have: > >>> > >>> 770 /* > >>> 771 * Ensure we connect even when two watches fire in > >>> 772 * close succession and we miss the intermediate > >>> value > >>> 773 * of frontend_state. > >>> 774 */ > >>> 775 if (dev->state == XenbusStateConnected) > >>> 776 break; > >>> 777 > >>> > >>> ? > >>> > >>> Now what about 'blkfront_connect' being called on the second time? > >>> > >>> Ah, info->connected is probably by then in BLKIF_STATE_CONNECTED > >>> (as blkif_recover changed) and we just reread the size of the disk. > >>> > >>> Is that how about the flow goes? > >> > >>blkfrontblkback > >> blkfront_resume() > >> > talk_to_blkback() > >> > Set blkfront to XenbusStateInitialised > >>Front changed() > >> > Connect() > >> > Set blkback to > >> XenbusStateConnected > >> > >> blkback_changed() > >> > Skip talk_to_blkback() > >>because frontstate == XenbusStateInitialised > >> > blkfront_connect() > >> > Set blkfront to XenbusStateConnected > >> > >> > >> -- > >> But sometimes blkfront receives > >> blkback_changed() event more than once! > > > > I think I know why. The udev scripts that get invoked when when > > we attach a disk are a bit custom. As such I think they just > > revalidate the size leading to this. > > > > And this 'poke-at-XenbusStateConnected' state multiple times > > is allowed. It is used to signal disk changes (or just to revalidate). > > Hence it does not matter why really - we need to deal with this. > > > > I modified your patch a bit and are testing it: > > > > Looks much better, thank you very much! Great! I also had it tested overnight and there was no hitch will send it out soon. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] docs/livepatch: Update URL to livepatch-build-tools.git
On Wed, Jun 08, 2016 at 10:43:33AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Jun 08, 2016 at 08:11:22AM +0100, Ross Lagerwall wrote: > > On 06/07/2016 07:15 PM, Konrad Rzeszutek Wilk wrote: > > >.. in the design document. The official location is: > > > > > >git://xenbits.xen.org/livepatch-builds-tools.git > > > > > >Wiki is also updated with this URL. > > > > > >Signed-off-by: Konrad Rzeszutek Wilk > > >--- > > >Cc: Andrew Cooper > > >Cc: George Dunlap > > >Cc: Ian Jackson > > >Cc: Jan Beulich > > >Cc: Stefano Stabellini > > >Cc: Tim Deegan > > >Cc: Wei Liu > > >Cc: Ross Lagerwall > > >--- > > > docs/misc/livepatch.markdown | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > >diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown > > >index efda8cf..381cf97 100644 > > >--- a/docs/misc/livepatch.markdown > > >+++ b/docs/misc/livepatch.markdown > > >@@ -816,7 +816,7 @@ The design of that is not discussed in this design. > > > This is implemented in a seperate tool which lives in a seperate > > > GIT repo. > > > > > >-Currently it resides at https://github.com/rosslagerwall/livepatch-build > > >+Currently it resides at git://xenbits.xen.org/livepatch-builds-tools.git > > > > Shouldn't the repo be called livepatch-build-tools? (not "builds") > > > > livepatch-builds-tools sounds weird to me as a native English speaker. > > Drats. You are right. Let me poke Ian to rename it (as I can't). OK. I will fix up the error and commit this patch to unstable and 4.7 in the mean time. Thanks everyone. Wei. > > > > -- > > Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] public/errno: sort entries numerically
On 08/06/16 14:11, Jan Beulich wrote: > Signed-off-by: Jan Beulich Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 03/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping (top level ones)
>>> On 08.06.16 at 10:58, wrote: > From: Quan Xu > > Signed-off-by: Quan Xu > Acked-by: Kevin Tian Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] docs/livepatch: Update URL to livepatch-build-tools.git
On Wed, Jun 08, 2016 at 08:11:22AM +0100, Ross Lagerwall wrote: > On 06/07/2016 07:15 PM, Konrad Rzeszutek Wilk wrote: > >.. in the design document. The official location is: > > > >git://xenbits.xen.org/livepatch-builds-tools.git > > > >Wiki is also updated with this URL. > > > >Signed-off-by: Konrad Rzeszutek Wilk > >--- > >Cc: Andrew Cooper > >Cc: George Dunlap > >Cc: Ian Jackson > >Cc: Jan Beulich > >Cc: Stefano Stabellini > >Cc: Tim Deegan > >Cc: Wei Liu > >Cc: Ross Lagerwall > >--- > > docs/misc/livepatch.markdown | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown > >index efda8cf..381cf97 100644 > >--- a/docs/misc/livepatch.markdown > >+++ b/docs/misc/livepatch.markdown > >@@ -816,7 +816,7 @@ The design of that is not discussed in this design. > > This is implemented in a seperate tool which lives in a seperate > > GIT repo. > > > >-Currently it resides at https://github.com/rosslagerwall/livepatch-build > >+Currently it resides at git://xenbits.xen.org/livepatch-builds-tools.git > > Shouldn't the repo be called livepatch-build-tools? (not "builds") > > livepatch-builds-tools sounds weird to me as a native English speaker. Drats. You are right. Let me poke Ian to rename it (as I can't). > > -- > Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)
>>> On 08.06.16 at 10:58, wrote: > From: Quan Xu > > Signed-off-by: Quan Xu > Acked-by: Kevin Tian Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 02/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
>>> On 08.06.16 at 10:58, wrote:
> @@ -831,10 +837,24 @@ out:
> {
> if ( iommu_flags )
> for ( i = 0; i < (1 << order); i++ )
> -iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
> +{
> +rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> iommu_flags);
> +if ( unlikely(rc) )
> +{
> +while ( i-- )
> +if ( iommu_unmap_page(p2m->domain, gfn + i) )
> +continue;
Nice idea. I would have preferred a brief comment explaining this,
but anyway.
> @@ -140,8 +142,17 @@ void __hwdom_init vtd_set_hwdom_mapping(struct domain *d)
>
> tmp = 1 << (PAGE_SHIFT - PAGE_SHIFT_4K);
> for ( j = 0; j < tmp; j++ )
> -iommu_map_page(d, pfn * tmp + j, pfn * tmp + j,
> - IOMMUF_readable|IOMMUF_writable);
> +{
> +int ret = iommu_map_page(d, pfn * tmp + j, pfn * tmp + j,
> + IOMMUF_readable|IOMMUF_writable);
> +
> +if( !rc )
Missing blank (could be fixed upon commit if no other reason for
another iteration arises).
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] BUG: NOW() seems to (sometimes) go backwards!
>>> On 08.06.16 at 15:43, wrote: > On Wed, 2016-06-08 at 04:42 -0600, Jan Beulich wrote: >> How big of system are we talking about? I'm asking to assess the >> overhead of adding some cross-CPU checks to get_s_time_fixed() >> (in a debugging patch), logging relevant values if non-monotonic >> output gets detected. (On too big a system, the overhead here >> might end up masking the problem.) >> > Yeah, I sort of tried doing something like that already, but was > logging the wrong thing (I was not yet suspecting a problem with > scaling). Yeah, I did also realize that with you observing the problem even within a core, the cross-CPU checking could be limited to just the other SMT sibling, which should bring the overhead down quite a bit. Otoh, with it - as you say - often just being a couple of nano- seconds, even that may then already be too much. Speaking of overhead: The tracing itself that you use does not influence the picture in any way, does it? Considering how easily you say you see the problem, it ought to be more widespread. I'm considering to try to do some such instrumentation to see whether I can see the issue anywhere. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/5] x86: mwait-idle updates
The first three are Linux imports, while the 4th is an adjustment genuine to our clone, and the 5th is an adjustment #3, the Linux equivalent of which I didn't get any feedback on so far. 1: add SKX support 2: add KBL support 3: add BXT support 4: add a missing __init annotation 5: correct/improve BXT support Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/5] mwait-idle: correct/improve BXT support
Linux commit 5dcef69486 ("intel_idle: add BXT support") added an
8-element lookup array with just a 2-bit value used for lookups. As per
the SDM that bit field is really 3 bits wide. Since the top two array
entries are zero, deal with the resulting invalid (zero) values by
moving the zero-MSR-value check into irtl_2_usec() and having that
function's caller check its result instead.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -922,7 +922,10 @@ static unsigned long long __init irtl_2_
{
unsigned long long ns;
- ns = irtl_ns_units[(irtl >> 10) & 0x3];
+ if (!irtl)
+ return 0;
+
+ ns = irtl_ns_units[(irtl >> 10) & 0x7];
return (irtl & 0x3FF) * ns / 1000;
}
@@ -935,43 +938,39 @@ static unsigned long long __init irtl_2_
static void __init bxt_idle_state_table_update(void)
{
unsigned long long msr;
+ unsigned int usec;
rdmsrl(MSR_PKGC6_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[2].exit_latency = usec;
bxt_cstates[2].target_residency = usec;
}
rdmsrl(MSR_PKGC7_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[3].exit_latency = usec;
bxt_cstates[3].target_residency = usec;
}
rdmsrl(MSR_PKGC8_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[4].exit_latency = usec;
bxt_cstates[4].target_residency = usec;
}
rdmsrl(MSR_PKGC9_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[5].exit_latency = usec;
bxt_cstates[5].target_residency = usec;
}
rdmsrl(MSR_PKGC10_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[6].exit_latency = usec;
bxt_cstates[6].target_residency = usec;
}
mwait-idle: correct/improve BXT support
Linux commit 5dcef69486 ("intel_idle: add BXT support") added an
8-element lookup array with just a 2-bit value used for lookups. As per
the SDM that bit field is really 3 bits wide. Since the top two array
entries are zero, deal with the resulting invalid (zero) values by
moving the zero-MSR-value check into irtl_2_usec() and having that
function's caller check its result instead.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -922,7 +922,10 @@ static unsigned long long __init irtl_2_
{
unsigned long long ns;
- ns = irtl_ns_units[(irtl >> 10) & 0x3];
+ if (!irtl)
+ return 0;
+
+ ns = irtl_ns_units[(irtl >> 10) & 0x7];
return (irtl & 0x3FF) * ns / 1000;
}
@@ -935,43 +938,39 @@ static unsigned long long __init irtl_2_
static void __init bxt_idle_state_table_update(void)
{
unsigned long long msr;
+ unsigned int usec;
rdmsrl(MSR_PKGC6_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[2].exit_latency = usec;
bxt_cstates[2].target_residency = usec;
}
rdmsrl(MSR_PKGC7_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[3].exit_latency = usec;
bxt_cstates[3].target_residency = usec;
}
rdmsrl(MSR_PKGC8_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[4].exit_latency = usec;
bxt_cstates[4].target_residency = usec;
}
rdmsrl(MSR_PKGC9_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[5].exit_latency = usec;
bxt_cstates[5].target_residency = usec;
}
rdmsrl(MSR_PKGC10_IRTL, msr);
- if (msr) {
- unsigned int usec = irtl_2_usec(msr);
-
+ usec = irtl_2_usec(msr);
+ if (usec) {
bxt_cstates[6].exit_latency = usec;
bxt_cstates[6].target_residency = usec;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/5] mwait-idle: add a missing __init annotation
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -983,7 +983,7 @@ static void __init bxt_idle_state_table_
* On SKL-H (model 0x5e) disable C8 and C9 if:
* C10 is enabled and SGX disabled
*/
-static void sklh_idle_state_table_update(void)
+static void __init sklh_idle_state_table_update(void)
{
u64 msr;
mwait-idle: add a missing __init annotation
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -983,7 +983,7 @@ static void __init bxt_idle_state_table_
* On SKL-H (model 0x5e) disable C8 and C9 if:
* C10 is enabled and SGX disabled
*/
-static void sklh_idle_state_table_update(void)
+static void __init sklh_idle_state_table_update(void)
{
u64 msr;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/5] mwait-idle: add BXT support
Broxton has all the HSW C-states, except C3.
BXT C-state timing is slightly different.
Here we trust the IRTL MSRs as authority
on maximum C-state latency, and override the driver's tables
with the values found in the associated IRTL MSRs.
Further we set the target_residency to 1x maximum latency,
trusting the hardware demotion logic.
Signed-off-by: Len Brown
[Linux commit: 5dcef694860100fd16885f052591b1268b764d21]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -612,6 +612,52 @@ static const struct cpuidle_state knl_cs
{}
};
+static struct cpuidle_state bxt_cstates[] = {
+ {
+ .name = "C1-BXT",
+ .flags = MWAIT2flg(0x00),
+ .exit_latency = 2,
+ .target_residency = 2,
+ },
+ {
+ .name = "C1E-BXT",
+ .flags = MWAIT2flg(0x01),
+ .exit_latency = 10,
+ .target_residency = 20,
+ },
+ {
+ .name = "C6-BXT",
+ .flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 133,
+ .target_residency = 133,
+ },
+ {
+ .name = "C7s-BXT",
+ .flags = MWAIT2flg(0x31) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 155,
+ .target_residency = 155,
+ },
+ {
+ .name = "C8-BXT",
+ .flags = MWAIT2flg(0x40) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 1000,
+ .target_residency = 1000,
+ },
+ {
+ .name = "C9-BXT",
+ .flags = MWAIT2flg(0x50) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 2000,
+ .target_residency = 2000,
+ },
+ {
+ .name = "C10-BXT",
+ .flags = MWAIT2flg(0x60) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 1,
+ .target_residency = 1,
+ },
+ {}
+};
+
static void mwait_idle(void)
{
unsigned int cpu = smp_processor_id();
@@ -793,11 +839,16 @@ static const struct idle_cpu idle_cpu_kn
.state_table = knl_cstates,
};
+static const struct idle_cpu idle_cpu_bxt = {
+ .state_table = bxt_cstates,
+ .disable_promotion_to_c1e = 1,
+};
+
#define ICPU(model, cpu) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_MONITOR, \
&idle_cpu_##cpu}
-static const struct x86_cpu_id intel_idle_ids[] __initconst = {
+static const struct x86_cpu_id intel_idle_ids[] __initconstrel = {
ICPU(0x1a, nehalem),
ICPU(0x1e, nehalem),
ICPU(0x1f, nehalem),
@@ -829,6 +880,7 @@ static const struct x86_cpu_id intel_idl
ICPU(0x9e, skl),
ICPU(0x55, skx),
ICPU(0x57, knl),
+ ICPU(0x5c, bxt),
{}
};
@@ -860,6 +912,72 @@ static void __init ivt_idle_state_table_
}
/*
+ * Translate IRTL (Interrupt Response Time Limit) MSR to usec
+ */
+
+static const unsigned int __initconst irtl_ns_units[] = {
+ 1, 32, 1024, 32768, 1048576, 33554432, 0, 0 };
+
+static unsigned long long __init irtl_2_usec(unsigned long long irtl)
+{
+ unsigned long long ns;
+
+ ns = irtl_ns_units[(irtl >> 10) & 0x3];
+
+ return (irtl & 0x3FF) * ns / 1000;
+}
+/*
+ * bxt_idle_state_table_update(void)
+ *
+ * On BXT, we trust the IRTL to show the definitive maximum latency
+ * We use the same value for target_residency.
+ */
+static void __init bxt_idle_state_table_update(void)
+{
+ unsigned long long msr;
+
+ rdmsrl(MSR_PKGC6_IRTL, msr);
+ if (msr) {
+ unsigned int usec = irtl_2_usec(msr);
+
+ bxt_cstates[2].exit_latency = usec;
+ bxt_cstates[2].target_residency = usec;
+ }
+
+ rdmsrl(MSR_PKGC7_IRTL, msr);
+ if (msr) {
+ unsigned int usec = irtl_2_usec(msr);
+
+ bxt_cstates[3].exit_latency = usec;
+ bxt_cstates[3].target_residency = usec;
+ }
+
+ rdmsrl(MSR_PKGC8_IRTL, msr);
+ if (msr) {
+ unsigned int usec = irtl_2_usec(msr);
+
+ bxt_cstates[4].exit_latency = usec;
+ bxt_cstates[4].target_residency = usec;
+ }
+
+ rdmsrl(MSR_PKGC9_IRTL, msr);
+ if (msr) {
+ unsigned int usec = irtl_2_usec(msr);
+
+ bxt_cstates[5].exit_latency = usec;
+ bxt_cstates[5].target_residency = usec;
+ }
+
+ rdmsrl(MSR_PKGC10_IRTL, msr);
+ if (msr) {
+ unsigned int usec = irtl_2_usec(msr);
+
+ bxt_cstates[6].exit_latency = usec;
+ bxt_cstates[6].target_residency = usec;
+ }
+}
+
+/*
* sklh_idle_state_table_update(void)
*
* On SKL-H (model 0x5e) disable C8 and C9 if:
@@ -907,6 +1025,9 @@ static void __init mwait_idle_state_tabl
case 0x3e: /* IVT */
ivt_idle_state_table_update();
break;
+
[Xen-devel] [PATCH 2/5] mwait-idle: add KBL support
KBL is similar to SKL
Signed-off-by: Len Brown
[Linux commit: 3ce093d4de753d6c92cc09366e29d0618a62f542]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -825,6 +825,8 @@ static const struct x86_cpu_id intel_idl
ICPU(0x56, bdw),
ICPU(0x4e, skl),
ICPU(0x5e, skl),
+ ICPU(0x8e, skl),
+ ICPU(0x9e, skl),
ICPU(0x55, skx),
ICPU(0x57, knl),
{}
mwait-idle: add KBL support
KBL is similar to SKL
Signed-off-by: Len Brown
[Linux commit: 3ce093d4de753d6c92cc09366e29d0618a62f542]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -825,6 +825,8 @@ static const struct x86_cpu_id intel_idl
ICPU(0x56, bdw),
ICPU(0x4e, skl),
ICPU(0x5e, skl),
+ ICPU(0x8e, skl),
+ ICPU(0x9e, skl),
ICPU(0x55, skx),
ICPU(0x57, knl),
{}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/5] mwait-idle: add SKX support
SKX is similar to BDX
Signed-off-by: Len Brown
[Linux commit: f9e71657c2c0a8f1c50884ab45794be2854e158e]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -530,6 +530,28 @@ static struct cpuidle_state skl_cstates[
{}
};
+static const struct cpuidle_state skx_cstates[] = {
+ {
+ .name = "C1-SKX",
+ .flags = MWAIT2flg(0x00),
+ .exit_latency = 2,
+ .target_residency = 2,
+ },
+ {
+ .name = "C1E-SKX",
+ .flags = MWAIT2flg(0x01),
+ .exit_latency = 10,
+ .target_residency = 20,
+ },
+ {
+ .name = "C6-SKX",
+ .flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 133,
+ .target_residency = 600,
+ },
+ {}
+};
+
static const struct cpuidle_state atom_cstates[] = {
{
.name = "C1E-ATM",
@@ -757,6 +779,11 @@ static const struct idle_cpu idle_cpu_sk
.disable_promotion_to_c1e = 1,
};
+static const struct idle_cpu idle_cpu_skx = {
+ .state_table = skx_cstates,
+ .disable_promotion_to_c1e = 1,
+};
+
static const struct idle_cpu idle_cpu_avn = {
.state_table = avn_cstates,
.disable_promotion_to_c1e = 1,
@@ -798,6 +825,7 @@ static const struct x86_cpu_id intel_idl
ICPU(0x56, bdw),
ICPU(0x4e, skl),
ICPU(0x5e, skl),
+ ICPU(0x55, skx),
ICPU(0x57, knl),
{}
};
mwait-idle: add SKX support
SKX is similar to BDX
Signed-off-by: Len Brown
[Linux commit: f9e71657c2c0a8f1c50884ab45794be2854e158e]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -530,6 +530,28 @@ static struct cpuidle_state skl_cstates[
{}
};
+static const struct cpuidle_state skx_cstates[] = {
+ {
+ .name = "C1-SKX",
+ .flags = MWAIT2flg(0x00),
+ .exit_latency = 2,
+ .target_residency = 2,
+ },
+ {
+ .name = "C1E-SKX",
+ .flags = MWAIT2flg(0x01),
+ .exit_latency = 10,
+ .target_residency = 20,
+ },
+ {
+ .name = "C6-SKX",
+ .flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 133,
+ .target_residency = 600,
+ },
+ {}
+};
+
static const struct cpuidle_state atom_cstates[] = {
{
.name = "C1E-ATM",
@@ -757,6 +779,11 @@ static const struct idle_cpu idle_cpu_sk
.disable_promotion_to_c1e = 1,
};
+static const struct idle_cpu idle_cpu_skx = {
+ .state_table = skx_cstates,
+ .disable_promotion_to_c1e = 1,
+};
+
static const struct idle_cpu idle_cpu_avn = {
.state_table = avn_cstates,
.disable_promotion_to_c1e = 1,
@@ -798,6 +825,7 @@ static const struct x86_cpu_id intel_idl
ICPU(0x56, bdw),
ICPU(0x4e, skl),
ICPU(0x5e, skl),
+ ICPU(0x55, skx),
ICPU(0x57, knl),
{}
};
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] BUG: NOW() seems to (sometimes) go backwards!
On Wed, 2016-06-08 at 04:42 -0600, Jan Beulich wrote:
> > > > On 07.06.16 at 17:54, wrote:
> > So, it looks to me that the TSC is actually ok, and it could be the
> > local_tsc_stamp and scale_delta() magic done in get_s_time_fixed()
> > (which, AFAICUI, is there to convert cycles to time) that does not
> > guarantee the result to be monotonic, even if the input is...
> > Thoughts?
> Indeed this smells like an issue in the scaling. However, the scaling
> values vary only when !CONSTANT_TSC. Can you check that this
> flag is actually set on that system?
>
Checked. I do have it. I instrumented the code to print stuff if it
finds it, and it prints.
Also:
root@Zhaman:~# xl debug-keys s
(XEN) [ 406.719464] TSC marked as reliable, warp = 0 (count=3)
(XEN) [ 406.719467] dom1(hvm):
mode=0,ofs=0xd9279716c276,khz=2394069,inc=4,vtsc count: 195367 kernel, 0
user
> (I hope you're not running a
> strange Dom0 setup with FREQCTL_dom0_kernel in effect.)
>
I've no idea what this is. I've been running 4.1.0, built myself, and
stock Debian unstable 4.5.0, and I'm seeing the issue in both cases.
Looking FREQCTL_dom0_kernel up, I guess you mean what happens when one
passes cpufreq="dom0-kernel" to xen on boot command line. In which
case, no, I'm not doing that.
> And
> at the same time that it's time_calibration_tsc_rendezvous() that
> is in use?
>
The code you're referring to should be this:
/* If we have constant-rate TSCs then scale factor can be shared. */
if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
{
/* If TSCs are not marked as 'reliable', re-sync during rendezvous. */
if ( !boot_cpu_has(X86_FEATURE_TSC_RELIABLE) )
time_calibration_rendezvous_fn = time_calibration_tsc_rendezvous;
}
And I have both X86_FEATURE_CONSTANT_TSC and X86_FEATURE_TSC_RELIABLE.
I've again instrumented the code in order to check whether it is
time_calibration_tsc_rendezvous() or time_calibration_std_rendezvous()
that is being used, and it's the latter:
(XEN) [1.795916] TSC reliable. Yay!! Using 82d080198362 for rendevousez
[dario@Solace xen.git] $ objdump -D xen/xen-syms |grep 82d080198362
82d080198362 :
which looks correct to me.
> Yet when the scaling values get set only once at boot, monotonic
> (cross-CPU) TSC means monotonic (cross-CPU) returns from NOW().
>
Yep. And at this point, this is what needs to be verified, I guess...
> In any event - could you try to exclude C- and P-state effects? Of
> course that makes sense only if you can reasonably repro the
> problem situation (and hence can tell from its absence over a certain
> period of time that whatever change was done did have some
> positive effect).
>
It's actually quite hard *NOT* to reproduce the problem... it happens
all the time, and if the load is high enough, I see the "Time went
backwards?" printk several times per second!
So, trying to do what you suggest in an online fashion, i.e., issueing:
# xenpm set-max-cstate 0
# xenpm set-scaling-governor all performance
did not change the situation (I still see the printks).
I've then tried passing both cpufreq="none" and max_cstate=0 to xen at
boot, but they made no difference at all either.
Most of the time, we're speaking of very small skews, e.g.:
(XEN) [ 59.59] WARNING: __update_runq_load: Time went backwards? now
5946079 llu 5946085
(XEN) [ 117.595508] WARNING: __update_runq_load: Time went backwards? now
117595495295 llu 117595495310
i.e., 6 nanoseconds or 15 nanoseconds!
Then there are instances where the difference is bigger (microseconds
time scale, like in the first email of the thread).
> How big of system are we talking about? I'm asking to assess the
> overhead of adding some cross-CPU checks to get_s_time_fixed()
> (in a debugging patch), logging relevant values if non-monotonic
> output gets detected. (On too big a system, the overhead here
> might end up masking the problem.)
>
Yeah, I sort of tried doing something like that already, but was
logging the wrong thing (I was not yet suspecting a problem with
scaling).
I can try putting something together again.
In any case, the system I use most for testing is a 16 cpus (in 2 NUMA
nodes) Xeon. But I see the issue even within the same socket, so I can
easily reduce to use a subset of the available processors.
Thanks for your time. :-)
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
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/HVM: re-order operations in hvm_ud_intercept()
Don't fetch CS explicitly, leverage the fact that hvm_emulate_prepare()
already does (and that hvm_virtual_to_linear_addr() doesn't alter it).
At once increase the length passed to hvm_virtual_to_linear_addr() by
one: There definitely needs to be at least one more opcode byte, and we
can avoid missing a wraparound case this way.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3834,19 +3834,20 @@ void hvm_ud_intercept(struct cpu_user_re
{
struct hvm_emulate_ctxt ctxt;
+hvm_emulate_prepare(&ctxt, regs);
+
if ( opt_hvm_fep )
{
struct vcpu *cur = current;
-struct segment_register cs;
+const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs];
unsigned long addr;
char sig[5]; /* ud2; .ascii "xen" */
-hvm_get_segment_register(cur, x86_seg_cs, &cs);
-if ( hvm_virtual_to_linear_addr(x86_seg_cs, &cs, regs->eip,
-sizeof(sig), hvm_access_insn_fetch,
+if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->eip,
+sizeof(sig) + 1, hvm_access_insn_fetch,
(hvm_long_mode_enabled(cur) &&
- cs.attr.fields.l) ? 64 :
-cs.attr.fields.db ? 32 : 16, &addr) &&
+ cs->attr.fields.l) ? 64 :
+cs->attr.fields.db ? 32 : 16, &addr) &&
(hvm_fetch_from_guest_virt_nofault(sig, addr, sizeof(sig),
0) == HVMCOPY_okay) &&
(memcmp(sig, "\xf\xbxen", sizeof(sig)) == 0) )
@@ -3856,8 +3857,6 @@ void hvm_ud_intercept(struct cpu_user_re
}
}
-hvm_emulate_prepare(&ctxt, regs);
-
switch ( hvm_emulate_one(&ctxt) )
{
case X86EMUL_UNHANDLEABLE:
x86/HVM: re-order operations in hvm_ud_intercept()
Don't fetch CS explicitly, leverage the fact that hvm_emulate_prepare()
already does (and that hvm_virtual_to_linear_addr() doesn't alter it).
At once increase the length passed to hvm_virtual_to_linear_addr() by
one: There definitely needs to be at least one more opcode byte, and we
can avoid missing a wraparound case this way.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3834,19 +3834,20 @@ void hvm_ud_intercept(struct cpu_user_re
{
struct hvm_emulate_ctxt ctxt;
+hvm_emulate_prepare(&ctxt, regs);
+
if ( opt_hvm_fep )
{
struct vcpu *cur = current;
-struct segment_register cs;
+const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs];
unsigned long addr;
char sig[5]; /* ud2; .ascii "xen" */
-hvm_get_segment_register(cur, x86_seg_cs, &cs);
-if ( hvm_virtual_to_linear_addr(x86_seg_cs, &cs, regs->eip,
-sizeof(sig), hvm_access_insn_fetch,
+if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->eip,
+sizeof(sig) + 1, hvm_access_insn_fetch,
(hvm_long_mode_enabled(cur) &&
- cs.attr.fields.l) ? 64 :
-cs.attr.fields.db ? 32 : 16, &addr) &&
+ cs->attr.fields.l) ? 64 :
+cs->attr.fields.db ? 32 : 16, &addr) &&
(hvm_fetch_from_guest_virt_nofault(sig, addr, sizeof(sig),
0) == HVMCOPY_okay) &&
(memcmp(sig, "\xf\xbxen", sizeof(sig)) == 0) )
@@ -3856,8 +3857,6 @@ void hvm_ud_intercept(struct cpu_user_re
}
}
-hvm_emulate_prepare(&ctxt, regs);
-
switch ( hvm_emulate_one(&ctxt) )
{
case X86EMUL_UNHANDLEABLE:
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/HVM: constify hvm_virtual_to_linear_addr()'s segment register parameter
... to clarify to callers that they don't need to fear the pointed to
data changing (which will be made use of subsequently).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2411,7 +2411,7 @@ int hvm_set_cr4(unsigned long value, boo
bool_t hvm_virtual_to_linear_addr(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
unsigned long offset,
unsigned int bytes,
enum hvm_access_type access_type,
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -469,7 +469,7 @@ enum hvm_access_type {
};
bool_t hvm_virtual_to_linear_addr(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
unsigned long offset,
unsigned int bytes,
enum hvm_access_type access_type,
x86/HVM: constify hvm_virtual_to_linear_addr()'s segment register parameter
... to clarify to callers that they don't need to fear the pointed to
data changing (which will be made use of subsequently).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2411,7 +2411,7 @@ int hvm_set_cr4(unsigned long value, boo
bool_t hvm_virtual_to_linear_addr(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
unsigned long offset,
unsigned int bytes,
enum hvm_access_type access_type,
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -469,7 +469,7 @@ enum hvm_access_type {
};
bool_t hvm_virtual_to_linear_addr(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
unsigned long offset,
unsigned int bytes,
enum hvm_access_type access_type,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/HVM: mis adjustments
1: constify hvm_virtual_to_linear_addr()'s segment register parameter 2: re-order operations in hvm_ud_intercept() Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V8 2/3] drivers/pl011: Use combination of UARTRIS and UARTMSC instead of UARTMIS
The Masked interrupt status register (UARTMIS) is not described in ARM
SBSA 2.x document. Anding of two registers UARTMSC and UARTRIS values
gives the same information as register UARTMIS.
UARTRIS, UARTMSC and UARTMIS definitions are found in PrimeCell UART
PL011 (Revision: r1p4).
- 3.3.10 Interrupt mask set/clear register, UARTIMSC
- 3.3.11 Raw interrupt status register, UARTRIS
- 3.3.12 Masked interrupt status register, UARTMIS
This change is necessary for driver to be SBSA compliant v2.x without
affecting the current driver functionality.
Signed-off-by: Shanker Donthineni
---
Changes since v7:
Moved comment 'To compatible with SBSA v2.x document, all accesses should be
32-bit' to #3
Changes since v1:
Added a new function to return an interrupt status.
xen/drivers/char/pl011.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 6a3c21b..a2f929b 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -53,11 +53,17 @@ static struct pl011 {
#define pl011_read(uart, off) readl((uart)->regs + (off))
#define pl011_write(uart, off,val) writel((val), (uart)->regs + (off))
+static unsigned int pl011_intr_status(struct pl011 *uart)
+{
+/* UARTMIS is not documented in SBSA v2.x, so using UARTRIS/UARTIMSC */
+return ( pl011_read(uart, RIS) & pl011_read(uart, IMSC) );
+}
+
static void pl011_interrupt(int irq, void *data, struct cpu_user_regs *regs)
{
struct serial_port *port = data;
struct pl011 *uart = port->uart;
-unsigned int status = pl011_read(uart, MIS);
+unsigned int status = pl011_intr_status(uart);
if ( status )
{
@@ -76,7 +82,7 @@ static void pl011_interrupt(int irq, void *data, struct
cpu_user_regs *regs)
if ( status & (TXI) )
serial_tx_interrupt(port, regs);
-status = pl011_read(uart, MIS);
+status = pl011_intr_status(uart);
} while (status != 0);
}
}
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V8 3/3] arm/acpi: Add Server Base System Architecture UART support
The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers, modem
control, DMA and hardware flow control features. So, extend the
driver probe() to handle SBSA interface and skip the accessing
PL011 registers that are not described in SBSA document
(ARM-DEN-0029 Version 3.0, 6 APPENDIX B: GENERIC UART).
Signed-off-by: Shanker Donthineni
Reviewed-by: Julien Grall
---
Changes sicne v7:
Moved comment 'To compatible with SBSA v2.x document, all accesses should be
32-bit' from #2
Changes since v3:
Moved non-SBSA related changes to patches 1/3 and 2/3.
changes since v2:
Edited commit text to include SBSA document version.
Remove setting baudrate code completely as per Julien's suggestion.
Support both the SBSA interface types ACPI_DBG2_SBSA & ACPI_DBG2_SBSA_32.
Replace MIS references with combination of RIS & IMSC.
Changes since v1:
Don't access UART registers that are not part of SBSA document.
Move setting baudrate function to a separate function.
xen/drivers/char/pl011.c | 55 +++-
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index a2f929b..d70ec99 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -41,6 +41,7 @@ static struct pl011 {
/* struct timer timer; */
/* unsigned int timeout_ms; */
/* bool_t probing, intr_works; */
+bool sbsa; /* ARM SBSA generic interface */
} pl011_com = {0};
/* These parity settings can be ORed directly into the LCR. */
@@ -50,6 +51,7 @@ static struct pl011 {
#define PARITY_MARK (PEN|SPS)
#define PARITY_SPACE (PEN|EPS|SPS)
+/* To compatible with SBSA v2.x document, all accesses should be 32-bit */
#define pl011_read(uart, off) readl((uart)->regs + (off))
#define pl011_write(uart, off,val) writel((val), (uart)->regs + (off))
@@ -95,14 +97,17 @@ static void __init pl011_init_preirq(struct serial_port
*port)
/* No interrupts, please. */
pl011_write(uart, IMSC, 0);
-/* Definitely no DMA */
-pl011_write(uart, DMACR, 0x0);
-
-/* This write must follow FBRD and IBRD writes. */
-pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
-| FEN
-| ((uart->stop_bits - 1) << 3)
-| uart->parity);
+if ( !uart->sbsa )
+{
+/* Definitely no DMA */
+pl011_write(uart, DMACR, 0x0);
+
+/* This write must follow FBRD and IBRD writes. */
+pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
+| FEN
+| ((uart->stop_bits - 1) << 3)
+| uart->parity);
+}
/* Clear errors */
pl011_write(uart, RSR, 0);
@@ -110,10 +115,13 @@ static void __init pl011_init_preirq(struct serial_port
*port)
pl011_write(uart, IMSC, 0);
pl011_write(uart, ICR, ALLI);
-/* Enable the UART for RX and TX; keep RTS and DTR */
-cr = pl011_read(uart, CR);
-cr &= RTS | DTR;
-pl011_write(uart, CR, cr | RXE | TXE | UARTEN);
+if ( !uart->sbsa )
+{
+/* Enable the UART for RX and TX; keep RTS and DTR */
+cr = pl011_read(uart, CR);
+cr &= RTS | DTR;
+pl011_write(uart, CR, cr | RXE | TXE | UARTEN);
+}
}
static void __init pl011_init_postirq(struct serial_port *port)
@@ -215,7 +223,7 @@ static struct uart_driver __read_mostly pl011_driver = {
.vuart_info = pl011_vuart,
};
-static int __init pl011_uart_init(int irq, u64 addr, u64 size)
+static int __init pl011_uart_init(int irq, u64 addr, u64 size, bool sbsa)
{
struct pl011 *uart;
@@ -224,6 +232,7 @@ static int __init pl011_uart_init(int irq, u64 addr, u64
size)
uart->data_bits = 8;
uart->parity= PARITY_NONE;
uart->stop_bits = 1;
+uart->sbsa = sbsa;
uart->regs = ioremap_nocache(addr, size);
if ( !uart->regs )
@@ -272,7 +281,7 @@ static int __init pl011_dt_uart_init(struct dt_device_node
*dev,
return -EINVAL;
}
-res = pl011_uart_init(res, addr, size);
+res = pl011_uart_init(res, addr, size, false);
if ( res < 0 )
{
printk("pl011: Unable to initialize\n");
@@ -303,6 +312,7 @@ static int __init pl011_acpi_uart_init(const void *data)
acpi_status status;
struct acpi_table_spcr *spcr = NULL;
int res;
+bool sbsa = false;
status = acpi_get_table(ACPI_SIG_SPCR, 0,
(struct acpi_table_header **)&spcr);
@@ -313,11 +323,15 @@ static int __init pl011_acpi_uart_init(const void *data)
return -EINVAL;
}
+if ( (spcr->interface_type == ACPI_DBG2_SBSA) ||
+ (spcr->interface_type == ACPI_DBG2_SBSA_32) )
+sbsa = true;
+
/* trigger/polarity information is not available in spcr */
irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
[Xen-devel] [PATCH V8 1/3] drivers/pl011: Don't configure baudrate
The default baud and clock_hz configuration parameters are hardcoded
(commit 60ff980995008caf) for Versatile Express. Other platforms,
these default values may not be valid and might cause problems by
programming registers IBRD and FBRD incorrectly.
So, removing driver logic that sets the baudrate to fix the problem.
The behavior is unchanged because the driver was already relying on
the boot firmware for setting the correct baudrate.
Signed-off-by: Shanker Donthineni
Reviewed-by: Julien Grall
---
Changes since v1:
Edited commit text.
xen/drivers/char/pl011.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 1212d5c..6a3c21b 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -31,7 +31,7 @@
#include
static struct pl011 {
-unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int data_bits, parity, stop_bits;
unsigned int irq;
void __iomem *regs;
/* UART with IRQ line: interrupt-driven I/O. */
@@ -84,7 +84,6 @@ static void pl011_interrupt(int irq, void *data, struct
cpu_user_regs *regs)
static void __init pl011_init_preirq(struct serial_port *port)
{
struct pl011 *uart = port->uart;
-unsigned int divisor;
unsigned int cr;
/* No interrupts, please. */
@@ -93,22 +92,6 @@ static void __init pl011_init_preirq(struct serial_port
*port)
/* Definitely no DMA */
pl011_write(uart, DMACR, 0x0);
-/* Line control and baud-rate generator. */
-if ( uart->baud != BAUD_AUTO )
-{
-/* Baud rate specified: program it into the divisor latch. */
-divisor = (uart->clock_hz << 2) / uart->baud; /* clk << 6 / bd << 4 */
-pl011_write(uart, FBRD, divisor & 0x3f);
-pl011_write(uart, IBRD, divisor >> 6);
-}
-else
-{
-/* Baud rate already set: read it out from the divisor latch. */
-divisor = (pl011_read(uart, IBRD) << 6) | (pl011_read(uart, FBRD));
-if (!divisor)
-panic("pl011: No Baud rate configured\n");
-uart->baud = (uart->clock_hz << 2) / divisor;
-}
/* This write must follow FBRD and IBRD writes. */
pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
| FEN
@@ -232,8 +215,6 @@ static int __init pl011_uart_init(int irq, u64 addr, u64
size)
uart = &pl011_com;
uart->irq = irq;
-uart->clock_hz = 0x16e3600;
-uart->baud = BAUD_AUTO;
uart->data_bits = 8;
uart->parity= PARITY_NONE;
uart->stop_bits = 1;
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/PV: drop pointless conditional from pv_cpuid()'s state leaf logic
In the control/hardware domain case without it we simply re-read the same value that was put into b near the top of the function. Signed-off-by: Jan Beulich --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1119,8 +1119,7 @@ void pv_cpuid(struct cpu_user_regs *regs * domain policy. It varies with enabled xstate, and the correct * xcr0 is in context. */ -if ( !is_control_domain(currd) && !is_hardware_domain(currd) ) -cpuid_count(leaf, subleaf, &tmp, &b, &tmp, &tmp); +cpuid_count(leaf, subleaf, &tmp, &b, &tmp, &tmp); break; } x86/PV: drop pointless conditional from pv_cpuid()'s state leaf logic In the control/hardware domain case without it we simply re-read the same value that was put into b near the top of the function. Signed-off-by: Jan Beulich --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1119,8 +1119,7 @@ void pv_cpuid(struct cpu_user_regs *regs * domain policy. It varies with enabled xstate, and the correct * xcr0 is in context. */ -if ( !is_control_domain(currd) && !is_hardware_domain(currd) ) -cpuid_count(leaf, subleaf, &tmp, &b, &tmp, &tmp); +cpuid_count(leaf, subleaf, &tmp, &b, &tmp, &tmp); break; } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/shadow: sh_pagetable_dying() cleanup
Don't call shadow_hash_lookup() at all when get_gfn_query_unlocked()
didn't return a valid MFN.
Also no need for local variables used only once, the more with scopes
much wider than their actual use.
Signed-off-by: Jan Beulich
---
Question is whether we shouldn't also get rid of
guest_l[234]e_get_paddr(), as they're now effectively unused.
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4501,7 +4501,6 @@ static void sh_pagetable_dying(struct vc
p2m_type_t p2mt;
char *gl3pa = NULL;
guest_l3e_t *gl3e = NULL;
-paddr_t gl2a = 0;
unsigned long l3gfn;
mfn_t l3mfn;
@@ -4528,7 +4527,6 @@ static void sh_pagetable_dying(struct vc
}
for ( i = 0; i < 4; i++ )
{
-unsigned long gfn;
mfn_t smfn, gmfn;
if ( fast_path ) {
@@ -4540,10 +4538,11 @@ static void sh_pagetable_dying(struct vc
else
{
/* retrieving the l2s */
-gl2a = guest_l3e_get_paddr(gl3e[i]);
-gfn = gl2a >> PAGE_SHIFT;
-gmfn = get_gfn_query_unlocked(d, gfn, &p2mt);
-smfn = shadow_hash_lookup(d, mfn_x(gmfn), SH_type_l2_pae_shadow);
+gmfn = get_gfn_query_unlocked(d, gfn_x(guest_l3e_get_gfn(gl3e[i])),
+ &p2mt);
+smfn = likely(mfn_x(gmfn) != INVALID_MFN)
+ ? shadow_hash_lookup(d, mfn_x(gmfn), SH_type_l2_pae_shadow)
+ : gmfn;
}
if ( mfn_valid(smfn) )
x86/shadow: sh_pagetable_dying() cleanup
Don't call shadow_hash_lookup() at all when get_gfn_query_unlocked()
didn't return a valid MFN.
Also no need for local variables used only once, the more with scopes
much wider than their actual use.
Signed-off-by: Jan Beulich
---
Question is whether we shouldn't also get rid of
guest_l[234]e_get_paddr(), as they're now effectively unused.
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4501,7 +4501,6 @@ static void sh_pagetable_dying(struct vc
p2m_type_t p2mt;
char *gl3pa = NULL;
guest_l3e_t *gl3e = NULL;
-paddr_t gl2a = 0;
unsigned long l3gfn;
mfn_t l3mfn;
@@ -4528,7 +4527,6 @@ static void sh_pagetable_dying(struct vc
}
for ( i = 0; i < 4; i++ )
{
-unsigned long gfn;
mfn_t smfn, gmfn;
if ( fast_path ) {
@@ -4540,10 +4538,11 @@ static void sh_pagetable_dying(struct vc
else
{
/* retrieving the l2s */
-gl2a = guest_l3e_get_paddr(gl3e[i]);
-gfn = gl2a >> PAGE_SHIFT;
-gmfn = get_gfn_query_unlocked(d, gfn, &p2mt);
-smfn = shadow_hash_lookup(d, mfn_x(gmfn), SH_type_l2_pae_shadow);
+gmfn = get_gfn_query_unlocked(d, gfn_x(guest_l3e_get_gfn(gl3e[i])),
+ &p2mt);
+smfn = likely(mfn_x(gmfn) != INVALID_MFN)
+ ? shadow_hash_lookup(d, mfn_x(gmfn), SH_type_l2_pae_shadow)
+ : gmfn;
}
if ( mfn_valid(smfn) )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86: drop hvm/iommu.h
As a follow-up to commit af07377007 ("IOMMU/x86: per-domain control
structure is not HVM-specific"), fold hvm/iommu.h into iommu.h.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/iommu.h
+++ /dev/null
@@ -1,66 +0,0 @@
-#ifndef __ASM_X86_HVM_IOMMU_H__
-#define __ASM_X86_HVM_IOMMU_H__
-
-#include
-
-struct iommu_ops;
-extern const struct iommu_ops intel_iommu_ops;
-extern const struct iommu_ops amd_iommu_ops;
-extern int intel_vtd_setup(void);
-extern int amd_iov_detect(void);
-
-static inline const struct iommu_ops *iommu_get_ops(void)
-{
-switch ( boot_cpu_data.x86_vendor )
-{
-case X86_VENDOR_INTEL:
-return &intel_iommu_ops;
-case X86_VENDOR_AMD:
-return &amd_iommu_ops;
-default:
-BUG();
-}
-
-return NULL;
-}
-
-static inline int iommu_hardware_setup(void)
-{
-switch ( boot_cpu_data.x86_vendor )
-{
-case X86_VENDOR_INTEL:
-return intel_vtd_setup();
-case X86_VENDOR_AMD:
-return amd_iov_detect();
-default:
-return -ENODEV;
-}
-
-return 0;
-}
-
-struct g2m_ioport {
-struct list_head list;
-unsigned int gport;
-unsigned int mport;
-unsigned int np;
-};
-
-#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
-
-struct arch_iommu
-{
-u64 pgd_maddr; /* io page directory machine address */
-spinlock_t mapping_lock;/* io page table lock */
-int agaw; /* adjusted guest address width, 0 is level 2 30-bit */
-struct list_head g2m_ioport_list; /* guest to machine ioport mapping */
-u64 iommu_bitmap; /* bitmap of iommu(s) that the domain uses
*/
-struct list_head mapped_rmrrs;
-
-/* amd iommu support */
-int paging_mode;
-struct page_info *root_table;
-struct guest_iommu *g_iommu;
-};
-
-#endif /* __ASM_X86_HVM_IOMMU_H__ */
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -14,10 +14,69 @@
#ifndef __ARCH_X86_IOMMU_H__
#define __ARCH_X86_IOMMU_H__
-#include /* For now - should really be merged here. */
+#include
+#include
+#include
+#include
+#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
#define MAX_IOMMUS 32
+struct g2m_ioport {
+struct list_head list;
+unsigned int gport;
+unsigned int mport;
+unsigned int np;
+};
+
+struct arch_iommu
+{
+u64 pgd_maddr; /* io page directory machine address */
+spinlock_t mapping_lock;/* io page table lock */
+int agaw; /* adjusted guest address width, 0 is level 2 30-bit */
+struct list_head g2m_ioport_list; /* guest to machine ioport mapping */
+u64 iommu_bitmap; /* bitmap of iommu(s) that the domain uses
*/
+struct list_head mapped_rmrrs;
+
+/* amd iommu support */
+int paging_mode;
+struct page_info *root_table;
+struct guest_iommu *g_iommu;
+};
+
+extern const struct iommu_ops intel_iommu_ops;
+extern const struct iommu_ops amd_iommu_ops;
+int intel_vtd_setup(void);
+int amd_iov_detect(void);
+
+static inline const struct iommu_ops *iommu_get_ops(void)
+{
+switch ( boot_cpu_data.x86_vendor )
+{
+case X86_VENDOR_INTEL:
+return &intel_iommu_ops;
+case X86_VENDOR_AMD:
+return &amd_iommu_ops;
+}
+
+BUG();
+
+return NULL;
+}
+
+static inline int iommu_hardware_setup(void)
+{
+switch ( boot_cpu_data.x86_vendor )
+{
+case X86_VENDOR_INTEL:
+return intel_vtd_setup();
+case X86_VENDOR_AMD:
+return amd_iov_detect();
+}
+
+return -ENODEV;
+}
+
/* Does this domain have a P2M table we can use as its IOMMU pagetable? */
#define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
x86: drop hvm/iommu.h
As a follow-up to commit af07377007 ("IOMMU/x86: per-domain control
structure is not HVM-specific"), fold hvm/iommu.h into iommu.h.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/iommu.h
+++ /dev/null
@@ -1,66 +0,0 @@
-#ifndef __ASM_X86_HVM_IOMMU_H__
-#define __ASM_X86_HVM_IOMMU_H__
-
-#include
-
-struct iommu_ops;
-extern const struct iommu_ops intel_iommu_ops;
-extern const struct iommu_ops amd_iommu_ops;
-extern int intel_vtd_setup(void);
-extern int amd_iov_detect(void);
-
-static inline const struct iommu_ops *iommu_get_ops(void)
-{
-switch ( boot_cpu_data.x86_vendor )
-{
-case X86_VENDOR_INTEL:
-return &intel_iommu_ops;
-case X86_VENDOR_AMD:
-return &amd_iommu_ops;
-default:
-BUG();
-}
-
-return NULL;
-}
-
-static inline int iommu_hardware_setup(void)
-{
-switch ( boot_cpu_data.x86_vendor )
-{
-case X86_VENDOR_INTEL:
-return intel_vtd_setup();
-case X86_VENDOR_AMD:
-return amd_iov_detect();
-default:
-return -ENODEV;
-}
-
-return 0;
-}
-
-struct g2m_ioport {
-struct list_head list;
-unsigned int gport;
-unsigned int mport;
-unsigned int np;
-};
-
-#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
-
-struct arch_iommu
-{
-u64 pgd_madd
[Xen-devel] [PATCH] public/errno: sort entries numerically
Signed-off-by: Jan Beulich --- a/xen/include/public/errno.h +++ b/xen/include/public/errno.h @@ -91,8 +91,8 @@ XEN_ERRNO(EDEADLK,35) /* Resource deadl XEN_ERRNO(EDEADLOCK, 35) /* Resource deadlock would occur. Aliases EDEADLK */ XEN_ERRNO(ENAMETOOLONG,36) /* File name too long */ XEN_ERRNO(ENOLCK, 37) /* No record locks available */ -XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */ XEN_ERRNO(ENOSYS, 38) /* Function not implemented */ +XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */ XEN_ERRNO(ENODATA, 61) /* No data available */ XEN_ERRNO(ETIME, 62) /* Timer expired */ XEN_ERRNO(EBADMSG, 74) /* Not a data message */ public/errno: sort entries numerically Signed-off-by: Jan Beulich --- a/xen/include/public/errno.h +++ b/xen/include/public/errno.h @@ -91,8 +91,8 @@ XEN_ERRNO(EDEADLK,35) /* Resource deadl XEN_ERRNO(EDEADLOCK, 35) /* Resource deadlock would occur. Aliases EDEADLK */ XEN_ERRNO(ENAMETOOLONG,36) /* File name too long */ XEN_ERRNO(ENOLCK, 37) /* No record locks available */ -XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */ XEN_ERRNO(ENOSYS, 38) /* Function not implemented */ +XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */ XEN_ERRNO(ENODATA, 61) /* No data available */ XEN_ERRNO(ETIME, 62) /* Timer expired */ XEN_ERRNO(EBADMSG, 74) /* Not a data message */ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: clean up AFLAGS management
No need to force inclusion of xen/config.h - AFLAGS incorporates
CFLAGS, which already does this.
Also no need to use nested $(filter-out ...) - one of them can deal
with any number of patterns.
Signed-off-by: Jan Beulich
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -64,7 +64,7 @@ ifneq ($(max_phys_irqs),)
CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
endif
-AFLAGS-y+= -D__ASSEMBLY__ -include
$(BASEDIR)/include/xen/config.h
+AFLAGS-y+= -D__ASSEMBLY__
# Clang's built-in assembler can't handle .code16/.code32/.code64 yet
AFLAGS-$(clang) += -no-integrated-as
@@ -79,7 +79,7 @@ CFLAGS += $(CFLAGS-y)
# Most CFLAGS are safe for assembly files:
# -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
# -flto makes no sense and annoys clang
-AFLAGS += $(AFLAGS-y) $(filter-out -std=gnu%,$(filter-out -flto,$(CFLAGS)))
+AFLAGS += $(AFLAGS-y) $(filter-out -std=gnu% -flto,$(CFLAGS))
# LDFLAGS are only passed directly to $(LD)
LDFLAGS += $(LDFLAGS_DIRECT)
clean up AFLAGS management
No need to force inclusion of xen/config.h - AFLAGS incorporates
CFLAGS, which already does this.
Also no need to use nested $(filter-out ...) - one of them can deal
with any number of patterns.
Signed-off-by: Jan Beulich
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -64,7 +64,7 @@ ifneq ($(max_phys_irqs),)
CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
endif
-AFLAGS-y+= -D__ASSEMBLY__ -include
$(BASEDIR)/include/xen/config.h
+AFLAGS-y+= -D__ASSEMBLY__
# Clang's built-in assembler can't handle .code16/.code32/.code64 yet
AFLAGS-$(clang) += -no-integrated-as
@@ -79,7 +79,7 @@ CFLAGS += $(CFLAGS-y)
# Most CFLAGS are safe for assembly files:
# -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
# -flto makes no sense and annoys clang
-AFLAGS += $(AFLAGS-y) $(filter-out -std=gnu%,$(filter-out -flto,$(CFLAGS)))
+AFLAGS += $(AFLAGS-y) $(filter-out -std=gnu% -flto,$(CFLAGS))
# LDFLAGS are only passed directly to $(LD)
LDFLAGS += $(LDFLAGS_DIRECT)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/HVM: use available linear->phys translations in REP MOVS/STOS handling
If we have the translation result available already, we should also use
is here. In my tests with Linux guests this eliminates all calls to
hvmemul_linear_to_phys() out of the two functions being changed.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1156,6 +1156,7 @@ static int hvmemul_rep_movs(
{
struct hvm_emulate_ctxt *hvmemul_ctxt =
container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+struct hvm_vcpu_io *vio = ¤t->arch.hvm_vcpu.hvm_io;
unsigned long saddr, daddr, bytes;
paddr_t sgpa, dgpa;
uint32_t pfec = PFEC_page_present;
@@ -1178,16 +1179,43 @@ static int hvmemul_rep_movs(
if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
pfec |= PFEC_user_mode;
-rc = hvmemul_linear_to_phys(
-saddr, &sgpa, bytes_per_rep, reps, pfec, hvmemul_ctxt);
-if ( rc != X86EMUL_OKAY )
-return rc;
+bytes = PAGE_SIZE - (saddr & ~PAGE_MASK);
+if ( vio->mmio_access.read_access &&
+ (vio->mmio_gva == (saddr & PAGE_MASK)) &&
+ bytes >= bytes_per_rep )
+{
+sgpa = pfn_to_paddr(vio->mmio_gpfn) | (saddr & ~PAGE_MASK);
+if ( *reps * bytes_per_rep > bytes )
+*reps = bytes / bytes_per_rep;
+}
+else
+{
+rc = hvmemul_linear_to_phys(saddr, &sgpa, bytes_per_rep, reps, pfec,
+hvmemul_ctxt);
+if ( rc != X86EMUL_OKAY )
+return rc;
-rc = hvmemul_linear_to_phys(
-daddr, &dgpa, bytes_per_rep, reps,
-pfec | PFEC_write_access, hvmemul_ctxt);
-if ( rc != X86EMUL_OKAY )
-return rc;
+latch_linear_to_phys(vio, saddr, sgpa, 0);
+}
+
+bytes = PAGE_SIZE - (daddr & ~PAGE_MASK);
+if ( vio->mmio_access.write_access &&
+ (vio->mmio_gva == (daddr & PAGE_MASK)) &&
+ bytes >= bytes_per_rep )
+{
+dgpa = pfn_to_paddr(vio->mmio_gpfn) | (daddr & ~PAGE_MASK);
+if ( *reps * bytes_per_rep > bytes )
+*reps = bytes / bytes_per_rep;
+}
+else
+{
+rc = hvmemul_linear_to_phys(daddr, &dgpa, bytes_per_rep, reps,
+pfec | PFEC_write_access, hvmemul_ctxt);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+latch_linear_to_phys(vio, daddr, dgpa, 1);
+}
/* Check for MMIO ops */
(void) get_gfn_query_unlocked(current->domain, sgpa >> PAGE_SHIFT, &sp2mt);
@@ -1279,25 +1307,40 @@ static int hvmemul_rep_stos(
{
struct hvm_emulate_ctxt *hvmemul_ctxt =
container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-unsigned long addr;
+struct hvm_vcpu_io *vio = ¤t->arch.hvm_vcpu.hvm_io;
+unsigned long addr, bytes;
paddr_t gpa;
p2m_type_t p2mt;
bool_t df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
int rc = hvmemul_virtual_to_linear(seg, offset, bytes_per_rep, reps,
hvm_access_write, hvmemul_ctxt, &addr);
-if ( rc == X86EMUL_OKAY )
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+bytes = PAGE_SIZE - (addr & ~PAGE_MASK);
+if ( vio->mmio_access.write_access &&
+ (vio->mmio_gva == (addr & PAGE_MASK)) &&
+ bytes >= bytes_per_rep )
+{
+gpa = pfn_to_paddr(vio->mmio_gpfn) | (addr & ~PAGE_MASK);
+if ( *reps * bytes_per_rep > bytes )
+*reps = bytes / bytes_per_rep;
+}
+else
{
uint32_t pfec = PFEC_page_present | PFEC_write_access;
if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
pfec |= PFEC_user_mode;
-rc = hvmemul_linear_to_phys(
-addr, &gpa, bytes_per_rep, reps, pfec, hvmemul_ctxt);
+rc = hvmemul_linear_to_phys(addr, &gpa, bytes_per_rep, reps, pfec,
+hvmemul_ctxt);
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+latch_linear_to_phys(vio, addr, gpa, 1);
}
-if ( rc != X86EMUL_OKAY )
-return rc;
/* Check for MMIO op */
(void)get_gfn_query_unlocked(current->domain, gpa >> PAGE_SHIFT, &p2mt);
x86/HVM: use available linear->phys translations in REP MOVS/STOS handling
If we have the translation result available already, we should also use
is here. In my tests with Linux guests this eliminates all calls to
hvmemul_linear_to_phys() out of the two functions being changed.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1156,6 +1156,7 @@ static int hvmemul_rep_movs(
{
struct hvm_emulate_ctxt *hvmemul_ctxt =
container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+struct hvm_vcpu_io *vio = ¤t->arch.hvm_vcpu.hvm_io;
unsigned long saddr, daddr, bytes;
paddr_t sgpa, dgpa;
uint32_t pfec = PFEC_page_present;
@@ -1178,16 +1179,43 @@ static int hvmemul_rep_movs(
if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
pfec |= PFEC_user_mode;
-rc
[Xen-devel] [PATCH 1/2] x86/HVM: latch linear->phys translation results
... to avoid re-doing the same translation later again (in a retry, for
example). This doesn't help very often according to my testing, but
it's pretty cheap to have, and will be of further use subsequently.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -678,6 +678,19 @@ static struct hvm_mmio_cache *hvmemul_fi
return cache;
}
+static void latch_linear_to_phys(struct hvm_vcpu_io *vio, unsigned long gla,
+ unsigned long gpa, bool_t write)
+{
+if ( vio->mmio_access.gla_valid )
+return;
+
+vio->mmio_gva = gla & PAGE_MASK;
+vio->mmio_gpfn = PFN_DOWN(gpa);
+vio->mmio_access = (struct npfec){ .gla_valid = 1,
+ .read_access = 1,
+ .write_access = write };
+}
+
static int hvmemul_linear_mmio_access(
unsigned long gla, unsigned int size, uint8_t dir, void *buffer,
uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt, bool_t known_gpfn)
@@ -703,6 +716,8 @@ static int hvmemul_linear_mmio_access(
hvmemul_ctxt);
if ( rc != X86EMUL_OKAY )
return rc;
+
+latch_linear_to_phys(vio, gla, gpa, dir == IOREQ_WRITE);
}
for ( ;; )
x86/HVM: latch linear->phys translation results
... to avoid re-doing the same translation later again (in a retry, for
example). This doesn't help very often according to my testing, but
it's pretty cheap to have, and will be of further use subsequently.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -678,6 +678,19 @@ static struct hvm_mmio_cache *hvmemul_fi
return cache;
}
+static void latch_linear_to_phys(struct hvm_vcpu_io *vio, unsigned long gla,
+ unsigned long gpa, bool_t write)
+{
+if ( vio->mmio_access.gla_valid )
+return;
+
+vio->mmio_gva = gla & PAGE_MASK;
+vio->mmio_gpfn = PFN_DOWN(gpa);
+vio->mmio_access = (struct npfec){ .gla_valid = 1,
+ .read_access = 1,
+ .write_access = write };
+}
+
static int hvmemul_linear_mmio_access(
unsigned long gla, unsigned int size, uint8_t dir, void *buffer,
uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt, bool_t known_gpfn)
@@ -703,6 +716,8 @@ static int hvmemul_linear_mmio_access(
hvmemul_ctxt);
if ( rc != X86EMUL_OKAY )
return rc;
+
+latch_linear_to_phys(vio, gla, gpa, dir == IOREQ_WRITE);
}
for ( ;; )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] Questions about virtlogd
On Wed, Jun 08, 2016 at 02:05:10PM +0100, George Dunlap wrote: > On 08/06/16 13:46, Wei Liu wrote: > > On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote: > >> On 6/8/16 6:57 AM, George Dunlap wrote: > >>> On 08/06/16 11:07, Daniel P. Berrange wrote: > On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote: > > On 07/06/16 16:57, Wei Liu wrote: > >>> I must admit I'm not familiar with the division of responsibility > >>> for managing QEMU between the Xen provided libxl library(s) and > >>> the libvirt libxl driver code. Naively I would expect the libvirt > >>> libxl driver code to deal with virtlogd and then configure the > >>> Xen libxl library / QEMU accordingly. Your request seems to imply > >>> that you will need the Xen libxl library to directly talk to > >>> virtlogd instead. > >>> > >>> Is there any way in which it would be practical for the libvirt > >>> libxl driver to talk to virtlogd to acquire the file descriptors > >>> to use and pass those file descriptors down to the libxl library ? > >>> > >> > >> There are two classes of configurations. > >> > >> For libvirt + libxl, There is currently no API for passing in a fd to > >> be > >> used as QEMU logging fd. But I'm thinking about having one. It wouldn't > >> be too hard. > >> > >> The other class is configurations that don't have libvirt. We need > >> some > >> sort of mechanism to handle QEMU logs. My intent of this email is > >> mainly > >> for this class of configurations. > > > > Just to be clear -- internally we're investigating options for dealing > > with the "qemu logging" problem* for XenProject for people not running > > libvirt -- people who use the xl toolstack, or people who build their > > own toolstack on top of libxl. > > > > (We *also* need to figure out how to deal with the libxl+libvirt > > situation, but that's just a matter of plumbing I think.) > > > > The options we've come up with, broadly, are as follows: > > > > 1. Try to use the existing syslog facilities > > > > 2. Re-purpose one of our existing daemons to perform a role similar to > > virtlogd > > > > 3. "Steal" virtlogd and import it into our tree (yay GPL!) > > > > 4. Work with the libvirt community to make virtlogd an independent > > project which can be used by both libvirt and libxl directly > > For completeness I'd also suggest > > 5. Declare it out of scope for xl toolstack to solve the whole > problem. Merely provide the minimal hooks to enable the layer > above libxl to solve it. This is effectively QEMU's approach. > > Of course, this would mean that any non-libvirt layer using libxl > stil faces the same problem you're facing, so I understand if thats > not desirable from your POV. > >>> > >>> [Removing libvirt-list] > >>> > >>> Well we definitely want to make it possible for people to use xl while > >>> still avoiding DoSes. But at the simplest level this could be done by > >>> having qemu's stderr/stdout piped to /dev/null by default, and allowing > >>> an option for the admin to enable piping it to a file on a per-guest > >>> basis when necessary. > >>> > >>> This would effectively be declaring a "proper solution" out-of-scope, > >>> while not opening up our users to security issues. > >>> > >>> -George > >>> > >> > >> I'm in favor of an approach like this that declares it out of scope. In > >> a world of finite resources Xen has to focus on what its strengths are > >> in the virtualization space and being the best possible solution for the > >> use cases where its strengths can shine. This requires some tough > >> choices and acknowledging that being the complete vertical stack and > >> legitimately competing against a number of other pieces that build the > >> stack for other hypervisor solutions is just not a situation that will > >> allow Xen to shine. > >> > > > > I'm more than happy to make this someone else's problem. :-) > > > >> You mentioned it earlier in the thread and we've talked about this > >> before but libxl should be enhanced to allow everything it needs to be > >> passed in as an fd and let the actual toolstack (be it xl or libvirt or > >> something else) do the actual open() and supply the fd. > >> > > > > Yeah, I do want to have something like this -- that is regardless of > > whatever we end up with the conclusion of the internal machinery for > > QEMU logging (declare it out of scope, use virtlogd, use xenconsoled etc > > etc). But I haven't had a clear idea how the interface should look like. > > > > My original plan is that if someone provides an fd via the new > > interface, libxl would use that; if not, libxl would use whatever thing > > we have for logging. This way is a bit nicer for setup that doesn't use > > the new API -- the output will still be ava
[Xen-devel] [xen-4.4-testing test] 95373: regressions - trouble: blocked/broken/fail/pass
flight 95373 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95373/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken REGR. vs. 95234 test-armhf-armhf-xl-multivcpu 16 guest-start.2fail REGR. vs. 95234 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 build-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-rumpuserxen 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail 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-libvirt 11 guest-start fail 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-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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen
Re: [Xen-devel] [libvirt] Questions about virtlogd
On 08/06/16 13:46, Wei Liu wrote: > On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote: >> On 6/8/16 6:57 AM, George Dunlap wrote: >>> On 08/06/16 11:07, Daniel P. Berrange wrote: On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote: > On 07/06/16 16:57, Wei Liu wrote: >>> I must admit I'm not familiar with the division of responsibility >>> for managing QEMU between the Xen provided libxl library(s) and >>> the libvirt libxl driver code. Naively I would expect the libvirt >>> libxl driver code to deal with virtlogd and then configure the >>> Xen libxl library / QEMU accordingly. Your request seems to imply >>> that you will need the Xen libxl library to directly talk to >>> virtlogd instead. >>> >>> Is there any way in which it would be practical for the libvirt >>> libxl driver to talk to virtlogd to acquire the file descriptors >>> to use and pass those file descriptors down to the libxl library ? >>> >> >> There are two classes of configurations. >> >> For libvirt + libxl, There is currently no API for passing in a fd to be >> used as QEMU logging fd. But I'm thinking about having one. It wouldn't >> be too hard. >> >> The other class is configurations that don't have libvirt. We need some >> sort of mechanism to handle QEMU logs. My intent of this email is mainly >> for this class of configurations. > > Just to be clear -- internally we're investigating options for dealing > with the "qemu logging" problem* for XenProject for people not running > libvirt -- people who use the xl toolstack, or people who build their > own toolstack on top of libxl. > > (We *also* need to figure out how to deal with the libxl+libvirt > situation, but that's just a matter of plumbing I think.) > > The options we've come up with, broadly, are as follows: > > 1. Try to use the existing syslog facilities > > 2. Re-purpose one of our existing daemons to perform a role similar to > virtlogd > > 3. "Steal" virtlogd and import it into our tree (yay GPL!) > > 4. Work with the libvirt community to make virtlogd an independent > project which can be used by both libvirt and libxl directly For completeness I'd also suggest 5. Declare it out of scope for xl toolstack to solve the whole problem. Merely provide the minimal hooks to enable the layer above libxl to solve it. This is effectively QEMU's approach. Of course, this would mean that any non-libvirt layer using libxl stil faces the same problem you're facing, so I understand if thats not desirable from your POV. >>> >>> [Removing libvirt-list] >>> >>> Well we definitely want to make it possible for people to use xl while >>> still avoiding DoSes. But at the simplest level this could be done by >>> having qemu's stderr/stdout piped to /dev/null by default, and allowing >>> an option for the admin to enable piping it to a file on a per-guest >>> basis when necessary. >>> >>> This would effectively be declaring a "proper solution" out-of-scope, >>> while not opening up our users to security issues. >>> >>> -George >>> >> >> I'm in favor of an approach like this that declares it out of scope. In >> a world of finite resources Xen has to focus on what its strengths are >> in the virtualization space and being the best possible solution for the >> use cases where its strengths can shine. This requires some tough >> choices and acknowledging that being the complete vertical stack and >> legitimately competing against a number of other pieces that build the >> stack for other hypervisor solutions is just not a situation that will >> allow Xen to shine. >> > > I'm more than happy to make this someone else's problem. :-) > >> You mentioned it earlier in the thread and we've talked about this >> before but libxl should be enhanced to allow everything it needs to be >> passed in as an fd and let the actual toolstack (be it xl or libvirt or >> something else) do the actual open() and supply the fd. >> > > Yeah, I do want to have something like this -- that is regardless of > whatever we end up with the conclusion of the internal machinery for > QEMU logging (declare it out of scope, use virtlogd, use xenconsoled etc > etc). But I haven't had a clear idea how the interface should look like. > > My original plan is that if someone provides an fd via the new > interface, libxl would use that; if not, libxl would use whatever thing > we have for logging. This way is a bit nicer for setup that doesn't use > the new API -- the output will still be available somewhere. > > But since there are many different opinions on this matter, while I > don't really care which one ends up "winning", I will just implement the > new API, redirect logging to /dev/null by default, and let other people > worry about the rest. If the libxl API is thought
[Xen-devel] [PATCH 0/2] x86/HVM: avoid full linear->phys translations more frequently
1: latch linear->phys translation results 2: use available linear->phys translations in REP MOVS/STOS handling Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Project Developer Summit : program Published
We recently announced the program and speakers [1] for our Xen Project Developer Summit [2] happening in Toronto, Canada from August 25-26, 2016. The event will be co-located with LinuxCon North America [3]. The Xen Project hypervisor powers the new needs of computing and virtualization through a rich ecosystem of community members that focus on everything from security, embedded, and web-scale environments. The Summit is an opportunity for developers and software engineers to collaborate and discuss the latest advancements of Xen Project software, and better understand what’s next for Xen Project technology, virtualization and cloud computing. In addition to presentations, we will be running a half-day hackathon alongside the Summit on the last day. Xen Project hackathons have evolved in format into a series of structured problem-solving sessions that scale up to 50 people. This flagship event features presentations on the latest developments, best practices, collaboration, product roadmap updates and future planning from developers and users who are leading the way in server density, hardware, automotive, cloud and enterprise security. To view the full schedule and register, please head here: http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule This event is being sponsored by Citrix (Diamond sponsor), Huawei (Platinum sponsor) and Intel (Platinum sponsor). Please be sure to follow updates on the event via Xen Project’s Twitter, Google+ or Facebook page. Hashtag for the event is #xendevsummit. We look forward to seeing you there! [1] http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule [2] http://events.linuxfoundation.org/events/xen-project-developer-summit [3] http://events.linuxfoundation.org/events/linuxcon-north-america ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] Questions about virtlogd
On 08/06/16 13:11, Daniel P. Berrange wrote: > On Wed, Jun 08, 2016 at 11:57:45AM +0100, George Dunlap wrote: >> >> Well we definitely want to make it possible for people to use xl while >> still avoiding DoSes. But at the simplest level this could be done by >> having qemu's stderr/stdout piped to /dev/null by default, and allowing >> an option for the admin to enable piping it to a file on a per-guest >> basis when necessary. >> >> This would effectively be declaring a "proper solution" out-of-scope, >> while not opening up our users to security issues. > > I hadn't thought of /dev/null as an option, that's a nice idea. > > > BTW, I want to raise another item as more general food for thought > which is somewhat related to this topic, albeit not useful as an > solution to use today. > > If you consider the risk to be a compromised QEMU inflicting DoS > on the host filesystem, then the stderr/out logging and serial > port file writing is not the only attack vector. If you give QEMU > any kind of file based disk, then (unless you have quotas in place) > it can expand those disk files to arbitrary size - this is by design > of course, since QEMU needs to save snapshots inside qcow2, and has > the ability to resize virtual disks, etc. > > At the same time, it would be nice to be able to have a possibility > too have a locked down solution. Conceptually it would be nice to be > able to place size limits on individual files that were open. It turns > out Linux introduced just such a facility under the concept "file sealing" > > The motivation for this was kDBus which wanted a way to share tmpfs backed > file handles between processes with certain policy rules. This concept was > implemented using a new fcntl() call F_ADD_SEAL which allows a number of > flags to be set against a file descriptor: > > - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced > in size. This affects ftruncate() and open(O_TRUNC). > - GROW: If SEAL_GROW is set, the file in question cannot be increased > in size. This affects ftruncate(), fallocate() and write(). > - WRITE: If SEAL_WRITE is set, no write operations (besides resizing) >are possible. This affects fallocate(PUNCH_HOLE), mmap() and >write(). > - SEAL: If SEAL_SEAL is set, no further seals can be added to a file. > This basically prevents the F_ADD_SEAL operation on a file and > can be set to prevent others from adding further seals that you > don't want. > > The SEAL_GROW flag seems like exactly the kind of thing QEMU could make > use of. First of all we would have to assume that the QEMU disk image > is fully pre-allocated, ie a non-sparse raw file, or a qcow2 file which > has had its extents fully allocated. This is not unreasonable for many > usage scenarios. I could imagine -drive gaining a new parameter > 'growable=yes|no'. eg > > $QEMU -drive file=/some/image/vm.qcow2,growable=no > > would cause QEMU to set SEAL_GROW when it open the disk image. After > that point it is not possible for a compromised QEMU to cause further > disk allocation on the /some/image filesystem. This of course relies > on SELinux/AppArmour/other-MAC to prevent QEMU opening/creating other > arbitrary files. > > Hotplug is not so simple though. At the time we hotplug the disk we > have to assume QEMU is already hostile, so we can't really rely on > QEMU to honour the request to set SEAL_GROW. To deal with this we > would have to deny QEMU any "open" permission using MAC. Instead > libvirt (or equiv) would have to be responsible for opening disk > images, setting SEAL_GROW and passing the file descriptor onto the > running QEMU to use. > > This all feels remarkably simple and useful, with one huge glaring > issue > > the kernel only implemented support for F_ADD_SEAL on the tmpfs > filesystem, since that's all kDBus needs it for :-) To be useful for > QEMU/libxl/libvirt/etc we'd at least need it supported on ext4 and xfs, > and preferrably NFS too. I've no clue how hard this would be since I'm > not at all familiar with the kernel code. > > So clearly this isn't something we can use at time in the forseeable > future, but if people are interested in attacking the more general > problem, it might be an approach worth investigating to see if it > really is viable for the future. > > How it would relate to the bug we're talking about here, is that I > could imagine pre-allocating the logfile at say 128 KB in size, opening > it, setting the SEAL_GROW flag and then attaching it to QEMU stdout/err. > This would let QEMU write straight to the file as normal, but not let > it exceed 128 KB. Interesting -- I had actually been thinking that if there were something along these lines it would be quite useful. :-) I was actually pondering whether in the qemu case it would be possible to add this kind of limit to logging / serial output files, but having the kernel do it is as you s
[Xen-devel] [PATCH 4/4] x86/vMSI-X: use generic intercept handler in place of MMIO one
This allows us to see the full ioreq without having to peek into state
which is supposedly private to the emulation framework.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -199,9 +199,8 @@ static struct msi_desc *msixtbl_addr_to_
return NULL;
}
-static int msixtbl_read(
-struct vcpu *v, unsigned long address,
-unsigned int len, unsigned long *pval)
+static int msixtbl_read(const struct hvm_io_handler *handler,
+uint64_t address, uint32_t len, uint64_t *pval)
{
unsigned long offset;
struct msixtbl_entry *entry;
@@ -213,7 +212,7 @@ static int msixtbl_read(
rcu_read_lock(&msixtbl_rcu_lock);
-entry = msixtbl_find_entry(v, address);
+entry = msixtbl_find_entry(current, address);
if ( !entry )
goto out;
offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
@@ -333,23 +332,29 @@ out:
return r;
}
-static int msixtbl_range(struct vcpu *v, unsigned long addr)
+static int _msixtbl_write(const struct hvm_io_handler *handler,
+ uint64_t address, uint32_t len, uint64_t val)
{
+return msixtbl_write(current, address, len, val);
+}
+
+static bool_t msixtbl_range(const struct hvm_io_handler *handler,
+const ioreq_t *r)
+{
+struct vcpu *curr = current;
+unsigned long addr = r->addr;
const struct msi_desc *desc;
-const ioreq_t *r;
+
+ASSERT(r->type == IOREQ_TYPE_COPY);
rcu_read_lock(&msixtbl_rcu_lock);
-desc = msixtbl_addr_to_desc(msixtbl_find_entry(v, addr), addr);
+desc = msixtbl_addr_to_desc(msixtbl_find_entry(curr, addr), addr);
rcu_read_unlock(&msixtbl_rcu_lock);
if ( desc )
return 1;
-r = &v->arch.hvm_vcpu.hvm_io.io_req;
-if ( r->state != STATE_IOREQ_READY || r->addr != addr )
-return 0;
-ASSERT(r->type == IOREQ_TYPE_COPY);
-if ( r->dir == IOREQ_WRITE )
+if ( r->state == STATE_IOREQ_READY && r->dir == IOREQ_WRITE )
{
unsigned int size = r->size;
@@ -368,8 +373,8 @@ static int msixtbl_range(struct vcpu *v,
PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET) &&
!(data & PCI_MSIX_VECTOR_BITMASK) )
{
-v->arch.hvm_vcpu.hvm_io.msix_snoop_address = addr;
-v->arch.hvm_vcpu.hvm_io.msix_snoop_gpa = 0;
+curr->arch.hvm_vcpu.hvm_io.msix_snoop_address = addr;
+curr->arch.hvm_vcpu.hvm_io.msix_snoop_gpa = 0;
}
}
else if ( (size == 4 || size == 8) &&
@@ -386,9 +391,9 @@ static int msixtbl_range(struct vcpu *v,
BUILD_BUG_ON((PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET + 4) &
(PCI_MSIX_ENTRY_SIZE - 1));
-v->arch.hvm_vcpu.hvm_io.msix_snoop_address =
+curr->arch.hvm_vcpu.hvm_io.msix_snoop_address =
addr + size * r->count - 4;
-v->arch.hvm_vcpu.hvm_io.msix_snoop_gpa =
+curr->arch.hvm_vcpu.hvm_io.msix_snoop_gpa =
r->data + size * r->count - 4;
}
}
@@ -396,10 +401,10 @@ static int msixtbl_range(struct vcpu *v,
return 0;
}
-static const struct hvm_mmio_ops msixtbl_mmio_ops = {
-.check = msixtbl_range,
+static const struct hvm_io_ops msixtbl_mmio_ops = {
+.accept = msixtbl_range,
.read = msixtbl_read,
-.write = msixtbl_write
+.write = _msixtbl_write
};
static void add_msixtbl_entry(struct domain *d,
@@ -544,13 +549,20 @@ found:
void msixtbl_init(struct domain *d)
{
+struct hvm_io_handler *handler;
+
if ( !has_hvm_container_domain(d) || !has_vlapic(d) ||
d->arch.hvm_domain.msixtbl_list.next )
return;
INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
-register_mmio_handler(d, &msixtbl_mmio_ops);
+handler = hvm_next_io_handler(d);
+if ( handler )
+{
+handler->type = IOREQ_TYPE_COPY;
+handler->ops = &msixtbl_mmio_ops;
+}
}
void msixtbl_pt_cleanup(struct domain *d)
x86/vMSI-X: use generic intercept handler in place of MMIO one
This allows us to see the full ioreq without having to peek into state
which is supposedly private to the emulation framework.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -199,9 +199,8 @@ static struct msi_desc *msixtbl_addr_to_
return NULL;
}
-static int msixtbl_read(
-struct vcpu *v, unsigned long address,
-unsigned int len, unsigned long *pval)
+static int msixtbl_read(const struct hvm_io_handler *handler,
+uint64_t address, uint32_t len, uint64_t *pval)
{
unsigned long offset;
struct msixtbl_entry *entry;
@@ -213,7 +212,7 @@ static int msixtbl_read(
rcu_read_lock(&msixtbl_rcu_lock);
-entry = msixtbl_find_entry(v, address);
+entry = msixtbl_find_entry(current, address);
if ( !entry )
got
[Xen-devel] [PATCH 3/4] x86/vMSI-X: drop pci_msix_get_table_len()
We can calculate the needed value at the single use site more easily.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -411,7 +411,7 @@ static void add_msixtbl_entry(struct dom
INIT_RCU_HEAD(&entry->rcu);
atomic_set(&entry->refcnt, 0);
-entry->table_len = pci_msix_get_table_len(pdev);
+entry->table_len = pdev->msix->nr_entries * PCI_MSIX_ENTRY_SIZE;
entry->pdev = pdev;
entry->gtable = (unsigned long) gtable;
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1463,27 +1463,6 @@ int pci_restore_msi_state(struct pci_dev
return 0;
}
-unsigned int pci_msix_get_table_len(struct pci_dev *pdev)
-{
-int pos;
-u16 control, seg = pdev->seg;
-u8 bus, slot, func;
-unsigned int len;
-
-bus = pdev->bus;
-slot = PCI_SLOT(pdev->devfn);
-func = PCI_FUNC(pdev->devfn);
-
-pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
-if ( !pos || !use_msi )
-return 0;
-
-control = pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos));
-len = msix_table_size(control) * PCI_MSIX_ENTRY_SIZE;
-
-return len;
-}
-
static int msi_cpu_callback(
struct notifier_block *nfb, unsigned long action, void *hcpu)
{
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -91,8 +91,6 @@ extern void teardown_msi_irq(int irq);
extern int msi_free_vector(struct msi_desc *entry);
extern int pci_restore_msi_state(struct pci_dev *pdev);
-extern unsigned int pci_msix_get_table_len(struct pci_dev *pdev);
-
struct msi_desc {
struct msi_attrib {
__u8type; /* {0: unused, 5h:MSI, 11h:MSI-X} */
x86/vMSI-X: drop pci_msix_get_table_len()
We can calculate the needed value at the single use site more easily.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -411,7 +411,7 @@ static void add_msixtbl_entry(struct dom
INIT_RCU_HEAD(&entry->rcu);
atomic_set(&entry->refcnt, 0);
-entry->table_len = pci_msix_get_table_len(pdev);
+entry->table_len = pdev->msix->nr_entries * PCI_MSIX_ENTRY_SIZE;
entry->pdev = pdev;
entry->gtable = (unsigned long) gtable;
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1463,27 +1463,6 @@ int pci_restore_msi_state(struct pci_dev
return 0;
}
-unsigned int pci_msix_get_table_len(struct pci_dev *pdev)
-{
-int pos;
-u16 control, seg = pdev->seg;
-u8 bus, slot, func;
-unsigned int len;
-
-bus = pdev->bus;
-slot = PCI_SLOT(pdev->devfn);
-func = PCI_FUNC(pdev->devfn);
-
-pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
-if ( !pos || !use_msi )
-return 0;
-
-control = pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos));
-len = msix_table_size(control) * PCI_MSIX_ENTRY_SIZE;
-
-return len;
-}
-
static int msi_cpu_callback(
struct notifier_block *nfb, unsigned long action, void *hcpu)
{
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -91,8 +91,6 @@ extern void teardown_msi_irq(int irq);
extern int msi_free_vector(struct msi_desc *entry);
extern int pci_restore_msi_state(struct pci_dev *pdev);
-extern unsigned int pci_msix_get_table_len(struct pci_dev *pdev);
-
struct msi_desc {
struct msi_attrib {
__u8type; /* {0: unused, 5h:MSI, 11h:MSI-X} */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] x86/vMSI-X: drop list lock
msixtbl_pt_{,un}register() already run with both the PCI devices lock
and the domain event lock held, so there's no need for another lock.
Just to be on the safe side, acquire the domain event lock in the
cleanup function (albeit I don't think this is strictly necessary).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -468,8 +468,6 @@ int msixtbl_pt_register(struct domain *d
pdev = msi_desc->dev;
-spin_lock(&d->arch.hvm_domain.msixtbl_list_lock);
-
list_for_each_entry( entry, &d->arch.hvm_domain.msixtbl_list, list )
if ( pdev == entry->pdev )
goto found;
@@ -480,7 +478,6 @@ int msixtbl_pt_register(struct domain *d
found:
atomic_inc(&entry->refcnt);
-spin_unlock(&d->arch.hvm_domain.msixtbl_list_lock);
r = 0;
out:
@@ -530,15 +527,10 @@ void msixtbl_pt_unregister(struct domain
pdev = msi_desc->dev;
-spin_lock(&d->arch.hvm_domain.msixtbl_list_lock);
-
list_for_each_entry( entry, &d->arch.hvm_domain.msixtbl_list, list )
if ( pdev == entry->pdev )
goto found;
-spin_unlock(&d->arch.hvm_domain.msixtbl_list_lock);
-
-
out:
spin_unlock_irq(&irq_desc->lock);
return;
@@ -547,7 +539,6 @@ found:
if ( !atomic_dec_and_test(&entry->refcnt) )
del_msixtbl_entry(entry);
-spin_unlock(&d->arch.hvm_domain.msixtbl_list_lock);
spin_unlock_irq(&irq_desc->lock);
}
@@ -558,7 +549,6 @@ void msixtbl_init(struct domain *d)
return;
INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
-spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
register_mmio_handler(d, &msixtbl_mmio_ops);
}
@@ -566,21 +556,17 @@ void msixtbl_init(struct domain *d)
void msixtbl_pt_cleanup(struct domain *d)
{
struct msixtbl_entry *entry, *temp;
-unsigned long flags;
if ( !d->arch.hvm_domain.msixtbl_list.next )
return;
-/* msixtbl_list_lock must be acquired with irq_disabled for check_lock() */
-local_irq_save(flags);
-spin_lock(&d->arch.hvm_domain.msixtbl_list_lock);
+spin_lock(&d->event_lock);
list_for_each_entry_safe( entry, temp,
&d->arch.hvm_domain.msixtbl_list, list )
del_msixtbl_entry(entry);
-spin_unlock(&d->arch.hvm_domain.msixtbl_list_lock);
-local_irq_restore(flags);
+spin_unlock(&d->event_lock);
}
void msix_write_completion(struct vcpu *v)
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -124,7 +124,6 @@ struct hvm_domain {
/* hypervisor intercepted msix table */
struct list_head msixtbl_list;
-spinlock_t msixtbl_list_lock;
struct viridian_domain viridian;
x86/vMSI-X: drop list lock
msixtbl_pt_{,un}register() already run with both the PCI devices lock
and the domain event lock held, so there's no need for another lock.
Just to be on the safe side, acquire the domain event lock in the
cleanup function (albeit I don't think this is strictly necessary).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -468,8 +468,6 @@ int msixtbl_pt_register(struct domain *d
pdev = msi_desc->dev;
-spin_lock(&d->arch.hvm_domain.msixtbl_list_lock);
-
list_for_each_entry( entry, &d->arch.hvm_domain.msixtbl_list, list )
if ( pdev == entry->pdev )
goto found;
@@ -480,7 +478,6 @@ int msixtbl_pt_register(struct domain *d
found:
atomic_inc(&entry->refcnt);
-spin_unlock(&d->arch.hvm_domain.msixtbl_list_lock);
r = 0;
out:
@@ -530,15 +527,10 @@ void msixtbl_pt_unregister(struct domain
pdev = msi_desc->dev;
-spin_lock(&d->arch.hvm_domain.msixtbl_list_lock);
-
list_for_each_entry( entry, &d->arch.hvm_domain.msixtbl_list, list )
if ( pdev == entry->pdev )
goto found;
-spin_unlock(&d->arch.hvm_domain.msixtbl_list_lock);
-
-
out:
spin_unlock_irq(&irq_desc->lock);
return;
@@ -547,7 +539,6 @@ found:
if ( !atomic_dec_and_test(&entry->refcnt) )
del_msixtbl_entry(entry);
-spin_unlock(&d->arch.hvm_domain.msixtbl_list_lock);
spin_unlock_irq(&irq_desc->lock);
}
@@ -558,7 +549,6 @@ void msixtbl_init(struct domain *d)
return;
INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
-spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
register_mmio_handler(d, &msixtbl_mmio_ops);
}
@@ -566,21 +556,17 @@ void msixtbl_init(struct domain *d)
void msixtbl_pt_cleanup(struct domain *d)
{
struct msixtbl_entry *entry, *temp;
-unsigned long flags;
if ( !d->arch.hvm_domain.msixtbl_list.next )
return;
-/* msixtbl_list_lock must be acquired with irq_disabled for check_lock() */
-local_irq_save(flags);
-spin_lock(&d->arch.hvm_domain.msixtbl_list_lock);
+spin_lock(&d->event_lock);
list_for_each_entry_safe( entry, temp,
&d-
[Xen-devel] [PATCH 1/4] x86/vMSI-X: defer intercept handler registration
There's no point in registering the internal MSI-X table intercept
functions on all domains - it is sufficient to do so once a domain gets
an MSI-X capable device assigned.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -644,8 +644,6 @@ int hvm_domain_initialise(struct domain
rtc_init(d);
-msixtbl_init(d);
-
register_portio_handler(d, 0xe9, 1, hvm_print_line);
if ( hvm_tsc_scaling_supported )
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -553,7 +553,8 @@ found:
void msixtbl_init(struct domain *d)
{
-if ( !has_vlapic(d) )
+if ( !has_hvm_container_domain(d) || !has_vlapic(d) ||
+ d->arch.hvm_domain.msixtbl_list.next )
return;
INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
@@ -567,7 +568,7 @@ void msixtbl_pt_cleanup(struct domain *d
struct msixtbl_entry *entry, *temp;
unsigned long flags;
-if ( !has_vlapic(d) )
+if ( !d->arch.hvm_domain.msixtbl_list.next )
return;
/* msixtbl_list_lock must be acquired with irq_disabled for check_lock() */
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1380,6 +1380,9 @@ static int assign_device(struct domain *
goto done;
}
+if ( pdev->msix )
+msixtbl_init(d);
+
pdev->fault.count = 0;
if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev),
flag)) )
x86/vMSI-X: defer intercept handler registration
There's no point in registering the internal MSI-X table intercept
functions on all domains - it is sufficient to do so once a domain gets
an MSI-X capable device assigned.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -644,8 +644,6 @@ int hvm_domain_initialise(struct domain
rtc_init(d);
-msixtbl_init(d);
-
register_portio_handler(d, 0xe9, 1, hvm_print_line);
if ( hvm_tsc_scaling_supported )
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -553,7 +553,8 @@ found:
void msixtbl_init(struct domain *d)
{
-if ( !has_vlapic(d) )
+if ( !has_hvm_container_domain(d) || !has_vlapic(d) ||
+ d->arch.hvm_domain.msixtbl_list.next )
return;
INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
@@ -567,7 +568,7 @@ void msixtbl_pt_cleanup(struct domain *d
struct msixtbl_entry *entry, *temp;
unsigned long flags;
-if ( !has_vlapic(d) )
+if ( !d->arch.hvm_domain.msixtbl_list.next )
return;
/* msixtbl_list_lock must be acquired with irq_disabled for check_lock() */
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1380,6 +1380,9 @@ static int assign_device(struct domain *
goto done;
}
+if ( pdev->msix )
+msixtbl_init(d);
+
pdev->fault.count = 0;
if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev),
flag)) )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/XSTATE: clarify XRSTOR() macro
Make obvious that xcomp_bv is expected to be clear when we get here
with XSTATE_COMPACTION_ENABLED not set.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -387,8 +387,11 @@ void xrstor(struct vcpu *v, uint64_t mas
{ \
if ( unlikely(!(ptr->xsave_hdr.xcomp_bv & \
XSTATE_COMPACTION_ENABLED)) ) \
-ptr->xsave_hdr.xcomp_bv |= ptr->xsave_hdr.xstate_bv | \
- XSTATE_COMPACTION_ENABLED; \
+{ \
+ASSERT(!ptr->xsave_hdr.xcomp_bv); \
+ptr->xsave_hdr.xcomp_bv = ptr->xsave_hdr.xstate_bv | \
+ XSTATE_COMPACTION_ENABLED; \
+} \
_xrstor(pfx "0x0f,0xc7,0x1f"); /* xrstors */ \
} \
else \
x86/XSTATE: clarify XRSTOR() macro
Make obvious that xcomp_bv is expected to be clear when we get here
with XSTATE_COMPACTION_ENABLED not set.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -387,8 +387,11 @@ void xrstor(struct vcpu *v, uint64_t mas
{ \
if ( unlikely(!(ptr->xsave_hdr.xcomp_bv & \
XSTATE_COMPACTION_ENABLED)) ) \
-ptr->xsave_hdr.xcomp_bv |= ptr->xsave_hdr.xstate_bv | \
- XSTATE_COMPACTION_ENABLED; \
+{ \
+ASSERT(!ptr->xsave_hdr.xcomp_bv); \
+ptr->xsave_hdr.xcomp_bv = ptr->xsave_hdr.xstate_bv | \
+ XSTATE_COMPACTION_ENABLED; \
+} \
_xrstor(pfx "0x0f,0xc7,0x1f"); /* xrstors */ \
} \
else \
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/4] x86/vMSI-X: misc improvements
1: defer intercept handler registration 2: drop list lock 3: drop pci_msix_get_table_len() 4: use generic intercept handler in place of MMIO one Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] Questions about virtlogd
On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote: > On 6/8/16 6:57 AM, George Dunlap wrote: > > On 08/06/16 11:07, Daniel P. Berrange wrote: > >> On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote: > >>> On 07/06/16 16:57, Wei Liu wrote: > > I must admit I'm not familiar with the division of responsibility > > for managing QEMU between the Xen provided libxl library(s) and > > the libvirt libxl driver code. Naively I would expect the libvirt > > libxl driver code to deal with virtlogd and then configure the > > Xen libxl library / QEMU accordingly. Your request seems to imply > > that you will need the Xen libxl library to directly talk to > > virtlogd instead. > > > > Is there any way in which it would be practical for the libvirt > > libxl driver to talk to virtlogd to acquire the file descriptors > > to use and pass those file descriptors down to the libxl library ? > > > > There are two classes of configurations. > > For libvirt + libxl, There is currently no API for passing in a fd to be > used as QEMU logging fd. But I'm thinking about having one. It wouldn't > be too hard. > > The other class is configurations that don't have libvirt. We need some > sort of mechanism to handle QEMU logs. My intent of this email is mainly > for this class of configurations. > >>> > >>> Just to be clear -- internally we're investigating options for dealing > >>> with the "qemu logging" problem* for XenProject for people not running > >>> libvirt -- people who use the xl toolstack, or people who build their > >>> own toolstack on top of libxl. > >>> > >>> (We *also* need to figure out how to deal with the libxl+libvirt > >>> situation, but that's just a matter of plumbing I think.) > >>> > >>> The options we've come up with, broadly, are as follows: > >>> > >>> 1. Try to use the existing syslog facilities > >>> > >>> 2. Re-purpose one of our existing daemons to perform a role similar to > >>> virtlogd > >>> > >>> 3. "Steal" virtlogd and import it into our tree (yay GPL!) > >>> > >>> 4. Work with the libvirt community to make virtlogd an independent > >>> project which can be used by both libvirt and libxl directly > >> > >> For completeness I'd also suggest > >> > >> 5. Declare it out of scope for xl toolstack to solve the whole > >>problem. Merely provide the minimal hooks to enable the layer > >>above libxl to solve it. This is effectively QEMU's approach. > >> > >> Of course, this would mean that any non-libvirt layer using libxl > >> stil faces the same problem you're facing, so I understand if thats > >> not desirable from your POV. > > > > [Removing libvirt-list] > > > > Well we definitely want to make it possible for people to use xl while > > still avoiding DoSes. But at the simplest level this could be done by > > having qemu's stderr/stdout piped to /dev/null by default, and allowing > > an option for the admin to enable piping it to a file on a per-guest > > basis when necessary. > > > > This would effectively be declaring a "proper solution" out-of-scope, > > while not opening up our users to security issues. > > > > -George > > > > I'm in favor of an approach like this that declares it out of scope. In > a world of finite resources Xen has to focus on what its strengths are > in the virtualization space and being the best possible solution for the > use cases where its strengths can shine. This requires some tough > choices and acknowledging that being the complete vertical stack and > legitimately competing against a number of other pieces that build the > stack for other hypervisor solutions is just not a situation that will > allow Xen to shine. > I'm more than happy to make this someone else's problem. :-) > You mentioned it earlier in the thread and we've talked about this > before but libxl should be enhanced to allow everything it needs to be > passed in as an fd and let the actual toolstack (be it xl or libvirt or > something else) do the actual open() and supply the fd. > Yeah, I do want to have something like this -- that is regardless of whatever we end up with the conclusion of the internal machinery for QEMU logging (declare it out of scope, use virtlogd, use xenconsoled etc etc). But I haven't had a clear idea how the interface should look like. My original plan is that if someone provides an fd via the new interface, libxl would use that; if not, libxl would use whatever thing we have for logging. This way is a bit nicer for setup that doesn't use the new API -- the output will still be available somewhere. But since there are many different opinions on this matter, while I don't really care which one ends up "winning", I will just implement the new API, redirect logging to /dev/null by default, and let other people worry about the rest. Wei. > -- > Doug Goldstein > ___ Xen-devel mailing list X
[Xen-devel] [xen-unstable-smoke test] 95426: tolerable all pass - PUSHED
flight 95426 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95426/
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 ba98196b54b27262ffe3d3463358eb4cff18b28d
baseline version:
xen 936a7a5483fbdd4ae3d813beff8921e902f43a46
Last test of basis95378 2016-06-07 14:13:36 Z0 days
Testing same since95426 2016-06-08 10:02:31 Z0 days1 attempts
People who touched revisions under test:
Christoph Egger
Haozhong Zhang
Jan Beulich
Jiandi An
Kevin Tian
Stefano Stabellini
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=ba98196b54b27262ffe3d3463358eb4cff18b28d
+ . ./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
ba98196b54b27262ffe3d3463358eb4cff18b28d
+ branch=xen-unstable-smoke
+ revision=ba98196b54b27262ffe3d3463358eb4cff18b28d
+ . ./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.6-testing
+ '[' xba98196b54b27262ffe3d3463358eb4cff18b28d = 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:9
Re: [Xen-devel] [RFC 0/8] xen/arm: acpi: Support SPIs routing
Hello Shanker, On 08/06/16 13:11, Shanker Donthineni wrote: I don't know exactly which of the patch causing the issue. I have noticed a couple of drivers are not receiving SPI interrupts in DOM0. I need to digest your patches before tracing/investigate the problem to get more details. FYI, our system uses both the EDGE and LEVEL interrupts, any major change in your patches? The routing is done when DOM0 is built and the interrupt configuration is deferred. It might be possible to the wrong type is retrieve by __vgic_get_virq_type. I would recommend you to add a print in vgic_enable_irqs to check the value and if p->desc != NULL for those IRQs. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] travis: drop broken LLVM repos
On 6/7/16 12:08 PM, Doug Goldstein wrote: > LLVM repos are currently down so drop them from being installed so we > can get some testing back. Signed-off-by: Doug Goldstein -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] Questions about virtlogd
On Wed, Jun 08, 2016 at 11:07:16AM +0100, Daniel P. Berrange wrote: [...] > > situation, but that's just a matter of plumbing I think.) > > > > The options we've come up with, broadly, are as follows: > > > > 1. Try to use the existing syslog facilities > > > > 2. Re-purpose one of our existing daemons to perform a role similar to > > virtlogd > > > > 3. "Steal" virtlogd and import it into our tree (yay GPL!) > > > > 4. Work with the libvirt community to make virtlogd an independent > > project which can be used by both libvirt and libxl directly > > For completeness I'd also suggest > > 5. Declare it out of scope for xl toolstack to solve the whole >problem. Merely provide the minimal hooks to enable the layer >above libxl to solve it. This is effectively QEMU's approach. > > Of course, this would mean that any non-libvirt layer using libxl > stil faces the same problem you're facing, so I understand if thats > not desirable from your POV. > > > None of the options are really that great. I'm sure you guys explored > > #1 yourselves before deciding to write your own tools, so I won't cover > > its deficiencies. #2 and #3 both involve a lot of duplicate effort and > > duplicate code. > > > > From a global perspective, #4 would seem to make sense, since it allows > > the virtlogd functionality to be more generally used (and potentially > > may be useful in non-virtualization scenarios as well). But it also has > > the cost of working cross-community, maintaining a clean separate > > codebase, &c &c. And we realize for the libvirt project it's extra work > > for no obvious immediate benefit. > > As you say there's not really any pre-existing tools that can easily > fit with the requirements, which is why we ended up creating virtlogd > ourselves - it was either that or OpenStack was going to invent their > own daemon which does what virtlogd does to solve it at the even higher > layer (though they could only fix serial port file based output, not > stderr outout) > > So, we wanted a standard solution that libvirt and all apps using > libvirt could rely up unconditionally. From our existing libvirtd, > and codebase in general, we have alot of infrastructure pieces that > made creating virtlogd a pretty easy task. In particular our formal > RPC protocol and handling code for libvirtd and virtlockd, was > able to serve as the basis for virtlogd with little need for extra > code. > > This in turn means that having virtlogd as a separate project would > be a major undertaking - it relies on so much libvirt infrastructure > code that to make it into a separate project, we'd have to pull out > a huge pile of libvirt internal code and turn it into a more formal > library that could be shared between an external virtlogd and libvirt. > We've never considered any of this code to be API/ABI stable, so don't > really want to go down that route. This would also make your option #3 > a surprisingly large effort - there's a load of libvirt code you would > have to pull into Xen, or alternatively re-write in a Xen friendly > manner. > > Less problematic, though still relevant, is that virtlogd is intended > to align with libvirtd/virtlockd designs, to give a consistent model. > By this I mean the config files are in common locations, the way we > auto-spawn the daemons works the same way - eg we have one libvirtd > running privileged, and one per-user account, and auto-spawn a > corresponding virtlogd for each. FWIW I came to the same conclusion in my own research. So I'm not really keen on #3 and #4. > > > As Wei said, we're still exploring options; even a negative response > > narrows down the search space. :-) > > > > Let us know what you think. > > I don't have a great answer for you I'm afraid, but I don't think > that #4 is really practical from the libvirt POV, due to the issue > with the all the libvirt internal code virtlogd relies upon that > we don't wish to turn into a stable API/ABI. > Understood. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] Questions about virtlogd
On Wed, Jun 08, 2016 at 11:57:45AM +0100, George Dunlap wrote: > > Well we definitely want to make it possible for people to use xl while > still avoiding DoSes. But at the simplest level this could be done by > having qemu's stderr/stdout piped to /dev/null by default, and allowing > an option for the admin to enable piping it to a file on a per-guest > basis when necessary. > > This would effectively be declaring a "proper solution" out-of-scope, > while not opening up our users to security issues. I hadn't thought of /dev/null as an option, that's a nice idea. BTW, I want to raise another item as more general food for thought which is somewhat related to this topic, albeit not useful as an solution to use today. If you consider the risk to be a compromised QEMU inflicting DoS on the host filesystem, then the stderr/out logging and serial port file writing is not the only attack vector. If you give QEMU any kind of file based disk, then (unless you have quotas in place) it can expand those disk files to arbitrary size - this is by design of course, since QEMU needs to save snapshots inside qcow2, and has the ability to resize virtual disks, etc. At the same time, it would be nice to be able to have a possibility too have a locked down solution. Conceptually it would be nice to be able to place size limits on individual files that were open. It turns out Linux introduced just such a facility under the concept "file sealing" The motivation for this was kDBus which wanted a way to share tmpfs backed file handles between processes with certain policy rules. This concept was implemented using a new fcntl() call F_ADD_SEAL which allows a number of flags to be set against a file descriptor: - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced in size. This affects ftruncate() and open(O_TRUNC). - GROW: If SEAL_GROW is set, the file in question cannot be increased in size. This affects ftruncate(), fallocate() and write(). - WRITE: If SEAL_WRITE is set, no write operations (besides resizing) are possible. This affects fallocate(PUNCH_HOLE), mmap() and write(). - SEAL: If SEAL_SEAL is set, no further seals can be added to a file. This basically prevents the F_ADD_SEAL operation on a file and can be set to prevent others from adding further seals that you don't want. The SEAL_GROW flag seems like exactly the kind of thing QEMU could make use of. First of all we would have to assume that the QEMU disk image is fully pre-allocated, ie a non-sparse raw file, or a qcow2 file which has had its extents fully allocated. This is not unreasonable for many usage scenarios. I could imagine -drive gaining a new parameter 'growable=yes|no'. eg $QEMU -drive file=/some/image/vm.qcow2,growable=no would cause QEMU to set SEAL_GROW when it open the disk image. After that point it is not possible for a compromised QEMU to cause further disk allocation on the /some/image filesystem. This of course relies on SELinux/AppArmour/other-MAC to prevent QEMU opening/creating other arbitrary files. Hotplug is not so simple though. At the time we hotplug the disk we have to assume QEMU is already hostile, so we can't really rely on QEMU to honour the request to set SEAL_GROW. To deal with this we would have to deny QEMU any "open" permission using MAC. Instead libvirt (or equiv) would have to be responsible for opening disk images, setting SEAL_GROW and passing the file descriptor onto the running QEMU to use. This all feels remarkably simple and useful, with one huge glaring issue the kernel only implemented support for F_ADD_SEAL on the tmpfs filesystem, since that's all kDBus needs it for :-) To be useful for QEMU/libxl/libvirt/etc we'd at least need it supported on ext4 and xfs, and preferrably NFS too. I've no clue how hard this would be since I'm not at all familiar with the kernel code. So clearly this isn't something we can use at time in the forseeable future, but if people are interested in attacking the more general problem, it might be an approach worth investigating to see if it really is viable for the future. How it would relate to the bug we're talking about here, is that I could imagine pre-allocating the logfile at say 128 KB in size, opening it, setting the SEAL_GROW flag and then attaching it to QEMU stdout/err. This would let QEMU write straight to the file as normal, but not let it exceed 128 KB. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/8] xen/arm: acpi: Support SPIs routing
I don't know exactly which of the patch causing the issue. I have noticed a couple of drivers are not receiving SPI interrupts in DOM0. I need to digest your patches before tracing/investigate the problem to get more details. FYI, our system uses both the EDGE and LEVEL interrupts, any major change in your patches? -- Shanker Donthineni Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda
On Wed, Jun 08, 2016 at 02:04:45PM +0200, Olaf Hering wrote: > On Wed, Jun 08, Wei Liu wrote: > > > I think we should just revert the patch in question and solve this issue > > properly in 4.8. > > What impact does reverting c0c099d have for OVMF? > I dont know myself, just used it the first time now with staging-4.6. OVMF should work as usual. Wei. > > Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda
On Wed, Jun 08, Wei Liu wrote: > I think we should just revert the patch in question and solve this issue > properly in 4.8. What impact does reverting c0c099d have for OVMF? I dont know myself, just used it the first time now with staging-4.6. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] travis: drop broken LLVM repos
>>> On 07.06.16 at 18:08, wrote: > LLVM repos are currently down so drop them from being installed so we > can get some testing back. > --- I was about to commit this, but you didn't provide an S-o-b. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] nested vmx: Intercept guest rdmsr for MSR_IA32_VMX_VMFUNC
On Tue, Jun 07, 2016 at 10:18:38AM +, Euan Harris wrote: > Guest reads of MSR_IA32_VMX_VMFUNC should be handled by > the logic in vmx_msr_read_intercept(). Otherwise a guest > can read the raw host value of this MSR, even if nested > vmx is disabled. > > Signed-off-by: Euan Harris For 4.7: Release-acked-by: Wei Liu > --- > xen/arch/x86/hvm/vmx/vmx.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 743b5a1..6c0721f 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -2624,7 +2624,7 @@ static int vmx_msr_read_intercept(unsigned int msr, > uint64_t *msr_content) > __vmread(GUEST_IA32_DEBUGCTL, msr_content); > break; > case IA32_FEATURE_CONTROL_MSR: > -case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS: > +case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC: > if ( !nvmx_msr_read_intercept(msr, msr_content) ) > goto gp_fault; > break; > -- > 1.7.10.4 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] Questions about virtlogd
On 6/8/16 6:57 AM, George Dunlap wrote: > On 08/06/16 11:07, Daniel P. Berrange wrote: >> On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote: >>> On 07/06/16 16:57, Wei Liu wrote: > I must admit I'm not familiar with the division of responsibility > for managing QEMU between the Xen provided libxl library(s) and > the libvirt libxl driver code. Naively I would expect the libvirt > libxl driver code to deal with virtlogd and then configure the > Xen libxl library / QEMU accordingly. Your request seems to imply > that you will need the Xen libxl library to directly talk to > virtlogd instead. > > Is there any way in which it would be practical for the libvirt > libxl driver to talk to virtlogd to acquire the file descriptors > to use and pass those file descriptors down to the libxl library ? > There are two classes of configurations. For libvirt + libxl, There is currently no API for passing in a fd to be used as QEMU logging fd. But I'm thinking about having one. It wouldn't be too hard. The other class is configurations that don't have libvirt. We need some sort of mechanism to handle QEMU logs. My intent of this email is mainly for this class of configurations. >>> >>> Just to be clear -- internally we're investigating options for dealing >>> with the "qemu logging" problem* for XenProject for people not running >>> libvirt -- people who use the xl toolstack, or people who build their >>> own toolstack on top of libxl. >>> >>> (We *also* need to figure out how to deal with the libxl+libvirt >>> situation, but that's just a matter of plumbing I think.) >>> >>> The options we've come up with, broadly, are as follows: >>> >>> 1. Try to use the existing syslog facilities >>> >>> 2. Re-purpose one of our existing daemons to perform a role similar to >>> virtlogd >>> >>> 3. "Steal" virtlogd and import it into our tree (yay GPL!) >>> >>> 4. Work with the libvirt community to make virtlogd an independent >>> project which can be used by both libvirt and libxl directly >> >> For completeness I'd also suggest >> >> 5. Declare it out of scope for xl toolstack to solve the whole >>problem. Merely provide the minimal hooks to enable the layer >>above libxl to solve it. This is effectively QEMU's approach. >> >> Of course, this would mean that any non-libvirt layer using libxl >> stil faces the same problem you're facing, so I understand if thats >> not desirable from your POV. > > [Removing libvirt-list] > > Well we definitely want to make it possible for people to use xl while > still avoiding DoSes. But at the simplest level this could be done by > having qemu's stderr/stdout piped to /dev/null by default, and allowing > an option for the admin to enable piping it to a file on a per-guest > basis when necessary. > > This would effectively be declaring a "proper solution" out-of-scope, > while not opening up our users to security issues. > > -George > I'm in favor of an approach like this that declares it out of scope. In a world of finite resources Xen has to focus on what its strengths are in the virtualization space and being the best possible solution for the use cases where its strengths can shine. This requires some tough choices and acknowledging that being the complete vertical stack and legitimately competing against a number of other pieces that build the stack for other hypervisor solutions is just not a situation that will allow Xen to shine. You mentioned it earlier in the thread and we've talked about this before but libxl should be enhanced to allow everything it needs to be passed in as an fd and let the actual toolstack (be it xl or libvirt or something else) do the actual open() and supply the fd. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/8] xen/arm: acpi: Support SPIs routing
On 08/06/16 12:48, Shanker Donthineni wrote: Hi Julien, Tested on our hardware, this patchset fixed the deadlock issue but some of the SPIs are not working. Can you give a bit more of details? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/8] xen/arm: acpi: Support SPIs routing
Hi Julien, Tested on our hardware, this patchset fixed the deadlock issue but some of the SPIs are not working. -- Shanker Donthineni Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
