Re: [PATCH v9 22/32] virtio_pci: queue_reset: extract the logic of active vq for modern pci

On Tue, 12 Apr 2022 14:58:19 +0800, Jason Wang wrote: > > 在 2022/4/6 上午11:43, Xuan Zhuo 写道: > > Introduce vp_active_vq() to configure vring to backend after vq attach > > vring. And configure vq vector if necessary. > > > > Signed-off-by: Xuan Zhuo > > --- > > drivers/virtio/virtio_pci_modern.c

Re: [PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero

Hi Jason, > However, one thing that I've been thinking about is that the c0 random > register is actually kind of garbage. In my fuzzy decade-old memory of > MIPS, I believe the c0 random register starts at the maximum number of > TLB entries (16?), and then counts down cyclically, decrementing on

Re: [PATCH v4 03/11] riscv: use fallback for random_get_entropy() instead of zero

Hi Rob, On Wed, Apr 13, 2022 at 4:40 PM Rob Herring wrote: > Moving this check to get_cycles() implementation would eliminate the > RiscV implementation of random_get_entropy() if you follow my other > suggestion. Not an option. random_get_entropy() != get_cycles(). Sometimes these are different

Re: [PATCH v4 01/11] timekeeping: add raw clock fallback for random_get_entropy()

Hi Rob, On Wed, Apr 13, 2022 at 4:32 PM Rob Herring wrote: > 'does not have a usable get_cycles(), ...' as clearly some arches have > get_cycles() and yet still need a fallback. > > Why not handle the 'if get_cycles() returns 0 do the fallback' within > a weak random_get_entropy() function? Then

Re: [PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero

Hi Maciej, On Wed, Apr 13, 2022 at 2:46 PM Maciej W. Rozycki wrote: > > On Wed, 13 Apr 2022, Thomas Bogendoerfer wrote: > > > > diff --git a/arch/mips/include/asm/timex.h b/arch/mips/include/asm/timex.h > > > index b05bb70a2e46..abc60a6395e3 100644 > > > --- a/arch/mips/include/asm/timex.h > > >

Re: [PATCH v4 03/11] riscv: use fallback for random_get_entropy() instead of zero

On Wed, Apr 13, 2022 at 6:56 AM Jason A. Donenfeld wrote: > > In the event that random_get_entropy() can't access a cycle counter or > similar, falling back to returning 0 is really not the best we can do. > Instead, at least calling random_get_entropy_fallback() would be > preferable, because tha

Re: [PATCH v4 01/11] timekeeping: add raw clock fallback for random_get_entropy()

On Wed, Apr 13, 2022 at 6:55 AM Jason A. Donenfeld wrote: > > The addition of random_get_entropy_fallback() provides access to > whichever time source has the highest frequency, which is useful for > gathering entropy on platforms without available cycle counters. It's > not necessarily as good as

Re: [PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero

On Wed, 13 Apr 2022, Thomas Bogendoerfer wrote: > > diff --git a/arch/mips/include/asm/timex.h b/arch/mips/include/asm/timex.h > > index b05bb70a2e46..abc60a6395e3 100644 > > --- a/arch/mips/include/asm/timex.h > > +++ b/arch/mips/include/asm/timex.h > > @@ -94,7 +94,7 @@ static inline unsigned lo

Re: [PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero

On Wed, Apr 13, 2022 at 01:54:04PM +0200, Jason A. Donenfeld wrote: > In the event that random_get_entropy() can't access a cycle counter or > similar, falling back to returning 0 is really not the best we can do. > Instead, at least calling random_get_entropy_fallback() would be > preferable, beca

Re: [PATCH v9 18/32] virtio_ring: introduce virtqueue_resize()

On Tue, 12 Apr 2022 14:41:18 +0800, Jason Wang wrote: > > 在 2022/4/6 上午11:43, Xuan Zhuo 写道: > > Introduce virtqueue_resize() to implement the resize of vring. > > Based on these, the driver can dynamically adjust the size of the vring. > > For example: ethtool -G. > > > > virtqueue_resize() implem

Re: [PATCH v9 18/32] virtio_ring: introduce virtqueue_resize()

On Tue, 12 Apr 2022 14:41:18 +0800, Jason Wang wrote: > > 在 2022/4/6 上午11:43, Xuan Zhuo 写道: > > Introduce virtqueue_resize() to implement the resize of vring. > > Based on these, the driver can dynamically adjust the size of the vring. > > For example: ethtool -G. > > > > virtqueue_resize() implem

[PATCH v4 11/11] random: insist on random_get_entropy() existing in order to simplify

All platforms are now guaranteed to provide some value for random_get_entropy(). In case some bug leads to this not being so, we print a warning, because that indicates that something is really very wrong (and likely other things are impacted too). This should never be hit, but it's a good and chea

[PATCH v4 10/11] xtensa: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 09/11] sparc: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 08/11] um: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 07/11] x86: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 06/11] nios2: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 05/11] arm: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 03/11] riscv: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 02/11] m68k: use fallback for random_get_entropy() instead of zero

In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies ev

[PATCH v4 01/11] timekeeping: add raw clock fallback for random_get_entropy()

The addition of random_get_entropy_fallback() provides access to whichever time source has the highest frequency, which is useful for gathering entropy on platforms without available cycle counters. It's not necessarily as good as being able to quickly access a cycle counter that the CPU has, but i

[PATCH v4 00/11] archs/random: fallback to best raw ktime when no cycle counter

Hi folks, The RNG uses a function called random_get_entropy() basically anytime that it needs to timestamp an event. For example, an interrupt comes in, and we mix a random_get_entropy() into the entropy pool somehow. Somebody mashes their keyboard or moves their mouse around? We mix a random_get_

Re: [PATCH v9 23/32] virtio_pci: queue_reset: support VIRTIO_F_RING_RESET

On Tue, 12 Apr 2022 15:07:58 +0800, Jason Wang wrote: > > 在 2022/4/6 上午11:43, Xuan Zhuo 写道: > > This patch implements virtio pci support for QUEUE RESET. > > > > Performing reset on a queue is divided into these steps: > > > > 1. notify the device to reset the queue > > 2. recycle the buffer s

Re: [PATCH v9 31/32] virtio_net: support rx/tx queue resize

On Wed, 13 Apr 2022 16:00:18 +0800, Jason Wang wrote: > > 在 2022/4/6 上午11:43, Xuan Zhuo 写道: > > This patch implements the resize function of the rx, tx queues. > > Based on this function, it is possible to modify the ring num of the > > queue. > > > > There may be an exception during the resize pr

Re: [PATCH v9 32/32] virtio_net: support set_ringparam

在 2022/4/6 上午11:43, Xuan Zhuo 写道: Support set_ringparam based on virtio queue reset. Users can use ethtool -G eth0 to modify the ring size of virtio-net. Signed-off-by: Xuan Zhuo Acked-by: Jason Wang (One thing that I see is that, when resize fails, the param reported via get_ringparam

Re: [PATCH v9 31/32] virtio_net: support rx/tx queue resize

在 2022/4/6 上午11:43, Xuan Zhuo 写道: This patch implements the resize function of the rx, tx queues. Based on this function, it is possible to modify the ring num of the queue. There may be an exception during the resize process, the resize may fail, or the vq can no longer be used. Either way, we

Re: [PATCH v9 09/32] virtio_ring: split: extract the logic of vq init

On Tue, 12 Apr 2022 11:42:25 +0800, Jason Wang wrote: > > 在 2022/4/6 上午11:43, Xuan Zhuo 写道: > > Separate the logic of initializing vq, and subsequent patches will call > > it separately. > > > > The feature of this part is that it does not depend on the information > > passed by the upper layer an