Hi, that was an error on my part, I was debugging the non-working command ring abort/stop functionality and as the xhci driver implementation I was working on used crcr_low and crcr_high as two separate registers it did not hit me it was actually my way of accessing them that caused the abort/stop to not work.
Thank you very much for the correction and I apologise for disturbing you, hope I didn't eat too much of your time. Have a nice day, Jaroslav Jindrak S pozdravem, Jaroslav Jindrak On 21 August 2017 at 14:23, Gerd Hoffmann <kra...@redhat.com> wrote: > On Tue, 2017-08-01 at 01:48 +0200, Jaroslav Jindrák wrote: > > Hello, > > > > I'd like to submit a patch to the xhci subsystem of QEMU. Currently, > > when the command stop or command abort flags in the crcr_low register > > are set, nothing happens. This is because the part of the code that > > tests those two flags (and performs command ring abort/stop) is in > > the crcr_high case. This error has a simple workaround - after > > writing to the crcr_low register with either of these two flags set, > > one can write the value of crcr_high to crcr_high, so I > > assume this fix does not have that big of a priority, but a driver > > that follows the specification strictly would misbehave in this kind > > of situation (stopping/aborting the command ring). > > Specs says (section 5.1, Register Conventions): > > <quote> > If the xHC supports 64-bit addressing (AC64 = ‘1’), then software > should write registers containing 64-bit address fields using only > Qword accesses. If a system is incapable of issuing Qword accesses, > then writes to the 64-bit address fields shall be performed using 2 > Dword accesses; low Dword-first, high-Dword second. > </quote> > > So I think the guest must write both crcr_low and crcr_high, and the > qemu behavior is correct. > > Are there any guests which actually have problems? > > cheers, > Gerd > >