[PATCH 0/3] Fix and cleanup for 32-bit PV sysexit

yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. Boris Ostrovsky (3): x86/xen: Avoid fast syscall path for Xen PV guests x86: irq_enable_sysexit pv op is no longer needed x86

Re: [PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed

On 11/18/2015 03:11 PM, Konrad Rzeszutek Wilk wrote: On Wed, Nov 18, 2015 at 03:06:18PM -0500, Boris Ostrovsky wrote: Xen PV guests have been the only ones using it and now they don't. Could you elaborate on the 'now they don't' please? Is Xen not doing it? Did it do it in the past

Re: [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

On 08/20/2015 02:16 PM, Juergen Groß wrote: On 08/18/2015 05:55 PM, Dario Faggioli wrote: Hey everyone, So, as a followup of what we were discussing in this thread: [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest

Re: [PATCH RFC Linux] x86/xen: allow using x2APIC under Xen without CONFIG_XEN enabled

On 08/20/2015 08:04 AM, Jan Beulich wrote: While commit 4cca6ea04d31c claims to not have any functional effect on Xen, this isn't the case: Before that change, kernels built without CONFIG_XEN_PVHVM (a dependency which meanwhile became just CONFIG_XEN) were able to run in x2APIC mode just fine.

Re: [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

On 09/02/2015 07:58 AM, Juergen Gross wrote: On 08/31/2015 06:12 PM, Boris Ostrovsky wrote: On 08/20/2015 02:16 PM, Juergen Groß wrote: On 08/18/2015 05:55 PM, Dario Faggioli wrote: Hey everyone, So, as a followup of what we were discussing in this thread: [Xen-devel] PV-vNUMA issue

Re: [Patch V2] xen: use correct type for HYPERVISOR_memory_op()

An int will overflow for a domain configured with 8TB of memory or more. Correct this by using the correct type. Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Juergen Gross <jgr...@suse.com> --- V2: change arm header as well to keep it in sync with x86

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 09/17/2015 05:10 AM, Andrew Cooper wrote: On 17/09/15 00:33, 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. This is IMO awful: it

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

On 09/29/2015 07:39 AM, Vitaly Kuznetsov wrote: Boris Ostrovsky <boris.ostrov...@oracle.com> writes: On 09/25/2015 03:35 PM, Konrad Rzeszutek Wilk wrote: On Fri, Sep 25, 2015 at 03:19:57PM -0400, Boris Ostrovsky wrote: On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote: On Fri,

Re: [Xen-devel] [PATCH] xen/pci: Don't build Xen pci code for ARM and ARM64

On 09/28/2015 09:59 AM, Julien Grall wrote: Hi David, On 28/09/15 14:52, David Vrabel wrote: On 28/09/15 14:30, Julien Grall wrote: The PCI support for Xen doesn't compile on ARM/ARM64 when CONFIG_PCI_MMCONFIG=y: drivers/xen/pci.c:31:25: fatal error: asm/pci_x86.h: No such file or directory

Re: [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

On 10/02/2015 10:52 AM, Julien Grall wrote: On 02/10/15 15:31, Julien Grall wrote: Hi David, On 02/10/15 15:09, David Vrabel wrote: On 30/09/15 11:45, Julien Grall wrote: For ARM64 guests, Linux is able to support either 64K or 4K page granularity. Although, the hypercall interface is

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

On 09/23/2015 03:35 AM, Juergen Gross wrote: Depends on the hardware. On some AMD processors one socket covers multiple NUMA nodes. This is the critical case. set_sched_topology() will be called on those machines possibly multiple times when bringing up additional cpus. I'm asking because

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

On 09/25/2015 09:59 AM, Konrad Rzeszutek Wilk wrote: On Fri, Sep 25, 2015 at 11:59:52AM +0200, Vitaly Kuznetsov wrote: Currently there is a number of issues preventing PVHVM Xen guests from doing successful kexec/kdump: - Bound event channels. - Registered vcpu_info. - PIRQ/emuirq mappings. -

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

On 09/25/2015 03:35 PM, Konrad Rzeszutek Wilk wrote: On Fri, Sep 25, 2015 at 03:19:57PM -0400, Boris Ostrovsky wrote: On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote: On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote: On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote: Also, I

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote: On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote: On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote: Also, I am not sure I see how this new op will be used in the hypervisor --- currently AFAICS it is only processed under

Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support

On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote: Also, I am not sure I see how this new op will be used in the hypervisor --- currently AFAICS it is only processed under is_hardware_domain(). Are there other patches that will support HVM guests? Please see my Xen series:

[PATCH] xen/x86: Don't try to write syscall-related MSRs for PV guests

For PV guests these registers are set up by hypervisor and thus should not be written by the guest. The comment in xen_write_msr_safe() says so but we still write the MSRs, causing the hypervisor to print a warning. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x

[PATCH] xen: Resume PMU from non-atomic context

suspending PMU to xen_arch_suspend() as well. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Reported-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: <sta...@vger.kernel.org> # 4.3 --- arch/x86/xen/suspend.c | 20 ++-- 1 file changed, 10

Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails

| 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.ke

Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.

On 11/30/2015 05:55 PM, Sander Eikelenboom wrote: On 2015-11-30 23:54, Boris Ostrovsky wrote: On 11/30/2015 04:46 PM, Sander Eikelenboom wrote: On 2015-11-30 22:45, Konrad Rzeszutek Wilk wrote: On Sat, Nov 28, 2015 at 04:47:43PM +0100, Sander Eikelenboom wrote: Hi all, I have just tested

Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.

On 12/01/2015 05:51 PM, Sander Eikelenboom wrote: On 2015-11-30 23:54, Boris Ostrovsky wrote: On 11/30/2015 04:46 PM, Sander Eikelenboom wrote: On 2015-11-30 22:45, Konrad Rzeszutek Wilk wrote: On Sat, Nov 28, 2015 at 04:47:43PM +0100, Sander Eikelenboom wrote: Hi all, I have just tested

Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.

On 12/01/2015 06:00 PM, Sander Eikelenboom wrote: On 2015-12-01 23:47, Boris Ostrovsky wrote: On 11/30/2015 05:55 PM, Sander Eikelenboom wrote: On 2015-11-30 23:54, Boris Ostrovsky wrote: On 11/30/2015 04:46 PM, Sander Eikelenboom wrote: On 2015-11-30 22:45, Konrad Rzeszutek Wilk wrote

Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.

On 12/01/2015 06:30 PM, Sander Eikelenboom wrote: On 2015-12-02 00:19, Boris Ostrovsky wrote: On 12/01/2015 06:00 PM, Sander Eikelenboom wrote: On 2015-12-01 23:47, Boris Ostrovsky wrote: On 11/30/2015 05:55 PM, Sander Eikelenboom wrote: On 2015-11-30 23:54, Boris Ostrovsky wrote: On 11/30

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

On 12/04/2015 10:24 AM, David Vrabel wrote: On 04/12/15 14:06, David Vrabel wrote: On 03/12/15 10:43, David Vrabel wrote: Adding the rtc platform device when there are no legacy irqs (no legacy PIC) causes a conflict with other devices that end up using the same irq number. An alternative

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

On 12/04/2015 10:52 AM, Vitaly Kuznetsov wrote: Boris Ostrovsky <boris.ostrov...@oracle.com> writes: On 12/04/2015 10:24 AM, David Vrabel wrote: On 04/12/15 14:06, David Vrabel wrote: On 03/12/15 10:43, David Vrabel wrote: Adding the rtc platform device when there are no legac

Re: [Xen-devel] [PATCH] x86: Xen PV guests don't have the rtc_cmos platform device

On 12/09/2015 10:00 AM, Sander Eikelenboom wrote: On 2015-12-09 15:42, Jan Beulich wrote: On 09.12.15 at 15:32, wrote: --- a/arch/x86/kernel/rtc.c +++ b/arch/x86/kernel/rtc.c @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void) } #endif +if

[PATCH] x86: Xen PV guests don't have the rtc_cmos platform device

it to any paravirt_enabled() guest since lguest is also unable to probe this device) Reported-by: Sander Eikelenboom <li...@eikelenboom.it> Signed-off-by: David Vrabel <david.vra...@citrix.com> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Tested-by: Sander Eikelenboom <

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

On 12/08/2015 04:02 PM, Thomas Gleixner wrote: On Fri, 4 Dec 2015, David Vrabel wrote: On 04/12/15 14:06, David Vrabel wrote: On 03/12/15 10:43, David Vrabel wrote: Adding the rtc platform device when there are no legacy irqs (no legacy PIC) causes a conflict with other devices that end up

Re: [Xen-devel] [PATCH] x86: Xen PV guests don't have the rtc_cmos platform device

On 12/09/2015 10:27 AM, Jan Beulich wrote: On 09.12.15 at 16:15, wrote: On 12/09/2015 10:00 AM, Sander Eikelenboom wrote: On 2015-12-09 15:42, Jan Beulich wrote: On 09.12.15 at 15:32, wrote: --- a/arch/x86/kernel/rtc.c +++

[PATCH v2] x86: Xen PV guests don't have the rtc_cmos platform device

). Instead of explicitly testing whether the guest is privileged we can extend pv_info structure to include information about guest's RTC support. Reported-by: Sander Eikelenboom <li...@eikelenboom.it> Signed-off-by: David Vrabel <david.vra...@citrix.com> Signed-off-by: Boris Ostrovsky &

Re: [Xen-devel] [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

On 12/14/2015 10:35 AM, Roger Pau Monné wrote: El 14/12/15 a les 16.27, Konrad Rzeszutek Wilk ha escrit: On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote: Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor will likely perform same IPIs as would have the guest

Re: [Xen-devel] [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

On 12/14/2015 08:58 AM, David Vrabel wrote: On 13/12/15 00:25, Boris Ostrovsky wrote: Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor will likely perform same IPIs as would have the guest. More importantly, using MMUEXT_INVLPG_MULTI may not to invalidate the guest's

Re: [PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On 12/15/2015 10:48 AM, Borislav Petkov wrote: On Tue, Dec 15, 2015 at 10:21:37AM -0500, Boris Ostrovsky wrote: I know this has been in the tip tree --- when do you think this will go Linus tree? In the 4.4 timeframe? It is queued for 4.5 currently. Xen 32-bit PV guests are broken without

[PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Suggested-by: Jan Beulich <jbeul...@suse.com> Cc: sta...@vger.kernel.org # 3.14+ --- arch/x86/xen/mmu.c |9 ++--- 1 files changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 9c47

Re: [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

On 12/14/2015 10:27 AM, Konrad Rzeszutek Wilk wrote: On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote: Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor will likely perform same IPIs as would have the guest. But if the VCPU is asleep, doing it via

Re: [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

t 07:25:55PM -0500, Boris Ostrovsky wrote: Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor will likely perform same IPIs as would have the guest. But if the VCPU is asleep, doing it via the hypervisor will save us waking up the guest VCPU, sending an IPI - just to do

Re: [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

On 12/15/2015 10:03 AM, Jan Beulich wrote: On 15.12.15 at 15:36, <boris.ostrov...@oracle.com> wrote: On 12/14/2015 10:27 AM, Konrad Rzeszutek Wilk wrote: On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote: Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hype

Re: [PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On 11/19/2015 04:55 PM, Boris Ostrovsky wrote: After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack frame that is passed to xen_sysexit is no longer a "standard" one (i.e. it's not pt_

Re: [Xen-devel] [PATCH RFC 3/3] xen/Kconfig: add XEN_TIME_VSYSCALL option

On 01/04/2016 11:12 AM, David Vrabel wrote: On 28/12/15 21:52, Joao Martins wrote: This option enables support for pvclock vsyscall/vdso support on Xen. Default is off, since Xen doesn't expose yet the PVCLOCK_TSC_STABLE_BIT flag. Do we need a Kconfig option for this? I think this should

Re: [PATCH RFC 2/3] x86/xen/time: setup vcpu 0 time info page

On 12/28/2015 04:52 PM, Joao Martins wrote: + +static int xen_setup_vsyscall_time_info(int cpu) +{ + struct pvclock_vsyscall_time_info *ti; + struct vcpu_register_time_memory_area t; + struct pvclock_vcpu_time_info *pvti; + unsigned long mem; + int ret, size; +

Re: [PATCH RFC 2/3] x86/xen/time: setup vcpu 0 time info page

On 01/04/2016 03:41 PM, Joao Martins wrote: On 01/04/2016 04:07 PM, Boris Ostrovsky wrote: On 12/28/2015 04:52 PM, Joao Martins wrote: + + size = PAGE_ALIGN(sizeof(struct pvclock_vsyscall_time_info)); + mem = memblock_alloc(size, PAGE_SIZE); + if (!mem

Re: arch/x86/xen/suspend.c:70:9: error: implicit declaration of function 'xen_pv_domain'

On 12/22/2015 06:49 AM, Stefano Stabellini wrote: On Mon, 21 Dec 2015, Andrew Morton wrote: On Mon, 21 Dec 2015 00:43:17 +0800 kbuild test robot wrote: First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu.

On 11/30/2015 04:46 PM, Sander Eikelenboom wrote: On 2015-11-30 22:45, Konrad Rzeszutek Wilk wrote: On Sat, Nov 28, 2015 at 04:47:43PM +0100, Sander Eikelenboom wrote: Hi all, I have just tested a 4.4-rc2 kernel (current linus tree) + the tip tree pulled on top. Running this kernel under Xen

Re: [Xen-devel] [PATCH] xen/events: Always allocate legacy interrupts on PV guests

On 11/18/2015 09:28 AM, Vitaly Kuznetsov wrote: Boris Ostrovsky <boris.ostrov...@oracle.com> writes: On 11/18/2015 06:16 AM, Vitaly Kuznetsov wrote: Boris Ostrovsky <boris.ostrov...@oracle.com> writes: After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before

Re: [Xen-devel] [PATCH] xen/events: Always allocate legacy interrupts on PV guests

On 11/18/2015 06:16 AM, Vitaly Kuznetsov wrote: Boris Ostrovsky <boris.ostrov...@oracle.com> writes: After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before allocating descs for legacy IRQs") early_irq_init() will no longer preallocate descriptors for legacy interr

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On 11/17/2015 02:16 PM, Andy Lutomirski wrote: Looks good to me. Does Xen have any sysexit/sysret32 equivalent to return to 32-bit user mode? If so, it could be worth trying to wire it up by patching the jz instead of the test instruction. We can actually make patching a little bit more

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On 11/17/2015 02:37 PM, Boris Ostrovsky wrote: On 11/17/2015 02:16 PM, Andy Lutomirski wrote: Looks good to me. Does Xen have any sysexit/sysret32 equivalent to return to 32-bit user mode? If so, it could be worth trying to wire it up by patching the jz instead of the test instruction. We

Re: [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On 11/18/2015 03:58 PM, Andy Lutomirski wrote: On Wed, Nov 18, 2015 at 12:50 PM, Brian Gerst wrote: Can you just add !xen_pv_domain() to the opportunistic SYSRET check instead? Bury the alternatives in that macro, ie. static_cpu_has(X86_FEATURE_XENPV). That would likely

Re: [PATCH v5 7/7] xen/x86: support XENPF_settime64

. Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[PATCH] xen/events: Always allocate legacy interrupts on PV guests

escriptors ourselves. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Suggested-by: Thomas Gleixner <t...@linutronix.de> --- v3: Add arm64 definition of nr_legacy_irqs() arch/arm/include/asm/irq.h | 4 arch/arm64/include/asm/irq.h | 6 ++ drivers/xen/ev

Re: [PATCH v2] xen/events: Always allocate legacy interrupts on PV guests

On 11/20/2015 06:24 AM, Stefano Stabellini wrote: On Wed, 18 Nov 2015, Boris Ostrovsky wrote: After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before allocating descs for legacy IRQs") early_irq_init() will no longer preallocate descriptors for legacy interrupts if PIC does

Re: [PATCH v2] xen/events: Always allocate legacy interrupts on PV guests

On 11/20/2015 10:36 AM, Stefano Stabellini wrote: On Fri, 20 Nov 2015, Boris Ostrovsky wrote: On 11/20/2015 06:24 AM, Stefano Stabellini wrote: On Wed, 18 Nov 2015, Boris Ostrovsky wrote: After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before allocating descs for legacy

Re: [PATCH v2] xen/events: Always allocate legacy interrupts on PV guests

On 11/20/2015 11:33 AM, Stefano Stabellini wrote: BTW, I got this build error: STUBCPY drivers/firmware/efi/libstub/lib-sort.stub.o R_AARCH64_ABS64 __efistub_sort 0008 R_AARCH64_ABS64 .init__ksymtab_strings drivers/firmware/efi/libstub/lib-sort.stub.o:

[PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

xen_sysexit we don't need to fix up the stack and instead follow entry_SYSENTER_32's IRET path directly to xen_iret. We can do the same thing for compat mode even though stack does not need to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in the subsequent patch) Signed-off

[PATCH v2 2/3] x86: irq_enable_sysexit pv op is no longer needed

As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests" irq_enable_sysexit pv op is not called by Xen PV guests anymore and since they were the only ones who used it we can safely remove it. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x8

[PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

Boris Ostrovsky (3): x86/xen: Avoid fast syscall path for Xen PV guests x86: irq_enable_sysexit pv op is no longer needed x86: usergs_sysret32 pv op is no longer needed arch/x86/entry/entry_32.S | 13 + arch/x86/entry/entry_64_compat.S | 20

[PATCH v2 3/3] x86: usergs_sysret32 pv op is no longer needed

As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests" usergs_sysret32 pv op is not called by Xen PV guests anymore and since they were the only ones who used it we can safely remove it. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ---

Re: [PATCH] xen/events: Always allocate legacy interrupts on PV guests

On 11/20/2015 11:35 AM, Stefano Stabellini wrote: On Fri, 20 Nov 2015, Boris Ostrovsky wrote: After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before allocating descs for legacy IRQs") early_irq_init() will no longer preallocate descriptors for legacy interrupts i

Re: [PATCH] x86/mm: fix regression with huge pages on PAE

On 11/12/2015 04:00 AM, Kirill A. Shutemov wrote: On Thu, Nov 12, 2015 at 09:54:18AM +0100, Ingo Molnar wrote: * Kirill A. Shutemov wrote: diff --git a/arch/x86/include/asm/page_types.h b/arch/x86/include/asm/page_types.h index c5b7fb2774d0..cc071c6f7d4d

Re: [PATCH 3/2] xen-pciback: drop rom_init()

On 06/06/2016 04:47 AM, Jan Beulich wrote: > It's identical to bar_init() now. > > Signed-off-by: Jan Beulich > --- > I'm sorry for this 3/2 - I only now noticed that this additional > simplification is now possible. I wonder whether we should also move content of

Re: [PATCH 1/2] xen-pciback: return proper values during BAR sizing

On 06/06/2016 04:11 AM, Jan Beulich wrote: > @@ -225,38 +225,42 @@ static inline void read_dev_bar(struct p > (PCI_BASE_ADDRESS_SPACE_MEMORY | > PCI_BASE_ADDRESS_MEM_TYPE_64))) { > bar_info->val = res[pos - 1].start >>

Re: [PATCH 2/2] xen-pciback: clean up read_dev_bar()

On 06/06/2016 04:12 AM, Jan Beulich wrote: > - drop unused function parameter > - simplify determination of 64-bit memory resource > - use const and unsigned > > Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

Re: [PATCH 1/2] xen-pciback: return proper values during BAR sizing

two entries. I thought that both words of a 64-bit BAR would result in a return under this check so both would be zero. But yes, pos needs to be initialized anyway (I didn't see this in the diff). Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

Re: [PATCH 3/2] xen-pciback: drop rom_init()

On 06/06/2016 09:54 AM, Jan Beulich wrote: On 06.06.16 at 15:09, wrote: >> On 06/06/2016 04:47 AM, Jan Beulich wrote: >>> It's identical to bar_init() now. >>> >>> Signed-off-by: Jan Beulich >>> --- >>> I'm sorry for this 3/2 - I only now

Re: [PATCH v2 1/2] xen-pciback: return proper values during BAR sizing

On 06/07/2016 02:30 AM, Jan Beulich wrote: > Reads following writes with all address bits set to 1 should return all > changeable address bits as one, not the BAR size (nor, as was the case > for the upper half of 64-bit BARs, the high half of the region's end > address). Presumably this didn't

Re: [PATCH v2 2/2] xen-pciback: clean up {bar,rom}_init()

> > Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/05/2016 12:58 AM, Lv Zheng wrote: > ACPICA commit c49a751b4dae7baec1790748a2b4b6e8ab599f51 > > For Access Size = 0, it actually can use user expected access bit width. > This patch implements this. > > Besides of the ACPICA upstream commit, this patch also includes a fix fixing > the issue

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

- torva...@linux-foundation.org wrote: > On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky > <boris.ostrov...@oracle.com> wrote: > > > > This breaks on older compilers: > > > > CC fs/nfs/nfs4state.o > > /home/build/linux-linus/fs/nfs/nfs4

Re: [RFC PATCH v2] ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width()

zed that the address check >> might not be necessary. >> But we need a max_bit_width check in this function to make it prepared for a >> future usage in acpi_read()/acpi_write(). >> Thanks in advance. You can add Tested-by: Boris Ostrovsky <boris.ostrov...@oracle.com> altho

Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/26/2016 12:26 PM, Jan Beulich wrote: >>>> Boris Ostrovsky <boris.ostrov...@oracle.com> 05/25/16 9:17 PM >>> >> On 05/05/2016 12:58 AM, Lv Zheng wrote: >>> +static u8 >>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg,

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

On 05/26/2016 11:29 AM, Anna Schumaker wrote: > Hi Linus, > > The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99: > > Linux 4.6-rc7 (2016-05-08 14:38:32 -0700) > > are available in the git repository at: > > git://git.linux-nfs.org/projects/anna/linux-nfs.git

Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/27/2016 03:34 AM, Zheng, Lv wrote: > Hi, > >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] >> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access >> bit width support >> >> On 05/26/2016 12:26 PM, Jan Beulich wrote:

Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/26/2016 12:55 PM, Boris Ostrovsky wrote: > On 05/26/2016 12:26 PM, Jan Beulich wrote: >>>>> Boris Ostrovsky <boris.ostrov...@oracle.com> 05/25/16 9:17 PM >>> >>> On 05/05/2016 12:58 AM, Lv Zheng wrote: >>>> +static u8 >>>>

Re: [PATCH 0/3] xen: add full support for CONFIG_PARAVIRT_TIME_ACCOUNTING

24 + > include/xen/interface/xen.h | 17 ++- > 7 files changed, 60 insertions(+), 27 deletions(-) > Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

[PATCH] xen/PMU: Log VPMU initialization error at lower level

This will match how PMU errors are reported at check_hw_exists()'s msr_fail label, which is reached when VPMU initialzation fails. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x

Re: [PATCH] xen/pciback: Fix conf_space read/write overlap check.

o https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html > > Cc: Jan Beulich <jbeul...@suse.com> > Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> > Cc: sta...@vger.kernel.org > Signed-off-by: Andrey Grodzovsky <andrey2...@gmail.com> + David and Juergen

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

On 02/08/2016 11:26 AM, Andrew Cooper wrote: On 08/02/16 16:12, Boris Ostrovsky wrote: On 02/08/2016 11:05 AM, Andrew Cooper wrote: For compatibility with other virtualisation specs, Xen's cpuid leaves shift depending on configuration. Spec at http://xenbits.xen.org/gitweb/?p=xen.git

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

On 02/08/2016 11:35 AM, Borislav Petkov wrote: On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote: I think we are OK for PV because this code will be executed after pvops are set and so we will be calling xen_cpuid(). Not for the early loader - it is too early for pvops then. So

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

On 02/08/2016 11:05 AM, Andrew Cooper wrote: For compatibility with other virtualisation specs, Xen's cpuid leaves shift depending on configuration. Spec at

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

On 02/08/2016 11:45 AM, Borislav Petkov wrote: On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote: Does the early loader have extable support? If so, this is fairly easy to fix. If not, we have a problem. It doesn't and regardless, you want to have this CPUID querying as simple

Re: [PATCH v2 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

com> Cc: sta...@vger.kernel.org Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

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

On 02/04/2016 03:57 PM, Luis R. Rodriguez wrote: Ah, well here lies the issue. As per hpa subarch was not designed for defining a hypervisor, but rather at least subarch PC (0) [should be used if the hardware is] "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need a special

Re: [PATCH 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 02/05/2016 08:21 AM, Juergen Gross wrote: When adding more than one LUN to a frontend a warning for a failed assignment is issued in dom0 for each already existing LUN. Avoid this warning. Aren't you just factoring out the check? The warning is still printed for each

Re: [PATCH 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 02/05/2016 10:50 AM, Boris Ostrovsky wrote: @@ -962,33 +973,31 @@ static int scsiback_del_translation_entry(struct vscsibk_info *info, struct ids_tuple *v) { struct v2p_entry *entry; -struct list_head *head = &(info->v2p_entry_lists); u

Re: [PATCH 1/2] xen/scsiback: correct frontend counting

On 02/05/2016 08:21 AM, Juergen Gross wrote: When adding a new frontend to xen-scsiback don't decrement the number of active frontends in case of no error. Not doing so results in a I think you meant "Doing so". Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

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

On 02/06/2016 03:05 PM, Andy Lutomirski wrote: Anyway, this is all ridiculous. I propose that rather than trying to clean up paravirt_enabled, you just delete it. Here are its users: static inline bool is_hypervisor_range(int idx) { /* * 8000 - 87ff is

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

On 02/06/2016 05:04 PM, Borislav Petkov wrote: On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote: int __init microcode_init(void) { [...] if (paravirt_enabled() || dis_ucode_ldr) return -EINVAL; This is also asking "are we the natively booted

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

On 02/08/2016 11:52 AM, Boris Ostrovsky wrote: On 02/08/2016 11:45 AM, Borislav Petkov wrote: On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote: Does the early loader have extable support? If so, this is fairly easy to fix. If not, we have a problem. It doesn't and regardless

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

On 02/06/2016 03:59 AM, Luis R. Rodriguez wrote: The enumeration of legacy crap by ACPI boot flags seems to provide enough details to suit our needs if we really wanted to zero down on the specifics of what paravirt_legacy() means, there are these flags: /* Masks for FADT IA-PC Boot

Re: [PATCH 2/2] xen/scsiback: avoid warnings when adding multiple LUNs to a domain

On 02/05/2016 11:59 AM, Juergen Gross wrote: On 05/02/16 16:50, Boris Ostrovsky wrote: On 02/05/2016 08:21 AM, Juergen Gross wrote: When adding more than one LUN to a frontend a warning for a failed assignment is issued in dom0 for each already existing LUN. Avoid this warning. Aren't you

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

On 02/04/2016 07:14 AM, Roger Pau Monné wrote: El 4/2/16 a les 11:04, David Vrabel ha escrit: On 01/02/16 15:38, Boris Ostrovsky wrote: HVMlite guests need to be viewed as having APIC, otherwise smpboot code, for example, will complain. I think we should consider always giving HVMlite guests

Re: [Xen-devel] [PATCH v2 10/11] xen/hvmlite: Boot secondary CPUs

On 02/04/2016 05:38 AM, David Vrabel wrote: On 01/02/16 15:38, Boris Ostrovsky wrote: HVMlite secondary VCPUs use baremetal bringup path (i.e. native_* smp_ops) but need to do some preparation in PV code. If we always provided an emulated APIC could we use the native SMP bring-up instead? We

[PATCH] x86, microcode: Remove unnecessary paravirt_enabled check

ug() macro which is invalid for Xen PV guests. A subsequent commit, fbae4ba8c4a3 ("x86, microcode: Reload microcode on resume"), eliminated this callchain thus making a18a0f6850d4 unnecessary. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/kernel/cpu/microcode/

Re: [Xen-devel] [PATCH v2 07/11] xen/hvmlite: Initialize context for secondary VCPUs

On 02/04/2016 07:58 AM, Doug Goldstein wrote: On 2/2/16 10:58 AM, Boris Ostrovsky wrote: On 02/02/2016 11:21 AM, David Vrabel wrote: This needs some more description in the commit message. --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c [...] +hctxt->cpu_regs.x86_32.cs_base

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

On 02/03/2016 06:40 PM, Luis R. Rodriguez wrote: On Wed, Feb 03, 2016 at 03:11:56PM -0500, Boris Ostrovsky wrote: On 02/03/2016 01:55 PM, Luis R. Rodriguez wrote: I saw no considerations for the recommendations I had made last on your v1: https://lkml.kernel.org/r/CAB=NE6XPA0YzbnM8

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

On 01/27/2016 02:00 PM, Luis R. Rodriguez wrote: On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote: Worth mentioning here also is hpa's clarification on when subarch type PC (0) should be used: [it should be used if the hardware is] "enumerable using standard PC

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

On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote: On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote: 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

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

On 02/02/2016 11:13 AM, David Vrabel wrote: On 01/02/16 15:38, Boris Ostrovsky wrote: .. just like we currently do for PVH guests I think this description is wrong. In the HVM guess the grant table initialization is delayed, but here we want to do it immediately (since we may have no platform

Re: [Xen-devel] [PATCH v2 07/11] xen/hvmlite: Initialize context for secondary VCPUs

On 02/02/2016 11:21 AM, David Vrabel wrote: This needs some more description in the commit message. --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c [...] + hctxt->cpu_regs.x86_32.cs_base = 0; + hctxt->cpu_regs.x86_32.cs_limit = ~0u; +

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

On 02/02/2016 11:27 AM, David Vrabel wrote: On 01/02/16 15:38, Boris Ostrovsky wrote: xen_timer_init() will be called from apic_bsp_setup(). I must be missing something because xen_init_time_ops() is only called from the PV-only xen_start_kernel()? This is leftover from the earlier series

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

On 02/02/2016 11:39 AM, David Vrabel wrote: On 01/02/16 15:38, Boris Ostrovsky wrote: --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -29,6 +29,12 @@ extern enum xen_domain_type xen_domain_type; #define xen_initial_domain() (0) #endif/* CONFIG_XEN_DOM0 */ +#ifdef

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