On 12/27/2018 08:17 PM, Christian Borntraeger wrote:
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?
That conversion is only needed when we need to send the value to the device.
cmd_id_received doesn't need to be sent to the device.
Best,
Wei
