Re: [Xen-devel] [PATCH] include: fix build without C++ compiler installed

>>> On 12.05.17 at 18:20, wrote: > On Fri, May 12, 2017 at 12:52:54AM -0600, Jan Beulich wrote: >> The rule for headers++.chk wants to move headers++.chk.new to the >> designated target, which means we have to create that file in the first >> place. >> >> Signed-off-by: Jan Beulich > > Reviewed

[Xen-devel] [PATCH V2] acpi: enlarge NUM_FIXMAP_ACPI_PAGES to support larger scale boards

In acpi_tb_verify_table()->__acpi_map_table(), it suppose all ACPI tables may not exceed 4 pages, the tables includes SRAT/APIC/ERST etc. Please note that the table DSDT is not mapped through acpi_tb_verify_table(), thus we don't care its size although it's usually the largest table among all the A

[Xen-devel] [qemu-mainline test] 109430: regressions - FAIL

flight 109430 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/109430/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 5 xen-buildfail REGR. vs. 107636 build-arm64

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

>>> On 12.05.17 at 17:34, wrote: On 12.05.17 at 17:25, wrote: >> On Fri, May 12, 2017 at 5:41 PM, Jan Beulich wrote: >> On 10.05.17 at 16:03, wrote: The "retrieving mapping" code has never executed since iommu_use_hap_pt(d) always returned true on ARM so far. But, with i

Re: [Xen-devel] [PATCH v1 02/10] iommu: Add extra order argument to the IOMMU APIs and platform callbacks

>>> On 12.05.17 at 18:25, wrote: > On Fri, May 12, 2017 at 7:17 PM, Jan Beulich wrote: > On 12.05.17 at 17:50, wrote: >>> On Fri, May 12, 2017 at 5:23 PM, Jan Beulich wrote: >>> On 10.05.17 at 16:03, wrote: > @@ -771,6 +773,47 @@ int amd_iommu_unmap_page(struct domain *d, unsigned

Re: [Xen-devel] [PATCH v1 06/10] iommu: Add extra use_iommu argument to iommu_domain_init()

>>> On 12.05.17 at 19:00, wrote: > On Fri, May 12, 2017 at 5:31 PM, Jan Beulich wrote: > On 10.05.17 at 16:03, wrote: >>> From: Oleksandr Tyshchenko >>> >>> The presence of this flag lets us know that the guest >>> has devices which will most likely be used for passthrough >>> and as the re

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

Hi Jan, On 15/05/2017 08:20, Jan Beulich wrote: On 12.05.17 at 17:34, wrote: On 12.05.17 at 17:25, wrote: On Fri, May 12, 2017 at 5:41 PM, Jan Beulich wrote: On 10.05.17 at 16:03, wrote: The "retrieving mapping" code has never executed since iommu_use_hap_pt(d) always returned true on AR

Re: [Xen-devel] [PATCH v2 03/18] x86/traps: lift do_guest_trap to domain.h

>>> On 12.05.17 at 20:16, wrote: > On 05/05/17 15:48, Wei Liu wrote: >> Put it along side with other pv_inject functions and rename it to >> pv_inject_trap. >> >> We need this because this function is used by PV emulation code and PV >> trap handling code, which will be split into different files.

Re: [Xen-devel] [BUG] EDAC infomation partially missing

>>> On 14.05.17 at 00:36, wrote: > I haven't yet done as much experimentation as Andreas Pflug has, but I > can confirm I'm also running into this bug with Xen 4.4.1. > > I've only tried Linux kernel 3.16.43, but as Dom0: > > EDAC MC: Ver: 3.0.0 > AMD64 EDAC driver v3.4.0 > EDAC amd64: DRAM ECC

Re: [Xen-devel] [Outreachy] Adding Floating Point support to Mini-OS Project

Hi Juliana, On 13/05/17 00:17, Juliana Rodrigues wrote: > Hello Juergen, > > I've learnt about your project through the Outreachy Projects List > . I'm > currently on the third year of my computer science bachelors course and > I'm very

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

>>> On 12.05.17 at 19:01, wrote: > > 1. Motivation and Description > > Virtual machines use grant table hypercalls to setup a share page for > inter-VMs communications. These hypercalls are us

Re: [Xen-devel] 4.9.0-rcX can not be built for ARM64

On 13/05/2017 13:38, Andrii Anisov wrote: Dear All, Hi Andrii, During the XEN 4.9.0-rc4 testing on Renesas R-Car Gen3 platform I faced a bug at compilation step. Thank you for testing Xen on your board. Again, the libxl_arm_acpi.c can not be built: | In file included from libxl_arm.

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

>>> On 15.05.17 at 09:42, wrote: > On 15/05/2017 08:20, Jan Beulich wrote: >> Having thought about this some more, what's still missing is a >> clear explanation why this new need of a non-stub mfn_to_gmfn() >> isn't finally enough of a reason to introduce an M2P on ARM. We >> currently have sever

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

Hi Jan, On 15/05/2017 09:08, Jan Beulich wrote: On 12.05.17 at 19:01, wrote: 1. Motivation and Description Virtual machines use grant table hypercalls to setup a share page for inter-VMs c

Re: [Xen-devel] 4.9.0-rcX can not be built for ARM64

Julien, On 15.05.17 11:12, Julien Grall wrote: It looks like you compiler does not (validly?) detect that size will always be initialized when (rc > 0). The question is if it should be considered as the XEN sources bug and to be patched appropriately. Can you try this small patch below:

Re: [Xen-devel] [Qemu-devel] [PATCH RESEND v2 03/21] xen-backend: Remove FIXME comment about user_creatable flag

Stefano or Anthony, please review. Eduardo Habkost writes: > xen-backend can be plugged/unplugged dynamically when using the > Xen accelerator, so keep the user_creatable flag on the device > class and remove the FIXME comment. > > Cc: Juergen Gross , > Cc: Peter Maydell , > Cc: Thomas Huth > C

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

>>> On 15.05.17 at 10:20, wrote: > On 15/05/2017 09:08, Jan Beulich wrote: > On 12.05.17 at 19:01, wrote: >>> >>> 1. Motivation and Description >>> >>> Virtual machines use grant table hy

Re: [Xen-devel] [PATCH v2 1/5] xentrace: add TRC_HVM_PI_LIST_ADD

On Mon, May 15, 2017 at 09:33:04AM +0800, Tian, Kevin wrote: >> From: Gao, Chao >> Sent: Thursday, May 11, 2017 2:04 PM >> >> This patch adds TRC_HVM_PI_LIST_ADD to track adding one entry to >> the per-pcpu blocking list. Also introduce a 'counter' to track >> the number of entries in the list. >>

[Xen-devel] [distros-debian-sid test] 71318: tolerable trouble: blocked/broken/fail/pass

flight 71318 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71318/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start fail blocked in 71263 test-amd64-amd64-am

Re: [Xen-devel] [PATCH v2 3/5] VT-d PI: restrict the vcpu number on a given pcpu

On Mon, May 15, 2017 at 01:24:45PM +0800, Tian, Kevin wrote: >> From: Gao, Chao >> Sent: Thursday, May 11, 2017 2:04 PM >> >> Currently, a blocked vCPU is put in its pCPU's pi blocking list. If >> too many vCPUs are blocked on a given pCPU, it will incur that the list >> grows too long. After a si

Re: [Xen-devel] [PATCH V2] acpi: enlarge NUM_FIXMAP_ACPI_PAGES to support larger scale boards

>>> On 15.05.17 at 09:04, wrote: > In acpi_tb_verify_table()->__acpi_map_table(), it suppose all ACPI tables > may not exceed 4 pages, the tables includes SRAT/APIC/ERST etc. > Please note that the table DSDT is not mapped through > acpi_tb_verify_table(), thus we don't care its size although it's

Re: [Xen-devel] null domains after xl destroy

On 13/05/17 06:02, Glenn Enright wrote: > On 09/05/17 21:24, Roger Pau Monné wrote: >> On Mon, May 08, 2017 at 11:10:24AM +0200, Juergen Gross wrote: >>> On 04/05/17 00:17, Glenn Enright wrote: On 04/05/17 04:58, Steven Haigh wrote: > On 04/05/17 01:53, Juergen Gross wrote: >> On 03/05

Re: [Xen-devel] [PATCH v3 1/3] xen/string: Clean up {xen, arm}/string.h

>>> On 12.05.17 at 19:35, wrote: > * Drop __kernel_size_t entirely. It isn't useful distinction, especially as >it means the the prototypes don't appear to match their common definitions. > * Introduce __HAVE_ARCH_* guards for strpbrk(), strsep() and strspn(), which >match their impleme

Re: [Xen-devel] [PATCH v3 2/3] xen/string: Use compiler __builtin_*() where possible

>>> On 12.05.17 at 19:35, wrote: > The use of -fno-builtin inhibits these automatic transformations. This causes > constructs such as strlen("literal") to be evaluated at compile time, and > certain simple operations to be replaced with repeated string operations. > > To avoid the macro altering

Re: [Xen-devel] [PATCH v3 3/3] x86/string: Clean up x86/string.h

>>> On 12.05.17 at 19:35, wrote: > --- a/xen/include/asm-x86/string.h > +++ b/xen/include/asm-x86/string.h > @@ -2,13 +2,23 @@ > #define __X86_STRING_H__ > > #define __HAVE_ARCH_MEMCPY > -#define memcpy(t,f,n) (__builtin_memcpy((t),(f),(n))) > +void *memcpy(void *dest, const void *src, size_t

Re: [Xen-devel] [PATCH v3 3/3] x86/string: Clean up x86/string.h

>>> On 15.05.17 at 12:08, wrote: On 12.05.17 at 19:35, wrote: >> --- a/xen/include/asm-x86/string.h >> +++ b/xen/include/asm-x86/string.h >> @@ -2,13 +2,23 @@ >> #define __X86_STRING_H__ >> >> #define __HAVE_ARCH_MEMCPY >> -#define memcpy(t,f,n) (__builtin_memcpy((t),(f),(n))) >> +void

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

Hi Jan, On 05/15/2017 09:52 AM, Jan Beulich wrote: On 15.05.17 at 10:20, wrote: On 15/05/2017 09:08, Jan Beulich wrote: On 12.05.17 at 19:01, wrote: 1. Motivation and Description Virtua

Re: [Xen-devel] [PATCH v2 for-next 2/2] x86/string: Use compiler __builtin_str*() where possible

Hi Andrew, On 05/12/2017 04:50 PM, Andrew Cooper wrote: On 12/05/17 16:42, Julien Grall wrote: Furthemore, someone mentioned a potential legal issue to linked against the built-in. Anyone heard about that? The main use of these are optimising things like strlen("literal") at compile time. T

Re: [Xen-devel] Enabling VT-d PI by default

On Fri, May 12, 2017 at 12:05 PM, Andrew Cooper wrote: > Citrix Netscalar SDX boxes have more MSI-X interrupts than fit in the > cumulative IDTs of a top end dual-socket Xeon server systems. Some of > the device drivers are purposefully modelled to use fewer interrupts > than they otherwise would

Re: [Xen-devel] 4.9.0-rcX can not be built for ARM64

On 05/15/2017 09:30 AM, Andrii Anisov wrote: Julien, Hi Andrii, On 15.05.17 11:12, Julien Grall wrote: It looks like you compiler does not (validly?) detect that size will always be initialized when (rc > 0). The question is if it should be considered as the XEN sources bug and to be pat

Re: [Xen-devel] [PATCH v1 02/10] iommu: Add extra order argument to the IOMMU APIs and platform callbacks

Hi, Jan On Mon, May 15, 2017 at 10:22 AM, Jan Beulich wrote: On 12.05.17 at 18:25, wrote: >> On Fri, May 12, 2017 at 7:17 PM, Jan Beulich wrote: >> On 12.05.17 at 17:50, wrote: On Fri, May 12, 2017 at 5:23 PM, Jan Beulich wrote: On 10.05.17 at 16:03, wrote: >> @@ -

Re: [Xen-devel] [PATCH V2] acpi: enlarge NUM_FIXMAP_ACPI_PAGES to support larger scale boards

> >> >> Thus, we make NUM_FIXMAP_ACPI_PAGES much larger, to 64(256KB). it's >> calculated for that the theoretical largest CPU number on main Linux >> distros is about 8092, and memory slots number should be within 1000, >> that's 24B*8092+40B*1000 = 234208B. Meanwhile, because >IOREMAP_VIRT_* >> r

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

flight 109428 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/109428/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-winxpsp3 16 guest-stop fail REGR. vs. 59254 Tests which are fai

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Reducing CC list now that we're off the topic of modules] On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk wrote: > Stefano, > > On 12 May 2017 at 21:43, Stefano Stabellini wrote: > >> On the topic of the technical reasons for being out of the hypervisor >> (EL0 app or stubdom), I'll spend a

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

Hi Jan, On 05/15/2017 09:19 AM, Jan Beulich wrote: On 15.05.17 at 09:42, wrote: On 15/05/2017 08:20, Jan Beulich wrote: Having thought about this some more, what's still missing is a clear explanation why this new need of a non-stub mfn_to_gmfn() isn't finally enough of a reason to introduce

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

>>> On 15.05.17 at 12:21, wrote: > On 05/15/2017 09:52 AM, Jan Beulich wrote: > On 15.05.17 at 10:20, wrote: >>> On 15/05/2017 09:08, Jan Beulich wrote: >>> On 12.05.17 at 19:01, wrote: > > 1. Motivation and Description > =

Re: [Xen-devel] [PATCH v1 02/10] iommu: Add extra order argument to the IOMMU APIs and platform callbacks

>>> On 15.05.17 at 12:43, wrote: > On Mon, May 15, 2017 at 10:22 AM, Jan Beulich wrote: > On 12.05.17 at 18:25, wrote: >>> On Fri, May 12, 2017 at 7:17 PM, Jan Beulich wrote: >>> On 12.05.17 at 17:50, wrote: > On Fri, May 12, 2017 at 5:23 PM, Jan Beulich wrote: > On 10.05.

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

>>> On 15.05.17 at 13:45, wrote: > On 05/15/2017 09:19 AM, Jan Beulich wrote: > On 15.05.17 at 09:42, wrote: >>> On 15/05/2017 08:20, Jan Beulich wrote: With this I think there's quite a bit of justification needed to keep going without M2P on ARM. >>> >>> As said in a previous thre

[Xen-devel] [PATCH for-4.9 1/2] x86/pv: Fix the handling of `int $x` for vectors which alias exceptions

The claim at the top of c/s 2e426d6eecf "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()" is only actually true for hardware exceptions. It is not true for `int $x` instructions (which never push error code), irrespective of whether the vector aliases an exception or not. Futherm

[Xen-devel] [PATCH for-4.9 2/2] x86/pv: Replace do_guest_trap() with pv_inject_hw_exception()

do_guest_trap() is now functionally equivelent to pv_inject_hw_exception(), but with a less useful API as it requires the error code parameter to be passed implicitly via cpu_user_regs. Extend pv_inject_event() with a further assertion which checks that hardware exception vectors are below 32, whi

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On Fri, May 12, 2017 at 7:47 PM, Volodymyr Babchuk wrote: >> Regarding modules (#3): The problem that loadable modules were >> primarily introduced to solve in Linux wasn't "How to deal with >> proprietary drivers", or even "how to deal with out-of-tree drivers". >> The problem was, "How to we all

Re: [Xen-devel] 4.9rc4: Cannot build with higher than -j4 - was: linux.c:27:28: fatal error: xen/sys/evtchn.h: No such file or directory

On Sun, May 14, 2017 at 10:50 AM, Steven Haigh wrote: > On 10/05/17 23:02, Steven Haigh wrote: >> On 10/05/17 01:20, M A Young wrote: >>> On Tue, 9 May 2017, Steven Haigh wrote: >>> I'm trying to use the same build procedure I had for working correctly for Xen 4.7 & 4.8.1 - but am coming

Re: [Xen-devel] [PATCH v3 3/3] x86/string: Clean up x86/string.h

On 15/05/17 11:19, Jan Beulich wrote: > >>> On 15.05.17 at 12:08, wrote: > On 12.05.17 at 19:35, wrote: >>> --- a/xen/include/asm-x86/string.h >>> +++ b/xen/include/asm-x86/string.h >>> @@ -2,13 +2,23 @@ >>> #define __X86_STRING_H__ >>> >>> #define __HAVE_ARCH_MEMCPY >>> -#define memcpy(

Re: [Xen-devel] [Xen-users] UEFI Secure Boot Xen 4.9

Hey, CC-ing Xen-devel to spread some knowledge about the issue. On Mon, May 15, 2017 at 10:42:23AM +0100, George Dunlap wrote: > On Wed, May 10, 2017 at 11:36 PM, Bill Jacobs (billjac) > wrote: > > Hi all > > > > I gather that with 4.9, UEFI secure boot of Xen should be possible. > > > > Is this

Re: [Xen-devel] 4.9.0-rcX can not be built for ARM64

Julien, On 15.05.17 13:34, Julien Grall wrote: Are you planning to submit a patch? I think we can take this for Xen 4.9. Both version are good for me, it is a matter of taste here I think. I would take your code, it is safer for possible future usage of libxl__estimate_madt_size() function.

[Xen-devel] [linux-4.9 test] 109435: regressions - FAIL

flight 109435 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109435/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358 test-arm64-arm64-xl

Re: [Xen-devel] Enabling VT-d PI by default

On 15/05/17 11:27, George Dunlap wrote: > On Fri, May 12, 2017 at 12:05 PM, Andrew Cooper > wrote: >> Citrix Netscalar SDX boxes have more MSI-X interrupts than fit in the >> cumulative IDTs of a top end dual-socket Xeon server systems. Some of >> the device drivers are purposefully modelled to u

Re: [Xen-devel] [PATCH v2 1/2] libxl/devd: fix a race with concurrent device addition/removal

Hi Roger, On 11/05/17 12:43, Roger Pau Monne wrote: On Thu, May 11, 2017 at 12:06:08PM +0100, Ian Jackson wrote: Roger Pau Monne writes ("[PATCH v2 1/2] libxl/devd: fix a race with concurrent device addition/removal"): Current code can free the libxl__device inside of the libxl__ddomain_devic

Re: [Xen-devel] [PATCH v2 for-4.9] x86/mm: Fix incorrect unmapping of 2MB and 1GB pages

On Wed, May 10, 2017 at 12:13 PM, Igor Druzhinin wrote: > The same set of functions is used to set as well as to clean > P2M entries, except that for clean operations INVALID_MFN (~0UL) > is passed as a parameter. Unfortunately, when calculating an > appropriate target order for a particular mappi

Re: [Xen-devel] [PATCH v8 0/3] arm64, xen: add xen_boot support into grub-mkconfig

On Sun, May 14, 2017 at 03:43:44PM +0800, fu@linaro.org wrote: > From: Fu Wei > > This patchset add xen_boot support into grub-mkconfig for > generating xen boot entrances automatically > > Also update the docs/grub.texi for new xen_boot commands. LGTM, if there are no objections I will commi

Re: [Xen-devel] [PATCH v8 0/3] arm64, xen: add xen_boot support into grub-mkconfig

Hi Daniel, On 15/05/17 14:38, Daniel Kiper wrote: On Sun, May 14, 2017 at 03:43:44PM +0800, fu@linaro.org wrote: From: Fu Wei This patchset add xen_boot support into grub-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands.

Re: [Xen-devel] [PATCH V4] x86/ioreq_server: Make p2m_finish_type_change actually work

On Fri, May 12, 2017 at 3:42 AM, Xiong Zhang wrote: > Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding > p2m_ioreq_server entries when an ioreq server unmaps") introduced > p2m_finish_type_change(), which was meant to synchronously finish a > previously initiated type change

Re: [Xen-devel] [PATCH V5] x86/ioreq_server: Make p2m_finish_type_change actually work

On Sat, May 13, 2017 at 1:34 AM, Xiong Zhang wrote: > Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding > p2m_ioreq_server entries when an ioreq server unmaps") introduced > p2m_finish_type_change(), which was meant to synchronously finish a > previously initiated type change

Re: [Xen-devel] [PATCH v8 0/3] arm64, xen: add xen_boot support into grub-mkconfig

Hi Julien, On Mon, May 15, 2017 at 02:43:28PM +0100, Julien Grall wrote: > Hi Daniel, > > On 15/05/17 14:38, Daniel Kiper wrote: > >On Sun, May 14, 2017 at 03:43:44PM +0800, fu@linaro.org wrote: > >>From: Fu Wei > >> > >>This patchset add xen_boot support into grub-mkconfig for > >>generating

Re: [Xen-devel] [PATCH] x86/efi: Reserve EFI properties table

Hi Andrew, On 08/05/17 17:29, Andrew Cooper wrote: On 08/05/17 17:17, Ross Lagerwall wrote: Some EFI firmware implementations may place the EFI properties table in RAM marked as BootServicesData, which Xen does not consider as reserved. When dom0 tries to access the EFI properties table (which

Re: [Xen-devel] [PATCH for-4.9] ioemu-stubdom: don't link *-softmmu* and *-linux-user*

Hi, On 12/05/17 17:23, Wei Liu wrote: On Fri, May 12, 2017 at 04:21:06PM +0100, Wei Liu wrote: They are generated by ./configure. Having them linked can cause race between tools build and stubdom build. Signed-off-by: Wei Liu FTR Juergen told me on IRC: Reviewed-by: Juergen Gross Releas

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On 12.05.17 21:47, Volodymyr Babchuk wrote: vcoproc driver should be able to work with real HW, probably it will handle real IRQs from device, we need one instance of driver per device, not per domain. Andrii can correct me, but vcoproc framework is not tied to vcpus, so it can work in context o

Re: [Xen-devel] [PATCH] tools: don't require unavailable optional libraries in pkg-config files

Hi Juergen, On 12/05/17 14:10, Juergen Gross wrote: blktap2 is optional, so there should be no pkg-config file requiring xenblktapctl if it isn't enabled for the build. Add a filter mechanism to tools/Rules.mk to filter out optional libraries. Signed-off-by: Juergen Gross Release-acked-by:

Re: [Xen-devel] [PATCH] include: fix build without C++ compiler installed

Hi Jan, On 12/05/17 07:52, Jan Beulich wrote: The rule for headers++.chk wants to move headers++.chk.new to the designated target, which means we have to create that file in the first place. Signed-off-by: Jan Beulich Release-acked-by: Julien Grall Cheers, --- a/xen/include/Makefile +++

[Xen-devel] [For Xen-4.10 PATCH 1/3] Allow control of icache invalidations when calling flush_page_to_ram()

flush_page_to_ram() unconditionally drops the icache. In certain situations this leads to execessive icache flushes when flush_page_to_ram() ends up being repeatedly called in a loop. Introduce a parameter to allow callers of flush_page_to_ram() to take responsibility of synchronising the icache.

[Xen-devel] [For Xen-4.10 PATCH 2/3] arm: p2m: Prevent redundant icache flushes

When toolstack requests flushing the caches, flush_page_to_ram() is called for each page of the requested domain. This needs to unnecessary icache invalidation operations. Let's take the responsibility of performing icache operations and use the recently introduced flag to prevent redundant icache

[Xen-devel] [For Xen-4.10 PATCH 0/3] Reduce unnecessary icache maintenance operations

Hi, This series was previously posted as an RFC[0]. An issue was discovered in the RFC related to delaying icache invalidations when the domain is active. Accordingly, Patch 3 has been modified to avoid per-page icache invalidations only during domain creation. Changes from RFC: * Fixed coding s

[Xen-devel] [For Xen-4.10 PATCH 3/3] Avoid excess icache flushes in populate_physmap() before domain has been created

populate_physmap() calls alloc_heap_pages() per requested extent. alloc_heap_pages() invalidates the entire icache per extent. During domain creation, the icache invalidations can be deffered until all the extents have been allocated as there is no risk of executing stale instructions from the icac

Re: [Xen-devel] [For Xen-4.10 PATCH 0/3] Reduce unnecessary icache maintenance operations

Looks like I've got Konrad's email wrong. Please ignore this thread. I'll repost with the right address. :( Apologies for the spam. Punit Punit Agrawal writes: > Hi, > > This series was previously posted as an RFC[0]. An issue was discovered > in the RFC related to delaying icache invalidatio

[Xen-devel] Support of lguest?

Lguest and Xen pv-guests are the only users of pv_mmu_ops (with the one exception of the .exit_mmap member, which is being used by Xen HVM-guests, too). As it is possible now to build a kernel without Xen pv-guest support while keeping PVH and PVHVM support, I thought about putting most pv_mmu_ops

[Xen-devel] [For Xen-4.10 Resend PATCH 0/3] Reduce unnecessary icache maintenance operations

Hi, This series was previously posted as an RFC[0]. An issue was discovered in the RFC related to delaying icache invalidations when the domain is active. Accordingly, Patch 3 has been modified to avoid per-page icache invalidations only during domain creation. Changes from RFC: * Fixed coding s

[Xen-devel] [For Xen-4.10 Resend PATCH 1/3] Allow control of icache invalidations when calling flush_page_to_ram()

flush_page_to_ram() unconditionally drops the icache. In certain situations this leads to execessive icache flushes when flush_page_to_ram() ends up being repeatedly called in a loop. Introduce a parameter to allow callers of flush_page_to_ram() to take responsibility of synchronising the icache.

[Xen-devel] [For Xen-4.10 Resend PATCH 3/3] Avoid excess icache flushes in populate_physmap() before domain has been created

populate_physmap() calls alloc_heap_pages() per requested extent. alloc_heap_pages() invalidates the entire icache per extent. During domain creation, the icache invalidations can be deffered until all the extents have been allocated as there is no risk of executing stale instructions from the icac

[Xen-devel] [For Xen-4.10 Resend PATCH 2/3] arm: p2m: Prevent redundant icache flushes

When toolstack requests flushing the caches, flush_page_to_ram() is called for each page of the requested domain. This needs to unnecessary icache invalidation operations. Let's take the responsibility of performing icache operations and use the recently introduced flag to prevent redundant icache

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

Hi Jan, On 15/05/17 13:28, Jan Beulich wrote: On 15.05.17 at 12:21, wrote: On 05/15/2017 09:52 AM, Jan Beulich wrote: On 15.05.17 at 10:20, wrote: On 15/05/2017 09:08, Jan Beulich wrote: On 12.05.17 at 19:01, wrote: 1. Motivation and D

Re: [Xen-devel] [PATCH v3 3/3] x86/string: Clean up x86/string.h

>>> On 15.05.17 at 15:08, wrote: > On 15/05/17 11:19, Jan Beulich wrote: >> >>> On 15.05.17 at 12:08, wrote: >> On 12.05.17 at 19:35, wrote: --- a/xen/include/asm-x86/string.h +++ b/xen/include/asm-x86/string.h @@ -2,13 +2,23 @@ #define __X86_STRING_H__ #de

Re: [Xen-devel] Support of lguest?

Juergen Gross writes: > Lguest and Xen pv-guests are the only users of pv_mmu_ops (with the > one exception of the .exit_mmap member, which is being used by Xen > HVM-guests, too). > > As it is possible now to build a kernel without Xen pv-guest support > while keeping PVH and PVHVM support, I th

Re: [Xen-devel] Support of lguest?

On 15/05/17 16:22, Vitaly Kuznetsov wrote: > Juergen Gross writes: > >> Lguest and Xen pv-guests are the only users of pv_mmu_ops (with the >> one exception of the .exit_mmap member, which is being used by Xen >> HVM-guests, too). >> >> As it is possible now to build a kernel without Xen pv-guest

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

>>> On 15.05.17 at 16:13, wrote: > On 15/05/17 13:28, Jan Beulich wrote: > On 15.05.17 at 12:21, wrote: >>> On Zhongze proposal, the share page will be mapped at the a specific >>> address in the guest memory. I agree this will require some work in the >>> toolstack, on the hypervisor side we

Re: [Xen-devel] Enabling VT-d PI by default

On Mon, May 15, 2017 at 2:35 PM, Andrew Cooper wrote: > On 15/05/17 11:27, George Dunlap wrote: >> On Fri, May 12, 2017 at 12:05 PM, Andrew Cooper >> wrote: >>> Citrix Netscalar SDX boxes have more MSI-X interrupts than fit in the >>> cumulative IDTs of a top end dual-socket Xeon server systems.

Re: [Xen-devel] [PATCH v2 4/5] VT-d PI: Adding reference count to pi_desc

On Thu, May 11, 2017 at 7:04 AM, Chao Gao wrote: > This patch intruduces a 'refcnt' field in vmx_pi_blocking to track > the reference count of 'pi_desc' of the vCPU. And change this field > every time we re-program one IRTE. > > Signed-off-by: Chao Gao > --- > xen/arch/x86/hvm/vmx/vmx.c

Re: [Xen-devel] [XEN-devel] arm64: fix incorrect pa_range_info table to support 42 bit PA systems.

Hello Feng, On 13/05/17 01:26, Feng Kan wrote: The pa_range_info table contain incorrect root_order and t0sz which prevent 42 bit PA systems from booting dom0. As I mentioned in the previous thread [1], this is not a bug. What you configure below is the stage-2 page table and not the hypervis

Re: [Xen-devel] [PATCH] x86/vvmx: Improvements to INVEPT instruction handling

On 08/02/17 07:46, Tian, Kevin wrote: >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Tuesday, February 07, 2017 12:55 AM >> >> * Latch current once at the start. >> * Avoid the memory operand read for INVEPT_ALL_CONTEXT. Experimentally, >> this >>is how hardware behaves,

Re: [Xen-devel] [PATCH v2 1/5] xentrace: add TRC_HVM_PI_LIST_ADD

On 11/05/17 07:04, Chao Gao wrote: > This patch adds TRC_HVM_PI_LIST_ADD to track adding one entry to > the per-pcpu blocking list. Also introduce a 'counter' to track > the number of entries in the list. So first of all, you have the importance of the order here backwards. The most important thin

Re: [Xen-devel] 4.9rc4: Cannot build with higher than -j4 - was: linux.c:27:28: fatal error: xen/sys/evtchn.h: No such file or directory

Hi George, CC Ian and Wei for feedback on the error. On 15/05/17 14:04, George Dunlap wrote: On Sun, May 14, 2017 at 10:50 AM, Steven Haigh wrote: On 10/05/17 23:02, Steven Haigh wrote: On 10/05/17 01:20, M A Young wrote: On Tue, 9 May 2017, Steven Haigh wrote: I'm trying to use the same

Re: [Xen-devel] [PATCH for-4.9 1/2] x86/pv: Fix the handling of `int $x` for vectors which alias exceptions

>>> On 15.05.17 at 14:50, wrote: > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -633,9 +633,12 @@ void pv_inject_event(const struct x86_event *event) > const struct trap_info *ti; > const uint8_t vector = event->vector; > const bool use_error_code = > +(event

Re: [Xen-devel] [PATCH for-4.9 2/2] x86/pv: Replace do_guest_trap() with pv_inject_hw_exception()

>>> On 15.05.17 at 14:50, wrote: > do_guest_trap() is now functionally equivelent to pv_inject_hw_exception(), > but with a less useful API as it requires the error code parameter to be > passed implicitly via cpu_user_regs. > > Extend pv_inject_event() with a further assertion which checks that

Re: [Xen-devel] [PATCH for-4.9 1/2] x86/pv: Fix the handling of `int $x` for vectors which alias exceptions

On 15/05/17 16:31, Jan Beulich wrote: On 15.05.17 at 14:50, wrote: >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -633,9 +633,12 @@ void pv_inject_event(const struct x86_event *event) >> const struct trap_info *ti; >> const uint8_t vector = event->vector; >>

Re: [Xen-devel] [PATCH v2 3/5] VT-d PI: restrict the vcpu number on a given pcpu

On Thu, May 11, 2017 at 7:04 AM, Chao Gao wrote: > Currently, a blocked vCPU is put in its pCPU's pi blocking list. If > too many vCPUs are blocked on a given pCPU, it will incur that the list > grows too long. After a simple analysis, there are 32k domains and > 128 vcpu per domain, thus about 4M

Re: [Xen-devel] [PATCH v2 3/5] VT-d PI: restrict the vcpu number on a given pcpu

On Mon, May 15, 2017 at 04:48:47PM +0100, George Dunlap wrote: >On Thu, May 11, 2017 at 7:04 AM, Chao Gao wrote: >> Currently, a blocked vCPU is put in its pCPU's pi blocking list. If >> too many vCPUs are blocked on a given pCPU, it will incur that the list >> grows too long. After a simple analy

Re: [Xen-devel] 4.9rc4: Cannot build with higher than -j4 - was: linux.c:27:28: fatal error: xen/sys/evtchn.h: No such file or directory

On Mon, May 15, 2017 at 04:29:31PM +0100, Julien Grall wrote: > Hi George, > > CC Ian and Wei for feedback on the error. > No you didn't. ;p I've tracked down the issue. Trying to work out a fix at the moment. The culprit is: stubdom build runs before tools build. The link farm rune in tools/i

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

On Sat, May 13, 2017 at 10:28:27AM +0800, Zhongze Liu wrote: > 2017-05-13 1:51 GMT+08:00 Wei Liu : > > Hi Zhongze > > > > This is a nice write-up. Some comments below. Feel free to disagree with > > what I say below, this is more a discussion than picking on your design > > or plan. > > > > HI, We

Re: [Xen-devel] [PATCH] include: fix build without C++ compiler installed

On Mon, May 15, 2017 at 01:02:48AM -0600, Jan Beulich wrote: > >>> On 12.05.17 at 18:20, wrote: > > On Fri, May 12, 2017 at 12:52:54AM -0600, Jan Beulich wrote: > >> The rule for headers++.chk wants to move headers++.chk.new to the > >> designated target, which means we have to create that file in

Re: [Xen-devel] [XEN-devel] arm64: fix incorrect pa_range_info table to support 42 bit PA systems.

On Mon, May 15, 2017 at 7:53 AM, Julien Grall wrote: > Hello Feng, > > On 13/05/17 01:26, Feng Kan wrote: >> >> The pa_range_info table contain incorrect root_order and t0sz which >> prevent 42 bit PA systems from booting dom0. > > > As I mentioned in the previous thread [1], this is not a bug. Wh

Re: [Xen-devel] [XEN-devel] arm64: fix incorrect pa_range_info table to support 42 bit PA systems.

Hi, On 15/05/17 18:11, Feng Kan wrote: On Mon, May 15, 2017 at 7:53 AM, Julien Grall wrote: Hello Feng, On 13/05/17 01:26, Feng Kan wrote: The pa_range_info table contain incorrect root_order and t0sz which prevent 42 bit PA systems from booting dom0. As I mentioned in the previous threa

[Xen-devel] Commit moratorium to staging

Committers, It looks like osstest is a bit behind because of ARM64 boxes (they are fully loaded) and XP testing (they now have been removed see [1]). I'd like to cut the next rc when staging == master, so please stop committing today. Ian forced pushed osstest today, so hopefully we can get

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On Mon, 15 May 2017, George Dunlap wrote: > [Reducing CC list now that we're off the topic of modules] > > On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk > wrote: > > Stefano, > > > > On 12 May 2017 at 21:43, Stefano Stabellini wrote: > > > >> On the topic of the technical reasons for being

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On Mon, 15 May 2017, George Dunlap wrote: > On Fri, May 12, 2017 at 7:47 PM, Volodymyr Babchuk > wrote: > >> Regarding modules (#3): The problem that loadable modules were > >> primarily introduced to solve in Linux wasn't "How to deal with > >> proprietary drivers", or even "how to deal with out-

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

On Mon, 15 May 2017, Jan Beulich wrote: > >>> On 15.05.17 at 12:21, wrote: > > On 05/15/2017 09:52 AM, Jan Beulich wrote: > > On 15.05.17 at 10:20, wrote: > >>> On 15/05/2017 09:08, Jan Beulich wrote: > >>> On 12.05.17 at 19:01, wrote: > >

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 2017-05-13 19:17, PGNet Dev wrote: On 5/13/17 3:15 PM, Valentin Vidic wrote: Try booting without 'hpet=force,verbose clocksource=hpet' and it should select xen by default: Nope. Well, not quite ... With both 'hpet=force,verbose clocksource=hpet' removed, I end up with ca

[Xen-devel] [linux-3.18 test] 109446: regressions - FAIL

flight 109446 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109446/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 7 host-ping-check-xen fail REGR. vs. 109161 test-amd64-i386-xl-q

[Xen-devel] [qemu-mainline test] 109445: regressions - FAIL

flight 109445 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/109445/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 5 xen-buildfail REGR. vs. 107636 build-arm64

Re: [Xen-devel] [PATCH v2 1/2] libxl/devd: fix a race with concurrent device addition/removal

On Mon, May 15, 2017 at 02:37:33PM +0100, Julien Grall wrote: > Hi Roger, > > On 11/05/17 12:43, Roger Pau Monne wrote: > > On Thu, May 11, 2017 at 12:06:08PM +0100, Ian Jackson wrote: > > > Roger Pau Monne writes ("[PATCH v2 1/2] libxl/devd: fix a race with > > > concurrent device addition/remov

Re: [Xen-devel] [Xen-users] UEFI Secure Boot Xen 4.9

> -Original Message- > From: Daniel Kiper [mailto:daniel.ki...@oracle.com] > Sent: Monday, May 15, 2017 6:13 AM > To: Bill Jacobs (billjac) ; george.dun...@citrix.com > Cc: xen-devel@lists.xen.org; xen-us...@lists.xen.org > Subject: Re: [Xen-users] UEFI Secure Boot Xen 4.9 > > Hey, > >

[Xen-devel] [xen-unstable test] 109441: regressions - FAIL

flight 109441 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/109441/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-winxpsp3 17 guest-start/win.repeat fail REGR. vs. 109165 Tests which ar

  1   2   >