qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode


From: Mark Cave-Ayland
Subject: Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode
Date: Fri, 6 Mar 2020 07:25:59 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 06/03/2020 00:21, BALATON Zoltan wrote:

> On Fri, 6 Mar 2020, BALATON Zoltan wrote:
>> On Thu, 5 Mar 2020, Mark Cave-Ayland wrote:
>>> On 04/03/2020 22:33, BALATON Zoltan wrote:
>>> another possibility: PCI configuration space register 0x3d (Interrupt pin) 
>>> is
>>> documented as having value 0 == Legacy IRQ routing which should be the 
>>> initial value
>>> on reset, but QEMU incorrectly sets it to 1 which indicates PCI IRQ routing.
>>
>> The VT8231 docs say this should always read 1 but may be this is somehow set 
>> to 0
>> on the Pegasos2. What does that mean? Should we use this value instead of the
>> feature bit to force using legacy interrupts? We'd still need a property in 
>> via-ide
>> to set this reg or is it possible to set it from board code overriding the 
>> default
>> after device is created? That would allow to drop patch 1. I can try this.
> 
> This seemed like it could simplify patches a bit but it does not work. 
> Setting this
> reg to 0 breaks Linux and MorphOS which then think the device does not have an
> interrupt at all and fail as before waiting for the irq. So we still need the 
> feature
> bit, cant use this reg to force legacy interrupts. I've spent considerable 
> time
> testing different OSes before I've ended up with this patch series I've 
> submitted and
> I could not find a simpler way that works with everything.

I appreciate that testing these things can take a lot of time, but what is 
important
thing to ask here is whether these hacks are attempting to work around 
something in
QEMU that doesn't match the hardware specification, and to me it feels that 
this is
what is happening here.

Obviously this thread has become quite long (and even I'm struggling to find 
previous
discussions) but here is my summary below:

- I don't think the patch in its current form is the right way to do this. 
Instead of
adding a feature bit to fudge the existing IRQ routing when the existing IRQ 
routing
is wrong, let's fix the existing IRQ routing instead.

- There is no mention of "non-100%" native mode in the 8231 or 686B datasheet: 
this
is simply a term used within the Linux patches. The controller is either in 
native
mode, or legacy mode. It may be that guests are making use of some undefined
behaviour here.

- The code that uses the value of PCI_INTERRUPT_LINE in via-ide is incorrect 
(as your
patch comment points out, some guests ignore it anyway).

- There is different behaviour here between the 8231 and 686B in this area, 
despite
having the same vendor/device id.


The first thing you need to fix is the PCI_INTERRUPT_LINE part; I would start by
removing the existing code and instead expose a qdev named gpio "legacy-irq" and
wiring that up to your interrupt controller. Note you'd have to do the same for
fulong2e, but that is reasonably trivial.


ATB,

Mark.



reply via email to

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