Re: [PATCH] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

On 11/27/2017 02:22 PM, Juergen Gross wrote: > On 27/11/17 19:05, Boris Ostrovsky wrote: >> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make >> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses >> eflags using 'pushfq' instruction

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: > > > On 11/23/2017 03:11 AM, Christian König wrote: >> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: >>> On 11/22/2017 11:54 AM, Christian König wrote: >>>> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: > > > On 11/23/2017 03:11 AM, Christian König wrote: >> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: >>> On 11/22/2017 11:54 AM, Christian König wrote: >>>> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >

[PATCH] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op when running paravirt. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/entry/entry_64.S|5 ++--- arch/x86/include/asm/irqflags.h |3 +++ arch/x86/include/asm/paravirt.h |9 +++

[PATCH] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op when running paravirt. Signed-off-by: Boris Ostrovsky --- arch/x86/entry/entry_64.S|5 ++--- arch/x86/include/asm/irqflags.h |3 +++ arch/x86/include/asm/paravirt.h |9 + arch/x86/kernel/asm-offsets_6

Re: Xen PV breakage after IRQ stack code refactoring

On 11/27/2017 12:34 AM, Juergen Gross wrote: > On 27/11/17 05:03, Andy Lutomirski wrote: >> On Sun, Nov 26, 2017 at 9:10 AM, Boris Ostrovsky >> <boris.ostrov...@oracle.com> wrote: >>> Andy, >>> >>> (Can't find the original patch in my mailbox) &g

Re: Xen PV breakage after IRQ stack code refactoring

On 11/27/2017 12:34 AM, Juergen Gross wrote: > On 27/11/17 05:03, Andy Lutomirski wrote: >> On Sun, Nov 26, 2017 at 9:10 AM, Boris Ostrovsky >> wrote: >>> Andy, >>> >>> (Can't find the original patch in my mailbox) >>> >>> This hunk fr

Xen PV breakage after IRQ stack code refactoring

Andy, (Can't find the original patch in my mailbox) This hunk from 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them NMI-safe") diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index a9a8027..0d4483a 100644 --- a/arch/x86/entry/entry_64.S +++

Xen PV breakage after IRQ stack code refactoring

Andy, (Can't find the original patch in my mailbox) This hunk from 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them NMI-safe") diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index a9a8027..0d4483a 100644 --- a/arch/x86/entry/entry_64.S +++

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/23/2017 03:11 AM, Christian König wrote: Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: On 11/22/2017 05:09 AM, Christian König wrote: Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/23/2017 03:11 AM, Christian König wrote: Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: On 11/22/2017 05:09 AM, Christian König wrote: Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/22/2017 11:54 AM, Christian König wrote: > Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >> On 11/22/2017 05:09 AM, Christian König wrote: >>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >>>> On 11/21/2017 08:34 AM, Christian König wrote: >>>&g

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/22/2017 11:54 AM, Christian König wrote: > Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >> On 11/22/2017 05:09 AM, Christian König wrote: >>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >>>> On 11/21/2017 08:34 AM, Christian König wrote: >>>&g

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/22/2017 05:09 AM, Christian König wrote: > Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >> On 11/21/2017 08:34 AM, Christian König wrote: >>> Hi Boris, >>> >>> attached are two patches. >>> >>> The first one is a trivial fix fo

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/22/2017 05:09 AM, Christian König wrote: > Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >> On 11/21/2017 08:34 AM, Christian König wrote: >>> Hi Boris, >>> >>> attached are two patches. >>> >>> The first one is a trivial fix fo

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

l problem was (on Xen)? Thanks. -boris > > Thanks for the help, > Christian. > > Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky: >> On 11/20/2017 11:07 AM, Christian König wrote: >>> Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky: >>>> (and then it breaks d

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

l problem was (on Xen)? Thanks. -boris > > Thanks for the help, > Christian. > > Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky: >> On 11/20/2017 11:07 AM, Christian König wrote: >>> Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky: >>>> (and then it breaks d

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/20/2017 11:07 AM, Christian König wrote: > Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky: >> >> (and then it breaks differently as a Xen guest --- we hung on the last >> pci_read_config_dword(), I haven't looked at this at all yet) > > Hui? How does this

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/20/2017 11:07 AM, Christian König wrote: > Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky: >> >> (and then it breaks differently as a Xen guest --- we hung on the last >> pci_read_config_dword(), I haven't looked at this at all yet) > > Hui? How does this

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 10/18/2017 09:58 AM, Christian König wrote: > From: Christian König > > Most BIOS don't enable this because of compatibility reasons. > > Manually enable a 64bit BAR of 64GB size so that we have > enough room for PCI devices. > > v2: style cleanups, increase size, add

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 10/18/2017 09:58 AM, Christian König wrote: > From: Christian König > > Most BIOS don't enable this because of compatibility reasons. > > Manually enable a 64bit BAR of 64GB size so that we have > enough room for PCI devices. > > v2: style cleanups, increase size, add resource name, set

Re: Commit fcd8843c40 breaks old compilers

On 11/20/2017 07:52 AM, Arnd Bergmann wrote: > On Sat, Nov 18, 2017 at 7:07 PM, Boris Ostrovsky > <boris.ostrov...@oracle.com> wrote: >> >> On 11/18/2017 12:39 PM, Trond Myklebust wrote: >>> On Sat, 2017-11-18 at 12:19 -0500, Boris Ostrovsky wr

Re: Commit fcd8843c40 breaks old compilers

On 11/20/2017 07:52 AM, Arnd Bergmann wrote: > On Sat, Nov 18, 2017 at 7:07 PM, Boris Ostrovsky > wrote: >> >> On 11/18/2017 12:39 PM, Trond Myklebust wrote: >>> On Sat, 2017-11-18 at 12:19 -0500, Boris Ostrovsky wrote: >>>> A similar bug was fixed by e

Re: [PATCH] NFSv4: Ensure gcc 4.4.4 can compile initialiser for "invalid_stateid"

On 11/18/2017 01:50 PM, Trond Myklebust wrote: gcc 4.4.4 is too old to have full C11 anonymous union support, so the current initialiser fails to compile. Reported-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Trond Myklebust <trond.mykleb...@primarydata.com>

Re: [PATCH] NFSv4: Ensure gcc 4.4.4 can compile initialiser for "invalid_stateid"

On 11/18/2017 01:50 PM, Trond Myklebust wrote: gcc 4.4.4 is too old to have full C11 anonymous union support, so the current initialiser fails to compile. Reported-by: Boris Ostrovsky Signed-off-by: Trond Myklebust (compile-)Tested-by: Boris Ostrovsky --- fs/nfs/nfs4state.c | 4

Re: Commit fcd8843c40 breaks old compilers

On 11/18/2017 01:12 PM, Trond Myklebust wrote: Sigh OK, how about something like the following then: { .data = { 0xff, 0xff, 0xff, 0xff, 0 }, } Yes, this does build. diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index 54fd56d..daa6085 100644 --- a/fs/nfs/nfs4state.c +++

Re: Commit fcd8843c40 breaks old compilers

On 11/18/2017 01:12 PM, Trond Myklebust wrote: Sigh OK, how about something like the following then: { .data = { 0xff, 0xff, 0xff, 0xff, 0 }, } Yes, this does build. diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index 54fd56d..daa6085 100644 --- a/fs/nfs/nfs4state.c +++

Re: Commit fcd8843c40 breaks old compilers

On 11/18/2017 12:39 PM, Trond Myklebust wrote: On Sat, 2017-11-18 at 12:19 -0500, Boris Ostrovsky wrote: Commit fcd8843c406b46433857ae45e5e9d84b01a7d20b breaks on older compilers which cannot process initializers for anonymous structures: +const nfs4_stateid invalid_stateid

Re: Commit fcd8843c40 breaks old compilers

On 11/18/2017 12:39 PM, Trond Myklebust wrote: On Sat, 2017-11-18 at 12:19 -0500, Boris Ostrovsky wrote: Commit fcd8843c406b46433857ae45e5e9d84b01a7d20b breaks on older compilers which cannot process initializers for anonymous structures: +const nfs4_stateid invalid_stateid

Commit fcd8843c40 breaks old compilers

Commit fcd8843c406b46433857ae45e5e9d84b01a7d20b breaks on older compilers which cannot process initializers for anonymous structures: +const nfs4_stateid invalid_stateid = { + { + .seqid = cpu_to_be32(0xU), + .other = { 0 }, + }, + .type =

Commit fcd8843c40 breaks old compilers

Commit fcd8843c406b46433857ae45e5e9d84b01a7d20b breaks on older compilers which cannot process initializers for anonymous structures: +const nfs4_stateid invalid_stateid = { + { + .seqid = cpu_to_be32(0xU), + .other = { 0 }, + }, + .type =

[PATCH] xen/pvcalls: Add MODULE_LICENSE()

Since commit ba1029c9cbc5 ("modpost: detect modules without a MODULE_LICENSE") modules without said macro will generate WARNING: modpost: missing MODULE_LICENSE() in While at it, also add module description and attribution. Signed-off-by: Boris Ostrovsky <boris.ostrov.

[PATCH] xen/pvcalls: Add MODULE_LICENSE()

Since commit ba1029c9cbc5 ("modpost: detect modules without a MODULE_LICENSE") modules without said macro will generate WARNING: modpost: missing MODULE_LICENSE() in While at it, also add module description and attribution. Signed-off-by: Boris Ostrovsky --- drivers/xen/pvcalls-b

[PATCH] xen/9pfs: Add MODULE_LICENSE()

Since commit ba1029c9cbc5 ("modpost: detect modules without a MODULE_LICENSE") modules without said macro will generate WARNING: modpost: missing MODULE_LICENSE() in net/9p/9pnet_xen.o Reported-by: Stephen Rothwell <s...@canb.auug.org.au> Signed-off-by: Boris Ostrovs

[PATCH] xen/9pfs: Add MODULE_LICENSE()

Since commit ba1029c9cbc5 ("modpost: detect modules without a MODULE_LICENSE") modules without said macro will generate WARNING: modpost: missing MODULE_LICENSE() in net/9p/9pnet_xen.o Reported-by: Stephen Rothwell Signed-off-by: Boris Ostrovsky --- net/9p/trans_xen.c | 1 + 1 file

Re: [PATCH v8 0/5] x86/xen: pvclock vdso support

On 11/08/2017 12:19 PM, Joao Martins wrote: > Hey, > > This is take 8 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting > Xen > 4.8 which is required for vdso time related calls. In order to have it on, > you > need to have the hypervisor clocksource be TSC e.g. with the following

Re: [PATCH v8 0/5] x86/xen: pvclock vdso support

On 11/08/2017 12:19 PM, Joao Martins wrote: > Hey, > > This is take 8 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting > Xen > 4.8 which is required for vdso time related calls. In order to have it on, > you > need to have the hypervisor clocksource be TSC e.g. with the following

Re: [PATCH] xen/privcmd: remove unused variable pageidx

On 11/08/2017 08:30 AM, Juergen Gross wrote: > On 08/11/17 14:00, Colin King wrote: >> From: Colin Ian King >> >> Variable pageidx is assigned a value but it is never read, hence it >> is redundant and can be removed. Cleans up clang warning: >> >>

Re: [PATCH] xen/privcmd: remove unused variable pageidx

On 11/08/2017 08:30 AM, Juergen Gross wrote: > On 08/11/17 14:00, Colin King wrote: >> From: Colin Ian King >> >> Variable pageidx is assigned a value but it is never read, hence it >> is redundant and can be removed. Cleans up clang warning: >> >> drivers/xen/privcmd.c:199:2: warning: Value

Re: [PATCH v2 0/5] xen: grant table interface v2 support

On 11/06/2017 03:46 PM, Boris Ostrovsky wrote: > On 11/02/2017 05:19 AM, Juergen Gross wrote: >> In order to support Linux to run as a pv guest on machines with huge >> memory (>16TB) or as a hvm guest with more than 16TB of memory the >> kernel has to support grant t

Re: [PATCH v2 0/5] xen: grant table interface v2 support

On 11/06/2017 03:46 PM, Boris Ostrovsky wrote: > On 11/02/2017 05:19 AM, Juergen Gross wrote: >> In order to support Linux to run as a pv guest on machines with huge >> memory (>16TB) or as a hvm guest with more than 16TB of memory the >> kernel has to support grant t

Re: [PATCH v4] xen: support priv-mapping in an HVM tools domain

On 11/03/2017 04:51 PM, Boris Ostrovsky wrote: > On 11/03/2017 01:04 PM, Paul Durrant wrote: >> If the domain has XENFEAT_auto_translated_physmap then use of the PV- >> specific HYPERVISOR_mmu_update hypercall is clearly incorrect. >> >> This patch adds checks in

Re: [PATCH v4] xen: support priv-mapping in an HVM tools domain

On 11/03/2017 04:51 PM, Boris Ostrovsky wrote: > On 11/03/2017 01:04 PM, Paul Durrant wrote: >> If the domain has XENFEAT_auto_translated_physmap then use of the PV- >> specific HYPERVISOR_mmu_update hypercall is clearly incorrect. >> >> This patch adds checks in

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

On 11/03/2017 04:04 AM, Juergen Gross wrote: > On 02/11/17 19:51, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Notice that in this particular case I placed the "fall through" comment >> on its

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

On 11/03/2017 04:04 AM, Juergen Gross wrote: > On 02/11/17 19:51, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Notice that in this particular case I placed the "fall through" comment >> on its

Re: [PATCH] xen/pvcalls: remove redundant check for irq >= 0

On 11/03/2017 06:01 AM, Juergen Gross wrote: > On 03/11/17 10:20, Colin King wrote: >> From: Colin Ian King >> >> This is a moot point, but irq is always less than zero at the label >> out_error, so the check for irq >= 0 is redundant and can be removed. >> >> Detected

Re: [PATCH] xen/pvcalls: remove redundant check for irq >= 0

On 11/03/2017 06:01 AM, Juergen Gross wrote: > On 03/11/17 10:20, Colin King wrote: >> From: Colin Ian King >> >> This is a moot point, but irq is always less than zero at the label >> out_error, so the check for irq >= 0 is redundant and can be removed. >> >> Detected by CoverityScan,

Re: [PATCH] xen/pvcalls: fix unsigned less than zero error check

On 11/03/2017 05:01 AM, Juergen Gross wrote: > On 03/11/17 09:42, Colin King wrote: >> From: Colin Ian King >> >> The check on bedata->ref is never true because ref is an unsigned >> integer. Fix this by assigning signed int ret to the return of the >> call to

Re: [PATCH] xen/pvcalls: fix unsigned less than zero error check

On 11/03/2017 05:01 AM, Juergen Gross wrote: > On 03/11/17 09:42, Colin King wrote: >> From: Colin Ian King >> >> The check on bedata->ref is never true because ref is an unsigned >> integer. Fix this by assigning signed int ret to the return of the >> call to gnttab_claim_grant_reference so the

Re: [PATCH] xen: xenbus_probe_frontend: mark expected switch fall-throughs

On 11/03/2017 04:03 AM, Juergen Gross wrote: > On 02/11/17 19:41, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Addresses-Coverity-ID: 146562 >> Addresses-Coverity-ID: 146563 >> Signed-off-by:

Re: [PATCH] xen: xenbus_probe_frontend: mark expected switch fall-throughs

On 11/03/2017 04:03 AM, Juergen Gross wrote: > On 02/11/17 19:41, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Addresses-Coverity-ID: 146562 >> Addresses-Coverity-ID: 146563 >> Signed-off-by:

Re: [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/31/2017 09:46 PM, Dongli Zhang wrote: > After guest live migration on xen, steal time in /proc/stat > (cpustat[CPUTIME_STEAL]) might decrease because steal returned by > xen_steal_lock() might be less than this_rq()->prev_steal_time which is > derived from previous return value of

Re: [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/31/2017 09:46 PM, Dongli Zhang wrote: > After guest live migration on xen, steal time in /proc/stat > (cpustat[CPUTIME_STEAL]) might decrease because steal returned by > xen_steal_lock() might be less than this_rq()->prev_steal_time which is > derived from previous return value of

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

On 11/08/2017 09:17 AM, Juergen Gross wrote: > On 08/11/17 15:10, Boris Ostrovsky wrote: >> On 11/08/2017 08:36 AM, Juergen Gross wrote: >>> Regarding ACPI tables: current PVH implementation in Linux kernel >>> seems not to make use of the special information presented

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

On 11/08/2017 09:17 AM, Juergen Gross wrote: > On 08/11/17 15:10, Boris Ostrovsky wrote: >> On 11/08/2017 08:36 AM, Juergen Gross wrote: >>> Regarding ACPI tables: current PVH implementation in Linux kernel >>> seems not to make use of the special information presented

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

On 11/08/2017 08:36 AM, Juergen Gross wrote: > > Regarding ACPI tables: current PVH implementation in Linux kernel > seems not to make use of the special information presented in the boot > information block. It will need to do so for dom0 (and, then, for simplicity, for all PVH guests). -boris

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

On 11/08/2017 08:36 AM, Juergen Gross wrote: > > Regarding ACPI tables: current PVH implementation in Linux kernel > seems not to make use of the special information presented in the boot > information block. It will need to do so for dom0 (and, then, for simplicity, for all PVH guests). -boris

Re: [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

On 11/08/2017 08:40 AM, Juergen Gross wrote: > On 08/11/17 14:37, Boris Ostrovsky wrote: >> On 11/08/2017 04:07 AM, Juergen Gross wrote: >>> Booting a Xen PVH guest requires a special boot entry as it is >>> mandatory to setup some Xen-specific interfaces rather e

Re: [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

On 11/08/2017 08:40 AM, Juergen Gross wrote: > On 08/11/17 14:37, Boris Ostrovsky wrote: >> On 11/08/2017 04:07 AM, Juergen Gross wrote: >>> Booting a Xen PVH guest requires a special boot entry as it is >>> mandatory to setup some Xen-specific interfaces rather e

Re: [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

On 11/08/2017 04:07 AM, Juergen Gross wrote: > Booting a Xen PVH guest requires a special boot entry as it is > mandatory to setup some Xen-specific interfaces rather early. When grub > or OVMF are used as boot loaders, however, those will fill the boot > parameters in zeropage and there is no

Re: [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

On 11/08/2017 04:07 AM, Juergen Gross wrote: > Booting a Xen PVH guest requires a special boot entry as it is > mandatory to setup some Xen-specific interfaces rather early. When grub > or OVMF are used as boot loaders, however, those will fill the boot > parameters in zeropage and there is no

Re: [PATCH v2 0/5] xen: grant table interface v2 support

ter > - in a pv guest if the maximum possible memory address of the host is > above 16TB (memory hotplug taken into account) > - in a hvm guest if the maximum guest memory address is above 16TB > (again with memory hotplug taken into account) > > Changes in V2: > - patch 2: rem

Re: [PATCH v2 0/5] xen: grant table interface v2 support

ter > - in a pv guest if the maximum possible memory address of the host is > above 16TB (memory hotplug taken into account) > - in a hvm guest if the maximum guest memory address is above 16TB > (again with memory hotplug taken into account) > > Changes in V2: > - patch 2: rem

Re: [PATCH v4] xen: support priv-mapping in an HVM tools domain

ch call through to the approprate > xlate_mmu function if the feature is present. A check is also added > to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this > should not be used in an HVM tools domain. > > Signed-off-by: Paul Durrant <paul.durr...@citrix.com> Review

Re: [PATCH v4] xen: support priv-mapping in an HVM tools domain

ch call through to the approprate > xlate_mmu function if the feature is present. A check is also added > to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this > should not be used in an HVM tools domain. > > Signed-off-by: Paul Durrant Reviewed-by: Boris Ostrovsky

[PATCH] xen/time: Return -ENODEV from xen_get_wallclock()

For any other error sync_cmos_clock() will reschedule itself every second or so, for no good reason. Suggested-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/time.c | 2 +- 1 file changed, 1 insertion(+), 1 delet

[PATCH] xen/time: Return -ENODEV from xen_get_wallclock()

For any other error sync_cmos_clock() will reschedule itself every second or so, for no good reason. Suggested-by: Paolo Bonzini Signed-off-by: Boris Ostrovsky --- arch/x86/xen/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c

Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain

On 11/02/2017 05:30 AM, Paul Durrant wrote: >> -Original Message- >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] >> Sent: 01 November 2017 18:19 >> To: Juergen Gross <jgr...@suse.com>; Paul Durrant >> <paul.durr...@c

Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain

On 11/02/2017 05:30 AM, Paul Durrant wrote: >> -Original Message- >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] >> Sent: 01 November 2017 18:19 >> To: Juergen Gross ; Paul Durrant >> ; x...@kernel.org; xen- >> de...@lists.xenproject.org

Re: [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

On 11/01/2017 09:19 PM, Dongli Zhang wrote: > Hi Boris, > > I have received from l...@intel.com that the prior version of patch hit issue > during compilation with aarch64-linux-gnu-gcc. I think this patch reviewed by > you would hit the same compiling issue on arm64 (there is no issue with >

Re: [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

On 11/01/2017 09:19 PM, Dongli Zhang wrote: > Hi Boris, > > I have received from l...@intel.com that the prior version of patch hit issue > during compilation with aarch64-linux-gnu-gcc. I think this patch reviewed by > you would hit the same compiling issue on arm64 (there is no issue with >

Re: [PATCH-tip v2 2/2] x86/xen: Deprecate xen_nopvspin

On 11/01/2017 04:58 PM, Waiman Long wrote: > +/* TODO: To be removed in a future kernel version */ > static __init int xen_parse_nopvspin(char *arg) > { > - xen_pvspin = false; > + pr_warn("xen_nopvspin is deprecated, replace it with > \"pvlock_type=queued\"!\n"); > + if

Re: [PATCH-tip v2 2/2] x86/xen: Deprecate xen_nopvspin

On 11/01/2017 04:58 PM, Waiman Long wrote: > +/* TODO: To be removed in a future kernel version */ > static __init int xen_parse_nopvspin(char *arg) > { > - xen_pvspin = false; > + pr_warn("xen_nopvspin is deprecated, replace it with > \"pvlock_type=queued\"!\n"); > + if

Re: [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

which would overflow steal time and lead to 100% st usage in top command > for linux 4.8-4.10. A backport of this patch would fix that issue. > > References: > https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest > Signed-off-by: Dongli Zhang <dongli.zh...@oracle.com> > > --- Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

Re: [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

which would overflow steal time and lead to 100% st usage in top command > for linux 4.8-4.10. A backport of this patch would fix that issue. > > References: > https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest > Signed-off-by: Dongli Zhang > > --- Reviewed-by: Boris Ostrovsky

Re: [PATCH] x86/paravirt: Add kernel parameter to choose paravirt lock type

On 11/01/2017 12:28 PM, Waiman Long wrote: > On 11/01/2017 11:51 AM, Juergen Gross wrote: >> On 01/11/17 16:32, Waiman Long wrote: >>> Currently, there are 3 different lock types that can be chosen for >>> the x86 architecture: >>> >>> - qspinlock >>> - pvqspinlock >>> - unfair lock >>> >>> One

Re: [PATCH] x86/paravirt: Add kernel parameter to choose paravirt lock type

On 11/01/2017 12:28 PM, Waiman Long wrote: > On 11/01/2017 11:51 AM, Juergen Gross wrote: >> On 01/11/17 16:32, Waiman Long wrote: >>> Currently, there are 3 different lock types that can be chosen for >>> the x86 architecture: >>> >>> - qspinlock >>> - pvqspinlock >>> - unfair lock >>> >>> One

Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain

On 11/01/2017 11:37 AM, Juergen Gross wrote: > > TBH I like V1 better, too. > > Boris, do you feel strong about the #ifdef part? Having looked at what this turned into I now like V1 better too ;-) Sorry, Paul. -boris

Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain

On 11/01/2017 11:37 AM, Juergen Gross wrote: > > TBH I like V1 better, too. > > Boris, do you feel strong about the #ifdef part? Having looked at what this turned into I now like V1 better too ;-) Sorry, Paul. -boris

Re: [PATCH v2] xen: support 52 bit physical addresses in pv guests

On 10/27/2017 01:49 PM, Juergen Gross wrote: > Physical addresses on processors supporting 5 level paging can be up to > 52 bits wide. For a Xen pv guest running on such a machine those > physical addresses have to be supported in order to be able to use any > memory on the machine even if the

Re: [PATCH v2] xen: support 52 bit physical addresses in pv guests

On 10/27/2017 01:49 PM, Juergen Gross wrote: > Physical addresses on processors supporting 5 level paging can be up to > 52 bits wide. For a Xen pv guest running on such a machine those > physical addresses have to be supported in order to be able to use any > memory on the machine even if the

Re: [PATCH v8 00/13] introduce the Xen PV Calls frontend

On 10/30/2017 06:40 PM, Stefano Stabellini wrote: > Hi all, > > this series introduces the frontend for the newly introduced PV Calls > procotol. > > PV Calls is a paravirtualized protocol that allows the implementation of > a set of POSIX functions in a different domain. The PV Calls frontend >

Re: [PATCH v8 00/13] introduce the Xen PV Calls frontend

On 10/30/2017 06:40 PM, Stefano Stabellini wrote: > Hi all, > > this series introduces the frontend for the newly introduced PV Calls > procotol. > > PV Calls is a paravirtualized protocol that allows the implementation of > a set of POSIX functions in a different domain. The PV Calls frontend >

Re: [Xen-devel] [PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/30/2017 11:13 PM, Dongli Zhang wrote: Hi Boris, On 10/31/2017 08:58 AM, Boris Ostrovsky wrote: On 10/30/2017 08:14 PM, Dongli Zhang wrote: Hi Boris, On 10/30/2017 09:34 PM, Boris Ostrovsky wrote: On 10/30/2017 04:03 AM, Dongli Zhang wrote: After guest live migration on xen, steal

Re: [Xen-devel] [PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/30/2017 11:13 PM, Dongli Zhang wrote: Hi Boris, On 10/31/2017 08:58 AM, Boris Ostrovsky wrote: On 10/30/2017 08:14 PM, Dongli Zhang wrote: Hi Boris, On 10/30/2017 09:34 PM, Boris Ostrovsky wrote: On 10/30/2017 04:03 AM, Dongli Zhang wrote: After guest live migration on xen, steal

Re: [Xen-devel] [PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/30/2017 08:14 PM, Dongli Zhang wrote: Hi Boris, On 10/30/2017 09:34 PM, Boris Ostrovsky wrote: On 10/30/2017 04:03 AM, Dongli Zhang wrote: After guest live migration on xen, steal time in /proc/stat (cpustat[CPUTIME_STEAL]) might decrease because steal returned by xen_steal_lock

Re: [Xen-devel] [PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/30/2017 08:14 PM, Dongli Zhang wrote: Hi Boris, On 10/30/2017 09:34 PM, Boris Ostrovsky wrote: On 10/30/2017 04:03 AM, Dongli Zhang wrote: After guest live migration on xen, steal time in /proc/stat (cpustat[CPUTIME_STEAL]) might decrease because steal returned by xen_steal_lock

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/30/2017 05:42 PM, Stefano Stabellini wrote: > On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >> On 10/30/2017 03:48 PM, Stefano Stabellini wrote: >>> On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >>>> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)) >

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/30/2017 05:42 PM, Stefano Stabellini wrote: > On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >> On 10/30/2017 03:48 PM, Stefano Stabellini wrote: >>> On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >>>> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)) >

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/30/2017 03:48 PM, Stefano Stabellini wrote: > On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >> >> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)) > Hi Boris, I am trying to repro the warnings below. I have been > unsuccessful so far. What system are you usin

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/30/2017 03:48 PM, Stefano Stabellini wrote: > On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >> >> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)) > Hi Boris, I am trying to repro the warnings below. I have been > unsuccessful so far. What system are you usin

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/26/2017 04:45 PM, Boris Ostrovsky wrote: > On 10/26/2017 04:16 PM, Stefano Stabellini wrote: >> On Thu, 26 Oct 2017, Boris Ostrovsky wrote: >>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote: >>>> Also add pvcalls-front to the Makefile. >>>> &g

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/26/2017 04:45 PM, Boris Ostrovsky wrote: > On 10/26/2017 04:16 PM, Stefano Stabellini wrote: >> On Thu, 26 Oct 2017, Boris Ostrovsky wrote: >>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote: >>>> Also add pvcalls-front to the Makefile. >>>> >&

Re: [PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/30/2017 04:03 AM, Dongli Zhang wrote: > After guest live migration on xen, steal time in /proc/stat > (cpustat[CPUTIME_STEAL]) might decrease because steal returned by > xen_steal_lock() might be less than this_rq()->prev_steal_time which is > derived from previous return value of

Re: [PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/30/2017 04:03 AM, Dongli Zhang wrote: > After guest live migration on xen, steal time in /proc/stat > (cpustat[CPUTIME_STEAL]) might decrease because steal returned by > xen_steal_lock() might be less than this_rq()->prev_steal_time which is > derived from previous return value of

Re: [PATCH v2] xen: support 52 bit physical addresses in pv guests

itself does not support 5 level paging. So when reading/writing a MFN from/to a pte don't use the kernel's PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs. Signed-off-by: Juergen Gross <jgr...@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

Re: [PATCH v2] xen: support 52 bit physical addresses in pv guests

itself does not support 5 level paging. So when reading/writing a MFN from/to a pte don't use the kernel's PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH 1/3] arm/xen: don't inclide rwlock.h directly.1~B

On 10/05/2017 03:58 PM, Stefano Stabellini wrote: > On Thu, 5 Oct 2017, Sebastian Andrzej Siewior wrote: >> rwlock.h should not be included directly. Instead linux/splinlock.h >> should be included. One thing it does is to break the RT build. >> >> Cc: Stefano Stabellini

Re: [Xen-devel] [PATCH 1/3] arm/xen: don't inclide rwlock.h directly.1~B

On 10/05/2017 03:58 PM, Stefano Stabellini wrote: > On Thu, 5 Oct 2017, Sebastian Andrzej Siewior wrote: >> rwlock.h should not be included directly. Instead linux/splinlock.h >> should be included. One thing it does is to break the RT build. >> >> Cc: Stefano Stabellini >> Cc:

Re: [PATCH v2] xen: fix booting ballooned down hvm guest

On 10/26/2017 10:12 AM, Boris Ostrovsky wrote: > On 10/26/2017 05:50 AM, Juergen Gross wrote: >> Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't >> online new memory initially") introduced a regression when booting a >> HVM domain with me

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