On Wed, 2022-11-02 at 23:18 +, Sean Christopherson wrote:
> Define pr_fmt using KBUILD_MODNAME for all KVM x86 code so that
> printks
> use consistent formatting across common x86, Intel, and AMD code. In
> addition to providing consistent print formatting, using
> KBUILD_MODNAME,
> e.g.
On Wed, 2022-11-02 at 23:19 +, Sean Christopherson wrote:
> From: Chao Gao
>
> The CPU STARTING section doesn't allow callbacks to fail. Move KVM's
> hotplug callback to ONLINE section so that it can abort onlining a
> CPU in
> certain cases to avoid potentially breaking VMs running on
Le 10/11/2022 à 01:35, Jordan Niethe a écrit :
> On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
>
>> -#define queued_spin_lock queued_spin_lock
>>
>> -static inline void queued_spin_unlock(struct qspinlock *lock)
>> +static __always_inline int queued_spin_trylock(struct qspinlock
On Thu, 2022-11-10 at 01:08 +, Huang, Kai wrote:
> > - WARN_ON(!irqs_disabled());
> > + /*
> > +* Compatibility checks are done when loading KVM and when enabling
> > +* hardware, e.g. during CPU hotplug, to ensure all online CPUs are
> > +* compatible, i.e. KVM should never
On Thu, 2022-11-10 at 01:33 +, Huang, Kai wrote:
> > @@ -9283,7 +9283,13 @@ static int
> > kvm_x86_check_processor_compatibility(struct kvm_x86_init_ops *ops)
> > int cpu = smp_processor_id();
> > struct cpuinfo_x86 *c = _data(cpu);
> >
> > - WARN_ON(!irqs_disabled());
> > + /*
>
On Wed, Nov 9, 2022 at 1:24 PM Christophe Leroy
wrote:
>
> + linuxppc-dev list as we start mentioning powerpc.
>
> Le 09/11/2022 à 18:43, Song Liu a écrit :
> > On Wed, Nov 9, 2022 at 3:18 AM Mike Rapoport wrote:
> >>
> > [...]
> >
>
> The proposed execmem_alloc() looks to me very much
On Wed, 2022-11-02 at 23:19 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Disable CPU hotplug during hardware_enable_all() to prevent the corner
> case where if the following sequence occurs:
>
> 1. A hotplugged CPU marks itself online in cpu_online_mask
> 2. The hotplugged CPU
If device_register() returns error in ibmebus_bus_init(), name of kobject
which is allocated in dev_set_name() called in device_add() is leaked.
As comment of device_add() says, it should call put_device() to drop
the reference count that was set in device_initialize() when it fails,
so the name
On Wed, 2022-11-02 at 23:19 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Disable CPU hotplug during hardware_enable_all() to prevent the corner
> case where if the following sequence occurs:
>
> 1. A hotplugged CPU marks itself online in cpu_online_mask
> 2. The hotplugged CPU
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Finding the owner or a queued waiter on a lock with a preempted vcpu
> is indicative of an oversubscribed guest causing the lock to get into
> trouble. Provide some options to detect this situation and have
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Provide an option that holds off queueing indefinitely while the lock
> owner is preempted. This could reduce queueing latencies for very
> overcommitted vcpu situations.
>
> This is disabled by default.
>
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Allow for a reduction in the number of times a CPU from a different
> node than the owner can attempt to steal the lock before queueing.
> This could bias the transfer behaviour of the lock across the
>
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Use the spin_begin/spin_cpu_relax/spin_end APIs in qspinlock, which helps
> to prevent threads issuing a lot of expensive priority nops which may not
> have much effect due to immediately executing low then
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> This gives trylock slightly more strength, and it also gives most
> of the benefit of passing 'val' back through the slowpath without
> the complexity.
> ---
> arch/powerpc/include/asm/qspinlock.h | 39
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> After the head of the queue acquires the lock, it releases the
> next waiter in the queue to become the new head. Add an option
> to prod the new head if its vCPU was preempted. This may only
> have an effect
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Having all CPUs poll the lock word for the owner CPU that should be
> yielded to defeats most of the purpose of using MCS queueing for
> scalability. Yet it may be desirable for queued waiters to to yield
> to
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> If the head of queue is preventing stealing but it finds the owner vCPU
> is preempted, it will yield its cycles to the owner which could cause it
> to become preempted. Add an option to re-allow stealers
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Queued waiters which are not at the head of the queue don't spin on
> the lock word but their qnode lock word, waiting for the previous queued
> CPU to release them. Add an option which allows these waiters to
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Waiters spinning on the lock word should yield to the lock owner if the
> vCPU is preempted. This improves performance when the hypervisor has
> oversubscribed physical CPUs.
> ---
>
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Store the owner CPU number in the lock word so it may be yielded to,
> as powerpc's paravirtualised simple spinlocks do.
> ---
> arch/powerpc/include/asm/qspinlock.h | 8 +++-
>
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Give the queue head the ability to stop stealers. After a number of
> spins without sucessfully acquiring the lock, the queue head employs
> this, which will assure it is the next owner.
> ---
>
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> Allow new waiters a number of spins on the lock word before queueing,
> which particularly helps paravirt performance when physical CPUs are
> oversubscribed.
> ---
> arch/powerpc/lib/qspinlock.c | 152
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> This uses more optimal ll/sc style access patterns (rather than
> cmpxchg), and also sets the EH=1 lock hint on those operations
> which acquire ownership of the lock.
> ---
>
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
> The first 16 bits of the lock are only modified by the owner, and other
> modifications always use atomic operations on the entire 32 bits, so
> unlocks can use plain stores on the 16 bits. This is the same
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
[resend as utf-8, not utf-7]
>
> +/*
> + * Bitfields in the atomic value:
> + *
> + * 0: locked bit
> + * 16-31: tail cpu (+1)
> + */
> +#define _Q_SET_MASK(type) (((1U << _Q_ ## type ## _BITS) - 1)\
> +
On Thu, 2022-07-28 at 16:31 +1000, Nicholas Piggin wrote:
> -#define queued_spin_lock queued_spin_lock
>
> -static inline void queued_spin_unlock(struct qspinlock *lock)
> +static __always_inline int queued_spin_trylock(struct qspinlock *lock)
> {
> - if
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> For a long time, PCSs have been tightly coupled with their MACs. For
> this reason, the MAC creates the "phy" or mdio device, and then passes
> it to the PCS to initialize. This has a few disadvantages:
>
> - Each MAC must
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> Several (later) patches in this series cannot be applied until a stable
> release has occured containing the dts updates.
New kernels must remain compatible with old device trees.
+ linuxppc-dev list as we start mentioning powerpc.
Le 09/11/2022 à 18:43, Song Liu a écrit :
> On Wed, Nov 9, 2022 at 3:18 AM Mike Rapoport wrote:
>>
> [...]
>
The proposed execmem_alloc() looks to me very much tailored for x86
to be
used as a replacement for
On 11/9/22 08:46, Greg Kroah-Hartman wrote:
On Sun, Nov 06, 2022 at 04:07:42PM -0500, Nayna Jain wrote:
securityfs is meant for Linux security subsystems to expose policies/logs
or any other information. However, there are various firmware security
features which expose their variables for
On Sun, Oct 23, 2022 at 10:32:08PM +0200, Jason A. Donenfeld wrote:
> The RNG always mixes in the Linux version extremely early in boot. It
> also always includes a cycle counter, not only during early boot, but
> each and every time it is invoked prior to being fully initialized.
> Together, this
On Sun, Nov 06, 2022 at 04:07:42PM -0500, Nayna Jain wrote:
> securityfs is meant for Linux security subsystems to expose policies/logs
> or any other information. However, there are various firmware security
> features which expose their variables for user management via the kernel.
> There is
November 9, 2022 7:42 PM, "Mike Rapoport" wrote:
> Hi Yajun,
>
> On Wed, Nov 09, 2022 at 11:32:27AM +, Yajun Deng wrote:
>
>> November 9, 2022 6:55 PM, "Sachin Sant" wrote:
>>
>> On 09-Nov-2022, at 3:55 PM, Yajun Deng wrote:
>>
>> November 9, 2022 6:03 PM, "Yajun Deng" wrote:
>>
>>
Hi Yajun,
On Wed, Nov 09, 2022 at 11:32:27AM +, Yajun Deng wrote:
> November 9, 2022 6:55 PM, "Sachin Sant" wrote:
>
> >> On 09-Nov-2022, at 3:55 PM, Yajun Deng wrote:
> >>
> >> November 9, 2022 6:03 PM, "Yajun Deng" wrote:
> >>
> >>> Hey Mike,
> >>
> >> Sorry, this email should be
November 9, 2022 6:55 PM, "Sachin Sant" wrote:
>> On 09-Nov-2022, at 3:55 PM, Yajun Deng wrote:
>>
>> November 9, 2022 6:03 PM, "Yajun Deng" wrote:
>>
>>> Hey Mike,
>>
>> Sorry, this email should be sent to Sachin but not Mike.
>> Please forgive my confusion. So:
>>
>> Hey Sachin,
>> Can
> On 09-Nov-2022, at 3:25 PM, Jason A. Donenfeld wrote:
>
> Should be fixed already in today's next.
Yup, thanks. next-20221109 boots successfully.
- Sachin
> On 09-Nov-2022, at 3:55 PM, Yajun Deng wrote:
>
> November 9, 2022 6:03 PM, "Yajun Deng" wrote:
>
>> Hey Mike,
>>
> Sorry, this email should be sent to Sachin but not Mike.
> Please forgive my confusion. So:
>
> Hey Sachin,
> Can you help me test the attached file?
> Please use this
November 9, 2022 6:03 PM, "Yajun Deng" wrote:
> Hey Mike,
>
Sorry, this email should be sent to Sachin but not Mike.
Please forgive my confusion. So:
Hey Sachin,
Can you help me test the attached file?
Please use this new patch instead of the one in memblock tree.
> Can you help me test the
> On 09-Nov-2022, at 2:27 AM, Arnaldo Carvalho de Melo wrote:
>
> Em Wed, Nov 02, 2022 at 02:07:06PM +0530, Athira Rajeev escreveu:
>>
>>
>>> On 18-Oct-2022, at 2:26 PM, Athira Rajeev
>>> wrote:
>>>
>>> In perf stat with CSV output option, number of fields
>>> in metrics output is not
Hey Mike,
Can you help me test the attached file?
Please use this new patch instead of the one in memblock tree.
November 8, 2022 3:55 PM, "Mike Rapoport" wrote:
> Hi Yajun,
>
> On Tue, Nov 08, 2022 at 02:27:53AM +, Yajun Deng wrote:
>
>> Hi Sachin,
>> I didn't have a powerpc
Should be fixed already in today's next.
41 matches
Mail list logo
