PCI_BASE_ADDRESS_MEM_TYPE_64
attribute and the given region doesn't fit in first 4GB. The patch has been
tested on Linux and BSD guest OS's and it appears to work fine.
Signed-off-by Alexey Korolev alexey.koro...@endace.com
Signed-off-by Stephen Donelly stephen.done...@endace.com
---
pciinit.c | 83
Hi,
Hi.
The current BAR allocation doesn't check overflow and some patches
are floating around which aren't merged yet.
There are several issues.
- overflow check
This should be fixed.
Some patches are proposed. None hasn't been merged yet.
Your patch also addresses this issue.
Hi,
There were a number of requests about support of 64bit PCI BAR allocations.
Also we have observed the issue on guests with older linux version
(2.6.18): if we
have a 64bit BAR allocated within first 4GB, the OS may hang during
start process.
(I guess it is an OS bug, but we need to take
.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
src/acpi-dsdt.dsl |7 +
src/acpi-dsdt.hex | 66
+
src/config.h |2 +
3 files changed, 65 insertions(+), 10 deletions
, the
bridges can describe 64bit ranges for prefetchable type of memory only.
So it's very
unlikely that devices exporting 64bit non-prefetchable BARs. Anyway this
code will work
with 64bit non-prefetchable BARs unless the PCI device is not behind the
secondary bus.
Signed-off-by: Alexey Korolev
All devices behind a bridge need to have all their regions consecutive and
not overlapping with all the normal memory ranges.
Since prefetchable memory is described by one record, we must avoid the
situations
when 32bit and 64bit prefetchable regions are present within one secondary bus.
I hate thunderbird. Will resend the patches tomorrow.
+pci_config_writel(bdf, PCI_PREF_BASE_UPPER32, base 32);
On 29/12/11 00:30, Michael S. Tsirkin wrote:
On Wed, Dec 28, 2011 at 06:26:05PM +1300, Alexey Korolev wrote:
This patch adds PCI_REGION_TYPE_PREFMEM_64 region type and modifies types of
variables to make it possible to work with 64 bit addresses.
Why I've added just one region type
On 29/12/11 15:56, Kevin O'Connor wrote:
On Wed, Dec 28, 2011 at 06:26:05PM +1300, Alexey Korolev wrote:
This patch adds PCI_REGION_TYPE_PREFMEM_64 region type and modifies types of
variables to make it possible to work with 64 bit addresses.
Why I've added just one region type
@@ -69,6 +72,8 @@ static enum pci_region_type pci_addr_to_type(u32 addr)
{
if (addr PCI_BASE_ADDRESS_SPACE_IO)
return PCI_REGION_TYPE_IO;
+if (addr PCI_BASE_ADDRESS_MEM_TYPE_64)
+return PCI_REGION_TYPE_PREFMEM_64;
This seems dangerous - a 64bit bar can be
On 29/12/11 00:43, Michael S. Tsirkin wrote:
On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
All devices behind a bridge need to have all their regions consecutive and
not overlapping with all the normal memory ranges.
Since prefetchable memory is described by one record, we
On 29/12/11 00:43, Michael S. Tsirkin wrote:
On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
All devices behind a bridge need to have all their regions consecutive and
not overlapping with all the normal memory ranges.
Since prefetchable memory is described by one record, we
Patches have been tested on several configurations which includes
linux 2.6.18 - 3.0
windows 2008. Everything works quite well.
Which qemu version did you use?
I tried both 0.15 and 1.0
On 30/12/11 05:21, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 09:20:00AM +, Alexey Korolev wrote:
Patches have been tested on several configurations which includes
linux 2.6.18 - 3.0
windows 2008. Everything works quite well.
Which qemu version did you use?
I tried both 0.15
On 30/12/11 05:18, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 06:40:26PM +1300, Alexey Korolev wrote:
On 29/12/11 00:43, Michael S. Tsirkin wrote:
On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
All devices behind a bridge need to have all their regions consecutive
On 30/12/11 05:21, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
Can't figure this out. What does this do?
Bios will panic if it founds prefmem BARs in both 32bit and 64bit areas.
That's not good, it's a legal configuration.
To be more complete
On 30/12/11 05:21, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
Can't figure this out. What does this do?
Bios will panic if it founds prefmem BARs in both 32bit and 64bit areas.
That's not good, it's a legal configuration.
To be more complete
There are two main things we can do:
1. Make the 64 bit device only use the low 32 bit
It was my first implementation. Unfortunately older versions of
Linux (Like 2.6.18) hang during startup with this.
As far as I remember it was qemu-0.15 so may be 1.0 have no such an
issue. I will check
Hi,
We have got some issues with 64bit PCI devices support under Windows guests.
Windows fails to start any PCI devices with 64bit BARs when size exceeds
512MB with error code 12 (can't allocate resources). In other words it
fails when the PCI memory region is located above 4GB.
I tried to
On Wed, Nov 30, 2011 at 02:04:08PM +1300, Alexey Korolev wrote:
Hi,
We have got some issues with 64bit PCI devices support under Windows guests.
Windows fails to start any PCI devices with 64bit BARs when size
exceeds 512MB with error code 12 (can't allocate resources). In
other words
,
Alexey
On Wed, Nov 30, 2011 at 02:04:08PM +1300, Alexey Korolev wrote:
Hi,
We have got some issues with 64bit PCI devices support under Windows guests.
Windows fails to start any PCI devices with 64bit BARs when size
exceeds 512MB with error code 12 (can't allocate resources). In
other words
.
Do you have any ideas what can be done to solve this problem?
Regards,
Alexey
On Thu, Dec 01, 2011 at 06:49:54PM +1300, Alexey Korolev wrote:
Isaku san,
I've just added you to discussion.
There are some issues with PCI 64bit support in Windows. Windows
fails to assign the resource
Hi Gerd,
We have very early prototype of data acquisition device, with quite
large MMIO buffer. It is an emulated device.
We are running the 0.15 release.
0.15 doesn't work correctly with 64bit BARs so I've already added some
hacks to Seabios to let OS to choose the memory region.
Thus you
On 05/12/11 19:31, Michael S. Tsirkin wrote:
On Mon, Dec 05, 2011 at 05:20:32PM +1300, Alexey Korolev wrote:
Hi Michael,
Thank you for good advice, you are right. When I added new range
above 4GB in _CRS the problem has gone.
QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed
Hi Gerd,
I'd strongly suggest to move forward to qemu 1.0. Memory region
handling has seen a major rewrite in 1.0 (memory api patches by avi).
Chances are good that the 64bit bar bugs in qemu have been fixed meanwhile.
Thanks, will try it. Hope it will be better.
I have experimental
Hi,
It shouldn't be that hard to add the latter though. seabios needs two
more pci_region_type (PCI_REGION_TYPE_MEM_64 and
PCI_REGION_TYPE_PREFMEM_64) to track and map 64bit bars separately. And
a address space window where it can map 64bit bars to.
Right. This is a thing I'm thinking about
2. Get a range toward the upper end of the memory, around 140
Yes. This solution works great. And this is very simple as well. Just
wondering if it will be good as a complete solution?
I would have tried this first too ;)
Care to share the patches so we can review merge them?
No worries.
I wonder if there any particular reason to separate prefetchable a
non-prefetchable memory regions in pciinit? Extra two more regions would
make code more complex.
Oh yes, there is. Which reminds me that the whole thing isn't that easy
unfortunaly ...
The reason are pci bridges. They have two
HI,
Current version of Seabios is causing blue screen on Windows2003 when 64bit PCI
resource is present and occupies high memory.
BSOD Error code is: 0x00A5 (0x02, 0xfADF6A446880, 0x1,
0xFADFAA34690)
The issue is localized, it is related to presence of 64bit resource in _CRS
Hi Kevin,
Unfortunately, it's very difficult to debug acpi issues on Windows.
Gerd's been on vacation this week - so, lets give him a chance to look
at it when he gets back. If it can't be resolved, we'll need to
revert the patch that broke Win2003.
Thank you for your reply.
Right - acpi issues
.
The patch is tested on Linux 2.6.18 - 3.1.0 and Windows 2008 Server
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
hw/pci.c | 45 +
hw/pci.h |7 +++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw
Hi Alex and Michael
For testing, I applied the following patch to qemu,
converting msix bar to 64 bit.
Guest did not seem to crash.
I booted Fedora Live CD 32 bit guest on a 32 bit host
to level 3 without crash, and verified that
the BAR is a 64 bit one, and that I got assigned an address
On 26/01/12 01:51, Michael S. Tsirkin wrote:
On Wed, Jan 25, 2012 at 06:46:03PM +1300, Alexey Korolev wrote:
Hi,
In this post
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg03171.html I've
mentioned about the issues when 64Bit PCI BAR is present and 32bit
address range is selected
On 27/01/12 03:36, Michael S. Tsirkin wrote:
On Thu, Jan 26, 2012 at 03:52:27PM +0200, Avi Kivity wrote:
On 01/26/2012 11:14 AM, Michael S. Tsirkin wrote:
On Wed, Jan 25, 2012 at 06:46:03PM +1300, Alexey Korolev wrote:
Hi,
In this post
http://lists.gnu.org/archive/html/qemu-devel/2011-12
On 27/01/12 04:12, Avi Kivity wrote:
On 01/26/2012 04:36 PM, Michael S. Tsirkin wrote:
On Thu, Jan 26, 2012 at 03:52:27PM +0200, Avi Kivity wrote:
On 01/26/2012 11:14 AM, Michael S. Tsirkin wrote:
On Wed, Jan 25, 2012 at 06:46:03PM +1300, Alexey Korolev wrote:
Hi,
In this post
http
On 31/01/12 22:43, Avi Kivity wrote:
On 01/31/2012 11:40 AM, Avi Kivity wrote:
On 01/27/2012 06:42 AM, Alexey Korolev wrote:
On 27/01/12 04:12, Avi Kivity wrote:
On 01/26/2012 04:36 PM, Michael S. Tsirkin wrote:
On Thu, Jan 26, 2012 at 03:52:27PM +0200, Avi Kivity wrote:
On 01/26/2012 11:14
On 01/02/12 20:04, Michael S. Tsirkin wrote:
On Wed, Feb 01, 2012 at 06:44:42PM +1300, Alexey Korolev wrote:
On 31/01/12 22:43, Avi Kivity wrote:
On 01/31/2012 11:40 AM, Avi Kivity wrote:
On 01/27/2012 06:42 AM, Alexey Korolev wrote:
On 27/01/12 04:12, Avi Kivity wrote:
On 01/26/2012 04:36
On 14/03/12 13:48, Kevin O'Connor wrote:
On Tue, Mar 13, 2012 at 05:45:19PM +1300, Alexey Korolev wrote:
Added pci_region_entry structure and list operations to pciinit.c
List is filled with entries during pci_check_devices.
List is used just for printing space allocation if we were using
On 16/03/12 13:55, Kevin O'Connor wrote:
On Thu, Mar 15, 2012 at 04:29:30PM +1300, Alexey Korolev wrote:
On 14/03/12 13:48, Kevin O'Connor wrote:
On Tue, Mar 13, 2012 at 05:45:19PM +1300, Alexey Korolev wrote:
Added pci_region_entry structure and list operations to pciinit.c
List is filled
Hi,
There is a typo in i440FX init code. This is causing problems when
somebody wants to access 64bit PCI range.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
hw/piix_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/piix_pci.c b/hw
On Wed, Feb 29, 2012 at 02:35:14PM +1300, Alexey Korolev wrote:
I've fixed the commit message and applied.
Thank you!
How does one trigger the problem?
I'd like to know so I can test for it.
The i440fx_init() function is called from pc_init code.
The call looks like that:
pci_bus
Hi,
This patch series redesigns the existing pciinit.c code and introduces
linked list operations.
Changes are more about structures definitions rather than functionality.
There are no more arrays of bases and counts in new implementation. The
new implementation is based on dynamic allocation of
This linked list implementation is partially based on kernel code. So it
should be quite stable
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/util.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/src/util.h b/src/util.h
index
In this patch the pci_region_entry structure is introduced.
The pci_device-bars are removed. The information from
pci_region_entry is used to program pci bars.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pci.h |5 --
src/pciinit.c | 116
In this patch instead of array based resource allocation approach
we calculate resource addresses linked lists of pci_region_entry structures.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 179 -
1 files
The 'size' element of pci_bus-r structure is no longer need
as the information about bridge region size is already stored in
pci_region_entry structure.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 21 +
1 files changed, 9 insertions(+), 12
This linked list implementation is partially based on kernel code. So it
should be quite stable
How about just copying the file?
I've used the linux kernel list implementation elsewhere too and it
worked just fine with only minor tweaks (remove some likely()/unlikely()
macros IIRC).
Right,
Hi Kevin,
Thank you for the patches!
I've created a diff of final version of your changes over mine, to make it
clear what has changed.
Rather than including the complete diff, I've just left relevant parts and
added comments.
--- a/src/pciinit.c +++ b/src/pciinit.c@@ -12,8 +12,9 @@
Hi,
There is a typo in i440FX init code. This is causing problems when
somebody wants to access 64bit PCI range.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
hw/piix_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
Hi,
This patch series enables 64bit BAR support in seabios.
It has a bit different approach for resources accounting, We did this
because we wanted:
a) Provide 64bit bar support for PCI BARs and bridges with 64bit memory
window.
b) Allow migration to 64bit bit ranges if we did not fit into 32bit
build topology and migrate entries if necessary.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pci.h |6 --
src/pciinit.c | 37 ++---
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/src/pci.h b/src/pci.h
index
-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 132 +++--
1 files changed, 91 insertions(+), 41 deletions(-)
diff --git a/src/pciinit.c b/src/pciinit.c
index 2e5416c..dbfa4f2 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
.
Then the pci_bios_fill_regions() scans pci_regions in reverse order
to calculate size of pci_region_entries belonging to a bridge.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 103 ++---
1 files changed, 98 insertions(+), 5
and provides
a pci_region for downstream devices, we set base address of the region the
entry provides.
3. Delete entry.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/config.h |2 +
src/pciinit.c | 123 -
2 files changed
Delete old code.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 212 -
1 files changed, 0 insertions(+), 212 deletions(-)
diff --git a/src/pciinit.c b/src/pciinit.c
index 0fba130..9c41e3c 100644
--- a/src
This patch was originally proposed by Michael, to solve issues I've seen
on Windows guests, when 64bit BAR's are present.
This patch also might be helpful on Linux guests when use_crs kernel
boot option is set.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
Signed-off-by: Michael S
Hi,
What is your setup?
I want to reproduce this case
a) Provide 64bit bar support for PCI BARs and bridges with 64bit memory
window.
Bridge support seems to be completely untested. /me has a test setup
using mst's bridge patches which looks like this:
[root@fedora ~]# lspci -tv
On 01/03/12 22:22, Gerd Hoffmann wrote:
On 03/01/12 07:57, Alexey Korolev wrote:
In pci_bios_map_regions() we try to reserve memory for
all entries of root bus regions.
If pci_bios_init_root_regions() fails - e.g no enough space, we create two
new pci_regions:
r64pref, r64mem and migrate
On 02/03/12 20:21, Gerd Hoffmann wrote:
On 03/01/12 23:01, Alexey Korolev wrote:
On 01/03/12 22:22, Gerd Hoffmann wrote:
On 03/01/12 07:57, Alexey Korolev wrote:
In pci_bios_map_regions() we try to reserve memory for
all entries of root bus regions.
If pci_bios_init_root_regions() fails
On 03/01/12 22:48, Alexey Korolev wrote:
Hi,
What is your setup?
I want to reproduce this case
qemu: latest master with a few patches (mst's bridge patches, pci64
fixes from me, posted to qemu-devel a few days ago), bundle pushed to
http://www.kraxel.org/cgit/qemu/log/?h=pci64 for your
On Thu, Mar 01, 2012 at 06:50:43PM +1300, Alexey Korolev wrote:
Hi,
This patch series enables 64bit BAR support in seabios.
It has a bit different approach for resources accounting, We did this
because we wanted:
a) Provide 64bit bar support for PCI BARs and bridges with 64bit memory
On 05/03/12 23:12, Gerd Hoffmann wrote:
Hi,
I can either send a patch over existing patches, or send new series or both.
For testing a incremental patch is fine, for merge a new series with the
fixes squashed into the buggy patches is needed.
cheers,
Gerd
Sure. Here are the hot fixes
On 06/03/12 02:49, Kevin O'Connor wrote:
On Mon, Mar 05, 2012 at 10:53:25AM +0100, Gerd Hoffmann wrote:
Given the churn in this area, I don't want to commit patches that do
wholesale code replacement. I'd prefer to see each patch
independently add some functionality and perform its related
Hi,
This patch series redesigns the existing pciinit.c code and introduces
linked list operations.
Changes are more about structures definitions rather than functionality.
There are no more arrays of bases and counts in new implementation. The
new implementation is based on dynamic allocation of
This linked list implementation is partially based on kernel code. So it
should be quite stable :)
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/util.h | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/src/util.h b/src
could keep code workable. I mean further patch
splitting is not possible as there are too many references to pci_bus
members.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pci.h |6 --
src/pciinit.c | 266 ++---
2 files
Now let simplify a bit a cumbersome code in pmm.c and stack.c
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pmm.c| 29 +
src/stacks.c |8 ++--
2 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/src/pmm.c b/src/pmm.c
index
Hi,
This patch series redesigns the existing pciinit.c code and introduces
linked list operations.
Changes are more about structures definitions rather than functionality.
There are no more arrays of bases and counts in new implementation. The
new implementation is based on dynamic allocation of
This linked list implementation is partially based on kernel code. So it
should be quite stable :)
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/util.h | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/src/util.h b/src
Added pci_region_entry structure and list operations to pciinit.c
List is filled with entries during pci_check_devices.
List is used just for printing space allocation if we were using lists.
Next step will resource allocation using mapping functions.
Signed-off-by: Alexey Korolev alexey.koro
-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 106 +
1 files changed, 46 insertions(+), 60 deletions(-)
diff --git a/src/pciinit.c b/src/pciinit.c
index 2bf5473..f766a75 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
This patch deletes array based code need for resource assignment.
The patches 3 and 4 are split just for better readability.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 109 +
1 files changed, 1 insertions
The size element of pci_bus-r structure is no longer need as the
information about bridge region size is stored in pci_region_entry
structure.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 21 +
1 files changed, 9 insertions(+), 12 deletions
This patch simplifies a bit complicated code in pmm.c and stack.c
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pmm.c| 29 +
src/stacks.c |8 ++--
2 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/src/pmm.c b/src/pmm.c
On 04/04/12 15:31, Kevin O'Connor wrote:
Agreed - the only thing it does is force a minimum size for memory bars as
you pointed out in a previous email. As above, I did play with
this a little more on Sunday. I also added in two patches from Gerd's series
and made alignment handling more
On 12/04/12 15:15, Kevin O'Connor wrote:
This was also me playing with one of Gerd's patches. It just makes
the bar read/write code 64bit aware. It doesn't actually program
them. The logic to do real 64bit allocations would require list
merging. Is this something you have looked at?
[...]
[Patch 5]
Track-alignment-explicitly
Almost the same as the previous, just changed priority from r-align to
r-sum when setting start address of root regions.
I guess there are more chances to fit memory regions if we try place regions
with higher r-sum like it was before.
Consider
-bridges-can-have-two-regions-too.patch
0007-pciinit-Switch-to-64bit-variable-types.patch
Alexey Korolev (6):
0003-pciinit-Remove-size-element-from-pci_bus-r-structure.patch
0008-pciinit-Add-pci_region-structure.patch
0009-pciinit-64bit-capability-discovery-for-pci-bridges.patch
0010-Do-not-store-pci
The pci_region_entry structure is introduced.
The pci_device-bars are removed. The information from
pci_region_entry is used to program pci bars.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
src/pci.h |5 --
src/pciinit.c
Perform bus bar assignment at same time as normal bar assignment
Signed-off-by: Kevin O'Connor ke...@koconnor.net
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 53 ++---
1 files changed, 18 insertions(+), 35
The 'size' element of pci_bus-r structure is no
longer need as the information about bridge region
size is already stored in pci_region_entry structure.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
src/pciinit.c | 20
Use sorted order allocation scheme instead of
array based count scheme.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
src/pciinit.c | 71 +---
1 files changed, 7 insertions(+), 64
Don't round up bridge regions to the next highest size - instead track
alignment explicitly. This should improve the memory layout for
bridge regions.
Also, unused bridge regions will no longer be allocated any space.
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
src/pciinit.c | 41
Patch takes into account PCI bar and ROM regions of PCI bridges
Original patch by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Kevin O'Connor ke...@koconnor.net
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pci.h |1 +
src/pciinit.c |8 +---
2 files changed
Switch to 64bit variable types.
Add parsing 64bit bars.
Original patch by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
src/pciinit.c | 116 ++---
1 files changed, 61 insertions(+), 55 deletions(-)
The pci_region structure is added.
Move setting of bus base address to pci_region_map_entries.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 50 --
1 files changed, 28 insertions(+), 22 deletions(-)
diff --git a/src
Add discovery if bridge region is 64bit is capable.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/src/pciinit.c b/src/pciinit.c
index f185cbd..0d66dbe 100644
--- a/src
Do not store pci region stats - instead calulate the
sum and alignment on demand.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 57
+++--
1 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/src
Do not store pci region stats - instead calulate the
sum and alignment on demand.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 57 +++--
1 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/src
Migrate 64bit entries to 64bit pci regions if they do
not fit in 32bit range.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/config.h |2 ++
src/pciinit.c | 50 ++
2 files changed, 48 insertions(+), 4 deletions(-)
diff
This patch solves issues on Windows guests, when 64bit
BAR's are present. It is also helpful on Linux guests
when use_crs kernel boot option is set.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
src/acpi-dsdt.dsl |7 +
src
A flowed text. Please apply another [10/12] in this series.
On Tue, 2012-04-24 at 18:23 +1200, Alexey Korolev wrote:
Do not store pci region stats - instead calulate the
sum and alignment on demand.
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
src/pciinit.c | 57
On 24/04/12 18:56, Gerd Hoffmann wrote:
On 04/24/12 08:17, Alexey Korolev wrote:
Don't round up bridge regions to the next highest size - instead track
alignment explicitly. This should improve the memory layout for
bridge regions.
This one got mangled too:
Applying: pciinit: Track region
On 25/04/12 13:48, Kevin O'Connor wrote:
On Tue, Apr 24, 2012 at 06:25:39PM +1200, Alexey Korolev wrote:
Migrate 64bit entries to 64bit pci regions if they do
not fit in 32bit range.
[...]
+static void pci_region_migrate_64bit_entries(struct pci_region *from
On 27/04/12 00:45, Kevin O'Connor wrote:
On Wed, Apr 25, 2012 at 05:29:04PM +0200, Gerd Hoffmann wrote:
Issue #1: seabios can't boot from a virtio-scsi disk if the controller
is behind a pci bridge. I think the reason simply is that (according to
the seabios log) only root bus pci devices
Hi,
Tried these patches today on Win2008 x64 guest with 64bit devices.
I've got BSOD on boot. I guess windows don't like changes in _CRS.
On 04/05/12 20:21, Gerd Hoffmann wrote:
Hi,
This patch series makes the PCI I/O windows runtime-configurable via
qemu firmware config interface. Main
Sometime ago I reported an issue about guest OS hang when 64bit BAR present.
http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg03189.html
http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00413.html
Some more investigation has been done, so in this post I'll try to explain why
it
a rule that the
regions which should not be overlapped are added to the
view first (i.e. having highest priority). The patch
also corrects ivshmem bar resource to be overlapable
which is the default for PCI BARs
Signed-off-by: Alexey Korolev alexey.koro...@endace.com
---
hw/ivshmem.c |2
On Wed, Feb 13, 2013 at 11:34:52AM +0100, Jan Kiszka wrote:
On 2013-02-13 11:24, Michael S. Tsirkin wrote:
On Wed, Feb 13, 2013 at 06:06:37PM +1300, Alexey Korolev wrote:
Sometime ago I reported an issue about guest OS hang when 64bit BAR
present.
http://lists.gnu.org/archive/html/qemu
On 13/02/13 23:26, Michael S. Tsirkin wrote:
On Wed, Feb 13, 2013 at 06:14:33PM +1300, Alexey Korolev wrote:
At the moment may_overlap flag of MemoryRegion structure
is ignored by the address range assignment process.
This may lead to guest OS hangs if critical qemu
resources are overlapped
1 - 100 of 114 matches
Mail list logo
