On Tue, Nov 26, 2013 at 04:42:16PM +0100, Gerd Hoffmann 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 think the issues are all around 64 bit. It's not hard to test. > > 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 >
