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

[Mark Cave-Ayland]

On 05/03/2020 23:35, BALATON Zoltan wrote:

>> I just a quick look at the PCI specification and found this interesting 
>> paragraph in
>> the section about "Interrupt Line":
>>
>>
>> "The Interrupt Line register is an eight-bit register used to communicate 
>> interrupt
>> line routing information. The register is read/write and must be implemented 
>> by any
>> device (or device function) that uses an interrupt pin. POST software will 
>> write the
>> routing information into this register as it initializes and configures the 
>> system."
>>
>> "The value in this register tells which input of the system interrupt 
>> controller(s)
>> the device's interrupt pin is connected to. The device itself does not use 
>> this
>> value, rather it is used by device drivers and operating systems. Device 
>> drivers and
>> operating systems can use this information to determine priority and vector
>> information. Values in this register are architecture-specific [43]."
>>
>> [43] For x86 based PCs, the values in this register correspond to IRQ 
>> numbers (0-15)
>> of the standard dual 8259 configuration. The value 255 is defined as meaning
>> "unknown" or "no connection" to the interrupt controller. Values between 15 
>> and 254
>> are reserved.
>>
>>
>> The key part here is "The device itself does not use this value, rather it 
>> is used by
>> device drivers and operating systems" since this immediately tells us that 
>> the
>> existing code in hw/ide/via.c which uses the interrupt line value for IRQ 
>> routing is
>> incorrect and should be removed.
> 
> On real hardware this may be true but in QEMU how would it otherwise raise the
> correct interrupt line the guest expects? This probably does not matter for 
> pegasos2
> but I think is needed for 100% native mode used with the fulong2e so it gets 
> the IRQ
> it expects.

That's easy - remember that both the PCI and IRQ interrupts are separate pins 
on the
chip, so all that needs to be done is expose the legacy IRQ via qdev and use 
that to
wire it up to your interrupt controller.

>> If we do that the next question is how does the VIA know whether the use the 
>> PCI
>> interrupt or the legacy interrupt? Another look at the datasheet showed that 
>> there is
> 
> I don't think via-ide ever uses a PCI interrupt, if you look at its datasheet 
> the
> description of the prog-if reg (0x9) says in native mode irq is programmable 
> via
> config reg 0x3c which then lists all the ISA IRQs as possible values, default 
> 14 and
> 0 meaning disable.
> 
>> 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.

Okay so this is interesting: I've been switching between the VT8231 and the 
VT82C686B
datasheets, and there is a difference here. You are correct in what you say 
above in
that the 8231 docs specify that this is set to 1, but on the 686B this is 
clearly not
the case.

What is rather unusual here is that both the 8231 and 686B have exactly the same
device and vendor ids, so I'm not sure how you'd distinguish between them?

>> In your previous email you included a trace of the PCI configuration 
>> accesses to the
>> via-ide device. Can you try this again with the following diff and post the 
>> same
>> output once again?
>>
>> diff --git a/hw/ide/via.c b/hw/ide/via.c
>> index 096de8dba0..db9f4af861 100644
>> --- a/hw/ide/via.c
>> +++ b/hw/ide/via.c
>> @@ -139,7 +139,7 @@ static void via_ide_reset(DeviceState *dev)
>>     pci_set_long(pci_conf + PCI_BASE_ADDRESS_2, 0x00000170);
>>     pci_set_long(pci_conf + PCI_BASE_ADDRESS_3, 0x00000374);
>>     pci_set_long(pci_conf + PCI_BASE_ADDRESS_4, 0x0000cc01); /* BMIBA: 
>> 20-23h */
>> -    pci_set_long(pci_conf + PCI_INTERRUPT_LINE, 0x0000010e);
>> +    pci_set_long(pci_conf + PCI_INTERRUPT_LINE, 0x0000000e);
>>
>>     /* IDE chip enable, IDE configuration 1/2, IDE FIFO Configuration*/
>>     pci_set_long(pci_conf + 0x40, 0x0a090600);
> 
> This does not change much:
> 
> pci_cfg_write via-ide 12:1 @0x9 <- 0xf
> pci_cfg_write via-ide 12:1 @0x40 <- 0xb
> pci_cfg_write via-ide 12:1 @0x41 <- 0xf2
> pci_cfg_write via-ide 12:1 @0x43 <- 0x35
> pci_cfg_write via-ide 12:1 @0x44 <- 0x18
> pci_cfg_write via-ide 12:1 @0x45 <- 0x1c
> pci_cfg_write via-ide 12:1 @0x46 <- 0xc0
> pci_cfg_write via-ide 12:1 @0x50 <- 0x17171717
> pci_cfg_write via-ide 12:1 @0x54 <- 0x14
> pci_cfg_read via-ide 12:1 @0x0 -> 0x5711106
> pci_cfg_read via-ide 12:1 @0x0 -> 0x5711106
> pci_cfg_read via-ide 12:1 @0x8 -> 0x1018f06
> pci_cfg_read via-ide 12:1 @0xc -> 0x0
> pci_cfg_read via-ide 12:1 @0x2c -> 0x11001af4
> pci_cfg_read via-ide 12:1 @0x3c -> 0xe
> pci_cfg_read via-ide 12:1 @0x4 -> 0x2800080
> pci_cfg_read via-ide 12:1 @0x3c -> 0xe
> pci_cfg_write via-ide 12:1 @0x3c <- 0x9
> 
> compared to
> 
>> pci_cfg_write via-ide 12:1 @0x9 <- 0xf
>> pci_cfg_write via-ide 12:1 @0x40 <- 0xb
>> pci_cfg_write via-ide 12:1 @0x41 <- 0xf2
>> pci_cfg_write via-ide 12:1 @0x43 <- 0x35
>> pci_cfg_write via-ide 12:1 @0x44 <- 0x18
>> pci_cfg_write via-ide 12:1 @0x45 <- 0x1c
>> pci_cfg_write via-ide 12:1 @0x46 <- 0xc0
>> pci_cfg_write via-ide 12:1 @0x50 <- 0x17171717
>> pci_cfg_write via-ide 12:1 @0x54 <- 0x14
>> pci_cfg_read via-ide 12:1 @0x0 -> 0x5711106
>> pci_cfg_read via-ide 12:1 @0x0 -> 0x5711106
>> pci_cfg_read via-ide 12:1 @0x8 -> 0x1018f06
>> pci_cfg_read via-ide 12:1 @0xc -> 0x0
>> pci_cfg_read via-ide 12:1 @0x2c -> 0x11001af4
>> pci_cfg_read via-ide 12:1 @0x3c -> 0x10e
>> pci_cfg_read via-ide 12:1 @0x4 -> 0x2800080
>> pci_cfg_read via-ide 12:1 @0x3c -> 0x10e
>> pci_cfg_write via-ide 12:1 @0x3c <- 0x109
> 
> firmware does not seem to care about this value.

I think this proves what I was saying about the legacy interrupt routing, but of
course this is based upon the 686B rather than the 8231.


ATB,

Mark.