All of lore.kernel.org
 help / color / mirror / Atom feed
* USB pass through into Mac OS 9.x with qemu-system-ppc
@ 2021-02-08 13:29 Howard Spoelstra
  2021-02-09 15:12 ` Gerd Hoffmann
  0 siblings, 1 reply; 10+ messages in thread
From: Howard Spoelstra @ 2021-02-08 13:29 UTC (permalink / raw)
  To: qemu-devel qemu-devel, Gerd Hoffmann


[-- Attachment #1.1.1: Type: text/plain, Size: 1525 bytes --]

Hi all,

I'd like to report an issue when passing through an USB device into Mac OS
9.2.
Passing through the same device into Fedora 12 ppc guest works fine. Host
is Fedora 33. Both guests use the OHCI controller. AFAICT Mac OS 9 only has
support for OHCI.

Pcap files for two runs are attached, as is a screenshot of Mac OS 9.2 USB
messages from inside the guest.

A noticeable issue when comparing the pcap files seems to be at Fedora pcap
frame 8 and Mac OS 9.2 pcap frame 28 (configuration descriptor). It seems
the Mac OS side is missing 5 bytes and hence the packet is malformed.
(A run with Mac OS 9.0 as guest showed that this guest only missed 1 byte
in the response.)

Also visible in the Mac OS pcap file at frame 53 is that it seems a setup
package is contained in an URB that is not suited for it.

Qemu-system-ppc is started like this for the Mac OS guest:
./qemu-system-ppc \
-M mac99,via=pmu \
-m 512 \
-boot c \
-serial stdio \
-L pc-bios \
-drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \
-device usb-host,vendorid=0x058f,productid=0x6387,pcap=macos92.pcap

Or like this for the Fedora 12 guest:
./qemu-system-ppc \
-L pc-bios \
-boot c \
-prom-env "boot-device=hd:,\yaboot" -prom-env
"boot-args=conf=hd:,\yaboot.conf" \
-M mac99,via=pmu \
-m 1024 \
-drive file=/home/hsp/Linux-disks/fedora12.qcow2 \
-g 1024x768x32 \
-device usb-host,vendorid=0x058f,productid=0x6387,pcap=fedora12.pcap

Thanks for looking into this,

Best,
Howard Spoelstra

[image: Screenshot from 2021-02-08 08-06-56.png]

[-- Attachment #1.1.2: Type: text/html, Size: 1988 bytes --]

[-- Attachment #1.2: Screenshot from 2021-02-08 08-06-56.png --]
[-- Type: image/png, Size: 99576 bytes --]

[-- Attachment #2: macos92.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 7332 bytes --]

[-- Attachment #3: fedora12.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 406574 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-08 13:29 USB pass through into Mac OS 9.x with qemu-system-ppc Howard Spoelstra
@ 2021-02-09 15:12 ` Gerd Hoffmann
  2021-02-09 17:17   ` Howard Spoelstra
  0 siblings, 1 reply; 10+ messages in thread
From: Gerd Hoffmann @ 2021-02-09 15:12 UTC (permalink / raw)
  To: Howard Spoelstra; +Cc: qemu-devel qemu-devel

  Hi,

> A noticeable issue when comparing the pcap files seems to be at Fedora pcap
> frame 8 and Mac OS 9.2 pcap frame 28 (configuration descriptor). It seems
> the Mac OS side is missing 5 bytes and hence the packet is malformed.
> (A run with Mac OS 9.0 as guest showed that this guest only missed 1 byte
> in the response.)

That is normal.  Note that the configuration descriptor is requested
twice:  Once with a buffer large enough to see the wTotalLength field.
and then again with a buffer large enough for the whole descriptor.

> Also visible in the Mac OS pcap file at frame 53 is that it seems a setup
> package is contained in an URB that is not suited for it.

Looks more like a bug in the qemu pcap code, probably have to set some
flag to indicate the setup section doesn't contain valid data instead
of just leaving it all blank.

Frame 55 is probably the problematic one.  Look at the timestamps.  The
device seems to not answer, then after a while macos seems to try reset
the device.

Also the fedora trace has the bulk transfer data so wireshark can decode
usb-storage commands and the scsi command wrapped inside.  That is not
the case in the macos trace.  Not sure whenever that is another bug in
the pcap code.  It could also indicate the bug in the ohci emulation
which in turn causes macos fail ...

> Qemu-system-ppc is started like this for the Mac OS guest:
> ./qemu-system-ppc \
> -M mac99,via=pmu \
> -m 512 \
> -boot c \
> -serial stdio \
> -L pc-bios \
> -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \
> -device usb-host,vendorid=0x058f,productid=0x6387,pcap=macos92.pcap

Does an emulated usb stick work with macos?

take care,
  Gerd



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-09 15:12 ` Gerd Hoffmann
@ 2021-02-09 17:17   ` Howard Spoelstra
  2021-02-12  8:53     ` Howard Spoelstra
  0 siblings, 1 reply; 10+ messages in thread
From: Howard Spoelstra @ 2021-02-09 17:17 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: qemu-devel qemu-devel

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

On Tue, Feb 9, 2021 at 4:12 PM Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
>
> > A noticeable issue when comparing the pcap files seems to be at Fedora
> pcap
> > frame 8 and Mac OS 9.2 pcap frame 28 (configuration descriptor). It seems
> > the Mac OS side is missing 5 bytes and hence the packet is malformed.
> > (A run with Mac OS 9.0 as guest showed that this guest only missed 1 byte
> > in the response.)
>
> That is normal.  Note that the configuration descriptor is requested
> twice:  Once with a buffer large enough to see the wTotalLength field.
> and then again with a buffer large enough for the whole descriptor.
>
> > Also visible in the Mac OS pcap file at frame 53 is that it seems a setup
> > package is contained in an URB that is not suited for it.
>
> Looks more like a bug in the qemu pcap code, probably have to set some
> flag to indicate the setup section doesn't contain valid data instead
> of just leaving it all blank.
>
> Frame 55 is probably the problematic one.  Look at the timestamps.  The
> device seems to not answer, then after a while macos seems to try reset
> the device.
>
> Also the fedora trace has the bulk transfer data so wireshark can decode
> usb-storage commands and the scsi command wrapped inside.  That is not
> the case in the macos trace.  Not sure whenever that is another bug in
> the pcap code.  It could also indicate the bug in the ohci emulation
> which in turn causes macos fail ...
>
> > Qemu-system-ppc is started like this for the Mac OS guest:
> > ./qemu-system-ppc \
> > -M mac99,via=pmu \
> > -m 512 \
> > -boot c \
> > -serial stdio \
> > -L pc-bios \
> > -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \
> > -device usb-host,vendorid=0x058f,productid=0x6387,pcap=macos92.pcap
>
> Does an emulated usb stick work with macos?
>
> Hi Gerd,

Thanks for getting back to me.
Yes, usb-storage works just fine with

-drive if=none,id=stick,file=/home/hsp/Mac-disks/9.0.img,format=raw \
-device usb-storage,drive=stick

Best,
Howard

[-- Attachment #2: Type: text/html, Size: 2613 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-09 17:17   ` Howard Spoelstra
@ 2021-02-12  8:53     ` Howard Spoelstra
  2021-02-16 14:48       ` Gerd Hoffmann
  0 siblings, 1 reply; 10+ messages in thread
From: Howard Spoelstra @ 2021-02-12  8:53 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: qemu-devel qemu-devel

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

On Tue, Feb 9, 2021 at 6:17 PM Howard Spoelstra <hsp.cat7@gmail.com> wrote:
>
>
>
> On Tue, Feb 9, 2021 at 4:12 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>>   Hi,
>>
>> > A noticeable issue when comparing the pcap files seems to be at Fedora pcap
>> > frame 8 and Mac OS 9.2 pcap frame 28 (configuration descriptor). It seems
>> > the Mac OS side is missing 5 bytes and hence the packet is malformed.
>> > (A run with Mac OS 9.0 as guest showed that this guest only missed 1 byte
>> > in the response.)
>>
>> That is normal.  Note that the configuration descriptor is requested
>> twice:  Once with a buffer large enough to see the wTotalLength field.
>> and then again with a buffer large enough for the whole descriptor.
>>
>> > Also visible in the Mac OS pcap file at frame 53 is that it seems a setup
>> > package is contained in an URB that is not suited for it.
>>
>> Looks more like a bug in the qemu pcap code, probably have to set some
>> flag to indicate the setup section doesn't contain valid data instead
>> of just leaving it all blank.
>>
>> Frame 55 is probably the problematic one.  Look at the timestamps.  The
>> device seems to not answer, then after a while macos seems to try reset
>> the device.
>>
>> Also the fedora trace has the bulk transfer data so wireshark can decode
>> usb-storage commands and the scsi command wrapped inside.  That is not
>> the case in the macos trace.  Not sure whenever that is another bug in
>> the pcap code.  It could also indicate the bug in the ohci emulation
>> which in turn causes macos fail ...
>>
>> > Qemu-system-ppc is started like this for the Mac OS guest:
>> > ./qemu-system-ppc \
>> > -M mac99,via=pmu \
>> > -m 512 \
>> > -boot c \
>> > -serial stdio \
>> > -L pc-bios \
>> > -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \
>> > -device usb-host,vendorid=0x058f,productid=0x6387,pcap=macos92.pcap
>>
>> Does an emulated usb stick work with macos?
>>
> Hi Gerd,
>
> Thanks for getting back to me.
> Yes, usb-storage works just fine with
>
> -drive if=none,id=stick,file=/home/hsp/Mac-disks/9.0.img,format=raw \
> -device usb-storage,drive=stick
>
> Best,
> Howard

Hi Gerd,

Please find another pcap file attached. This one stems from an attempt
to pass through a midi device when running qemu-system-ppc with Mac OS
9.2 in macOS host.
In case you'd like to run a MacOS 9.2 guest yourself, I've prepared a
zipped disk image to do just that:
https://surfdrive.surf.nl/files/index.php/s/jalNAWL3Fkehts4/download

Best,
Howard

[-- Attachment #2: usblog.pcap --]
[-- Type: application/octet-stream, Size: 3298 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-12  8:53     ` Howard Spoelstra
@ 2021-02-16 14:48       ` Gerd Hoffmann
  2021-02-16 15:42         ` Howard Spoelstra
  0 siblings, 1 reply; 10+ messages in thread
From: Gerd Hoffmann @ 2021-02-16 14:48 UTC (permalink / raw)
  To: Howard Spoelstra; +Cc: qemu-devel qemu-devel

  Hi,

> Please find another pcap file attached. This one stems from an attempt
> to pass through a midi device when running qemu-system-ppc with Mac OS
> 9.2 in macOS host.

Ah, yes, I remember now.  Problem is that the usb stick is plugged into
a high-speed port (usb2) on the host but passed as full-speed device
(usb1) to the guest.  That works in some cases, but is not guaranteed
to work.  usb_host_speed_compat() tries to catch some of the
incompatible cases.  The usb-storage incompatibility slips through
because the incompatibility is specific to the mass storage protocol.
Specifically the wMaxPacketSize is 64 for usb1 and 512 for usb2.

Seems fedora deals better with the situation ...

take care,
  Gerd



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-16 14:48       ` Gerd Hoffmann
@ 2021-02-16 15:42         ` Howard Spoelstra
  2021-02-17  7:17           ` Howard Spoelstra
  2021-02-17  7:27           ` Gerd Hoffmann
  0 siblings, 2 replies; 10+ messages in thread
From: Howard Spoelstra @ 2021-02-16 15:42 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: qemu-devel qemu-devel

On Tue, Feb 16, 2021 at 3:48 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > Please find another pcap file attached. This one stems from an attempt
> > to pass through a midi device when running qemu-system-ppc with Mac OS
> > 9.2 in macOS host.
>
> Ah, yes, I remember now.  Problem is that the usb stick is plugged into
> a high-speed port (usb2) on the host but passed as full-speed device
> (usb1) to the guest.  That works in some cases, but is not guaranteed
> to work.  usb_host_speed_compat() tries to catch some of the
> incompatible cases.  The usb-storage incompatibility slips through
> because the incompatibility is specific to the mass storage protocol.
> Specifically the wMaxPacketSize is 64 for usb1 and 512 for usb2.
>
> Seems fedora deals better with the situation ...
>
> take care,
>   Gerd
>

Hi Gerd,

Thanks for looking into this. It looks to me that the usb storage
device nicely reports endpoints 1 and 2 when asked, but that the host
only ever communicates with endpoint 1.
Is that the issue you refer to, or might that be libusb related?

Can this also explain that other (non-mass-storage) devices cannot be
passed through successfully ?

Best,
Howard


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-16 15:42         ` Howard Spoelstra
@ 2021-02-17  7:17           ` Howard Spoelstra
  2021-02-17  7:45             ` Gerd Hoffmann
  2021-02-17  7:27           ` Gerd Hoffmann
  1 sibling, 1 reply; 10+ messages in thread
From: Howard Spoelstra @ 2021-02-17  7:17 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: qemu-devel qemu-devel

On Tue, Feb 16, 2021 at 4:42 PM Howard Spoelstra <hsp.cat7@gmail.com> wrote:
>
> On Tue, Feb 16, 2021 at 3:48 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> >   Hi,
> >
> > > Please find another pcap file attached. This one stems from an attempt
> > > to pass through a midi device when running qemu-system-ppc with Mac OS
> > > 9.2 in macOS host.
> >
> > Ah, yes, I remember now.  Problem is that the usb stick is plugged into
> > a high-speed port (usb2) on the host but passed as full-speed device
> > (usb1) to the guest.  That works in some cases, but is not guaranteed
> > to work.  usb_host_speed_compat() tries to catch some of the
> > incompatible cases.  The usb-storage incompatibility slips through
> > because the incompatibility is specific to the mass storage protocol.
> > Specifically the wMaxPacketSize is 64 for usb1 and 512 for usb2.
> >
> > Seems fedora deals better with the situation ...
> >
> > take care,
> >   Gerd
> >
>
> Hi Gerd,
>
> Thanks for looking into this. It looks to me that the usb storage
> device nicely reports endpoints 1 and 2 when asked, but that the host
> only ever communicates with endpoint 1.
> Is that the issue you refer to, or might that be libusb related?
>
> Can this also explain that other (non-mass-storage) devices cannot be
> passed through successfully ?
>
> Best,
> Howard

Hi Gerd,

Thanks for the explanation. I've been successful in passing through an
USB 2.0 stick into Mac OS 9.x when connected to a real USB 1.1 hub in
a old Apple keyboard. This at least gives some perspective to connect
other devices as well.

So we can consider this quest finished ;-)

Best,
Howard


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-16 15:42         ` Howard Spoelstra
  2021-02-17  7:17           ` Howard Spoelstra
@ 2021-02-17  7:27           ` Gerd Hoffmann
  1 sibling, 0 replies; 10+ messages in thread
From: Gerd Hoffmann @ 2021-02-17  7:27 UTC (permalink / raw)
  To: Howard Spoelstra; +Cc: qemu-devel qemu-devel

> Hi Gerd,
> 
> Thanks for looking into this. It looks to me that the usb storage
> device nicely reports endpoints 1 and 2 when asked, but that the host
> only ever communicates with endpoint 1.

EP 1 is host -> device.
EP 2 is device -> host.

So the host sends requests but the device never answers, probably due to
the wMaxPacketSize mismatch, macos being confused and sending broken
requests ...

> Can this also explain that other (non-mass-storage) devices cannot be
> passed through successfully ?

Yes, you can have simliar issues with other devices.  Devices can have
different interface descriptors for different device speeds.  This can
be rather small differences like the wMacPacketSize for usb sticks.  The
descriptors can be identical.  Or there can be large differences, like
usb-audio devices offering more channels when plugged into a usb2 port
(with enough bandwidth for that).

Problem is when the device is plugged into a usb2 port you can't query
the usb1 descriptors.  So qemu presents the wrong descriptors to the
guest in case host and guest use different usb speeds.  That may or may
not work ...

The other way around is less problematic, when plugging a usb2 device
into a usb3-capable (xhci) port I can tell the guest "this is a usb2
device".  But reporting "this is a usb2 device" via ohci isn't going to
fly for obvious reasons ...

take care,
  Gerd



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
  2021-02-17  7:17           ` Howard Spoelstra
@ 2021-02-17  7:45             ` Gerd Hoffmann
  0 siblings, 0 replies; 10+ messages in thread
From: Gerd Hoffmann @ 2021-02-17  7:45 UTC (permalink / raw)
  To: Howard Spoelstra; +Cc: qemu-devel qemu-devel

  Hi,

> Thanks for the explanation. I've been successful in passing through an
> USB 2.0 stick into Mac OS 9.x when connected to a real USB 1.1 hub in
> a old Apple keyboard.

Ah, neat trick to force the device into usb1 mode.

take care,
  Gerd



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: USB pass through into Mac OS 9.x with qemu-system-ppc
       [not found] <mailman.2361.1612790999.21101.qemu-devel@nongnu.org>
@ 2021-02-11 20:46 ` Programmingkid
  0 siblings, 0 replies; 10+ messages in thread
From: Programmingkid @ 2021-02-11 20:46 UTC (permalink / raw)
  To: qemu Developers, Howard Spoelstra; +Cc: Gerd Hoffmann



> On Feb 8, 2021, at 8:29 AM, qemu-devel-request@nongnu.org wrote:
> 
> Message: 15
> Date: Mon, 8 Feb 2021 14:29:06 +0100
> From: Howard Spoelstra <hsp.cat7@gmail.com>
> To: qemu-devel qemu-devel <qemu-devel@nongnu.org>, Gerd Hoffmann
> 	<kraxel@redhat.com>
> Subject: USB pass through into Mac OS 9.x with qemu-system-ppc
> Message-ID:
> 	<CABLmASF7YP3qfcuhAQsm8J28e8omZstBf7E5Eir=8MyqnvPLRQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> I'd like to report an issue when passing through an USB device into Mac OS
> 9.2.
> Passing through the same device into Fedora 12 ppc guest works fine. Host
> is Fedora 33. Both guests use the OHCI controller. AFAICT Mac OS 9 only has
> support for OHCI.
> 
> Pcap files for two runs are attached, as is a screenshot of Mac OS 9.2 USB
> messages from inside the guest.
> 
> A noticeable issue when comparing the pcap files seems to be at Fedora pcap
> frame 8 and Mac OS 9.2 pcap frame 28 (configuration descriptor). It seems
> the Mac OS side is missing 5 bytes and hence the packet is malformed.
> (A run with Mac OS 9.0 as guest showed that this guest only missed 1 byte
> in the response.)
> 
> Also visible in the Mac OS pcap file at frame 53 is that it seems a setup
> package is contained in an URB that is not suited for it.
> 
> Qemu-system-ppc is started like this for the Mac OS guest:
> ./qemu-system-ppc \
> -M mac99,via=pmu \
> -m 512 \
> -boot c \
> -serial stdio \
> -L pc-bios \
> -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \
> -device usb-host,vendorid=0x058f,productid=0x6387,pcap=macos92.pcap
> 
> Or like this for the Fedora 12 guest:
> ./qemu-system-ppc \
> -L pc-bios \
> -boot c \
> -prom-env "boot-device=hd:,\yaboot" -prom-env
> "boot-args=conf=hd:,\yaboot.conf" \
> -M mac99,via=pmu \
> -m 1024 \
> -drive file=/home/hsp/Linux-disks/fedora12.qcow2 \
> -g 1024x768x32 \
> -device usb-host,vendorid=0x058f,productid=0x6387,pcap=fedora12.pcap
> 
> Thanks for looking into this,
> 
> Best,
> Howard Spoelstra

Hi Howard. I suggest you make a bug report so we may track this issue.

This is where you would file the bug: https://bugs.launchpad.net/qemu/

I didn't know about the pcap option. It looks very useful.

Thank you.



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-02-17  7:47 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-08 13:29 USB pass through into Mac OS 9.x with qemu-system-ppc Howard Spoelstra
2021-02-09 15:12 ` Gerd Hoffmann
2021-02-09 17:17   ` Howard Spoelstra
2021-02-12  8:53     ` Howard Spoelstra
2021-02-16 14:48       ` Gerd Hoffmann
2021-02-16 15:42         ` Howard Spoelstra
2021-02-17  7:17           ` Howard Spoelstra
2021-02-17  7:45             ` Gerd Hoffmann
2021-02-17  7:27           ` Gerd Hoffmann
     [not found] <mailman.2361.1612790999.21101.qemu-devel@nongnu.org>
2021-02-11 20:46 ` Programmingkid

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.