[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] virtio_stw_phys_cached crash
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] virtio_stw_phys_cached crash |
Date: |
Thu, 23 Aug 2018 16:43:30 +0800 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Wed, 08/22 19:45, Paolo Bonzini wrote:
> On 22/08/2018 16:57, Fam Zheng wrote:
> > On master (13b7b188501) and v3.0.0, booting the OpenBSD install63.iso with a
> > virtio-net (slirp backend) device gives this assertion failure:
> >
> > (gdb) bt
> > #0 0x00007f6f25703feb in raise () at /lib64/libc.so.6
> > #1 0x00007f6f256ee5c1 in abort () at /lib64/libc.so.6
> > #2 0x00007f6f256ee491 in _nl_load_domain.cold.0 () at /lib64/libc.so.6
> > #3 0x00007f6f256fc752 in () at /lib64/libc.so.6
> > #4 0x000055d966f5b5d6 in address_space_stw_le_cached
> > (cache=0x7f6f040fd700, addr=516, val=1, attrs=..., result=0x0)
> > at /stor/work/qemu/include/exec/memory_ldst_cached.inc.h:85
>
> Does this help?
Nope. The crash happens the same (once you press "Auto Install" at the first
prompt).
Fam
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index d4e4d98b59..5982678c75 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -2006,14 +2006,25 @@ static int virtio_set_features_nocheck(VirtIODevice
> *vdev, uint64_t val)
>
> int virtio_set_features(VirtIODevice *vdev, uint64_t val)
> {
> - /*
> + int ret;
> + /*
> * The driver must not attempt to set features after feature negotiation
> * has finished.
> */
> if (vdev->status & VIRTIO_CONFIG_S_FEATURES_OK) {
> return -EINVAL;
> }
> - return virtio_set_features_nocheck(vdev, val);
> + ret = virtio_set_features_nocheck(vdev, val);
> + if (!ret && (val & VIRTIO_RING_F_EVENT_IDX)) {
> + /* VIRTIO_RING_F_EVENT_IDX changes the size of the caches. */
> + int i;
> + for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
> + if (vdev->vq[i].vring.num != 0) {
> + virtio_init_region_cache(vdev, i);
> + }
> + }
> + }
> + return ret;
> }
>
> int virtio_load(VirtIODevice *vdev, QEMUFile *f, int version_id)
>
> (I haven't tried to reproduce, or checked the spec to see if this could
> be a guest bug too. Of course assertion failures are wrong anyway, so
> we might as well work around it as above).
>
> Paolo