search for: ostrovsky

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330642361 -3600 # Node ID 99df5c6b2964ceaa73651d7bc02fb1ae820f7691 # Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9 x86: Use deep C states for off-lined CPUs Currently when a core is taken off-line it is placed in C1 state (unless MONITOR/MWAIT is used). T...

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1345135101 -7200 # Node ID 85190245a94d9945b7656c971ba36f7d1eff5c19 # Parent 6d56e31fe1e1dc793379d662a36ff1731760eb0c AMD, powernow: Update P-state directly when _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL When _PSD''s CoordType is DOMAIN_C...

On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote: > > So, I suppose it can be relaxed to a null test and a WARN_ON that it > > hasn't changed? > > You mean > > if (use_ptemod) { > ??????? WARN_ON(map->vma != vma); > ??????? ... > > > Yes, that sounds good. I amended my copy of the patch wi...

From: Matt Wilson <msw@amazon.com> Commit f62805f1 introduced a bug where lazy MMU mode isn''t exited if a m2p_add/remove_override call fails. Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Anthony Liguori <aliguori@amazon.com> Cc: xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Matt Wilson <msw@amazon.com> --- drivers/xen/grant-table.c | 6 ++++-- 1 f...

On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote: > On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: > > On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > >> On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > >>> Maybe we can add a new field to the alternatives entry struct which > >>> sp...

On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote: > On 10/17/2017 04:17 PM, Josh Poimboeuf wrote: > > On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > >> On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > >>> Maybe we can add a new field to the alternatives entry struct which > >>> sp...

On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: > On 10/12/2017 03:27 PM, Andrew Cooper wrote: >> On 12/10/17 20:11, Boris Ostrovsky wrote: >>> There is also another problem: >>> >>> [ 1.312425] general protection fault: 0000 [#1] SMP >>> [ 1.312901] Modules linked in: >>> [ 1...

On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: > On 10/12/2017 03:27 PM, Andrew Cooper wrote: >> On 12/10/17 20:11, Boris Ostrovsky wrote: >>> There is also another problem: >>> >>> [ 1.312425] general protection fault: 0000 [#1] SMP >>> [ 1.312901] Modules linked in: >>> [ 1...

...compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said 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: usergs_sysret32 pv op is no longer needed arch/x86/entry/entry_32.S | 11 ++++------- arch/x86/entry/entry_64_compat.S | 16 ++++++---------- arch/x86/include/asm/...

...compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said 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: usergs_sysret32 pv op is no longer needed arch/x86/entry/entry_32.S | 11 ++++------- arch/x86/entry/entry_64_compat.S | 16 ++++++---------- arch/x86/include/asm/...

...anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a single JMP * Add magic prefix to X86_FEATURE_XENPV comment to avoid having it printed in /proc/cpuinfo * Clarify in commit messages why irq_enable_sysexit and usergs_sysret32 are 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: usergs_sysret32 pv op is no longer needed arch/x86/entry/entry_32.S | 13 +++++-------- arch/x86/entry/entry_64_compat.S | 20 ++++++++------------ arch/x86/includ...

...anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a single JMP * Add magic prefix to X86_FEATURE_XENPV comment to avoid having it printed in /proc/cpuinfo * Clarify in commit messages why irq_enable_sysexit and usergs_sysret32 are 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: usergs_sysret32 pv op is no longer needed arch/x86/entry/entry_32.S | 13 +++++-------- arch/x86/entry/entry_64_compat.S | 20 ++++++++------------ arch/x86/includ...

...nable_sysexit-pv-op.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable at vger.kernel.org> know about it. >From 88c15ec90ff16880efab92b519436ee17b198477 Mon Sep 17 00:00:00 2001 From: Boris Ostrovsky <boris.ostrovsky at oracle.com> Date: Thu, 19 Nov 2015 16:55:46 -0500 Subject: x86/paravirt: Remove the unused irq_enable_sysexit pv op From: Boris Ostrovsky <boris.ostrovsky at oracle.com> commit 88c15ec90ff16880efab92b519436ee17b198477 upstream. As result of commit "x86/xen: A...

Hi all, I''ve had a report of a host starting to give this output: Oct 7 19:36:37 kernel: INFO: rcu_sched self-detected stall on CPU { 2} (t=273561 jiffies g=17919 c=17918 q=9688) Oct 7 19:36:37 kernel: sending NMI to all CPUs: Oct 7 19:36:37 kernel: xen: vector 0x2 is not implemented Kernel is 3.11.2. Xen is 4.2.3. I''ve seen various random reports of this, but never a follow

On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote: > On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: > > On 10/12/2017 03:27 PM, Andrew Cooper wrote: > >> On 12/10/17 20:11, Boris Ostrovsky wrote: > >>> There is also another problem: > >>> > >>> [ 1.312425] general protection fault: 000...

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_regs). > > Si...

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 this. > So this needs to go into 4.4 or even earlier? Since 5f310f739b4c w...

On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > > > Maybe we can add a new field to the alternatives entry struct which > > specifies the offset to the CALL instruction, so apply_alternatives() > > can find it. > > We'd also have to assume that the r...

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_regs). > > Si...

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 this. > So this needs to go into 4.4 or even earlier? Since 5f310f739b4c w...