qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] large size PCI windows vs ivshmem vs windows guests


From: Michael S. Tsirkin
Subject: [Qemu-devel] large size PCI windows vs ivshmem vs windows guests
Date: Thu, 18 Jul 2013 19:32:18 +0300

Currently seabios simply looks for 64 bit BARs and sums them up
to get the size of the region.
The result is reported in the CRS method in ACPI tables.
But this means that e.g. hotplug is broken - if we try to
add a huge ivshmem device there won't be place for it
in the 32 bit PCI hole, and a 64 bit one isn't declared.

So we really should declare some 64 bit windows,
but the question is - what's a good value for CRS?

It would appear that we should be able to declare
a very large window in CRS and be done with it.
Works fine for linux, but it turns out adding the following in CRS is
enough to make e.g. win7 x86 crash on boot:

diff --git a/src/acpi-dsdt-pci-crs.dsl b/src/acpi-dsdt-pci-crs.dsl
index d421891..405859d 100644
--- a/src/acpi-dsdt-pci-crs.dsl
+++ b/src/acpi-dsdt-pci-crs.dsl
@@ -36,6 +36,13 @@ Scope(\_SB.PCI0) {
             0x00000000,         // Address Translation Offset
             0x00020000,         // Address Length
             ,, , AddressRangeMemory, TypeStatic)
+        QWordMemory(ResourceProducer, PosDecode, MinFixed, MaxFixed, 
Cacheable, ReadWrite,
+            0x00000000,          // Address Space Granularity
+            0x8000000000,        // Address Range Minimum
+            0x80FFFFFFFF,        // Address Range Maximum
+            0x00000000,          // Address Translation Offset
+            0x0100000000,        // Address Length
+            ,, , AddressRangeMemory, TypeStatic)
         DWordMemory(ResourceProducer, PosDecode, MinFixed, MaxFixed, 
NonCacheable, ReadWrite,
             0x00000000,         // Address Space Granularity
             0xE0000000,         // Address Range Minimum


The issue is the Length field - if it's 0x0080000000 or
less win7 32 bit boots (an interesting tidbit - it seems
possible to declare more than one 2G resource,
but each one needs to be at most 2G - did they use some
signed integer somewhere?).

I'd like to propose the following:
    - declare a safe value (2G) in CRS by default
        you won't be able to use ivshmem with huge sizes
        we can detect common cases and warn users
    - add a flag controlling size of 64 bit window declared

I am guessing most people use <2G shared memory so won't
be affected.

Comments?

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]