On 09/29/14 00:03, Gabriel L. Somlo wrote:
> On Sat, Sep 27, 2014 at 06:06:45PM -0400, Gabriel L. Somlo wrote:
>> Factor out logic to distinguish between Q35 and PIIX4 platforms
>> into a separate header (OvmfPkg/Include/Library/PciHostBridge.h),
>> then refer to these macros from all relevant source locations
>> throughouth OvmfPkg.
>>
>> This patch also adds a Q35-specific PIC IRQ routing initialization
>> function to OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Gabriel Somlo <[email protected]>
>> ---
> 
> First off, please ignore the [01/14] part of the "subject" line, that
> was nothing more than git outsmarting me (again) :)
> 
> 
> So, with this patch and Reza's AHCI/SATA patch set, and with the
> following Q35 command line:

Do you mean the series:

<[email protected]>

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/8706

I have not forgotten about it; patch v2 3/6 is still in my queue. I
didn't bother reviewing it because the patchset modifies (beside
OvmfPkg) MdeModulePkg, DuetPkg, and PcAtChipsetPkg, and those patches
have not been reviewed / accepted by the respective module maintainers.

> bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo -smp 4,cores=2 \
>   -machine q35 -device ide-drive,bus=ide.2,drive=CD \
>   -drive id=CD,if=none,snapshot=on,file=Fedora-Live-Desktop-x86_64-20-1.iso \
>   -device isa-applesmc,osk="<apple smc magic string>" \
>   -netdev user,id=usr0 -device e1000-82545em,netdev=usr0,id=vnet0 \
>   -usb -device usb-kbd -device usb-mouse \
>   -monitor stdio \
>   [ -bios OVMF.fd ]

DO NOT USE OVMF WITH -bios.

It perpetuates a bad practice that was unavoidable in the beginning, but
is entirely unnecessary nowadays. If you're willing to type just one
word, type "-pflash". Please.

> I diff-ed the entire contents of 'dmesg' between instances started
> without "-bios OVMF.fd" (i.e., using SeaBIOS), and with OVMF.
> 
> 
> With more detail enclosed at the end of this email, what caught my
> attention was:
> 
> + mtrr: your CPUs had inconsistent fixed MTRR settings
> + mtrr: your CPUs had inconsistent variable MTRR settings
> + mtrr: your CPUs had inconsistent MTRRdefType settings
> + mtrr: probably your BIOS does not setup all CPUs.
> + mtrr: corrected configuration.
> 
> If I "cat /proc/mtrr" after booting fedora with OVMF, I get
> 
> reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
> 
> With SeaBIOS, OTOH, it looks like this:
> 
> reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable

On "modern" processors, MTRRs need to be programmed on all CPUs
"simultaneously". That is, they need to be lined up at a barrier, then
their MTRRs must be programmed one by one. Then each CPU that has been
programmed must wait at a second barrier *after*, until all are done,
and then they can all go their merry ways.

As Paolo and Gerd explained:
- we don't really care about MTRRs
- we don't bring up the APs.

Multi-VCPU Windows & Linux guests are apparently fine with this (Linux
complains but that's it).

Chen Fan has been working on the Mp Service protocol for UefiCpuPkg, and
it would be probably usable in the OVMF build as well, but I continue to
fail to see the point (in OVMF). First, we don't care about MTRRs (see
above). Second, APs are not allowed to call anything in edk2 (edk2 is
not multi-thread-safe); whatever they do must be self-contained (like,
you could do some number crunching). I just don't see the point, for OVMF.

> The other interesting bit was that with OVMF I also get:

> + pci 0000:00:01.0: no compatible bridge window for [mem 
> 0x80000000-0x81ffffff pref]
> + pci 0000:00:01.0: no compatible bridge window for [mem 
> 0x82022000-0x82022fff]
> + pci 0000:00:02.0: no compatible bridge window for [mem 
> 0x82000000-0x8201ffff]
> + pci 0000:00:1d.7: no compatible bridge window for [mem 
> 0x82021000-0x82021fff]
> + pci 0000:00:1f.2: no compatible bridge window for [mem 
> 0x82020000-0x82020fff]

What are these devices?

Thanks
Laszlo

------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to