Re: [Qemu-devel] [PULL for-1.8 1/2] pc: disable pci-info

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 26 Nov 2013 16:42:16 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > This doesn't clamp the w32.begin value into [0x80000000, 0xe0000000],
> > which seems wrong.
> 
> Why?  In a 1G guest you can map pci bars at 0x40000000 just fine.
> 
> _CRS in acpi should declare the area where you can map pci bars, and
> that happens to be end-of-ram -> ioapci base.
> 
> Firmware can choose to use a smaller area.  Both seabios and ovmf will
> not map anyting below 0x80000000.  That is just fine.  As long as all
> pci bars get mapped inside the region declared in _CRS things will work.
> 
> While thinking about it:  There is one possible reason to not do it:
> Guest bugs.  IIRC windows doesn't like the 64bit pci window being larger
> than 2G.  Possibly that is an issue with the 32bit window too.  If that
> is the case we should indeed not use w32.begin values smaller than
> 0x8000000.  Igor, any clue?
I saw windows BSOD with present 64-bit CRS only on WS2003/XP
regardless of OS being 32 or 64 bit or CRS size. The newer versions
worked just fine.
Perhaps we shouldn't care about already broken case for soon to be EOLed OS? 

> 
> > Guys, I'm confused and annoyed out of my brains by the divergence here.
> > In my perception Michael, Igor, and Gerd are all proposing different
> > things, and my ideas are either rejected or ignored (even though they
> > occasionally overlap with ideas from others).
> 
> Hmm, as far as I can see there is an agreement that it is qemu's fault,
> the acpi tables need fixing, and ovmf should not need changes any
> changes.
> 
> Mimicing seabios/qemu logic in ovmf can be used as temporary stopgap
> while details are sorted on the qemu side.
> 
> cheers,
>   Gerd
> 
> 


-- 
Regards,
  Igor