On 09/14/2011 11:06 PM, Blue Swirl wrote:
On Wed, Sep 14, 2011 at 8:35 AM, Avi Kivity<a...@redhat.com> wrote:
> On 09/14/2011 11:27 AM, Alexander Graf wrote:
>>
>> On 14.09.2011, at 10:24, Jan Kiszka wrote:
>>
>> > On 2011-09-14 10:22, Avi Kivity wrote:
>> >> On 09/14/2011 11:20 AM, Jan Kiszka wrote:
>> >>>>
>> >>>> Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it
>> >>>> supposed to be mapped?
>> >>>
>> >>> ...but not all PCI bridges make use of this feature / forward legacy
>> >>> requests.
>> >>>
>> >>
>> >> Then this should be fixed in the bridge?
>> >
>> > Yes, it's a PPC bug.
>>
>> So how does the bridge not forward it then?
>>
>
> I expect that currently vga adds the region to pci_address_space(). We need
> to create a pci_address_space_vga() function that returns a region for vga
> to use. Then add or remove the region to pci_address_space(), within the
> bridge code, depending on whether the bridge forwards vga accesses or not.
Similar treatment should be also needed for VGA IO ports 0x3b0 etc.
> (assuming I understood the problem correctly - not sure)
I think you did.
Maybe, but the solution can't be right. The bridge can't distinguish
between a BAR mapped at 0xa0000 and the vga device claiming accesses to
0xa0000. Is this what is happening?
The current pci bridge implementation (440fx) uses an alias to
instantiate pci 0xa0000-0xc0000 at the same address in the host address
space. If you disable it, those addresses map back to RAM - but there
is no distinction between a BAR at that address and a VGA card at that
address.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.