[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bi

From: Alexey Korolev
Subject: Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions
Date: Fri, 30 Dec 2011 17:56:06 +1300
User-agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0

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 and
not overlapping with all the normal memory ranges.
Since prefetchable memory is described by one record, we must avoid the 
when 32bit and 64bit prefetchable regions are present within one secondary bus.
How do we avoid this? Assume we have two devices:
a 32 bit and a 64 bit one, behind a bridge.
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 this.
2. Put the 32 bit one in the non-prefetcheable range
I'd rather not do this. Bios should not change memory region types.
It will confuse guest OS drivers.
It shouldn't, it's a legal behavious.
Prefetcheable BAR allows certain optimizations but does not
require them.
Well it is really difficult to say what is a "legal behavior".
Yes it is legal behavior for PCI operations. But it could be a problem in software . I won't be surprised if a driver fail to start if we substitute the regions. It will be very hard
to check all possible cases.

reply via email to

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