Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

On 16/02/17 08:52, Olaf Hering wrote: > Am Wed, 15 Feb 2017 15:51:12 -0500 > schrieb Konrad Rzeszutek Wilk : >> mkdir /run/xen >> mkdir /run/xenstored > > This must be done by the startup scripts because the "run" directories, > where ever they are, are volatile. > > I

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Wed, 15 Feb 2017 15:51:12 -0500 schrieb Konrad Rzeszutek Wilk : > mkdir /run/xen > mkdir /run/xenstored This must be done by the startup scripts because the "run" directories, where ever they are, are volatile. I think

[Xen-devel] [PATCH] build: add --with-rundir option to configure

There have been reports that Fedora 25 uses /run instead of /var/run. Add a --with-rundir option ito configure to be able to specify that directory. Default is still /var/run. A re-run of autogen.sh is required. Signed-off-by: Juergen Gross --- Backport candidate (at least

[Xen-devel] [xen-unstable test] 105821: tolerable FAIL - PUSHED

flight 105821 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105821/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105804

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

On 15/02/17 22:10, Boris Ostrovsky wrote: > On 02/15/2017 03:51 PM, Konrad Rzeszutek Wilk wrote: >> Hey, >> >> Credit goes to Boris (CC-ed) for figuring out how to fix this. >> >> I was doing: >> >> ./configure --prefix=/usr --enable-systemd >> make -j8 >> cd dist;./install.sh;) >> reboot >> >>

[Xen-devel] (resend) qemu crashes during VCPU hotplug

(Now with correct address for Stefano) Upstream qemu appears to be crashing during VCPU hotplug. I think this is something relatively new since I have been doing this a few week ago. I reproduced this on two different setups. Haven't had a chance to look any further but e3cadac073 looks

[Xen-devel] qemu crashes during VCPU hotplug

Upstream qemu appears to be crashing during VCPU hotplug. I think this is something relatively new since I have been doing this a few week ago. I reproduced on two different setups. Haven't had a chance to look any further but e3cadac073 looks suspicious. The crash happens in

[Xen-devel] [xen-unstable-smoke test] 105836: tolerable trouble: broken/fail/pass - PUSHED

flight 105836 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105836/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5

[Xen-devel] [xtf test] 105823: all pass - PUSHED

flight 105823 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/105823/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 01b0192030c01dc8af02dca6b92d720cf3908b80 baseline version: xtf

[Xen-devel] [xen-4.8-testing test] 105818: tolerable FAIL - PUSHED

flight 105818 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105818/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105662

Re: [Xen-devel] [PATCH 8/8] xen/arm: acpi: Move the ACPI banks in bootinfo

On Fri, 3 Feb 2017, Julien Grall wrote: > Currently the acpi banks are stored in a separate variable and have an > header just for them. > > This variable can be moved in the structure bootinfo removing an header > and a global variable. > > Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH 0/8] xen/arm: Fix and clean-up for ACPI and EFI

On Fri, 3 Feb 2017, Julien Grall wrote: > Hi all, > > This patch series contains a bunch of fix and clean-up for ACPI and EFI on > ARM64. > > Note that the patch "xen/arm64: Don't zero BSS when booting using EFI" [1] is > required in order to test this series. Thanks Julien! I committed patch

Re: [Xen-devel] [PATCH 7/8] xen/arm: efi: Rework acpi_create_efi_mmap_table to avoid memory_map[offset]

On Fri, 3 Feb 2017, Julien Grall wrote: > The code contains a lot of memory_map[offset]. This could be simplified > by incrementing the descriptor pointer every time. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- >

Re: [Xen-devel] [PATCH 6/8] xen/arm: efi: Avoid duplicating the addition of a new efi memory descriptor

On Fri, 3 Feb 2017, Julien Grall wrote: > The code to add a new memory descriptor is duplicated three times. Add a > new helper that adds the descriptor. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- >

Re: [Xen-devel] [PATCH 5/8] xen/arm: efi: Avoid duplicating the addition of a new bank

On Wed, 15 Feb 2017, Stefano Stabellini wrote: > On Fri, 3 Feb 2017, Julien Grall wrote: > > The code to add a new bank is duplicated twice. Add a new helper that > > checks if the maximum of bank has not reached and adds the bank. > > > > Signed-off-by: Julien Grall > >

Re: [Xen-devel] [PATCH 5/8] xen/arm: efi: Avoid duplicating the addition of a new bank

On Fri, 3 Feb 2017, Julien Grall wrote: > The code to add a new bank is duplicated twice. Add a new helper that > checks if the maximum of bank has not reached and adds the bank. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini >

Re: [Xen-devel] [PATCH RFC V2 7/7] COLO-Proxy: Use socket to get checkpoint event.

On 02/16/2017 12:24 AM, Konrad Rzeszutek Wilk wrote: On Wed, Feb 15, 2017 at 05:54:33PM +0800, Zhang Chen wrote: We use kernel colo proxy's way to get the checkpoint event from qemu colo-compare. Qemu colo-compare need add a API to support this(I will add this in qemu). Signed-off-by: Zhang

Re: [Xen-devel] [PATCH 4/8] xen/arm: Print whether Xen is booting using ACPI or DT

On Fri, 3 Feb 2017, Julien Grall wrote: > Make it easier to figure out whether Xen is booting using ACPI or DT by > printing a message on the console. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > xen/arch/arm/setup.c |

Re: [Xen-devel] [PATCH 3/8] xen/arm: acpi: Don't fallback on DT when user request ACPI

On Fri, 3 Feb 2017, Julien Grall wrote: > On ARM, when the user put 'acpi=force' Xen will use ACPI over DT. > Currently, if Xen fails to initialize ACPI it will fallback on DT. > > This behavior makes difficult for a user to notice Xen didn't used ACPI > has requested on platform where the

Re: [Xen-devel] [PATCH 2/8] xen/arm: acpi: Rework acpi_boot_table_init error paths

On Fri, 3 Feb 2017, Julien Grall wrote: > There are multiple path disable ACPI on error. Consolidate in a single > place, this will help in a follow-up patch to add more code on the error > path. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini

[Xen-devel] OVMF blows up at unless I use pci_platform=0

Hey, I just built today Xen based on 93e1435290867703c50acad1f54b9208df473562 Author: Oleksandr Tyshchenko Date: Wed Feb 15 12:20:01 2017 + IOMMU: always call teardown callback And tried this guest which used to work in the past: # more root-image-uefi.xm

Re: [Xen-devel] [PATCH RFC V2 0/7] COLO-Proxy: Make Xen COLO use userspace colo-proxy

On 02/16/2017 12:18 AM, Konrad Rzeszutek Wilk wrote: On Wed, Feb 15, 2017 at 05:54:26PM +0800, Zhang Chen wrote: Because of some reason, We no longer support COLO kernel proxy. So we send this patch set to make Xen use userspace colo-proxy in qemu. How come it is RFC? It looks quite baked?

Re: [Xen-devel] [PATCH 1/8] xen/arm: acpi: Handle correctly detection of GICv2 on GICv3

On Fri, 3 Feb 2017, Julien Grall wrote: > When the GICv3 is not GICv2 compatible, the associated field in the MADT > will be zeroed. However, the rest of the code expects the variable to > be set to INVALID_PADDR. > > This will result to false detection of GICv2 and give I/O access to page > 0

Re: [Xen-devel] [PATCH] xen/arm: Remove build option CONFIG_LOAD_ADDRESS

On Fri, 3 Feb 2017, Julien Grall wrote: > The build option CONFIG_LOAD_ADDRESS is defined but never plumbed > through. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > config/arm32.mk| 2 -- > config/arm64.mk

Re: [Xen-devel] [PATCH] xen/arm: Remove the makefile target xen.axf

On Fri, 3 Feb 2017, Julien Grall wrote: > Since commit 4557c22 "xen: arm: rewrite start of day page table and cpu > bring up", Xen requires to be launched in NS HYP/EL2. > > xen.axf is generated in order to directly boot Xen on ARM models (e.g > Foundation). However they usually start in secure

[Xen-devel] [xen-4.4-testing test] 105815: regressions - FAIL

flight 105815 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105815/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 103812

[Xen-devel] [PATCH] xen/arm: increase default dom0_mem to 512M

The default dom0_mem is 128M which is not sufficient to boot a Ubuntu based Dom0. Increase it to 512M. Signed-off-by: Stefano Stabellini diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index c97a1f5..f4612a2 100644 --- a/xen/arch/arm/domain_build.c

[Xen-devel] [xen-unstable-smoke test] 105830: tolerable trouble: broken/fail/pass - PUSHED

flight 105830 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105830/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5

[Xen-devel] [PATCH] ACPICA: ACPI 6.0: Add support for IORT table.

From: Lv Zheng ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca This patch adds support for IORT (IO Remapping Table) in iasl. Note that some field names are modified to shrink their length or the decompiled IORT ASL will contain fields with ugly ":" alignment. The

Re: [Xen-devel] [RFC QEMU PATCH 1/8] nvdimm: do not initialize label_data if label_size is zero

On Mon, Oct 10, 2016 at 08:34:16AM +0800, Haozhong Zhang wrote: > When memory-backend-xen is used, the label_data pointer can not be got > via memory_region_get_ram_ptr(). We will use other functions to get Could you explain why it cannot be retrieved via that way? > label_data once we introduce

[Xen-devel] [xen-unstable baseline-only test] 68563: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 68563 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68563/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13

[Xen-devel] [xen-4.7-testing test] 105819: regressions - FAIL

flight 105819 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105819/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs.

Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms

On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich wrote: > >>> On 14.02.17 at 19:38, wrote: > > --- a/xen/arch/x86/boot/head.S > > +++ b/xen/arch/x86/boot/head.S > > @@ -394,10 +394,18 @@ __start: > > > > /* EFI IA-32 platforms are not supported. */ > >

[Xen-devel] [PATCH v4 0/2] x86/kvm: Reduce vcpu_is_preempted() overhead

v3->v4: - Fix x86-32 build error. v2->v3: - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted() in assembly as suggested by PeterZ. - Add a new patch to change vcpu_is_preempted() argument type to long to ease the writing of the assembly code. v1->v2: - Rerun the

[Xen-devel] [PATCH v4 1/2] x86/paravirt: Change vcp_is_preempted() arg type to long

The cpu argument in the function prototype of vcpu_is_preempted() is changed from int to long. That makes it easier to provide a better optimized assembly version of that function. For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the downcast from long to int is not a problem as vCPU

[Xen-devel] [PATCH v4 2/2] x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

It was found when running fio sequential write test with a XFS ramdisk on a KVM guest running on a 2-socket x86-64 system, the %CPU times as reported by perf were as follows: 69.75% 0.59% fio [k] down_write 69.15% 0.01% fio [k] call_rwsem_down_write_failed 67.12% 1.12% fio [k]

Re: [Xen-devel] Xen 4.9 Development Update

Hi all, Unfortunately, I have been quite busy over the last few months and did not manage to finish the patch series, yet. I will continue working in the next few weeks, however, it is rather unlikely to make the patch series ready for 4.9. Cheers ~Sergej On 02/08/2017 07:59 PM, Tamas K Lengyel

Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

.snip.. > > > > > I will define 2 sections: > > > > >*-- Connector Request Transport Parameters > > > > > --- > > > > >* > > > > >* ctrl-event-channel > > > > >* ctrl-ring-ref > > > > >* > > > > >*--- Connector Event Transport

Re: [Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests

On Wed, 15 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 14/02/17 21:00, Stefano Stabellini wrote: > > On Mon, 30 Jan 2017, Andre Przywara wrote: > > > +/* > > > + * Handle incoming LPIs, which are a bit special, because they are > > > potentially > > > + * numerous and also only get

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Wed, 15 Feb 2017, Bhupinder Thakur wrote: > On 15 February 2017 at 13:45, Bhupinder Thakur > wrote: > > Hi Stefano, > > > > On 14 February 2017 at 03:14, Stefano Stabellini > > wrote: > >> On Mon, 13 Feb 2017, Bhupinder Thakur wrote: > >>>

Re: [Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

On Wed, Feb 15, 2017 at 04:49:21PM +0100, Borislav Petkov wrote: > On Wed, Feb 15, 2017 at 07:40:51AM -0800, Thomas Garnier wrote: > > Why do you think they rely on it being static? The VSYSCALL address is > > not changed for example. > > I don't know, that's why I'm asking first. Userspace is

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

On 02/15/2017 03:51 PM, Konrad Rzeszutek Wilk wrote: > Hey, > > Credit goes to Boris (CC-ed) for figuring out how to fix this. > > I was doing: > > ./configure --prefix=/usr --enable-systemd > make -j8 > cd dist;./install.sh;) > reboot > > and to my surprise it would hang on > Starting Terminate

Re: [Xen-devel] [win-pv-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

On Wed, 15 Feb 2017, Lars Kurth wrote: > Hi all, > > I am kind of stuck on this one and wanted to pick up the discussion again. > Apologies that it took so long. > > To to summarise, we all are agreed on most sections of the proposal, > with the exception of decision making across projects. One

[Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

Hey, Credit goes to Boris (CC-ed) for figuring out how to fix this. I was doing: ./configure --prefix=/usr --enable-systemd make -j8 cd dist;./install.sh;) reboot and to my surprise it would hang on Starting Terminate Plymouth Boot Screen"...

[Xen-devel] [xen-unstable-smoke test] 105825: tolerable trouble: broken/fail/pass - PUSHED

flight 105825 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105825/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5

[Xen-devel] [xen-4.6-testing test] 105816: regressions - FAIL

flight 105816 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105816/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 105685

Re: [Xen-devel] [PATCH v3 2/2] x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

Hi Waiman, [auto build test ERROR on kvm/linux-next] [also build test ERROR on v4.10-rc8 next-20170215] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Waiman-Long

Re: [Xen-devel] [PATCH 15/28] ARM: vGICv3: introduce basic ITS emulation bits

Hi Andre On 01/30/2017 12:31 PM, Andre Przywara wrote: Create a new file to hold the emulation code for the ITS widget. For now we emulate the memory mapped ITS registers and provide a stub to introduce the ITS command handling framework (but without actually emulating any commands at this

[Xen-devel] [PATCH] arm/hypercall: Use the common hcall_preempted boolean

With hcall_preempted having just been made common, ARM can use use it to simplify its hypercall handling. This simplifies the continuation logic and removes the risk of accidentally skipping multiple instructions. Signed-off-by: Andrew Cooper --- CC: Stefano

[Xen-devel] [PATCH] x86/hypercall: Make the HVM hcall_preempted boolean common

HVM guests currently make use of arch.hvm_vcpu.hcall_preempted to track hypercall preemption in struct vcpu. Move this boolean to being common at the top level of struct vcpu, which will allow it to be reused elsewhere. Alter the PV preemption logic to use this boolean. This simplifies the code

Re: [Xen-devel] STAO spec in xen.git

On Wed, 15 Feb 2017, Olaf Hering wrote: > Am Tue, 14 Feb 2017 20:27:15 + > schrieb Wei Liu : > > > Better to just push to a branch for us to fetch. > > That would be git://github.com/olafhering/xen.git#libreoffice > >

[Xen-devel] [PATCH] x86/hypercall: Split out PV hypercall infrastructure

Repurpose arch/x86/hypercall.c to be common x86 hypercall infrastructure, and move the PV specific routines to arch/x86/pv/hypercall.c This is purely code motion. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/Makefile

[Xen-devel] [PATCH] [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM

Making PV and HVM guests individually compilable is useful as a reduction in hypervisor size, and as an aid to enforcing clean API boundaries. Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do until either can actually be disabled. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH] x86/hypercall: Make the HVM hcall_64bit boolean common

HVM guests currently make use of arch.hvm_vcpu.hcall_64bit to track the ABI of the hypercall in use. The rest of Xen deals in terms of the comat ABI or not, so rename the boolean and make it common, guared by CONFIG_COMPAT to avoid bloat if a compat ABI is not wanted/needed. Set hcall_compat

[Xen-devel] [PATCH] Common hypercall handing improvements

This original purpose of this work was towards the RFC patch at the end of the series, but there turned out to be a lot of cleanup opportunity in common and ARM code as well. Andrew Cooper (7): x86/hypercall: Make the HVM hcall_preempted boolean common arm/hypercall: Use the common

[Xen-devel] [PATCH] xen/multicall: Use the common hcall_preempted boolean

The now-common hcall_preempted boolean is perfectly usable for multicalls. Remove the multicall-specific preemption mechanism. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall

[Xen-devel] [PATCH] x86/hypercall: Move hypercall continuation logic

The newly-repurposed arch/x86/hypercall.c is a more appropriate place for the hypercall continuation logic to live. This is purely code motion. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/domain.c| 177

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

On Wed, Feb 15, 2017 at 12:30 PM, Tamas K Lengyel wrote: > On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote: > On 15.02.17 at 00:21, wrote: >>> On 14/02/2017 22:47, Tamas K Lengyel wrote: (XEN) Switched to APIC

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote: On 15.02.17 at 00:21, wrote: >> On 14/02/2017 22:47, Tamas K Lengyel wrote: >>> (XEN) Switched to APIC driver x2apic_cluster. >>> (XEN) XSM Framework v1.0.0 initialized >>> (XEN) Flask: 128

[Xen-devel] [xen-4.5-testing test] 105817: regressions - FAIL

flight 105817 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105817/ 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. 104590

Re: [Xen-devel] [PATCH 13/28] ARM: vGICv3: handle virtual LPI pending and property tables

Hi Andre, On 30/01/17 18:31, Andre Przywara wrote: Allow a guest to provide the address and size for the memory regions it has reserved for the GICv3 pending and property tables. We sanitise the various fields of the respective redistributor registers and map those pages into Xen's address

[Xen-devel] Network interface change notifications between an ethX and vif?

I will apologize up front for my ignorance on the topic of 'Xen' since I have just been thrown into it. My task at hand is to make modifications to the Linux kernel so that when the vif on one VHD connected to the corresponding eth0 on another VHD goes down (ip link set vif1.0 down), eth0 appears

Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

On 02/15/2017 05:45 PM, Konrad Rzeszutek Wilk wrote: On Wed, Feb 15, 2017 at 09:33:41AM +0200, Oleksandr Andrushchenko wrote: On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote: On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote: Hi, Konrad! Thank you for reviewing

[Xen-devel] [PATCH v3 0/2] x86/kvm: Reduce vcpu_is_preempted() overhead

v2->v3: - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted() in assembly as suggested by PeterZ. - Add a new patch to change vcpu_is_preempted() argument type to long to ease the writing of the assembly code. v1->v2: - Rerun the fio test on a different system on both

[Xen-devel] [PATCH v3 2/2] x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

It was found when running fio sequential write test with a XFS ramdisk on a KVM guest running on a 2-socket x86-64 system, the %CPU times as reported by perf were as follows: 69.75% 0.59% fio [k] down_write 69.15% 0.01% fio [k] call_rwsem_down_write_failed 67.12% 1.12% fio [k]

Re: [Xen-devel] [PATCH 04/28] ARM: GICv3 ITS: allocate device and collection table

Hi Andre, On 01/30/2017 12:31 PM, Andre Przywara wrote: Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a pair of LPI number and collection ID, which points to the target CPU. This mapping is stored in the device and

[Xen-devel] [PATCH v3 1/2] x86/paravirt: Change vcp_is_preempted() arg type to long

The cpu argument in the function prototype of vcpu_is_preempted() is changed from int to long. That makes it easier to provide a better optimized assembly version of that function. For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the downcast from long to int is not a problem as vCPU

[Xen-devel] [ovmf baseline-only test] 68564: all pass

This run is configured for baseline tests only. flight 68564 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68564/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf cb8674999c6bf94cdb3be18df3746131aac6386b baseline

[Xen-devel] [linux-next test] 105812: regressions - FAIL

flight 105812 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/105812/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 105807

[Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically

generated/autoconf.h is already included automatically so CONFIG_* defines are avaialble. However, the companion macros such as IS_ENABLED() are not included. Include them uniformally everywhere. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] [PATCH 2/3] xen/include: Remove explicit asm/config.h includes

xen/config.h includes asm/config.h, and is included automatically via CFLAGS. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall --- xen/arch/arm/acpi/lib.c|

Re: [Xen-devel] [PATCH 00/28] arm64: Dom0 ITS emulation

On 30/01/17 18:31, Andre Przywara wrote: Hi, Hi Andre, Compared to the previous post (RFC-v2) this has seen a lot of reworks and cleanups in various areas. I tried to address all of the review comments, though some are hard to follow due to rewrites. So apologies if some points have slipped

[Xen-devel] [xen-unstable-smoke test] 105822: regressions - trouble: broken/fail/pass

flight 105822 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105822/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 11 guest-start fail REGR. vs. 105820 Tests which

Re: [Xen-devel] Unshared IOMMU issues

Hi, Jan. On Wed, Feb 15, 2017 at 6:22 PM, Jan Beulich wrote: On 15.02.17 at 16:52, wrote: >> I think, but I am not 100% sure that we could avoid actions above if >> we would have knowledge about device assignment for particular >> domain before

[Xen-devel] [PATCH 1/2] xen/sched.h Whitespace and bool cleanup

Extend the Maptrack comment to point at the Grant table subsystem. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall ---

[Xen-devel] [PATCH 2/2] common/vcpu: Switch v->vcpu_info_mfn to mfn_t

No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall --- xen/common/domain.c | 15 ++- xen/include/xen/sched.h | 2 +- 2

Re: [Xen-devel] [PATCH 12/28] ARM: GICv3: enable ITS and LPIs on the host

Hi Andre, On 30/01/17 18:31, Andre Przywara wrote: Now that the host part of the ITS code is in place, we can enable the ITS and also LPIs on each redistributor to get the show rolling. At this point there would be no LPIs mapped, as guests don't know about the ITS yet. Signed-off-by: Andre

[Xen-devel] [linux-linus test] 105807: regressions - FAIL

flight 105807 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105807/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254

Re: [Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests

Hi Andre, On 30/01/17 18:31, Andre Przywara wrote: Upon receiving an LPI, we need to find the right VCPU and virtual IRQ number to get this IRQ injected. Iterate our two-level LPI table to find this information quickly when the host takes an LPI. Call the existing injection function to let the

Re: [Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests

Hi Stefano, On 14/02/17 21:00, Stefano Stabellini wrote: On Mon, 30 Jan 2017, Andre Przywara wrote: +/* + * Handle incoming LPIs, which are a bit special, because they are potentially + * numerous and also only get injected into guests. Treat them specially here, + * by just looking up their

[Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

Callers to libxl_cpupool_create() can either request a specific pool id, or request that Xen do it for them. But at the moment, the "automatic" selection is indicated by using a magic value, 0. This is undesirable both because it doesn't obviously have meaning, but also because '0' is a valid

[Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

Callers to xc_cpupool_create() can either request a specific pool id, or request that Xen do it for them. But at the moment, the "automatic" selection is indicated by using a magic value, 0. This is undesirable both because it doesn't obviously have meaning, but also because '0' is a valid

Re: [Xen-devel] [PATCH 10/28] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Stefano, On 14/02/17 20:39, Stefano Stabellini wrote: On Mon, 30 Jan 2017, Andre Przywara wrote: For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. However we actually only need those

Re: [Xen-devel] [PATCH 10/28] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Andre, On 30/01/17 18:31, Andre Przywara wrote: For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. However we actually only need those when an interrupt is on a vCPU (or is about to be

Re: [Xen-devel] [PATCH] x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs

>>> On 15.02.17 at 17:53, wrote: > bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h > result in forward declarations of the bitops.h contents. Move > ASM_FLAG_OUT() > to a new asm/compiler.h to compensate. > > While making changes, switch

Re: [Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued

>>> On 15.02.17 at 17:37, wrote: > On 15/02/17 09:44, Jan Beulich wrote: > On 14.02.17 at 18:25, wrote: >>> 4. The security team will only issue an advisory if there is a known >>> combination of software in which the vulnerability can be

Re: [Xen-devel] [PATCH v3.1 01/18] x86emul: catch exceptions occurring in stubs

Before adding more use of stubs cloned from decoded guest insns, guard ourselves against mistakes there: Should an exception (with the noteworthy exception of #PF) occur inside the stub, forward it to the guest. Since the exception fixup table entry can't encode the address of the faulting insn

[Xen-devel] [PATCH] x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs

bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT() to a new asm/compiler.h to compensate. While making changes, switch bool_t to bool and use named asm parameters. No functional change.

Re: [Xen-devel] [PATCH v8 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

On Wed, Feb 15, 2017 at 04:49:16PM +0800, Yi Sun wrote: > This patch creates CAT and CDP feature document in doc/features/. It describes > key points to implement L3 CAT/CDP and L2 CAT which is described in details in > Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION >

Re: [Xen-devel] [PATCH v5 1/3] Code motion changes to make real patches easier to read

On Wed, Nov 23, 2016 at 12:20:44PM +, Lars Kurth wrote: > Added TOC > Re-arranged sections compared to previous version of document > Added new anchors where needed > Split Roles section into two sections > > The actual content was not changed (with the exception of minor > typos that I

Re: [Xen-devel] [win-pv-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

> >> We could split out the following git repos: mini-os, osstest, raisin, > >> livepatch-build-tools, xtf , xentesttools/* > >> In terms of contributions per release, there is more activity than Windows > >> PV Drivers, which are a separate project. > > > > I see what you meant now. That could

Re: [Xen-devel] [PATCH v5 2/3] Added document containing governance related todo list

On Wed, Nov 23, 2016 at 12:20:45PM +, Lars Kurth wrote: > Contains items that at some point need to be addressed. > The items do not directly affect governance.pandoc > > Signed-off-by: Lars Kurth Reviewed-by: Konrad Rzeszutek Wilk > --- >

Re: [Xen-devel] [PATCH 07/28] ARM: GICv3 ITS: introduce device mapping

Hi Andre, On 30/01/17 18:31, Andre Przywara wrote: +static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid, + int size, uint64_t itt_addr, bool valid) +{ +uint64_t cmd[4]; + +cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32); +cmd[1] =

Re: [Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued

On 15/02/17 09:44, Jan Beulich wrote: On 14.02.17 at 18:25, wrote: >> 4. The security team will only issue an advisory if there is a known >> combination of software in which the vulnerability can be exploited. > > Considering the following text, perhaps "may"

Re: [Xen-devel] [PATCH RFC V2 7/7] COLO-Proxy: Use socket to get checkpoint event.

On Wed, Feb 15, 2017 at 05:54:33PM +0800, Zhang Chen wrote: > We use kernel colo proxy's way to get the checkpoint event > from qemu colo-compare. > Qemu colo-compare need add a API to support this(I will add this in qemu). > > Signed-off-by: Zhang Chen > --- >

Re: [Xen-devel] Unshared IOMMU issues

>>> On 15.02.17 at 16:52, wrote: > I think, but I am not 100% sure that we could avoid actions above if > we would have knowledge about device assignment for particular > domain before making any updates in P2M. Well, one could in theory make this work for boot time assigned

Re: [Xen-devel] [PATCH RFC V2 0/7] COLO-Proxy: Make Xen COLO use userspace colo-proxy

On Wed, Feb 15, 2017 at 05:54:26PM +0800, Zhang Chen wrote: > Because of some reason, We no longer support COLO kernel proxy. > So we send this patch set to make Xen use userspace colo-proxy in qemu. How come it is RFC? It looks quite baked? ___

Re: [Xen-devel] [PATCH v8 00/24] Enable L2 Cache Allocation Technology & Refactor psr.c

On Wed, Feb 15, 2017 at 04:49:15PM +0800, Yi Sun wrote: > Hi all, > > We plan to bring a new PSR (Platform Shared Resource) feature called > Intel L2 Cache Allocation Technology (L2 CAT) to Xen. > > Besides the L2 CAT implementaion, we refactor the psr.c to make it more > flexible to add new

Re: [Xen-devel] [PATCH] x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs

>>> On 15.02.17 at 17:00, wrote: > On 15/02/17 14:55, Jan Beulich wrote: > On 15.02.17 at 15:22, wrote: >>> bitops.h cannot include asm_defns.h, because the static inlines in > cpumasks.h >>> result in forward declarations of the

Re: [Xen-devel] [PATCH v2 00/10] xen: credit2: improve style, and tracing; fix two bugs

On Thu, Feb 9, 2017 at 1:58 PM, Dario Faggioli wrote: > Hello, > > This series contains mostly style or cosmetic fixes for Credit2, with the > following two exceptions: > - 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6); > - some tracing

  1   2   3   >