On 09/13/12 22:12, Jason Baron wrote:
+void mch_mem_addr_init(struct pci_device *dev, void *arg) +{
- struct pci_mem_addr *addr = arg;
- u64 s, e;
+#if BUILD_MAX_HIGHMEM != 0xe0000000 +# error "please adjust memory mapping area" +#endif
- /*
* BUILD_MAX_HIGHMEM == 0xe0000000
* [0xe000 0000, 0xf000 0000) for MCFG
* 4GB - 512MB, 4GB - 256MB
* [0xf000 0000, 0xfec0 0000) for DMI interface(subtractive decode)
* 4GB - 256MB, 4GB - 20MB
*/
- s = BUILD_MAX_HIGHMEM + 256 * 1024 * 1024;
- e = s + 128 * 1024 * 1024 - 1;
- *(addr->pcimem_start) = s;
- *(addr->pcimem_end) = e;
+}
This must be adapted too to not hard-code things.
cheers, Gerd
On Fri, Sep 14, 2012 at 09:52:24AM +0200, Gerd Hoffmann wrote:
On 09/13/12 22:12, Jason Baron wrote:
+void mch_mem_addr_init(struct pci_device *dev, void *arg) +{
- struct pci_mem_addr *addr = arg;
- u64 s, e;
+#if BUILD_MAX_HIGHMEM != 0xe0000000 +# error "please adjust memory mapping area" +#endif
- /*
* BUILD_MAX_HIGHMEM == 0xe0000000
* [0xe000 0000, 0xf000 0000) for MCFG
* 4GB - 512MB, 4GB - 256MB
* [0xf000 0000, 0xfec0 0000) for DMI interface(subtractive decode)
* 4GB - 256MB, 4GB - 20MB
*/
- s = BUILD_MAX_HIGHMEM + 256 * 1024 * 1024;
- e = s + 128 * 1024 * 1024 - 1;
- *(addr->pcimem_start) = s;
- *(addr->pcimem_end) = e;
+}
This must be adapted too to not hard-code things.
Is it reasonable to pull these out of the dsdt acpi table?
Thanks,
-Jason
Hi,
- *(addr->pcimem_start) = s;
- *(addr->pcimem_end) = e;
+}
This must be adapted too to not hard-code things.
Is it reasonable to pull these out of the dsdt acpi table?
It's a solved problem ;)
acpi.c builds a ssdt BDAT entry, then places the pcimem addresses there. The DSDT table has AML code to pick up the values and stick them into a RessourceTemplate, so the guest OS can see it just fine (you'll see it show up in /proc/iomem in linux guests).
You can basically just copy _SB.PCI0._CRS logic from the piix dtst. Maybe it is a good idea to separate out common stuff into a include file while being at it.
cheers, Gerd