The initial pvops functions handling irq flags will only ever be called
before interrupts are being enabled.
So make the __init and switch them to be dummy functions:
- xen_save_fl() can always return 0
- xen_irq_disable() is a nop
- xen_irq_enable() can BUG()
Add some generic paravirt functions
The pvops function for Xen PV guests handling the interrupt flag are
much more complex than needed.
With the supported Xen hypervisor versions they can be simplified a
lot, especially by removing the need for disabling preemption.
Juergen Gross (2):
x86/xen: remove xen_have_vcpu_info_placement
Thanks for the replying and suggesting. ;)
On 9/20/21 3:45 AM, Vivek Goyal wrote:
> On Thu, Sep 16, 2021 at 04:21:59PM +0800, JeffleXu wrote:
>> Hi, I add some performance statistics below.
>>
>>
>> On 8/17/21 8:40 PM, Vivek Goyal wrote:
>>> On Tue, Aug 17, 2021 at 10:32:14AM +0100, Dr. David
On Fri, Sep 17, 2021 at 02:57:02PM +0200, Laurent Vivier wrote:
> On 17/09/2021 00:58, Michael S. Tsirkin wrote:
> > On Thu, Sep 16, 2021 at 10:52:59AM +0200, Laurent Vivier wrote:
> > > On 13/09/2021 10:25, Alexander Potapenko wrote:
> > > > Hi Laurent,
> > > >
> > > > I took the latest kernel
Hi Mike,
On Tue, Sep 21, 2021 at 11:55 PM Mike Christie
wrote:
> The vhost worker threads need the same frame setup as io_uring's worker
> threads, but handle signals differently and do not need the same
> scheduling behavior. This patch separate's the frame setup parts of
> PF_IO_WORKER into a
On Wed, Sep 22, 2021 at 12:31:00PM +0200, Juergen Gross wrote:
> The pvops function for Xen PV guests handling the interrupt flag are
> much more complex than needed.
>
> With the supported Xen hypervisor versions they can be simplified a
> lot, especially by removing the need for disabling
On Tue, Sep 21, 2021 at 11:55 PM Mike Christie
wrote:
> We need to break up PF_IO_WORKER into the parts that are used for
> scheduling and signal handling and the part that tells copy_thread to
> treat it as a special type of thread during setup. This patch passes the
> worker_flags to
On Wed, Sep 22, 2021 at 08:08:44PM +0800, Junji Wei wrote:
> > On Sep 15, 2021, at 9:43 PM, Jason Gunthorpe wrote:
<...>
> >> 4. The FRMR api need to set key of MR through IB_WR_REG_MR.
> >> But it is impossible to change a key of mr using uverbs.
> >
> > FRMR is more like memory windows in
On Wed, Sep 22, 2021 at 09:37:37PM +0800, 魏俊吉 wrote:
> On Wed, Sep 22, 2021 at 9:06 PM Leon Romanovsky wrote:
> >
> > On Wed, Sep 22, 2021 at 08:08:44PM +0800, Junji Wei wrote:
> > > > On Sep 15, 2021, at 9:43 PM, Jason Gunthorpe wrote:
> >
> > <...>
> >
> > > >> 4. The FRMR api need to set key
On Wed, Sep 22, 2021 at 7:09 PM Laurent Vivier wrote:
>
> hwrng core uses two buffers that can be mixed in the virtio-rng queue.
>
> This series fixes the problem by adding an internal buffer in virtio-rng.
>
> Once the internal buffer is added, we can fix two other problems:
>
> - to be able to
When virtio-rng device was dropped by the hwrng core we were forced
to wait the buffer to come back from the device to not have
remaining ongoing operation that could spoil the buffer.
But now, as the buffer is internal to the virtio-rng we can release
the waiting loop immediately, the buffer
if we don't use all the entropy available in the buffer, keep it
and use it later.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 52 +++--
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/char/hw_random/virtio-rng.c
If we ensure we have already some data available by enqueuing
again the buffer once data are exhausted, we can return what we
have without waiting for the device answer.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 24 ++--
1 file changed, 10
hwrng core uses two buffers that can be mixed in the virtio-rng queue.
This series fixes the problem by adding an internal buffer in virtio-rng.
Once the internal buffer is added, we can fix two other problems:
- to be able to release the driver without waiting the device releases the
buffer
hwrng core uses two buffers that can be mixed in the
virtio-rng queue.
If the buffer is provided with wait=0 it is enqueued in the
virtio-rng queue but unused by the caller.
On the next call, core provides another buffer but the
first one is filled instead and the new one queued.
And the caller
On Wed, Sep 22, 2021 at 07:09:00PM +0200, Laurent Vivier wrote:
> hwrng core uses two buffers that can be mixed in the
> virtio-rng queue.
>
> If the buffer is provided with wait=0 it is enqueued in the
> virtio-rng queue but unused by the caller.
> On the next call, core provides another buffer
On 9/22/21 6:31 AM, Juergen Gross wrote:
> The initial pvops functions handling irq flags will only ever be called
> before interrupts are being enabled.
>
> So make the __init and switch them to be dummy functions:
What are you making __init?
>
> +/* stub always return ing 0. */
"always
On 22.09.21 23:49, Boris Ostrovsky wrote:
On 9/22/21 6:31 AM, Juergen Gross wrote:
The initial pvops functions handling irq flags will only ever be called
before interrupts are being enabled.
So make the __init and switch them to be dummy functions:
What are you making __init?
Oh, sorry,
18 matches
Mail list logo
