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

[Alexey Korolev <alexey.korolev@endace.com>]

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 situations
>>>> 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.