On 27.12.2018 12:59, Christian Borntraeger wrote: > On 27.12.2018 12:31, Christian Borntraeger wrote: >> This patch triggers random crashes in the guest kernel on s390 early during boot. >> No migration and no setting of the balloon is involved. >> > > Adding Conny and Halil, > > As the QEMU provides no PAGE_HINT feature yet, this quick hack makes the > guest boot fine again: > > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c > index 728ecd1eea305..aa2e1864c5736 100644 > --- a/drivers/virtio/virtio_balloon.c > +++ b/drivers/virtio/virtio_balloon.c > @@ -492,7 +492,7 @@ static int init_vqs(struct virtio_balloon *vb) > callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL; > } > > - err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX, > + err = vb->vdev->config->find_vqs(vb->vdev, 3, //VIRTIO_BALLOON_VQ_MAX, > vqs, callbacks, names, NULL, NULL); > if (err) > return err; > > > To me it looks like that virtio_ccw_find_vqs will abort if any of the virtqueues > that it is been asked for does not exist (including the earlier ones). > This "hack" makes the random crashes go away, but the balloon interface itself does not work. (setting the value to anything will hang the guest). As patch 1 also modifies the main path, there seem to be additional issues, maybe endianess Looking at things like + vb->cmd_id_received = VIRTIO_BALLOON_CMD_ID_STOP; + vb->cmd_id_active = cpu_to_virtio32(vb->vdev, + VIRTIO_BALLOON_CMD_ID_STOP); + vb->cmd_id_stop = cpu_to_virtio32(vb->vdev, + VIRTIO_BALLOON_CMD_ID_STOP); Why is cmd_id_received not using cpu_to_virtio32?
