Re: [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

der protocol as well, and since that's standard do wonder if that could instead be extended to help unify a mechanism for different OSes instead of making this just a solution for Linux. Code review below. On Mon, Feb 01, 2016 at 10:38:48AM -0500, Boris Ostrovsky wrote: Start HVMlite guest at XEN_

[PATCH v2 04/11] xen/hvmlite: Allow HVMlite guests delay initializing grant table

.. just like we currently do for PVH guests Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/grant-table.c |4 ++-- drivers/xen/grant-table.c |8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/grant-table.c b/arch/x

[PATCH v2 06/11] xen/hvmlite: Prepare cpu_initialize_context() routine for HVMlite SMP

Subsequent patch will add support for starting secondary VCPUs in HVMlite guest. This patch exists to simmplify code review. No functional changes (except for introduction of 'if (!xen_hvmlite)'). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/smp.c

[PATCH v2 07/11] xen/hvmlite: Initialize context for secondary VCPUs

Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/smp.c | 57 arch/x86/xen/smp.h |4 +++ arch/x86/xen/xen-hvmlite.S |7 + 3 files changed, 63 insertions(+), 5 deletions(-) diff --git a/ar

[PATCH v2 09/11] xen/hvmlite: Use x86's default timer init for HVMlite guests

xen_timer_init() will be called from apic_bsp_setup(). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/time.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index f1ba6a0..d77b398

[PATCH v2 01/11] xen/hvmlite: Import hvmlite-related Xen public interfaces

Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- include/xen/interface/elfnote.h | 12 +++- include/xen/interface/hvm/hvm_vcpu.h | 143 ++ include/xen/interface/xen.h | 24 ++ 3 files changed, 178 insertions(+), 1 del

[PATCH v2 08/11] xen/hvmlite: Extend APIC operations for HVMlite guests

HVMlite guests need to be viewed as having APIC, otherwise smpboot code, for example, will complain. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- Not sure about xen_cpu_present_to_apicid() being an identity function, given xen_x86_32_early_logical_apicid(). Suspend/

[PATCH v2 05/11] xen/hvmlite: HVMlite guests always have PV devices

Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/platform-pci-unplug.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c index 9586ff3..802ec90 100644 --- a/arch/x

[PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

here into .data. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/Makefile |1 + arch/x86/xen/enlighten.c | 86 +- arch/x86/xen/xen-hvmlite.S | 175 include/xen/xen.h |6 ++ 4

[PATCH v2 00/11] HVMlite domU support

() is no longer necessary. (patch 3) * Dropped pcifront use until we decide that we *are* using it. (patch 5) Boris Ostrovsky (11): xen/hvmlite: Import hvmlite-related Xen public interfaces xen/hvmlite: Bootstrap HVMlite guest xen/hvmlite: Initialize HVMlite kernel xen/hvmlite: Allow HVMlite guests

[PATCH v2 03/11] xen/hvmlite: Initialize HVMlite kernel

HVMlite guests need to make a few additional initialization calls compared to regular HVM guests. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/enlighten.c | 18 -- 1 files changed, 12 insertions(+), 6 deletions(-) diff --git a/arch/x

[PATCH v2 10/11] xen/hvmlite: Boot secondary CPUs

HVMlite secondary VCPUs use baremetal bringup path (i.e. native_* smp_ops) but need to do some preparation in PV code. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/enlighten.c |2 + arch/x86/xen/pmu.c |4 +- arch/x86/xen/smp.c

[PATCH v2 11/11] xen/hvmlite: Enable CPU on-/offlining

for 32-bit case. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/smp.c | 35 +-- arch/x86/xen/xen-hvmlite.S |8 2 files changed, 33 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen

[PATCH v2] xen/x86: Zero out .bss for PV guests

macros for specifying 32- and 64-bit registers we can get rid of ifdefs in startup_xen()) Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: sta...@vger.kernel.org --- arch/x86/xen/xen-head.S | 29 ++--- 1 file changed, 22 insertions(+), 7 deletions(-)

Re: [PATCH 1/2] hvc_xen: add earlycon support

On 02/24/2016 07:23 AM, Stefano Stabellini wrote: Introduce EARLYCON support in hvc_xen, useful for early debugging on arm and arm64, where xen early_printk is not available. Differently from xenboot_write_console on x86, we won't just return if !xen_pv_domain(), because arm and arm64 guests are

Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests

On 02/24/2016 09:15 AM, Andrew Cooper wrote: On 24/02/16 14:12, David Vrabel wrote: On 22/02/16 22:06, Boris Ostrovsky wrote: Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't excecute that early code they should do it too. (Since we introduce macros for specifying 32

Re: [PATCH v2] xen/x86: Zero out .bss for PV guests

On 02/24/2016 11:05 AM, Brian Gerst wrote: Use the macros in instead of defining your own. Also, xorl %eax,%eax is good for 64-bit too, since the upper bits are cleared. I suspected this would have to be defined somewhere but couldn't find it. Thanks! -boris

Re: [Xen-devel] [PATCH v2] xen/x86: Zero out .bss for PV guests

On 02/24/2016 12:26 PM, Andrew Cooper wrote: On 24/02/16 15:19, Boris Ostrovsky wrote: + /* Clear .bss */ + xor REG(ax),REG(ax) If we are nitpicking, This should be xor %eax, %eax even in 64bit. Functionally identical, and shorter to encode. Right, Brian Gerst pointed this out

Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests

On 02/24/2016 11:22 AM, Luis R. Rodriguez wrote: On Wed, Feb 24, 2016 at 6:58 AM, David Vrabel wrote: Yes. Can you respin with a commit message explaining? (Or just provide the message here and I'll fix it up). Is there no way to re-use somehow the clear_bss() from

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On 02/22/2016 05:27 AM, Borislav Petkov wrote: On Mon, Feb 22, 2016 at 07:07:56AM +0100, Luis R. Rodriguez wrote: diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h index 1ae89a2721d6..fe0d579b63e3 100644 --- a/arch/x86/include/asm/x86_init.h +++

Re: [PATCH 5/9] apm32: remove paravirt_enabled() use

On 02/19/2016 07:42 PM, Luis R. Rodriguez wrote: On Fri, Feb 19, 2016 at 05:17:27PM -0500, Boris Ostrovsky wrote: On 02/19/2016 03:58 PM, Luis R. Rodriguez wrote: On Fri, Feb 19, 2016 at 10:08:43AM -0500, Boris Ostrovsky wrote: in xen_start_kernel(). Better yet, clear whole .bss

[PATCH] xen/x86: Zero out .bss for PV guests

Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't excecute that early code they should do it too. (Since we introduce macros for specifying 32- and 64-bit registers we can get rid of ifdefs in startup_xen()) Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.

Re: [PATCH v2 1/3] hvc_xen: add earlycon support

<stefano.stabell...@eu.citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

Re: [PATCH v2 2/3] hvc_xen: fix xenboot for DomUs

return -ENODEV; } +static int xen_early_pv_console_init(struct xencons_info *info, int vtermno) Nit: not sure whether "early" is the right word to use here: when called from xen_pv_console_init() it's not really on the early path. Other than that: Reviewed-by: Boris Ostrovs

Re: [PATCH v2 3/3] hvc_xen: make early_printk work with HVM guests

Stabellini <stefano.stabell...@eu.citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

[PATCH v3 2/2] xen/x86: Drop mode-selecting ifdefs in startup_xen()

Use asm/asm.h macros instead. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/xen-head.S | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index 11dbe49..2366895 100644 --- a/arch/x

[PATCH v3 0/2] Clear .bss for VP guests

PV guests need to have their .bss zeroed out since it is not guaranteed to be cleared by Xen's domain builder v3: * Use existing macros for selecting mode-appropriate instructions/registers * Use 32-bit registers in XOR * Split removal of mode-selecting ifdefs into a separate patch Boris

[PATCH v3 1/2] xen/x86: Zero out .bss for PV guests

Baremetal kernels clear .bss early in the boot but Xen PV guests don't execute that code. They have been able to run without problems because Xen domain builder happens to give out zeroed pages. However, since this is not really guaranteed, .bss should be explicitly cleared. Signed-off-by: Boris

Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests

On 02/26/2016 09:42 AM, Brian Gerst wrote: On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky <boris.ostrov...@oracle.com> wrote: On 02/26/2016 05:53 AM, Roger Pau Monné wrote: El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit: PV guests need to have their .bss zeroed out

Re: [PATCH v2 2/3] hvc_xen: fix xenboot for DomUs

On 02/26/2016 10:39 AM, Stefano Stabellini wrote: On Thu, 25 Feb 2016, Boris Ostrovsky wrote: On 02/25/2016 07:10 AM, Stefano Stabellini wrote: The xenboot early console has been partially broken for DomU for a long time: the output would only go to the hypervisor via hypercall

Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests

On 02/26/2016 10:26 AM, David Vrabel wrote: The tools support loading bzImages, not just ELF images. We load them as ELF images though, I believe, after uncompressing. E.g.: static int xc_dom_load_bzimage_kernel(struct xc_dom_image *dom) { return elf_loader.loader(dom); } -boris

Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests

On 02/26/2016 10:22 AM, Roger Pau Monné wrote: El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit: On 02/26/2016 09:42 AM, Brian Gerst wrote: On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky <boris.ostrov...@oracle.com> wrote: On 02/26/2016 05:53 AM, Roger Pau Monné wrote: El 25/2/16 a

Re: [PATCH, RESEND] xen: allocate gntdev_copy_batch dynamically

On 02/25/2016 04:25 PM, Arnd Bergmann wrote: struct gntdev_copy_batch is arguably too large to fit on the kernel stack, and we get a warning about the stack usage in gntdev_ioctl_grant_copy: drivers/xen/gntdev.c:949:1: error: the frame size of 1240 bytes is larger than 1024 bytes This changes

Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests

On 02/26/2016 05:53 AM, Roger Pau Monné wrote: El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit: PV guests need to have their .bss zeroed out since it is not guaranteed to be cleared by Xen's domain builder I guess I'm missing something, but elf_load_image (in libelf-loader.c) seems

[PATCH v4 2/2] xen/x86: Drop mode-selecting ifdefs in startup_xen()

Use asm/asm.h macros instead. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/xen-head.S | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index 5c63d2d..de93b20 100644 --- a/arch/x

[PATCH v4 0/2] Clear .bss for PV guests

PV guests need to have their .bss zeroed out since it is not guaranteed to be cleared by Xen's domain builder (even if it is done so currently) v4: * Better use of mode-selecting macros. * Drop stable tag. * Update commit message for patch 1. Boris Ostrovsky (2): xen/x86: Zero out .bss for PV

[PATCH v4 1/2] xen/x86: Zero out .bss for PV guests

ELF spec is unclear about whether .bss must me cleared by the loader. Currently the domain builder does it when loading the guest but because it is not (or rather may not be) guaranteed we should zero it out explicitly. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x

Re: [RFC v1 4/8] x86/init: add linker table support

On 01/21/2016 03:38 AM, Roger Pau Monné wrote: El 20/01/16 a les 22.33, Luis R. Rodriguez ha escrit: On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk wrote: +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) +{ + if (!fn->supp_hardware_subarch)

[PATCH v1 10/12] xen/hvmlite: Use x86's default timer init for HVMlite guests

xen_timer_init() will be called from apic_bsp_setup(). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/time.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index a0a4e55..93745e7

[PATCH v1 08/12] xen/hvmlite: Initialize context for secondary VCPUs

Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/smp.c | 57 arch/x86/xen/smp.h |4 +++ arch/x86/xen/xen-hvmlite.S |7 + 3 files changed, 63 insertions(+), 5 deletions(-) diff --git a/ar

[PATCH v1 01/12] x86/smp: Make start_secondary() and initial_pg_pmd visible globally

Xen's HVMlite guests will want to use them. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/include/asm/smp.h |1 + arch/x86/kernel/head_32.S |2 +- arch/x86/kernel/smpboot.c |2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/ar

[PATCH v1 05/12] xen/hvmlite: Allow HVMlite guests delay initializing grant table

.. just like we currently do for PVH guests Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/grant-table.c |4 ++-- drivers/xen/grant-table.c |8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/grant-table.c b/arch/x

[PATCH v1 09/12] xen/hvmlite: Extend APIC operations for HVMlite guests

HVMlite guests need to be viewed as having APIC, otherwise smpboot code, for example, will complain. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- Not sure about xen_cpu_present_to_apicid() being an identity function, given xen_x86_32_early_logical_apicid(). arch/x

[PATCH v1 07/12] xen/hvmlite: Prepare cpu_initialize_context() routine for HVMlite SMP

Subsequent patch will add support for starting secondary VCPUs in HVMlite guest. This patch exists to make review easier. No functional changes (except for introduction of 'if (!xen_hvmlite)'). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/smp.c

[PATCH v1 12/12] xen/hvmlite: Enable CPU on-/offlining

for 32-bit case. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/smp.c | 35 +-- arch/x86/xen/xen-hvmlite.S |8 2 files changed, 33 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen

[PATCH v1 03/12] xen/hvmlite: Import hvmlite-related Xen public interfaces

Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- include/xen/interface/elfnote.h | 12 +++- include/xen/interface/hvm/hvm_vcpu.h | 143 ++ include/xen/interface/xen.h | 24 ++ 3 files changed, 178 insertions(+), 1 del

[PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

Start HVMlite guest XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall page, initialize boot_params, enable early page tables. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/Makefile |1 + arch/x86/xen/enlighten.c | 91 +-

[PATCH v1 00/12] HVMlite domU support

) Compile-tested on ARM Boris Ostrovsky (12): x86/smp: Make start_secondary() and initial_pg_pmd visible globally xen/hvmlite: Factor out common kernel init code xen/hvmlite: Import hvmlite-related Xen public interfaces xen/hvmlite: Bootstrap HVMlite guest xen/hvmlite: Allow HVMlite

[PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

HVMlite guests (to be introduced in subsequent patches) share most of the kernel initialization code with PV(H). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/enlighten.c | 225 -- 1 files changed, 119 insertions(+

[PATCH v1 06/12] xen/hvmlite: Initialize PCI

HVMlite guests need PCI frontend and always have PV devices Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/pci/xen.c |2 +- arch/x86/xen/platform-pci-unplug.c |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x

[PATCH v1 11/12] xen/hvmlite: Boot secondary CPUs

HVMlite secondary VCPUs use baremetal bringup path (i.e. native_* smp_ops) but need to do some preparation in PV code. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/enlighten.c |2 + arch/x86/xen/pmu.c |4 +- arch/x86/xen/smp.c

Re: [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

On 01/22/2016 06:01 PM, Luis R. Rodriguez wrote: On Fri, Jan 22, 2016 at 04:35:48PM -0500, Boris Ostrovsky wrote: HVMlite guests (to be introduced in subsequent patches) share most of the kernel initialization code with PV(H). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.

Re: [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

On 01/22/2016 06:12 PM, Boris Ostrovsky wrote: On 01/22/2016 06:01 PM, Luis R. Rodriguez wrote: On Fri, Jan 22, 2016 at 04:35:48PM -0500, Boris Ostrovsky wrote: HVMlite guests (to be introduced in subsequent patches) share most of the kernel initialization code with PV(H). Signed-off

Re: [PATCH v1 00/12] HVMlite domU support

On 01/25/2016 05:51 AM, David Vrabel wrote: On 22/01/16 21:35, Boris Ostrovsky wrote: This series introduces HVMlite support for unprivileged guests. It has been tested on Intel/AMD, both 32- and 64-bit, including CPU on- and offlining and save/restore. (Restore will result in APIC write

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/22/2016 07:30 PM, Andrew Cooper wrote: On 22/01/2016 23:32, Luis R. Rodriguez wrote: On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote: + /* +* See Documentation/x86/boot.txt. +* +* Version 2.12 supports Xen entry point but we will use default

Re: [PATCH v1 01/12] x86/smp: Make start_secondary() and initial_pg_pmd visible globally

On 01/25/2016 05:53 AM, David Vrabel wrote: On 22/01/16 21:35, Boris Ostrovsky wrote: Xen's HVMlite guests will want to use them. Please explain in detail why they are needed. Actually, start_secondary is not needed anymore, I removed its use at some point. initial_pg_pmd (together

Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/22/2016 06:32 PM, Luis R. Rodriguez wrote: On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote: +/* + * This routine (and those that it might call) should not use + * anything that lives in .bss since that segment will be cleared later + */ +void __init xen_prepare_hvmlite

Re: [Xen-devel] [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

On 01/25/2016 06:04 AM, David Vrabel wrote: On 22/01/16 21:35, Boris Ostrovsky wrote: HVMlite guests (to be introduced in subsequent patches) share most of the kernel initialization code with PV(H). Where possible, HVMlite should share initialization with bare metal/HVM and not PV(H

Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/25/2016 04:21 PM, H. Peter Anvin wrote: On 01/25/16 13:12, Luis R. Rodriguez wrote: Perhaps, but someone would still have to set hardware_subarch. And it's hvmlite_bootparams() that does it. No, Xen would do it as well, essentially all of hvmlite_bootparams() could be done in Xen. Or a

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote: On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote: it causes inappropriate linkage between the toolstack and the version of Linux wishing to be booted. There are ways to do it in such a way that it does not create dependency issues

Re: [PATCH 3/3] tty: hvc_xen: hide xen_console_remove when unused

On 01/25/2016 04:54 PM, Arnd Bergmann wrote: xencons_disconnect_backend() is only called from xen_console_remove(), and also from xencons_probe()/xencons_resume(). But those two are also under the same ifdef. -boris which is conditionally compiled, so we get a harmless warning when

Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/26/2016 01:46 PM, Andy Lutomirski wrote: On Tue, Jan 26, 2016 at 10:34 AM, Luis R. Rodriguez <mcg...@suse.com> wrote: On Mon, Jan 25, 2016 at 05:28:08PM -0500, Boris Ostrovsky wrote: On 01/25/2016 04:21 PM, H. Peter Anvin wrote: On 01/25/16 13:12, Luis R. Rodriguez wrote: P

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/26/2016 03:30 PM, Luis R. Rodriguez wrote: What I'm proposing? 1) Lets see if we can put a proactive stop-gap to issues such as the cr4 shadow bug and Kasan bugs from creeping in. This should not only help PV but perhaps HVMLite. If you'd like to help with that refer to this thread:

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/27/2016 09:50 AM, David Vrabel wrote: On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote: On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote: On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote: On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/27/2016 10:09 AM, David Vrabel wrote: On 27/01/16 15:06, Boris Ostrovsky wrote: On 01/27/2016 09:50 AM, David Vrabel wrote: On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote: On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote: On Jan 26, 2016 6:16 PM, "Luis R. Rodr

Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> (This, btw, is the second time we got bitten by pcifront_sd bit not being pci_sysdata. dc4fdaf0e48 was a workaround for a similar problem and we shoul

Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/17/2016 03:49 PM, Borislav Petkov wrote: On Wed, Feb 17, 2016 at 12:07:13PM -0800, Luis R. Rodriguez wrote: OK so here's a wiki to keep track of progress of the difference uses: http://kernelnewbies.org/KernelProjects/remove-paravirt-enabled It seems we have a resolution one way or

Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/17/2016 05:03 PM, Borislav Petkov wrote: On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote: That's exactly the point: if something is mapped it's an error for a non-PV kernel. How would something be mapped there? __PAGE_OFFSET is 0x8800. Or are you thinking

Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 02/17/2016 05:18 PM, Andy Lutomirski wrote: On Wed, Feb 17, 2016 at 2:03 PM, Borislav Petkov <b...@alien8.de> wrote: On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote: That's exactly the point: if something is mapped it's an error for a non-PV kernel. How would som

Re: [PATCH] x86/ptdump: Remove paravirt_enabled()

on/x86/x86_64/mm.txt. Signed-off-by: Borislav Petkov <b...@suse.de> Cc: Andy Lutomirski <l...@amacapital.net> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: "Luis R. Rodriguez" <mcg...@kernel.org> Under Xen, as PV guest: Tested-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

Re: [PATCH 5/9] apm32: remove paravirt_enabled() use

On 02/19/2016 08:08 AM, Luis R. Rodriguez wrote: There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true) do never set the apm_bios_info, the

Re: [RFC v2 1/6] x86/boot: add BIT() to boot/bitops.h

On 02/19/2016 09:15 AM, Luis R. Rodriguez wrote: diff --git a/arch/x86/boot/bitops.h b/arch/x86/boot/bitops.h index 878e4b9940d9..232cff0ff4e3 100644 --- a/arch/x86/boot/bitops.h +++ b/arch/x86/boot/bitops.h @@ -40,4 +40,6 @@ static inline void set_bit(int nr, void *addr) asm("btsl

Re: [PATCH 5/9] apm32: remove paravirt_enabled() use

On 02/19/2016 03:58 PM, Luis R. Rodriguez wrote: On Fri, Feb 19, 2016 at 10:08:43AM -0500, Boris Ostrovsky wrote: in xen_start_kernel(). Better yet, clear whole .bss. (This applies to the next patch as well). So clear_bss() -- oh look, another call that xen_start_kernel() could have made

Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.

On 02/15/2016 09:05 AM, Konrad Rzeszutek Wilk wrote: On Sat, Feb 13, 2016 at 08:23:14PM -0500, Boris Ostrovsky wrote: On 02/11/2016 04:10 PM, Konrad Rzeszutek Wilk wrote: This patch fixes the issue by: 1) Use kzalloc to initialize to a well known state. 2) Put 'struct pci_sysdata

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

On 03/12/2016 04:19 AM, Thomas Gleixner wrote: Boris, On Tue, 14 Jul 2015, Boris Ostrovsky wrote: On 07/14/2015 04:15 PM, Thomas Gleixner wrote: The issue here is that all architectures need that protection and just Xen does irq allocations in cpu_up. So moving that protection

[PATCH 1/2] xen/x86: Move irq allocation from Xen smp_op.cpu_up()

up ops. We can move those allocations into CPU notifiers so that original patch can be reinstated. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/enlighten.c | 53 ++--- arch/

[PATCH 1/2] xen/apic: Provide Xen-specific version of cpu_present_to_apicid APIC op

become 64K which is obviously problematic. While RAPL code (and any other users of logical_package_id) should be careful in their assumptions about id's validity, Xen's cpu_present_to_apicid op should still provide value consistent with its own xen_apic_read(APIC_ID). Signed-off-by: Boris Ostrovsky <

[PATCH v2] xen/events: Mask a moving irq

ay result in a EVTCHNOP_unmask hypercall which, in turn, may make the event pending on the target CPU. We can avoid this situation by moving and clearing the event while keeping event masked. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: sta...@vger.kernel.org --- v2: * Use irq_move_maske

[PATCH 0/2] Reinstate irq alloc/dealloc locking patch

Original version of that patch (commit a89941816726) had to be reverted due to Xen allocating irqs in its cpu_up ops. The first patch moves allocations into hotplug notifiers and the second one restores the original patch (with minor adjustments to new hotplug framework) Boris Ostrovsky (2

Re: [Xen-devel] [PATCH v4 0/5] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling

On 03/12/2016 01:08 PM, Andy Lutomirski wrote: Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently turns all rdmsr and wrmsr operations into the safe variants without any checks that the operations actually succeed. With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and

Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote: We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific

Re: [PATCH v4 08/14] apm32: remove paravirt_enabled() use

On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote: There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the apm_bios.info. The Xen folks are sure

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

return value to zero when native_rdmsr_safe fails With Xen (on top of eb1af3b): Tested-by: Boris Ostrovsky <boris.ostrov...@oracle.com> -boris

Re: Xen regression, Was: [PATCH] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs

On 04/12/2016 02:06 PM, Stefano Stabellini wrote: On Tue, 12 Apr 2016, Boris Ostrovsky wrote: On 04/11/2016 10:08 PM, Stefano Stabellini wrote: Hi all, Unfortunately this patch (now commit 8c058b0b9c34d8c8d7912880956543769323e2d8) causes a regression on Xen when running on top of QEMU

Re: Xen regression, Was: [PATCH] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs

On 04/12/2016 05:56 PM, Stefano Stabellini wrote: I am not sure, maybe you didn't have CONFIG_SPARSE_IRQ? But I am certain that 4.6-rc2, with the attached config, fails as Dom0 on QEMU with the following sequence of calls: I did have CONFIG_SPARSE_IRQ and I just rebuilt 4.5.0 with your

Re: Xen regression, Was: [PATCH] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs

On 04/12/2016 05:14 PM, Stefano Stabellini wrote: On Tue, 12 Apr 2016, Boris Ostrovsky wrote: On 04/12/2016 02:06 PM, Stefano Stabellini wrote: On Tue, 12 Apr 2016, Boris Ostrovsky wrote: On 04/11/2016 10:08 PM, Stefano Stabellini wrote: Hi all, Unfortunately this patch (now commit

Re: Xen regression, Was: [PATCH] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs

On 04/12/2016 07:15 PM, Stefano Stabellini wrote: On Tue, 12 Apr 2016, Boris Ostrovsky wrote: On 04/12/2016 05:56 PM, Stefano Stabellini wrote: I am not sure, maybe you didn't have CONFIG_SPARSE_IRQ? But I am certain that 4.6-rc2, with the attached config, fails as Dom0 on QEMU

Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On 04/08/2016 02:29 AM, Luis R. Rodriguez wrote: On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross <jgr...@suse.com> wrote: On 08/04/16 02:32, Luis R. Rodriguez wrote: On Thu, Apr 07, 2016 at 08:55:54AM -0400, Boris Ostrovsky wrote: On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote: We

Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On 04/08/2016 03:59 AM, Juergen Gross wrote: On 08/04/16 09:36, Luis R. Rodriguez wrote: On Fri, Apr 8, 2016 at 12:13 AM, Juergen Gross wrote: On 08/04/16 08:56, Luis R. Rodriguez wrote: On Thu, Apr 7, 2016 at 11:38 PM, Juergen Gross wrote: Okay. Another

Re: [PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On 04/08/2016 07:40 PM, Luis R. Rodriguez wrote: diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h index 1ae89a2721d6..8bb8c1a4615a 100644 --- a/arch/x86/include/asm/x86_init.h +++ b/arch/x86/include/asm/x86_init.h @@ -142,6 +142,15 @@ struct x86_cpuinit_ops {

Re: Xen regression, Was: [PATCH] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs

On 04/11/2016 10:08 PM, Stefano Stabellini wrote: Hi all, Unfortunately this patch (now commit 8c058b0b9c34d8c8d7912880956543769323e2d8) causes a regression on Xen when running on top of QEMU: the number of PIT irqs get set to 0 by probe_8259A but actually there are 16. Any suggestions on how

[PATCH 2/2] xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()

This call has always been missing from xen_play dead() but until recently this was rather benign. With new cpu hotplug framework however this call is required, otherwise a hot-plugged CPU will not be properly brough up (by never calling cpuhp_online_idle()) Signed-off-by: Boris Ostrovsky

[PATCH 0/2] Hotplug fixes

Two patches fixing regressions introduced by new CPU hotplug framework Boris Ostrovsky (2): xen/apic: Provide Xen-specific version of cpu_present_to_apicid APIC op xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead() arch/x86/xen/apic.c | 12

Re: [Xen-devel] [PATCH] xen/events: Mask a moving irq

On 03/17/2016 12:03 PM, David Vrabel wrote: On 17/03/16 12:45, Boris Ostrovsky wrote: Moving an unmasked irq may result in irq handler being invoked on both source and target CPUs. With 2-level this can happen as follows: On source CPU: evtchn_2l_handle_events

Re: [Xen-devel] [PATCH] xen/events: Mask a moving irq

On 03/17/2016 01:29 PM, David Vrabel wrote: On 17/03/16 16:53, Boris Ostrovsky wrote: On 03/17/2016 12:03 PM, David Vrabel wrote: On 17/03/16 12:45, Boris Ostrovsky wrote: Moving an unmasked irq may result in irq handler being invoked on both source and target CPUs. With 2-level this can

[PATCH] xen/events: Mask a moving irq

ay result in a EVTCHNOP_unmask hypercall which, in turn, may make the event pending on the target CPU. We can avoid this situation by moving and clearing the event while keeping event masked. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: sta...@vger.kernel.org --- drivers/xen/events/event

[PATCH 2/2] hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)

Now that Xen no longer allocates irqs in _cpu_up() we can restore commit a89941816726 ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down") Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/kernel/smpboot.c | 11 -

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

On 03/24/2016 10:53 PM, Steven Haigh wrote: Hi all, Firstly, I've cross-posted this to xen-devel and the lkml - as this problem seems to only exist when using kernel 4.4 as a Xen DomU kernel. I have also CC'ed Greg KH for his awesome insight as maintainer. Please CC myself into replies - as

Re: [PATCH 2/2] xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()

On 03/25/2016 10:53 AM, Konrad Rzeszutek Wilk wrote: On Thu, Mar 17, 2016 at 09:03:25AM -0400, Boris Ostrovsky wrote: This call has always been missing from xen_play dead() but until recently this was rather benign. With new cpu hotplug framework however this call is required, otherwise a hot

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

On 03/25/2016 10:05 AM, Steven Haigh wrote: On 25/03/2016 11:23 PM, Boris Ostrovsky wrote: On 03/24/2016 10:53 PM, Steven Haigh wrote: Hi all, Firstly, I've cross-posted this to xen-devel and the lkml - as this problem seems to only exist when using kernel 4.4 as a Xen DomU kernel. I have

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