On 1/5/22 08:25, zhenwei pi wrote: > > On 1/4/22 11:22 PM, Philippe Mathieu-Daudé wrote: >> On 27/12/21 15:27, zhenwei pi wrote: >>> A device of USB video class usually uses larger desc structure, so >>> use larger buffer to avoid failure. >>> >>> Signed-off-by: zhenwei pi <pizhen...@bytedance.com> >>> --- >>> hw/usb/desc.c | 15 ++++++++------- >>> hw/usb/desc.h | 1 + >>> 2 files changed, 9 insertions(+), 7 deletions(-) >>> >>> diff --git a/hw/usb/desc.c b/hw/usb/desc.c >>> index 8b6eaea407..7f6cc2f99b 100644 >>> --- a/hw/usb/desc.c >>> +++ b/hw/usb/desc.c >>> @@ -632,7 +632,8 @@ int usb_desc_get_descriptor(USBDevice *dev, >>> USBPacket *p, >>> bool msos = (dev->flags & (1 << USB_DEV_FLAG_MSOS_DESC_IN_USE)); >>> const USBDesc *desc = usb_device_get_usb_desc(dev); >>> const USBDescDevice *other_dev; >>> - uint8_t buf[256]; >>> + size_t buflen = USB_DESC_MAX_LEN; >>> + g_autofree uint8_t *buf = g_malloc(buflen); >> >> Do we want to have a per-device desc_size (in USBDevice, default to >> 256, video devices set it to 8K)? >> >> How "hot" is this path? Could we keep 8K on the stack? >> > It's an unlikely code path: > 1, During guest startup, guest tries to probe device. > 2, run 'lsusb' command in guest
If you have to respin, do you mind adding this 3 lines in the description? Anyhow: Reviewed-by: Philippe Mathieu-Daudé <f4...@amsat.org>
