We try to harden virtio device notifications in 8b4ec69d7e09 ("virtio:
harden vring IRQ"). It works with the assumption that the driver or
core can properly call virtio_device_ready() at the right
place. Unfortunately, this seems to be not true and uncover various
bugs of the existing drivers,
On Tue, Jun 21, 2022 at 5:58 PM Cornelia Huck wrote:
>
> On Tue, Jun 21 2022, Jason Wang wrote:
>
> > On Tue, Jun 21, 2022 at 5:16 PM Cornelia Huck wrote:
> >>
> >> The ifdeffery looks a big ugly, but I don't have a better idea.
> >
> > I guess you meant the ccw part, I leave the spinlock here
On Wed, 15 Jun 2022 17:03:01 -0700
Nicolin Chen wrote:
> From: Jason Gunthorpe
>
> The KVM mechanism for controlling wbinvd is based on OR of the coherency
> property of all devices attached to a guest, no matter those devices are
> attached to a single domain or multiple domains.
>
> So,
Call vringh_complete_iotlb() even when we encounter a serious error
that prevents us from writing the status in the "in" header
(e.g. the header length is incorrect, etc.).
The guest is misbehaving, so maybe the ring is in a bad state, but
let's avoid making things worse.
Signed-off-by: Stefano
On Tue, 2022-06-21 at 17:34 +0800, Jason Wang wrote:
> On Tue, Jun 21, 2022 at 5:24 PM David Hildenbrand wrote:
> >
> > On 20.06.22 20:49, Ben Hutchings wrote:
> > > I've tested a 5.19-rc3 kernel on top of QEMU/KVM with machine type
> > > pc-q35-5.2. It has a virtio balloon device defined in
Limit the number of requests (4 per queue as for vdpa_sim_net) handled
in a batch to prevent the worker from using the CPU for too long.
Suggested-by: Eugenio Pérez
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 15 ++-
1 file changed, 14
Use dev_dbg() instead of dev_err()/dev_warn() to avoid flooding the
host with prints, when the guest driver is misbehaving.
In this way, prints can be dynamically enabled when the vDPA block
simulator is used to validate a driver.
Suggested-by: Jason Wang
Signed-off-by: Stefano Garzarella
---
The first two patches essentially limit the possibility of the guest
doing a DoS to the host.
The third makes the simulator more correct (following what we do in
vdpa_sim_net) by calling vringh_complete_iotlb() in the error path as well.
Stefano Garzarella (3):
vdpa_sim_blk: use dev_dbg() to
Hi Gautam,
On Wed, Mar 30, 2022 at 8:21 PM Gautam Dawar wrote:
>
> This patch introduces the control virtqueue support for vDPA
> simulator. This is a requirement for supporting advanced features like
> multiqueue.
>
> A requirement for control virtqueue is to isolate its memory access
> from
Commit bda324fd037a ("vdpasim: control virtqueue support") added two
new fields (nas, ngroups) to vdpasim_dev_attr, but we forgot to
initialize them for vdpa_sim_blk.
When creating a new vdpa_sim_blk device this causes the kernel
to panic in this way:
$ vdpa dev add mgmtdev vdpasim_blk name
Commit bda324fd037a ("vdpasim: control virtqueue support") changed
the allocation of iotlbs calling vhost_iotlb_init() for each address
space, instead of vhost_iotlb_alloc().
With this change we forgot to use the limit we had introduced with
the `max_iotlb_entries` module parameter.
Fixes:
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
# ip link set eth0 down
Missing register, driver bug
WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138
Virtio devices might lose their state when the VMM is restarted
after a suspend to disk (hibernation) cycle. This means that the
guest page size register must be restored for the virtio_mmio legacy
interface, since otherwise the virtio queues are not functional.
This is particularly problematic
Most virtio drivers provide freeze/restore callbacks to finish up
device usage before suspend and to reinitialize the virtio device after
resume. However, these callbacks are currently only called when using
virtio_pci. virtio_mmio does not have any PM ops defined.
This causes problems for
At the moment suspend to disk (hibernation) works correctly when using
virtio_pci, but not when using virtio_mmio. This is because virtio_mmio
does not call the freeze/restore callbacks provided by most virtio
drivers.
Fix this by adding the missing PM calls to virtio_mmio and restore
the guest
On Tue, Jun 21 2022, Jason Wang wrote:
> On Tue, Jun 21, 2022 at 5:16 PM Cornelia Huck wrote:
>>
>> The ifdeffery looks a big ugly, but I don't have a better idea.
>
> I guess you meant the ccw part, I leave the spinlock here in V1, but
> Michael prefers to have that.
Not doing the locking
On Tue, Jun 21, 2022 at 5:16 PM Cornelia Huck wrote:
>
> On Mon, Jun 20 2022, Jason Wang wrote:
>
> > We try to harden virtio device notifications in 8b4ec69d7e09 ("virtio:
> > harden vring IRQ"). It works with the assumption that the driver or
> > core can properly call virtio_device_ready() at
On Tue, Jun 21, 2022 at 5:24 PM David Hildenbrand wrote:
>
> On 20.06.22 20:49, Ben Hutchings wrote:
> > I've tested a 5.19-rc3 kernel on top of QEMU/KVM with machine type
> > pc-q35-5.2. It has a virtio balloon device defined in libvirt as:
> >
> >
> >> function="0x0"/>
> >
>
On 20.06.22 20:49, Ben Hutchings wrote:
> I've tested a 5.19-rc3 kernel on top of QEMU/KVM with machine type
> pc-q35-5.2. It has a virtio balloon device defined in libvirt as:
>
>
>function="0x0"/>
>
>
> but the virtio_balloon driver fails to bind to it:
>
>
On Mon, Jun 20 2022, Jason Wang wrote:
> We try to harden virtio device notifications in 8b4ec69d7e09 ("virtio:
> harden vring IRQ"). It works with the assumption that the driver or
> core can properly call virtio_device_ready() at the right
> place. Unfortunately, this seems to be not true and
On Tue, Jun 21, 2022 at 3:49 PM Eugenio Perez Martin
wrote:
>
> On Tue, Jun 21, 2022 at 5:05 AM Jason Wang wrote:
> >
> > On Mon, Jun 20, 2022 at 5:59 PM Eugenio Perez Martin
> > wrote:
> > >
> > > On Mon, Jun 20, 2022 at 10:56 AM Jason Wang wrote:
> > > >
> > > > On Thu, Jun 16, 2022 at 9:27
21 matches
Mail list logo
