search for: statsq

...to update_balloon_stats to make sure that all stats fields are initialized. Alternative fixes: * Push an empty buffer in init_vqs. Not easily done with the current virtio implementation and violates the spec "Driver MUST supply the same subset of statistics in all buffers submitted to the statsq". * Push a buffer with invalid tags in init_vqs. Violates the same spec clause, plus "invalid tag" is not really defined. Signed-off-by: Ladi Prosek <lprosek at redhat.com> --- v1->v2: * Call update_balloon_stats instead of filling the buffer with invalid tags. * Add...

...to update_balloon_stats to make sure that all stats fields are initialized. Alternative fixes: * Push an empty buffer in init_vqs. Not easily done with the current virtio implementation and violates the spec "Driver MUST supply the same subset of statistics in all buffers submitted to the statsq". * Push a buffer with invalid tags in init_vqs. Violates the same spec clause, plus "invalid tag" is not really defined. Signed-off-by: Ladi Prosek <lprosek at redhat.com> --- v1->v2: * Call update_balloon_stats instead of filling the buffer with invalid tags. * Add...

...t; > > > * Memory statistics structure. > > > Not for this patch, but it looks to me that exporting such nr through uapi is fragile. > > Sorry, can you explain what you mean here? > > > > Jon > > Spec said "Within an output buffer submitted to the statsq, the device MUST > ignore entries with tag values that it does not recognize". So exporting > VIRTIO_BALLOON_S_NR seems useless and device implementation can not depend > on such number in uapi. > > Thanks Suggestions? I don't like to break build for people ... > >...

...lling-interval. And they would be updated on driver (re-)load, so kind of arbitrarily from host pov. On the other hand, this patch does not really comply with (5.5.6.3.1 Driver Requirements: Memory Statistics): "Driver MUST supply the same subset of statistics in all buffers submitted to the statsq." So going by the letter of the law, we should fill in actual values. Going by the (the purpose of the initial buffer is to wait for the host to request stats), we should push an empty buffer or invalid values. >> sg_init_one(&sg, vb->stats, sizeof vb->stats); &...

...lling-interval. And they would be updated on driver (re-)load, so kind of arbitrarily from host pov. On the other hand, this patch does not really comply with (5.5.6.3.1 Driver Requirements: Memory Statistics): "Driver MUST supply the same subset of statistics in all buffers submitted to the statsq." So going by the letter of the law, we should fill in actual values. Going by the (the purpose of the initial buffer is to wait for the host to request stats), we should push an empty buffer or invalid values. >> sg_init_one(&sg, vb->stats, sizeof vb->stats); &...

.... >>>>> Not for this patch, but it looks to me that exporting such nr >>>>> through uapi is fragile. >>>> Sorry, can you explain what you mean here? >>>> >>>> Jon >>> Spec said "Within an output buffer submitted to the statsq, the >>> device MUST >>> ignore entries with tag values that it does not recognize". So exporting >>> VIRTIO_BALLOON_S_NR seems useless and device implementation can not >>> depend >>> on such number in uapi. >>> >>> Thanks >&...

...h, but it looks to me that exporting such nr >>>>>>> through uapi is fragile. >>>>>> Sorry, can you explain what you mean here? >>>>>> >>>>>> Jon >>>>> Spec said "Within an output buffer submitted to the statsq, the >>>>> device MUST >>>>> ignore entries with tag values that it does not recognize". So >>>>> exporting >>>>> VIRTIO_BALLOON_S_NR seems useless and device implementation can not >>>>> depend >>>>>...

> On Mar 19, 2018, at 7:31 PM, Jason Wang <jasowang at redhat.com> wrote: > > > > On 2018?03?20? 06:14, Jonathan Helman wrote: >> Export the number of successful and failed hugetlb page >> allocations via the virtio balloon driver. These 2 counts >> come directly from the vm_events HTLB_BUDDY_PGALLOC and >> HTLB_BUDDY_PGALLOC_FAIL. >> >>

This series fixes issues with variable initialization in the virtio balloon driver which manifest as the driver sending invalid memory stats to the host. v1->v2: * Call update_balloon_stats instead of filling the buffer with invalid tags. * Add BUG_ON to update_balloon_stats to formalize the invariant that all slots in the buffer must be initialized. v2->v3: * Remove BUG_ON and

This series fixes issues with variable initialization in the virtio balloon driver which manifest as the driver sending invalid memory stats to the host. v1->v2: * Call update_balloon_stats instead of filling the buffer with invalid tags. * Add BUG_ON to update_balloon_stats to formalize the invariant that all slots in the buffer must be initialized. v2->v3: * Remove BUG_ON and

...ile. > > > > > > > > Sorry, can you explain what you mean here? > > > > > > > > > > > > > > > > Jon > > > > > > > Spec said "Within an output buffer submitted to the > > > > > > > statsq, the device MUST > > > > > > > ignore entries with tag values that it does not > > > > > > > recognize". So exporting > > > > > > > VIRTIO_BALLOON_S_NR seems useless and device > > > > > > > implementation can...

...> Sorry, can you explain what you mean here? > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > Spec said "Within an output buffer submitted to the > > > > > > > > > statsq, the device MUST > > > > > > > > > ignore entries with tag values that it does not > > > > > > > > > recognize". So exporting > > > > > > > > > VIRTIO_BALLOON_S_NR seems useless and device > > > > >...

...ON_S_NR 10 >>> /* >>> * Memory statistics structure. >> Not for this patch, but it looks to me that exporting such nr through uapi is fragile. > Sorry, can you explain what you mean here? > > Jon Spec said "Within an output buffer submitted to the statsq, the device MUST ignore entries with tag values that it does not recognize". So exporting VIRTIO_BALLOON_S_NR seems useless and device implementation can not depend on such number in uapi. Thanks > >> Thanks > > --------------------------------------------------------------...

...>> * Memory statistics structure. >>>> Not for this patch, but it looks to me that exporting such nr through uapi is fragile. >>> Sorry, can you explain what you mean here? >>> >>> Jon >> Spec said "Within an output buffer submitted to the statsq, the device MUST >> ignore entries with tag values that it does not recognize". So exporting >> VIRTIO_BALLOON_S_NR seems useless and device implementation can not depend >> on such number in uapi. >> >> Thanks > Suggestions? I don't like to break build for...

...meone might come to depend on this. Doesn't look like a big deal to me. > On the other hand, this patch does not really comply with (5.5.6.3.1 > Driver Requirements: Memory Statistics): > > "Driver MUST supply the same subset of statistics in all buffers > submitted to the statsq." > > So going by the letter of the law, we should fill in actual values. > Going by the (the purpose of the initial buffer is to wait for the > host to request stats), we should push an empty buffer or invalid > values. > >> sg_init_one(&sg, vb->s...

...ving update_balloon_stats return the actual number of counters, and its callers use it when pushing buffers to the stats virtqueue. Note that it is still out of spec to change the number of counters at run-time. "Driver MUST supply the same subset of statistics in all buffers submitted to the statsq." Suggested-by: Arnd Bergmann <arnd at arndb.de> Signed-off-by: Ladi Prosek <lprosek at redhat.com> --- drivers/virtio/virtio_balloon.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_b...

...t; Not for this patch, but it looks to me that exporting such nr >>>>>> through uapi is fragile. >>>>> Sorry, can you explain what you mean here? >>>>> >>>>> Jon >>>> Spec said "Within an output buffer submitted to the statsq, the >>>> device MUST >>>> ignore entries with tag values that it does not recognize". So >>>> exporting >>>> VIRTIO_BALLOON_S_NR seems useless and device implementation can not >>>> depend >>>> on such number in uapi....

...e that exporting such nr >>>>>>>> through uapi is fragile. >>>>>>> Sorry, can you explain what you mean here? >>>>>>> >>>>>>> Jon >>>>>> Spec said "Within an output buffer submitted to the statsq, the >>>>>> device MUST >>>>>> ignore entries with tag values that it does not recognize". So >>>>>> exporting >>>>>> VIRTIO_BALLOON_S_NR seems useless and device implementation can >>>>>> not depend &...

...h uapi is fragile. >>>>>>>>> Sorry, can you explain what you mean here? >>>>>>>>> >>>>>>>>> Jon >>>>>>>> Spec said "Within an output buffer submitted to the >>>>>>>> statsq, the device MUST >>>>>>>> ignore entries with tag values that it does not >>>>>>>> recognize". So exporting >>>>>>>> VIRTIO_BALLOON_S_NR seems useless and device >>>>>>>> implementation can not depe...

When init_vqs runs, virtio_balloon.stats is either uninitialized or contains stale values. The host updates its state with garbage data because it has no way of knowing that this is just a marker buffer used for signaling. This patch initializes all tags with U16_MAX which is guaranteed to be ignored by the host. The alternative fix would be to push an empty buffer in init_vqs but that's not