search for: cmd_id_received_cache

...eceived(struct virtio_balloon *vb) { if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, - &vb->config_read_bitmap)) + &vb->config_read_bitmap)) { virtio_cread(vb->vdev, struct virtio_balloon_config, free_page_hint_cmd_id, &vb->cmd_id_received_cache); + /* Legacy balloon config space is LE, unlike all other devices. */ + if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1)) + vb->cmd_id_received_cache = le32_to_cpu((__force __le32)vb->cmd_id_received_cache); + } return vb->cmd_id_received_cache; } -- MST

...573,10 @@ static u32 virtio_balloon_cmd_id_received(struct virtio_balloon *vb) { if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, &vb->config_read_bitmap)) { - virtio_cread(vb->vdev, struct virtio_balloon_config, - free_page_hint_cmd_id, - &vb->cmd_id_received_cache); /* Legacy balloon config space is LE, unlike all other devices. */ - if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1)) - vb->cmd_id_received_cache = le32_to_cpu((__force __le32)vb->cmd_id_received_cache); + virtio_cread_le(vb->vdev, struct virtio_balloon_config, + free_...

Since virtio-ccw doesn't work with accessing to the config space inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. v2->v3 ChangeLog: - rename cmd_id_received to cmd_id_received_cache, and have call sites read the latest value via virtio_balloon_cmd_id_received. (Still kept Cornelia and Halil's reviewed-by as it's a minor change) - remove zeroing vb->num_free_page_blocks in probe since vb is allocated via kzalloc. v1->v2 ChangeLog: - add c...

...alloon_cmd_id_received(struct virtio_balloon *vb) if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, &vb->config_read_bitmap)) virtio_cread(vb->vdev, struct virtio_balloon_config, - free_page_report_cmd_id, + free_page_hint_cmd_id, &vb->cmd_id_received_cache); return vb->cmd_id_received_cache; diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h index 19974392d324..dc3e656470dd 100644 --- a/include/uapi/linux/virtio_balloon.h +++ b/include/uapi/linux/virtio_balloon.h @@ -48,8 +48,15 @@ struct virtio_balloon_conf...

...alloon_cmd_id_received(struct virtio_balloon *vb) if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, &vb->config_read_bitmap)) virtio_cread(vb->vdev, struct virtio_balloon_config, - free_page_report_cmd_id, + free_page_hint_cmd_id, &vb->cmd_id_received_cache); return vb->cmd_id_received_cache; diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h index 19974392d324..dc3e656470dd 100644 --- a/include/uapi/linux/virtio_balloon.h +++ b/include/uapi/linux/virtio_balloon.h @@ -48,8 +48,15 @@ struct virtio_balloon_conf...

...alloon_cmd_id_received(struct virtio_balloon *vb) if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, &vb->config_read_bitmap)) virtio_cread(vb->vdev, struct virtio_balloon_config, - free_page_report_cmd_id, + free_page_hint_cmd_id, &vb->cmd_id_received_cache); return vb->cmd_id_received_cache; diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h index 19974392d324..3ce64f72bd09 100644 --- a/include/uapi/linux/virtio_balloon.h +++ b/include/uapi/linux/virtio_balloon.h @@ -34,7 +34,7 @@ #define VIRTIO_BALLOON_F_M...

...IO_BALLOON_CONFIG_READ_CMD_ID, > > &vb->config_read_bitmap)) > > virtio_cread(vb->vdev, struct virtio_balloon_config, > > free_page_hint_cmd_id, > > &vb->cmd_id_received_cache); > > > > return vb->cmd_id_received_cache; > > } > > > > > > So guest assumes native, host assumes LE. > > This wasn't even the one I was talking about, but now that you point > it out this is definately bug. The command ID I was talking...

...IO_BALLOON_CONFIG_READ_CMD_ID, > > &vb->config_read_bitmap)) > > virtio_cread(vb->vdev, struct virtio_balloon_config, > > free_page_hint_cmd_id, > > &vb->cmd_id_received_cache); > > > > return vb->cmd_id_received_cache; > > } > > > > > > So guest assumes native, host assumes LE. > > This wasn't even the one I was talking about, but now that you point > it out this is definately bug. The command ID I was talking...

...b) { if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, &vb->config_read_bitmap)) virtio_cread(vb->vdev, struct virtio_balloon_config, free_page_hint_cmd_id, &vb->cmd_id_received_cache); return vb->cmd_id_received_cache; } So guest assumes native, host assumes LE. > > --- > > drivers/virtio/virtio_balloon.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virti...

...b) { if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, &vb->config_read_bitmap)) virtio_cread(vb->vdev, struct virtio_balloon_config, free_page_hint_cmd_id, &vb->cmd_id_received_cache); return vb->cmd_id_received_cache; } So guest assumes native, host assumes LE. > > --- > > drivers/virtio/virtio_balloon.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virti...

...virtio_balloon *vb) > if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, > &vb->config_read_bitmap)) > virtio_cread(vb->vdev, struct virtio_balloon_config, > - free_page_report_cmd_id, > + free_page_hint_cmd_id, > &vb->cmd_id_received_cache); > > return vb->cmd_id_received_cache; > diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h > index 19974392d324..dc3e656470dd 100644 > --- a/include/uapi/linux/virtio_balloon.h > +++ b/include/uapi/linux/virtio_balloon.h > @@ -48,8 +...

...AD_CMD_ID, > > > &vb->config_read_bitmap)) > > > virtio_cread(vb->vdev, struct virtio_balloon_config, > > > free_page_hint_cmd_id, > > > &vb->cmd_id_received_cache); > > > > > > return vb->cmd_id_received_cache; > > > } > > > > > > > > > So guest assumes native, host assumes LE. > > > > This wasn't even the one I was talking about, but now that you point > > it out this is...

...id_received(vb); This will not achieve what you are trying to do, which is cancel reporting if it's in progress. You need to re-read each time you compare to cmd_id_active. An API similar to u32 virtio_balloon_cmd_id_received(vb) seems to be called for, and I would rename cmd_id_received to cmd_id_received_cache to make sure we caught all users. > + if (vb->cmd_id_received == VIRTIO_BALLOON_CMD_ID_DONE) { > + /* Pass ULONG_MAX to give back all the free pages */ > + return_free_pages_to_mm(vb, ULONG_MAX); > + } else if (vb->cmd_id_received != VIRTIO_BALLOON_CMD_ID_STOP && >...

...id_received(vb); This will not achieve what you are trying to do, which is cancel reporting if it's in progress. You need to re-read each time you compare to cmd_id_active. An API similar to u32 virtio_balloon_cmd_id_received(vb) seems to be called for, and I would rename cmd_id_received to cmd_id_received_cache to make sure we caught all users. > + if (vb->cmd_id_received == VIRTIO_BALLOON_CMD_ID_DONE) { > + /* Pass ULONG_MAX to give back all the free pages */ > + return_free_pages_to_mm(vb, ULONG_MAX); > + } else if (vb->cmd_id_received != VIRTIO_BALLOON_CMD_ID_STOP && >...

...t_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID, > &vb->config_read_bitmap)) > virtio_cread(vb->vdev, struct virtio_balloon_config, > free_page_hint_cmd_id, > &vb->cmd_id_received_cache); > > return vb->cmd_id_received_cache; > } > > > So guest assumes native, host assumes LE. This wasn't even the one I was talking about, but now that you point it out this is definately bug. The command ID I was talking about was the one being passed via the descr...

Page reporting features were never supported by legacy hypervisors. Supporting them poses a problem: should we use native endian-ness (like current code assumes)? Or little endian-ness like the virtio spec says? Rather than try to figure out, and since results of incorrect endian-ness are dire, let's just block this configuration. Cc: stable at vger.kernel.org Signed-off-by: Michael S.

Page reporting features were never supported by legacy hypervisors. Supporting them poses a problem: should we use native endian-ness (like current code assumes)? Or little endian-ness like the virtio spec says? Rather than try to figure out, and since results of incorrect endian-ness are dire, let's just block this configuration. Cc: stable at vger.kernel.org Signed-off-by: Michael S.

...cancel reporting if it's > in progress. > > You need to re-read each time you compare to cmd_id_active. Yes, already did, please see [1] above > An API similar to > u32 virtio_balloon_cmd_id_received(vb) > seems to be called for, and I would rename cmd_id_received to > cmd_id_received_cache to make sure we caught all users. > I'm not sure about adding "cache" here, cmd_id_received refers to the cmd id that the driver just received from the device. There is one called "cmd_id_active" which is the one that the driver is actively using. So cmd_id_received is...

...to out_iput; } vb->balloon_wq = alloc_workqueue("balloon-wq", WQ_FREEZABLE | WQ_CPU_INTENSIVE, 0); if (!vb->balloon_wq) { err = -ENOMEM; - goto out_del_vqs; + goto out_iput; } INIT_WORK(&vb->report_free_page_work, report_free_page_func); vb->cmd_id_received_cache = VIRTIO_BALLOON_CMD_ID_STOP; @@ -953,6 +952,12 @@ static int virtballoon_probe(struct virtio_device *vdev) out_del_balloon_wq: if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) destroy_workqueue(vb->balloon_wq); +out_iput: +#ifdef CONFIG_BALLOON_COMPACTION + iput(vb->vb_de...

Since virtio-ccw doesn't work with accessing to the config space inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. v1->v2 ChangeLog: - add config_read_bitmap to indicate to the workqueue callbacks about the necessity of reading the related config fields. Wei Wang (2): virtio-balloon: tweak