On 1/11/22 13:27, zhenwei pi wrote: > On 1/11/22 8:25 PM, Daniel P. Berrangé wrote: >> On Tue, Jan 11, 2022 at 12:21:42PM +0000, Peter Maydell wrote: >>> On Tue, 11 Jan 2022 at 10:54, zhenwei pi <pizhen...@bytedance.com> >>> wrote: >>>> >>>> A device of USB video class usually uses larger desc structure, so >>>> use larger buffer to avoid failure. (dev-video.c is ready) >>>> >>>> Allocating memory dynamically by g_malloc of the orignal version of >>>> this change, Philippe suggested just using the stack. Test the two >>>> versions of qemu binary, the size of stack gets no change. >>>> >>>> CC: Philippe Mathieu-Daudé <f4...@amsat.org> >>>> Signed-off-by: zhenwei pi <pizhen...@bytedance.com> >>>> --- >>>> hw/usb/desc.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/hw/usb/desc.c b/hw/usb/desc.c >>>> index 8b6eaea407..57d2aedba1 100644 >>>> --- a/hw/usb/desc.c >>>> +++ b/hw/usb/desc.c >>>> @@ -632,7 +632,7 @@ 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]; >>>> + uint8_t buf[8192]; >>>> uint8_t type = value >> 8; >>>> uint8_t index = value & 0xff; >>>> int flags, ret = -1; >>> >>> I think 8K is too large to be allocating as an array on >>> the stack, so if we need this buffer to be larger we should >>> switch to some other allocation strategy for it. >> >> IIUC, querying USB device descriptors is not a hot path, so using >> heap allocation feels sufficient. >> > Yes, I tested this a lot, and found that it's an unlikely code path: > 1, during guest startup, guest tries to probe device. > 2, run 'lsusb' command in guest(or other similar commands).
Sorry, I thought this was a hot path without looking at the code. > The original patch and context link: > https://patchwork.kernel.org/project/qemu-devel/patch/20211227142734.691900-5-pizhen...@bytedance.com/ > >> >> Regards, >> Daniel >> >