qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 4/6] docs: Add CanoKey documentation


From: Gerd Hoffmann
Subject: Re: [PATCH v5 4/6] docs: Add CanoKey documentation
Date: Thu, 9 Jun 2022 11:56:59 +0200

On Thu, May 19, 2022 at 08:39:38PM +0800, Hongren (Zenithal) Zheng wrote:
> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me>
> ---
>  docs/system/device-emulation.rst |   1 +
>  docs/system/devices/canokey.rst  | 168 +++++++++++++++++++++++++++++++
>  2 files changed, 169 insertions(+)
>  create mode 100644 docs/system/devices/canokey.rst
> 
> Note on the qemu-xhci issue:
> 
> For FIDO2 packets, they follow the pattern below
> 
>   Interrupt IN (size 64)
>   Interrupt OUT (size 128 with payload)
>   Interrupt OUT ACK (size 64)
>   Interrupt IN ACK (size 128 with payload)

> In qemu-xhci, it assumes a pattern like this
> 
>   Interrupt IN (size 64)
>    -> usb_handle_packet
>   Interrupt IN ACK (size 128 with payload (not possible))
>    <- usb_handle_packet returns
>   Interrupt OUT (size 128 with payload)
>    -> the next usb_handle_packet
>   Interrupt OUT ACK (size 64)
>    <- the next usb_handle_packet returns

> The code works for uhci/ehci in the following way
> 
>   Interrupt IN (size 64)
>    -> usb_handle_packet
>   Interrupt IN NAK (size 64)
>    <- usb_handle_packet returns
>   ... there are many IN NAK here
>   ... uhci/ehci reschedule OUT before IN now
>   Interrupt OUT (size 128 with payload)
>    -> the next usb_handle_packet
>   Interrupt OUT ACK (size 64)
>    <- the next usb_handle_packet returns
>   Interrupt IN (size 64)
>    -> last usb_handle_packet
>   Interrupt IN ACK (size 128 with payload)
>    <- last usb_handle_packet returns

I think this is just a missing usb_wakeup() call somewhere.  If a
usb device got data it must notify the host adapter that way.

> I think qemu-xhci should retry/schedule the failed IN token after
> receiving NAK instead of failing immediately, because interrupt
> endpoint is async.

uhci/ehci keeps polling the device.  That is pretty much mandatory for
correct emulation due to the way the host adapter hardware is designed.
So things are typically working even without an explicit usb_wakeup()
call.

xhci doesn't poll (which is good because that reduces virtualization
overhead alot) but requires an explicit usb_wakeup() call to make xhci
re-try NACK-ed transfers.

take care,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]