Re: [Xen-devel] PCIe devices that are hotplugged after MMIO has been setup fail due to _CRS not covering 64-bit area

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.11.16 at 15:39, <konrad.wilk@xxxxxxxxxx> wrote:
> Also I realized that "Range Size and Alignment Requirement" aren't meet
> with the code I wrote - as the size (2^n) must be aligned on the
> 2^n boundary, and that is certainly not meet.

Yes, this would better be obeyed to.

> Anyhow the point here is that with modifications here I will
> still run in the variable MTRR limit if I am to cover most of the
> space. I can do up to a certain value. And that 'value' could
> become the pci_high_mem_end?

Yes - moving the boundary to require fewer MTRRs is certainly
an option. Also remember that we are required to leave a few
MTRRs for OS use.

> Or perhaps revisit a6a822324:
> Author: Keir Fraser <keir.fraser@xxxxxxxxxx>
> Date:   Wed Apr 16 13:36:44 2008 +0100
> 
>     x86, hvm: Lots of MTRR/PAT emulation cleanup.
>     
>      - Move MTRR MSR initialisation into hvmloader.
>      - Simplify initialisation logic by overlaying UC on default WB rather
>        than vice versa.
>      - Clean up hypervisor HVM MTRR/PAE code's interface with rest of
>        hypervisor.
>     
> 
> As the default MTRR is WB. If that was UC we could just set MTRRs
> for RAM regions and have the type be WB for those regions?
> 
> I am not sure thought if that is a good direction either?

Actually I think we should pick the variant requiring fewer MTRRs.
I've seen BIOSes of both kinds. Otoh I've never been really
convinced using WB as the default is really that good an idea.

> And that actually worked out nicely. Linux sees the new _CRS regions
> and I got [this includes two extra regions - so that the HT region
> is not touched]:
> 
>  ...
>      pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
>      pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
>      pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
>      pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff window]
>      pci_bus 0000:00: root bus resource [mem 0x10fc00000-0xfcfffffffe window]
>      pci_bus 0000:00: root bus resource [mem 0x10000000000-0xffffffffffff 
> window]
>      pci_bus 0000:00: root bus resource [bus 00-ff]
> 
> from:
>     pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
>     pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
>     pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
>     pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff window]
>     pci_bus 0000:00: root bus resource [bus 00-ff]
> 
> Except that when I tried this with Windows 2000 I found out that
> its AML interpreter blows up if any of the values are bigger than
> 8GB. With a bit of extra AML duct-tape that got solved, albeit I need
> to verify other Windows platforms. Which reminds me - you had dabbled
> in this - are there any other surprises I should be aware of ?

The only thing I remember is the WinXP issue with qword fields (as
mentioned in a comment in dsdt.asl).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel