Re: [PATCH] xen: avoid link error on ARM

On 04/03/2019 21:47, Arnd Bergmann wrote: > Building the privcmd code as a loadable module on ARM, we get > a link error due to the private cache management functions: > > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined! > > Move the code into a new file that is built along w

Re: [BUG linux-4.9.x] xen hotplug cpu leads to 100% steal usage

On 01/03/2019 03:35, Dongli Zhang wrote: > This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is > still in the lasted mainline kernel. > > This is obviated by new feature patch set ended with b672592f0221 > ("sched/cputime: Remove generic asm headers"). > > After xen guest

Re: [Xen-devel] xen/evtchn and forced threaded irq

On 21/02/2019 09:38, Julien Grall wrote: > Hi Roger, > > On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, > wrote: > > FWIW, you can also mask the interrupt while waiting for the thread to > execute the interrupt handler. Ie: > > > Thank you for providing steps,

Re: xen/evtchn and forced threaded irq

On 19/02/2019 18:31, Julien Grall wrote: > Hi all, > > I have been looking at using Linux RT in Dom0. Once the guest is started, > the console is ending to have a lot of warning (see trace below). > > After some investigation, this is because the irq handler will now be > threaded. > I can repro

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On 21/02/2019 00:39, Marek Marczykowski-Górecki wrote: > On Wed, Feb 20, 2019 at 08:15:30PM +, Joao Martins wrote: >> 2. PV Driver support (patches 17 - 39) >> >> We start by redirecting hypercalls from the backend to routines >> which emulate the behaviour that PV backends expect i.e. grant

Re: [Xen-devel][PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

On 14/02/2019 15:23, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > If there are exported DMA buffers which are still in use and > grant device is closed by either normal user-space close or by > a signal this leads to the grant device context to be destroyed, > thus making it

Re: [Xen-devel][PATCH 2/2] xen/gntdev: Check and release imported dma-bufs on close

On 14/02/2019 15:23, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Check if there are any imported dma-bufs left not released by > user-space when grant device's release callback is called and > free those if this is the case. This can happen if user-space > leaks the buffers

Re: [Xen-devel][PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

On 15/02/2019 16:35, Oleksandr Andrushchenko wrote: > On 2/15/19 5:28 PM, Boris Ostrovsky wrote: >> On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote: >>> On 2/15/19 5:03 PM, Boris Ostrovsky wrote: On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote: >      /* DMA buffer export support. */

[PATCH v3 1/2] x86: respect memory size limiting via mem= parameter

n adding PCI devices due to corresponding ACPI table entries. Not respecting "mem=" can be corrected by adding a global max_mem_size variable set by parse_memopt() which will result in rejecting adding memory areas resulting in a memory size above the allowed limit. Signed-off-by: Juerge

[PATCH v3 2/2] x86/xen: dont add memory above max allowed allocation

75241] [] phys_pmd_init+0x210/0x255 [ 584.681587] [] phys_pud_init+0x1da/0x247 [ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4 [ 584.695682] [] init_memory_mapping+0x18d/0x380 [ 584.702631] [] arch_add_memory+0x59/0xf0 Signed-off-by: Juergen Gross --- arch/x86/xen/setup.c

[PATCH v3 0/2] x86: respect memory size limits

owed size to U64_MAX instead -1 - patch 2: set initial allowed size to end of E820 RAM Juergen Gross (2): x86: respect memory size limiting via mem= parameter x86/xen: dont add memory above max allowed allocation arch/x86/kernel/e820.c | 5 + arch/x86/xen/setup.c | 13 ++

Re: [PATCH] xen: mark expected switch fall-through

On 13/02/2019 00:50, Boris Ostrovsky wrote: > On Tue, Feb 12, 2019 at 02:37:20PM -0600, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch >> cases where we are expecting to fall through. >> >> This patch fixes the following warning: >> >> drivers/xen/xen-p

Re: [Xen-devel] [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter

On 11/02/2019 13:23, Ingo Molnar wrote: > > * Juergen Gross wrote: > >>> If PCI devices had physical mmio memory areas above this range, we'd >>> still expect them to work - the option was really only meant to limit >>> RAM. >> >> No, in

Re: [Xen-devel] [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter

On 11/02/2019 13:06, Ingo Molnar wrote: > > * Juergen Gross wrote: > >> When limiting memory size via kernel parameter "mem=" this should be >> respected even in case of memory made accessible via a PCI card. >> >> Today this kind of memory won't

Re: [PATCH] x86: make set_pmd_at() paravirt aware

On 10/02/2019 19:14, Linus Torvalds wrote: > On Sat, Feb 9, 2019 at 11:41 PM Juergen Gross wrote: >> >> Make set_pmd_at() paravirt aware by just letting it use set_pmd(). > > Well, that was simpler than I worried. > > Just checking: Is this purely an x86 issue

[tip:x86/urgent] x86/mm: Make set_pmd_at() paravirt aware

Commit-ID: 20e55bc17dd01f13cec0eb17e76e9511b23963ef Gitweb: https://git.kernel.org/tip/20e55bc17dd01f13cec0eb17e76e9511b23963ef Author: Juergen Gross AuthorDate: Sun, 10 Feb 2019 08:40:56 +0100 Committer: Thomas Gleixner CommitDate: Sun, 10 Feb 2019 08:47:12 +0100 x86/mm: Make

[PATCH] x86: make set_pmd_at() paravirt aware

x on large regions") Reported-by: Sander Eikelenboom Signed-off-by: Juergen Gross --- arch/x86/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 40616e805292..2779ace16d23 100644

Re: Linux 5.0 regression: BUG: unable to handle kernel paging request at ffff888023e26778 RIP: e030:move_page_tables+0x7c1/0xae0

On 09/02/2019 19:51, Sander Eikelenboom wrote: > On 09/02/2019 19:48, Juergen Gross wrote: >> On 09/02/2019 19:45, Sander Eikelenboom wrote: >>> On 09/02/2019 09:26, Sander Eikelenboom wrote: >>>> L.S., >>>> >>>> >>>> Whil

Re: Linux 5.0 regression: BUG: unable to handle kernel paging request at ffff888023e26778 RIP: e030:move_page_tables+0x7c1/0xae0

On 09/02/2019 19:45, Sander Eikelenboom wrote: > On 09/02/2019 09:26, Sander Eikelenboom wrote: >> L.S., >> >> >> While testing a Linux 5.0-rc5-ish kernel (pull of yesterday) with some >> additional patches for >> already reported other issues i came across the issue below which i haven't >> seen

[GIT PULL] xen: fixes for 5.0-rc6

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.0-rc6-tag xen: fixes for 5.0-rc6 It contains two very minor fixes: one remove of a #include for an unused header and a fix of the xen ML address in MAINTAINERS. Thanks. Juergen M

Re: [PATCH v2 2/2] x86/xen: dont add memory above max allowed allocation

On 01/02/2019 19:46, Boris Ostrovsky wrote: > On 1/30/19 3:22 AM, Juergen Gross wrote: >> Don't allow memory to be added above the allowed maximum allocation >> limit set by Xen. >> >> Trying to do so would result in cases like the following: >> &g

Re: RIP: e030:move_page_tables+0xaa3/0xb80

On 02/02/2019 05:37, Christian Kujau wrote: > Hi, > > I'm running an Ubuntu "mainline" kernel[0] as a Xen 4.11.1 DomU (PV) and > ever since upgrading to Linux 5.0-rcX I get these WARNING messages shown > below. Going back in my logs[1] I can see that I got a similar messages > for v4.20 too, bu

Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules

On 01/02/2019 09:39, Oleksandr Andrushchenko wrote: > On 1/31/19 11:44 PM, Stefano Stabellini wrote: >> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote: >>> Hello, >>> >>> I am working on porting an out-of-tree kernel driver to the kernel >>> 5.0 and that driver uses functionality provided by >>

[PATCH v2 0/2] x86: respect memory size limits

s problems (e.g. avoiding to add only parts of a 128MB memory bar which might be difficult to remove later). Changes in V2: - patch 1: set initial allowed size to U64_MAX instead -1 - patch 2: set initial allowed size to end of E820 RAM Juergen Gross (2): x86: respect memory size limiting via mem= para

[PATCH v2 2/2] x86/xen: dont add memory above max allowed allocation

75241] [] phys_pmd_init+0x210/0x255 [ 584.681587] [] phys_pud_init+0x1da/0x247 [ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4 [ 584.695682] [] init_memory_mapping+0x18d/0x380 [ 584.702631] [] arch_add_memory+0x59/0xf0 Signed-off-by: Juergen Gross --- arch/x86/xen/setup.c

[PATCH v2 1/2] x86: respect memory size limiting via mem= parameter

n adding PCI devices due to corresponding ACPI table entries. Not respecting "mem=" can be corrected by adding a global max_mem_size variable set by parse_memopt() which will result in rejecting adding memory areas resulting in a memory size above the allowed limit. Signed-off-by: Juerg

Re: [PATCH 1/2] x86: respect memory size limiting via mem= parameter

On 23/01/2019 15:35, William Kucharski wrote: > > >> On Jan 22, 2019, at 1:06 AM, Juergen Gross wrote: >> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >> index b9a667d36c55..7fc2a87110a3 100644 >> --- a/mm/memory_hotplug.c >> +++ b/mm/me

Re: [PATCH 6/6] x86: xen: no need to check return value of debugfs_create functions

On 22/01/2019 15:35, Greg Kroah-Hartman wrote: > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Cc: Boris Ostrovsky > Cc: Juergen Gr

Re: [Xen-devel] [PATCH 2/2] x86/xen: dont add memory above max allowed allocation

On 22/01/2019 09:52, Jan Beulich wrote: On 22.01.19 at 09:06, wrote: >> Don't allow memory to be added above the allowed maximum allocation >> limit set by Xen. > > This reads as if the hypervisor was imposing a limit here, but looking at > xen_get_max_pages(), xen_foreach_remap_area(), and

[PATCH 1/2] x86: respect memory size limiting via mem= parameter

n adding PCI devices due to corresponding ACPI table entries. Not respecting "mem=" can be corrected by adding a global max_mem_size variable set by parse_memopt() which will result in rejecting adding memory areas resulting in a memory size above the allowed limit. Signed-off-by: Juerg

[PATCH 0/2] x86: respect memory size limits

s problems (e.g. avoiding to add only parts of a 128MB memory bar which might be difficult to remove later). Juergen Gross (2): x86: respect memory size limiting via mem= parameter x86/xen: dont add memory above max allowed allocation arch/x86/kernel/e820.c | 5 + arch/x86/xen/setup.

[PATCH 2/2] x86/xen: dont add memory above max allowed allocation

75241] [] phys_pmd_init+0x210/0x255 [ 584.681587] [] phys_pud_init+0x1da/0x247 [ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4 [ 584.695682] [] init_memory_mapping+0x18d/0x380 [ 584.702631] [] arch_add_memory+0x59/0xf0 Signed-off-by: Juergen Gross --- arch/x86/xen/setup.c | 5 + 1

[GIT PULL] xen: fixes for 5.0-rc3

| 2 +- drivers/xen/pvcalls-back.c | 9 ++-- drivers/xen/pvcalls-front.c | 104 --- 5 files changed, 90 insertions(+), 42 deletions(-) Juergen Gross (1): xen: Fix x86 sched_clock() interface for xen Stefano Stabellini (5): pvcalls-front

Re: [PATCH v15 5/6] x86/boot: Parse SRAT address from RSDP and store immovable memory

On 17/01/2019 09:22, Kairui Song wrote: > On Thu, Jan 17, 2019 at 3:58 PM Chao Fan wrote: >> >> On Wed, Jan 16, 2019 at 03:28:52PM +0800, Kairui Song wrote: >>> On Mon, Jan 7, 2019 at 11:24 AM Chao Fan wrote: + +/* Determine RSDP, based on acpi_os_get_root_pointer(). */ +stati

Re: [PATCH v3] xen: Fix x86 sched_clock() interface for xen

On 16/01/2019 16:07, Boris Ostrovsky wrote: > On 1/16/19 9:33 AM, Juergen Gross wrote: >> On 16/01/2019 14:17, Boris Ostrovsky wrote: >>> On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote: >>> >>>> @@ -1650,13 +1

Re: [PATCH v3] xen: Fix x86 sched_clock() interface for xen

On 16/01/2019 14:17, Boris Ostrovsky wrote: > On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote: > >> @@ -1650,13 +1650,14 @@ void xen_callback_vector(void) >> xen_have_vector_callback = 0; >>

Re: [Xen-devel] [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()

u bytes align=0x%lx\n", __func__, > size, align); > > Signed-off-by: Mike Rapoport For the Xen part: Reviewed-by: Juergen Gross Juergen

Re: [PATCH v3] x86-64/Xen: fix stack switching

y() and nmi(), as > those code paths are unreachable afaict when running PV Xen guests. > > Fixes: 7f2590a110b837af5679d08fc25c6227c5a8c497 > Signed-off-by: Jan Beulich > Cc: sta...@kernel.org Reviewed-by: Juergen Gross Juergen

Re: [PATCH v3] xen: Fix x86 sched_clock() interface for xen

On 16/01/2019 01:24, Hans van Kranenburg wrote: > Hi, > > On 1/14/19 1:44 PM, Juergen Gross wrote: >> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' >> sched_clock() interface") broke Xen guest time handling across >> migr

Re: [PATCH v3] xen: Fix x86 sched_clock() interface for xen

On 15/01/2019 11:43, Thomas Gleixner wrote: > On Mon, 14 Jan 2019, Juergen Gross wrote: > >> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' >> sched_clock() interface") broke Xen guest time handling across >> migration: >&g

Re: [PATCH] x86/mm/mem_encrypt_identity : fix error useage to sizeof

On 15/01/2019 11:25, Thomas Gleixner wrote: > On Tue, 15 Jan 2019, Juergen Gross wrote: >> On 15/01/2019 11:13, Thomas Gleixner wrote: >>> On Mon, 7 Jan 2019, peng.h...@zte.com.cn wrote: >>> >>>>>> Fix error usage to sizeof. It should not us

Re: [PATCH] x86/mm/mem_encrypt_identity : fix error useage to sizeof

On 15/01/2019 11:13, Thomas Gleixner wrote: > On Mon, 7 Jan 2019, peng.h...@zte.com.cn wrote: > Fix error usage to sizeof. It should not use sizeof to pointer. >>> >>> because? >>> >>> The commit message needs to explain what the potential issue could be >>> and why it doesn't matter in

[PATCH v3] xen: Fix x86 sched_clock() interface for xen

ity to 16777216 Fix that by setting xen_sched_clock_offset at resume time to ensure a monotonic clock value. Fixes: f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") Cc: # 4.11 Reported-by: Hans van Kranenburg Signed-off-by: Juer

Re: [PATCH v2] xen: Fix x86 sched_clock() interface for xen

On 11/01/2019 21:35, Boris Ostrovsky wrote: > On 1/11/19 7:08 AM, Juergen Gross wrote: >> @@ -421,6 +424,11 @@ void xen_restore_time_memory_area(void) >> if (ret != 0) >> pr_notice("Cannot restore secondary vcpu_time_info (err %d)", >>

Re: [PATCH] MAINTAINERS: unify reference to xen-devel list

-de...@lists.xen.org instead, but that is just the same > mailing list as the mailing list above. > > Signed-off-by: Lukas Bulwahn Reviewed-by: Juergen Gross Juergen

Re: [Xen-devel] [PATCH v2] xen: Fix x86 sched_clock() interface for xen

On 11/01/2019 14:12, Hans van Kranenburg wrote: > Hi, > > On 1/11/19 1:08 PM, Juergen Gross wrote: >> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' >> sched_clock() interface") broke Xen guest time handling across >> migr

[PATCH v2] xen: Fix x86 sched_clock() interface for xen

ity to 16777216 Fix that by setting xen_sched_clock_offset at resume time to ensure a monotonic clock value. Fixes: f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") Cc: # 4.11 Reported-by: Hans van Kranenburg Signed-off-by: Juer

Re: [PATCH] xen: Fix x86 sched_clock() interface for xen

On 11/01/2019 08:15, Juergen Gross wrote: > On 11/01/2019 00:10, Boris Ostrovsky wrote: >> On 1/10/19 12:17 PM, Boris Ostrovsky wrote: >>> On 1/10/19 11:14 AM, Juergen Gross wrote: >>>> On 10/01/2019 16:34, Boris Ostrovsky wrote: >>>>> On 1/10/19 5:07 A

Re: [PATCH] xen: Fix x86 sched_clock() interface for xen

On 11/01/2019 00:10, Boris Ostrovsky wrote: > On 1/10/19 12:17 PM, Boris Ostrovsky wrote: >> On 1/10/19 11:14 AM, Juergen Gross wrote: >>> On 10/01/2019 16:34, Boris Ostrovsky wrote: >>>> On 1/10/19 5:07 AM, Juergen Gross wrote: >>>>&g

Re: [PATCH] xen: Fix x86 sched_clock() interface for xen

On 10/01/2019 16:34, Boris Ostrovsky wrote: > On 1/10/19 5:07 AM, Juergen Gross wrote: >> >> +void xen_clocksource_suspend(void) >> +{ >> +xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset; > > > xen_clock_value_saved =

[PATCH] xen: Fix x86 sched_clock() interface for xen

ity to 16777216 Fix that by setting xen_sched_clock_offset at resume time to ensure a monotonic clock value. Fixes: f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") Cc: # 4.11 Reported-by: Hans van Kranenburg Signed-off-by: Juergen

Re: [PATCH 13/20] xenbus: drop useless LIST_HEAD

://coccinelle.lip6.fr/) > > // > @@ > identifier x; > @@ > - LIST_HEAD(x); > ... when != x > // > > Fixes: 1107ba885e46 ("xen: add xenfs to allow usermode <-> Xen interaction") > Signed-off-by: Julia Lawall Reviewed-by: Juergen Gross Juergen

Re: [RFC PATCH 4/4] x86/mm: remove bottom-up allocation style for x86_64

On 08/01/2019 07:13, Pingfan Liu wrote: > On Tue, Jan 8, 2019 at 1:42 AM Dave Hansen wrote: >> >> On 1/7/19 12:24 AM, Pingfan Liu wrote: >>> There are two acheivements by this patch. >>> -1st. keep the subtree of pgtable away from movable node. >>> Background about the defect of the current bottom

[GIT PULL] xen: features and fixes for 4.21

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.21-rc1-tag xen: features and fixes for 4.21 It contains the following changes: - a series to enable KVM guests to be booted by qemu via the Xen PVH boot entry for speeding up KVM

Re: [PATCH] xen/netfront: tolerate frags with no data

On 19/12/2018 07:00, David Miller wrote: > From: Juergen Gross > Date: Tue, 18 Dec 2018 16:06:19 +0100 > >> At least old Xen net backends seem to send frags with no real data >> sometimes. In case such a fragment happens to occur with the frag limit >> already re

[PATCH] xen/netfront: tolerate frags with no data

...@vger.kernel.org Tested-by: Dietmar Hahn Signed-off-by: Juergen Gross --- drivers/net/xen-netfront.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index f17f602e6171..5b97cc946d70 100644 --- a/drivers/net/xen-netfront.c +++ b

Re: [PATCH -next] x86/xen: Fix read buffer overflow

On 18/12/2018 09:19, YueHaibing wrote: > Fix smatch warning: > > arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error: > buffer overflow 'early_idt_handler_array' 32 <= 32 > > Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guests") > Signed-off-by: YueHaibing > --- > arch/x

Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 07/12/2018 14:52, Paolo Bonzini wrote: > On 07/12/18 14:50, Juergen Gross wrote: >> The PVH boot entry is in the same bzImage binary as the normal one. >> Its just another entry, similar to the Xen PV boot entry. So the binary >> arch/x86/boot/bzimage can be booted eit

Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 07/12/2018 14:41, Paolo Bonzini wrote: > On 07/12/18 07:02, Juergen Gross wrote: >> On 06/12/2018 23:11, Paolo Bonzini wrote: >>> On 06/12/18 07:04, Maran Wilson wrote: >>>> +config PVH >>>> + bool "Support for running PVH guests" >>&g

Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 06/12/2018 23:11, Paolo Bonzini wrote: > On 06/12/18 07:04, Maran Wilson wrote: >> +config PVH >> +bool "Support for running PVH guests" >> +---help--- >> + This option enables the PVH entry point for guest virtual machines >> + as specified in the x86/HVM direct boot ABI. >> +

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

On 04/12/2018 06:49, H. Peter Anvin wrote: > On 12/3/18 9:32 PM, Juergen Gross wrote: >> >> I'd like to send a followup patch doing that. And I'd like to not only >> test sentinel for being non-zero, but all padding fields as well. This >> should be 4.21 mater

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

On 04/12/2018 00:07, h...@zytor.com wrote: > On December 3, 2018 2:38:11 AM PST, Juergen Gross wrote: >> In case a broken boot loader doesn't clear its struct boot_params clear >> rsdp_addr in sanitize_boot_params(). >> >> This fixes commit e6e094e053af75

[tip:x86/urgent] x86/boot: Clear RSDP address in boot_params for broken loaders

Commit-ID: 182ddd16194cd082f25fa1b063dae3c7c5cce384 Gitweb: https://git.kernel.org/tip/182ddd16194cd082f25fa1b063dae3c7c5cce384 Author: Juergen Gross AuthorDate: Mon, 3 Dec 2018 11:38:11 +0100 Committer: Ingo Molnar CommitDate: Mon, 3 Dec 2018 11:56:37 +0100 x86/boot: Clear RSDP

[PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available") Reported-by: Gunnar Krueger Tested-by: Gunnar Krueger Signed-off-by: Juergen Gross --- arch/x86/include/asm/bootparam_utils.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/bootparam_ut

Re: [PATCH 1/2] x86/mm: Fix guard hole handling

On 30/11/2018 13:11, Kirill A. Shutemov wrote: > On Fri, Nov 30, 2018 at 12:03:33PM +0000, Juergen Gross wrote: >> On 30/11/2018 12:57, Kirill A. Shutemov wrote: >>> There is a guard hole at the beginning of kernel address space, also >>> used by hypervisors. It occupies

Re: [PATCH 1/2] x86/mm: Fix guard hole handling

On 30/11/2018 12:57, Kirill A. Shutemov wrote: > There is a guard hole at the beginning of kernel address space, also > used by hypervisors. It occupies 16 PGD entries. > > We do not state the reserved range directly, but calculate it relative > to other entities: direct mapping and user space ran

Re: arch/x86/include/asm/cmpxchg.h:245:2: error: 'asm' operand has impossible constraints

On 30/11/2018 07:44, kbuild test robot wrote: > Hi Juergen, > > FYI, the error/warning still remains. This problem is one of gcc. It is in no way the (direct) result of my patch. Please see my gcc bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908154 Juergen > > tree: https:

Re: [PATCH] pvcalls-front: Use GFP_ATOMIC under spin_lock

On 29/11/2018 13:01, Wen Yang wrote: > The problem is that we call this with a spin lock held. > The call tree is: > pvcalls_front_accept() holds bedata->socket_lock. > -> create_active() > -> __get_free_pages() uses GFP_KERNEL > > The create_active() function is only called from pvcal

Re: [PATCH] Revert "xen/balloon: Mark unallocated host memory as UNUSABLE"

On 27/11/2018 21:58, Igor Druzhinin wrote: > This reverts commit b3cf8528bb21febb650a7ecbf080d0647be40b9f. > > That commit unintentionally broke Xen balloon memory hotplug with > "hotplug_unpopulated" set to 1. As long as "System RAM" resource > got assigned under a new "Unusable memory" resource

Re: [PATCH] pvcalls-front: fixes incorrect error handling

On 22/11/2018 03:07, Pan Bian wrote: > kfree() is incorrectly used to release the pages allocated by > __get_free_page() and __get_free_pages(). Use the matching deallocators > i.e., free_page() and free_pages(), respectively. > > Signed-off-by: Pan Bian Pushed to xen/tip.git for-linus-4.20a J

Re: [PATCH] xen/x86: add diagnostic printout to xen_mc_flush() in case of error

On 26/11/2018 21:11, Boris Ostrovsky wrote: > On 11/23/18 11:24 AM, Juergen Gross wrote: >> Failure of an element of a Xen multicall is signalled via a WARN() >> only unless the kernel is compiled with MC_DEBUG. It is impossible to > > s/unless/if > > >> know wh

[PATCH] xen/x86: add diagnostic printout to xen_mc_flush() in case of error

. without information which caller produced the failing element). Move the printing out of the switch statement in order to have the same information for a single call. Signed-off-by: Juergen Gross --- arch/x86/xen/multicalls.c | 35 --- 1 file changed, 20 insertions

[tip:x86/urgent] x86/boot: Mostly revert commit ae7e1238e68f2a ("Add ACPI RSDP address to setup_header")

Commit-ID: 3841840449817ba6cf3e636008bc4e1061a03388 Gitweb: https://git.kernel.org/tip/3841840449817ba6cf3e636008bc4e1061a03388 Author: Juergen Gross AuthorDate: Tue, 20 Nov 2018 08:25:28 +0100 Committer: Ingo Molnar CommitDate: Tue, 20 Nov 2018 09:43:10 +0100 x86/boot: Mostly revert

[tip:x86/urgent] x86/acpi, x86/boot: Take RSDP address from boot params if available

Commit-ID: e6e094e053af75cbc164e950814d3d084fb1e698 Gitweb: https://git.kernel.org/tip/e6e094e053af75cbc164e950814d3d084fb1e698 Author: Juergen Gross AuthorDate: Tue, 20 Nov 2018 08:25:29 +0100 Committer: Ingo Molnar CommitDate: Tue, 20 Nov 2018 09:43:11 +0100 x86/acpi, x86/boot: Take

[PATCH 2/2] x86/acpi, x86/boot: Take RSDP address from boot params if available

In case the RSDP address in struct boot_params is specified don't try to find the table by searching, but take the address directly as set by the boot loader. Signed-off-by: Juergen Gross --- arch/x86/include/uapi/asm/bootparam.h | 3 ++- arch/x86/kernel/acpi/boot.c | 2 +- 2

[PATCH] x86/xen: cleanup includes in arch/x86/xen/spinlock.c

arch/x86/xen/spinlock.c includes several headers which are not needed. Remove the #includes. Signed-off-by: Juergen Gross --- arch/x86/xen/spinlock.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 1c8a8816a402

Re: [PATCH v1 4/8] xen/balloon: mark inflated pages PG_offline

On 19/11/2018 11:16, David Hildenbrand wrote: > Mark inflated and never onlined pages PG_offline, to tell the world that > the content is stale and should not be dumped. > > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: Stefano Stabellini > Cc: Andrew Morton > Cc: Matt

Re: [PATCH v2] x86/build: Build VSMP support only if CONFIG_PCI is selected

EST and PARAVIRT is a little bit strange, you can add: Reviewed-by: Juergen Gross Juergen

Re: [PATCH] x86/build: Build VSMP support only if selected

On 01/11/2018 16:09, Eial Czerwacki wrote: > Greetings, > > On 11/01/2018 03:45 PM, Juergen Gross wrote: >> On 01/11/2018 14:10, Eial Czerwacki wrote: >>> Greetings, >>> >>> On 11/01/2018 12:39 PM, Shai Fultheim (s...@scalemp.com) wrote: >

Re: [PATCH] x86/build: Build VSMP support only if selected

On 01/11/2018 14:10, Eial Czerwacki wrote: > Greetings, > > On 11/01/2018 12:39 PM, Shai Fultheim (s...@scalemp.com) wrote: >> On 01/11/18 11:37, Thomas Gleixner wrote: >> >>> VSMP support is built even if CONFIG_X86_VSMP is not set. This leads to a >>> build >>> breakage when CONFIG_PCI is disab

Re: x86/paravirt: Use a single ops structure

On 30/10/2018 14:33, Marc Dionne wrote: > On Mon, Oct 29, 2018 at 11:25 AM Juergen Gross wrote: >> >> On 29/10/2018 13:58, Marc Dionne wrote: >>> On Tue, Oct 23, 2018 at 2:37 PM Linux Kernel Mailing List >>> wrote: >>>> >>>> Commit:

[tip:x86/urgent] x86/paravirt: Remove unused _paravirt_ident_32

Commit-ID: 7847c7be0481558f17e3ef3b03f573677fd30d29 Gitweb: https://git.kernel.org/tip/7847c7be0481558f17e3ef3b03f573677fd30d29 Author: Juergen Gross AuthorDate: Tue, 30 Oct 2018 07:33:01 +0100 Committer: Ingo Molnar CommitDate: Tue, 30 Oct 2018 09:55:31 +0100 x86/paravirt: Remove

[tip:x86/urgent] x86/paravirt: Remove GPL from pv_ops export

Commit-ID: 8af1909580595a303b03d5999e410d407b7a6db7 Gitweb: https://git.kernel.org/tip/8af1909580595a303b03d5999e410d407b7a6db7 Author: Juergen Gross AuthorDate: Mon, 29 Oct 2018 16:01:16 +0100 Committer: Thomas Gleixner CommitDate: Mon, 29 Oct 2018 19:04:05 +0100 x86/paravirt: Remove

Re: x86/paravirt: Use a single ops structure

aster >> Web: >> https://git.kernel.org/torvalds/c/5c83511bdb9832c86be20fb86b783356e2f58062 >> Author: Juergen Gross >> AuthorDate: Tue Aug 28 09:40:19 2018 +0200 >> Committer: Thomas Gleixner >> CommitDate: Mon Sep 3 16:50:35 2018 +0200 >> >> x8

Re: [PATCH] x86/ioremap: tighten integer overflow checking

On 25/10/2018 08:16, Dan Carpenter wrote: > The current check is a bit off in the case where "phys_addr + size" > wraps to zero because then "last_addr" is set to ULONG_MAX which is >= > phys_addr. And -2 would be okay? For 32-bit systems I believe ULONG_MAX is a perfectly valid physical address.

Re: [PATCH] xen: remove redundant 'default n' from Kconfig

On 16/10/2018 16:33, Bartlomiej Zolnierkiewicz wrote: > 'default n' is the default value for any bool or tristate Kconfig > setting so there is no need to write it explicitly. > > Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO > is not set' for visible symbols") the Kconfig beh

Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall

On 22/10/2018 03:53, Yi Sun wrote: > On 18-10-19 16:20:52, Juergen Gross wrote: >> On 19/10/2018 15:13, Yi Sun wrote: > > [...] > >>> diff --git a/kernel/locking/qspinlock_paravirt.h >>> b/kernel/locking/qspinlock_paravirt.h >>> index 013

Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall

commended number is 0x, never retry. > > Signed-off-by: Yi Sun > Cc: "K. Y. Srinivasan" > Cc: Haiyang Zhang > Cc: Stephen Hemminger > Cc: Thomas Gleixner > Cc: Michael Kelley (EOSG) > Cc: Juergen Gross > --- > arch/x86/hyperv/hv_spinlock.c

Re: [PATCH] x86: modify inline asm constraints in __cmpxchg_double()

On 16/10/2018 10:01, Ingo Molnar wrote: > > * Juergen Gross wrote: > >> On 16/10/2018 08:25, Ingo Molnar wrote: >>> >>> * Juergen Gross wrote: >>> >>>> Some gcc versions seem to have problems with the constraints in >>>> _

Re: [PATCH] x86: modify inline asm constraints in __cmpxchg_double()

On 16/10/2018 08:25, Ingo Molnar wrote: > > * Juergen Gross wrote: > >> Some gcc versions seem to have problems with the constraints in >> __cmpxchg_double() as they suddenly issue a build error when random >> parts of sources calling __cmpxchg_double() are modified

[PATCH] x86: modify inline asm constraints in __cmpxchg_double()

"a" in the input constraints has the same semantics while avoiding that build error. Signed-off-by: Juergen Gross --- I should note that I have observed gcc hangs instead sometimes. Not taking any patches modifying users of __cmpxchg_double() due to a gcc bug which seems to be distro-specif

Re: [PATCH] mm: Speed up mremap on large regions

On 12/10/2018 07:34, Jann Horn wrote: > On Fri, Oct 12, 2018 at 7:29 AM Juergen Gross wrote: >> On 12/10/2018 05:21, Jann Horn wrote: >>> +cc xen maintainers and kvm folks >>> >>> On Fri, Oct 12, 2018 at 4:40 AM Joel Fernandes (Google) >>> wrote:

Re: [PATCH] mm: Speed up mremap on large regions

On 12/10/2018 05:21, Jann Horn wrote: > +cc xen maintainers and kvm folks > > On Fri, Oct 12, 2018 at 4:40 AM Joel Fernandes (Google) > wrote: >> Android needs to mremap large regions of memory during memory management >> related operations. The mremap system call can be really slow if THP is >>

Re: [Xen-devel] [PATCH] xen: drop writing error messages to xenstore

On 10/10/2018 18:57, Boris Ostrovsky wrote: > On 10/10/18 11:53 AM, Juergen Gross wrote: >> On 10/10/2018 17:09, Joao Martins wrote: >>> On 10/09/2018 05:09 PM, Juergen Gross wrote: >>>> xenbus_va_dev_error() will try to write error messages to Xenstore >>

[PATCH v4 0/3] x86: make rsdp address accessible via boot params

order to support an arbitrary RSDP address this patch series adds the physical address of the RSDP to the boot params structure filled by the boot loader. Juergen Gross (3): x86/xen: fix boot loader version reported for pvh guests x86/boot: add acpi rsdp address to setup_header x86/acpi

[PATCH v4 2/3] x86/boot: add acpi rsdp address to setup_header

lobbered. Signed-off-by: Juergen Gross --- V3: fix commit message and some documentation bits (Ingo Molnar) V4: add version feedback from bootloader --- Documentation/x86/boot.txt| 32 +++- arch/x86/boot/header.S| 6 +- arch/x86/inc

[PATCH v4 3/3] x86/acpi: take rsdp address for boot params if available

In case the rsdp address in struct boot_params is specified don't try to find the table by searching, but take the address directly as set by the boot loader. Signed-off-by: Juergen Gross --- V3: use a generic retrieval function with a __weak annotated default function (Ingo Molnar

Re: [PATCH v4 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

t; Cc: Michael Kelley (EOSG) > Cc: Juergen Gross > Signed-off-by: Yi Sun Reviewed-by: Juergen Gross Juergen

Re: [tip:x86/hyperv] x86/hyperv: Enable PV qspinlock for Hyper-V

Sorry for noticing this only now, but I have been fighting with Xen PV qspinlocks last weekend: On 02/10/2018 13:28, tip-bot for Yi Sun wrote: > Commit-ID: aaa7fc34c003bd8133a49f7634480cef6288ad55 > Gitweb: > https://git.kernel.org/tip/aaa7fc34c003bd8133a49f7634480cef6288ad55 > Author: Y

Re: [PATCH v2] x86/mm: Expand static page table for fixmap space

g max_pfn) > /* L3_k[511] -> level2_fixmap_pgt */ > convert_pfn_mfn(level3_kernel_pgt); > > - /* L3_k[511][506] -> level1_fixmap_pgt */ > + /* L3_k[507, 508 - FIXMAP_PMD_NUM] -> level1_fixmap_pgt */ You messed up the comment. The [511] must not be dropped. I would swap the "508 - FIXMAP_PMD_NUM" and "507" in order to start with the lower index, and replace "," by "...": + /* L3_k[511][508-FIXMAP_PMD_NUM ... 507] -> level1_fixmap_pgt */ With that corrected you can have my: Reviewed-by: Juergen Gross (Xen parts) Juergen

<    1   2   3   4   5   6   7   8   9   10   >