On 10/06/14 21:54, Gabriel L. Somlo wrote:
> On Mon, Sep 29, 2014 at 02:52:30PM +0200, Laszlo Ersek wrote:
>> On 09/29/14 14:30, Paolo Bonzini wrote:
>>> Il 29/09/2014 14:07, Laszlo Ersek ha scritto:
>>>> Apparently so, for 00:01.3 on the PIIX4.
>>>>
>>>> But for other PCI devices, I think it's writeable, isn't it? (Of course
>>>> the devices-related code in this function should go away completely, if
>>>> possible. git-blame is probably helpful here.)
>>>
>>> No, it's read-only. The PCI spec says so, and pci_init_wmask in QEMU's
>>> hw/pci/pci.c agrees (in QEMU, PCI_INTERRUPT_LINE is 0x3c, and
>>> PCI_INTERRUPT_PIN is 0x3d).
>>>
>>>>>> In fact, 0x3d should be _used_ to determine whether to fill in the
>>>>>> register at 0x3c, and what value to write. OVMF must write there the
>>>>>> GSI number associated to the corresponding INTX pin. See
>>>>>> pci_bios_init_device in SeaBIOS's src/fw/pciinit.c.
>>>> The PIIX4 spec says in 7.1.8. "INTLN???INTERRUPT LINE REGISTER (FUNCTION
>>>> 3)" that "The value in this register has no affect on PIIX4 hardware
>>>> operations."
>>>>
>>>> (It might still be useful for code that reads the register later, for
>>>> all I know.)
>>>
>>> Exactly. The OS will usually use 0x3d together with the result of _PRT
>>> to find the interrupt that is associated to a device; but the OS can
>>> also rely on the firmware's setting of 0x3c, which is basically the same
>>> thing but precomputed for non-ACPI-aware systems.
>>>
>>>>>> This should be done
>>>>>> in a PEI (or is it PI?) driver, not DXE, because it must run on resume
>>>>>> from S3.
>>>> The place would be MiscInitialization() in
>>>> "OvmfPkg/PlatformPei/Platform.c", but I'm not sure it would have any
>>>> effect. (Its lack doesn't seem to.)
>>>
>>> Likely not, but still it's wrong and the current code doesn't make much
>>> sense for Q35, so Gabriel may want to fix it anyway based on the Q35 DSDT.
>>
>> Yes, please. :)
>
> OK, so for now I'm planning on doing something like the following,
> which will be part of my upcoming Q35/OVMF patch set (soon as we agree
> on what to do about AcpiTimerLib, in a parallel thread):
>
> --- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> @@ -720,48 +720,27 @@ VOID
> PciInitialization (
> )
> {
> - //
> - // Bus 0, Device 0, Function 0 - Host to PCI Bridge
> - //
> - PciWrite8 (PCI_LIB_ADDRESS (0, 0, 0, 0x3c), 0x00);
> -
> - //
> - // Bus 0, Device 1, Function 0 - PCI to ISA Bridge
> - //
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x3c), 0x00);
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA routing target
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB routing target
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // LNKC routing target
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // LNKD routing target
> -
> - //
> - // Bus 0, Device 1, Function 1 - IDE Controller
> - //
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 1, 0x3c), 0x00);
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 1, 0x0d), 0x40);
> -
> - //
> - // Bus 0, Device 1, Function 3 - Power Managment Controller
> - //
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 3, 0x3c), 0x09);
> - PciWrite8 (PCI_LIB_ADDRESS (0, 1, 3, 0x3d), 0x01); // INTA
> -
> - //
> - // Bus 0, Device 2, Function 0 - Video Controller
> - //
> - PciWrite8 (PCI_LIB_ADDRESS (0, 2, 0, 0x3c), 0x00);
> -
> - //
> - // Bus 0, Device 3, Function 0 - Network Controller
> - //
> - PciWrite8 (PCI_LIB_ADDRESS (0, 3, 0, 0x3c), 0x0a);
> - PciWrite8 (PCI_LIB_ADDRESS (0, 3, 0, 0x3d), 0x01); // INTA (-> LNKC)
> -
> - //
> - // Bus 0, Device 5, Function 0 - RAM Memory
> - //
> - PciWrite8 (PCI_LIB_ADDRESS (0, 5, 0, 0x3c), 0x0b);
> - PciWrite8 (PCI_LIB_ADDRESS (0, 5, 0, 0x3d), 0x01); // INTA (->
> LNKA)
> + if (IS_PLATFORM_Q35) {
> + //
> + // 00:1f.0 LPC Bridge (Q35) routing targets
> + //
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x60), 0x0a); // LNKA
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x61), 0x0a); // LNKB
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x62), 0x0b); // LNKC
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x63), 0x0b); // LNKD
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x68), 0x0a); // LNKE
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x69), 0x0a); // LNKF
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // LNKG
> + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // LNKH
> + } else {
> + //
> + // 00:01.0 ISA Bridge (PIIX4) routing targets
> + //
> + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA
> + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB
> + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // LNKC
> + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // LNKD
> + }
> }
>
> So far, this seems to work great (and have zero side effects) on
> either Linux or OSX (running on piix4 + ovmf).
>
> I'll try to have a look at whether anything can/should be done in
> OvmfPkg/PlatformPei/Platform.c:MiscInitialization() to make up
> for the code I'm removing; However, I'm probably going to leave that
> for a future patch set (unless Windows breaks, that is :) ...
>
> In the meantime, what's the "gold standard" of Windows versions to
> tested with OVMF ? I have access to Win7 (32 and 64bit), but that's
> probably considered "old" by now ?
I haven't answered here yet.
I'll admit up-front that I've lost context over the last weeks. I guess
I'll just wait until you find the time to post the next version(s) of
the Q35 support patches. Don't rush it -- this is not to urge you; I'm
just saying that I'm trying to finish up this thread on my part.
To answer your last question: preferably, Windows 8, Windows 8.1, or
Windows Server 2012 R2 should be used for "windows UEFI guest" testing.
I prefer these over the Windows 7 family because UEFI support
"permeates" them entirely (which wasn't the case with Windows 7).
I'd recommend the third option (ie. a Windows Server 2012 R2
installation, with GUI). There's no consumerist UI / app cruft in that
option -- it's a much cleaner experience.
Laszlo
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
