| Message ID | 1432568042-19553-24-git-send-email-marcel@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: > PXB does not work with unsupported bioses, but should > not interfere with normal OS operation. > We don't ship them anymore, but it's reasonable > to keep the work-around until we update the bios in qemu. We already did, did we not? > Fix this by not adding PXB mem/IO chunks to _CRS > if they weren't configured by BIOS. > > Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> > --- > hw/i386/acpi-build.c | 87 ++++++++++++++++++++++++++++++++++------------------ > 1 file changed, 58 insertions(+), 29 deletions(-) > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index f7d2c80..895d64c 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -784,6 +784,14 @@ static Aml *build_crs(PCIHostState *host, > range_base = r->addr; > range_limit = r->addr + r->size - 1; > > + /* > + * Work-around for old bioses > + * that do not support multiple root buses > + */ > + if (!range_base || range_base > range_limit) { > + continue; > + } > + > if (r->type & PCI_BASE_ADDRESS_SPACE_IO) { > aml_append(crs, > aml_word_io(aml_min_fixed, aml_max_fixed, > @@ -817,45 +825,66 @@ static Aml *build_crs(PCIHostState *host, > > range_base = pci_bridge_get_base(dev, PCI_BASE_ADDRESS_SPACE_IO); > range_limit = pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_SPACE_IO); > - aml_append(crs, > - aml_word_io(aml_min_fixed, aml_max_fixed, > - aml_pos_decode, aml_entire_range, > - 0, > - range_base, > - range_limit, > - 0, > - range_limit - range_base + 1)); > - crs_range_insert(io_ranges, range_base, range_limit); > + > + /* > + * Work-around for old bioses > + * that do not support multiple root buses > + */ > + if (range_base || range_base > range_limit) { > + aml_append(crs, > + aml_word_io(aml_min_fixed, aml_max_fixed, > + aml_pos_decode, aml_entire_range, > + 0, > + range_base, > + range_limit, > + 0, > + range_limit - range_base + 1)); > + crs_range_insert(io_ranges, range_base, range_limit); > + } > > range_base = > pci_bridge_get_base(dev, PCI_BASE_ADDRESS_SPACE_MEMORY); > range_limit = > pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_SPACE_MEMORY); > - aml_append(crs, > - aml_dword_memory(aml_pos_decode, aml_min_fixed, > - aml_max_fixed, aml_non_cacheable, > - aml_ReadWrite, > - 0, > - range_base, > - range_limit, > - 0, > - range_limit - range_base + 1)); > - crs_range_insert(mem_ranges, range_base, range_limit); > + > + /* > + * Work-around for old bioses > + * that do not support multiple root buses > + */ > + if (range_base || range_base > range_limit) { > + aml_append(crs, > + aml_dword_memory(aml_pos_decode, aml_min_fixed, > + aml_max_fixed, aml_non_cacheable, > + aml_ReadWrite, > + 0, > + range_base, > + range_limit, > + 0, > + range_limit - range_base + 1)); > + crs_range_insert(mem_ranges, range_base, range_limit); > + } > > range_base = > pci_bridge_get_base(dev, PCI_BASE_ADDRESS_MEM_PREFETCH); > range_limit = > pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_MEM_PREFETCH); > - aml_append(crs, > - aml_dword_memory(aml_pos_decode, aml_min_fixed, > - aml_max_fixed, aml_non_cacheable, > - aml_ReadWrite, > - 0, > - range_base, > - range_limit, > - 0, > - range_limit - range_base + 1)); > - crs_range_insert(mem_ranges, range_base, range_limit); > + > + /* > + * Work-around for old bioses > + * that do not support multiple root buses > + */ > + if (range_base || range_base > range_limit) { > + aml_append(crs, > + aml_dword_memory(aml_pos_decode, aml_min_fixed, > + aml_max_fixed, aml_non_cacheable, > + aml_ReadWrite, > + 0, > + range_base, > + range_limit, > + 0, > + range_limit - range_base + 1)); > + crs_range_insert(mem_ranges, range_base, range_limit); > + } > } > } > > -- > 2.1.0 >
On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: > On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: >> PXB does not work with unsupported bioses, but should >> not interfere with normal OS operation. >> We don't ship them anymore, but it's reasonable >> to keep the work-around until we update the bios in qemu. > > We already did, did we not? Yes, we did, but Gerd preferred to keep this patch around. Adding him to thread. CC: Gerd Hoffmann <kraxel@redhat.com> Thanks, Marcel > >> Fix this by not adding PXB mem/IO chunks to _CRS >> if they weren't configured by BIOS. >> >> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> >> --- >> hw/i386/acpi-build.c | 87 ++++++++++++++++++++++++++++++++++------------------ >> 1 file changed, 58 insertions(+), 29 deletions(-) >> >> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c >> index f7d2c80..895d64c 100644 >> --- a/hw/i386/acpi-build.c >> +++ b/hw/i386/acpi-build.c >> @@ -784,6 +784,14 @@ static Aml *build_crs(PCIHostState *host, >> range_base = r->addr; >> range_limit = r->addr + r->size - 1; >> >> + /* >> + * Work-around for old bioses >> + * that do not support multiple root buses >> + */ >> + if (!range_base || range_base > range_limit) { >> + continue; >> + } >> + >> if (r->type & PCI_BASE_ADDRESS_SPACE_IO) { >> aml_append(crs, >> aml_word_io(aml_min_fixed, aml_max_fixed, >> @@ -817,45 +825,66 @@ static Aml *build_crs(PCIHostState *host, >> >> range_base = pci_bridge_get_base(dev, PCI_BASE_ADDRESS_SPACE_IO); >> range_limit = pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_SPACE_IO); >> - aml_append(crs, >> - aml_word_io(aml_min_fixed, aml_max_fixed, >> - aml_pos_decode, aml_entire_range, >> - 0, >> - range_base, >> - range_limit, >> - 0, >> - range_limit - range_base + 1)); >> - crs_range_insert(io_ranges, range_base, range_limit); >> + >> + /* >> + * Work-around for old bioses >> + * that do not support multiple root buses >> + */ >> + if (range_base || range_base > range_limit) { >> + aml_append(crs, >> + aml_word_io(aml_min_fixed, aml_max_fixed, >> + aml_pos_decode, aml_entire_range, >> + 0, >> + range_base, >> + range_limit, >> + 0, >> + range_limit - range_base + 1)); >> + crs_range_insert(io_ranges, range_base, range_limit); >> + } >> >> range_base = >> pci_bridge_get_base(dev, PCI_BASE_ADDRESS_SPACE_MEMORY); >> range_limit = >> pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_SPACE_MEMORY); >> - aml_append(crs, >> - aml_dword_memory(aml_pos_decode, aml_min_fixed, >> - aml_max_fixed, aml_non_cacheable, >> - aml_ReadWrite, >> - 0, >> - range_base, >> - range_limit, >> - 0, >> - range_limit - range_base + 1)); >> - crs_range_insert(mem_ranges, range_base, range_limit); >> + >> + /* >> + * Work-around for old bioses >> + * that do not support multiple root buses >> + */ >> + if (range_base || range_base > range_limit) { >> + aml_append(crs, >> + aml_dword_memory(aml_pos_decode, aml_min_fixed, >> + aml_max_fixed, aml_non_cacheable, >> + aml_ReadWrite, >> + 0, >> + range_base, >> + range_limit, >> + 0, >> + range_limit - range_base + 1)); >> + crs_range_insert(mem_ranges, range_base, range_limit); >> + } >> >> range_base = >> pci_bridge_get_base(dev, PCI_BASE_ADDRESS_MEM_PREFETCH); >> range_limit = >> pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_MEM_PREFETCH); >> - aml_append(crs, >> - aml_dword_memory(aml_pos_decode, aml_min_fixed, >> - aml_max_fixed, aml_non_cacheable, >> - aml_ReadWrite, >> - 0, >> - range_base, >> - range_limit, >> - 0, >> - range_limit - range_base + 1)); >> - crs_range_insert(mem_ranges, range_base, range_limit); >> + >> + /* >> + * Work-around for old bioses >> + * that do not support multiple root buses >> + */ >> + if (range_base || range_base > range_limit) { >> + aml_append(crs, >> + aml_dword_memory(aml_pos_decode, aml_min_fixed, >> + aml_max_fixed, aml_non_cacheable, >> + aml_ReadWrite, >> + 0, >> + range_base, >> + range_limit, >> + 0, >> + range_limit - range_base + 1)); >> + crs_range_insert(mem_ranges, range_base, range_limit); >> + } >> } >> } >> >> -- >> 2.1.0 >>
On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: > On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: > > On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: > >> PXB does not work with unsupported bioses, but should > >> not interfere with normal OS operation. > >> We don't ship them anymore, but it's reasonable > >> to keep the work-around until we update the bios in qemu. > > > > We already did, did we not? > Yes, we did, but Gerd preferred to keep this patch around. > Adding him to thread. seabios bundled with qemu isn't the only possible firmware. We have ovmf, coreboot, qboot. You might boot with old seabios for whatever reasons (say bisecting down something). IMO qemu should deal with pxe not being initialized by the firmware in a sensible way, for robustness reasons. cheers, Gerd
On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: > On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: > > On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: > > > On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: > > >> PXB does not work with unsupported bioses, but should > > >> not interfere with normal OS operation. > > >> We don't ship them anymore, but it's reasonable > > >> to keep the work-around until we update the bios in qemu. > > > > > > We already did, did we not? > > Yes, we did, but Gerd preferred to keep this patch around. > > Adding him to thread. > > seabios bundled with qemu isn't the only possible firmware. > > We have ovmf, coreboot, qboot. ovmf is especially interesting. Marcel, did you look at what happens with pxb and ovmf? > You might boot with old seabios for > whatever reasons (say bisecting down something). But then you won't have pxb, will you? > IMO qemu should deal > with pxe not being initialized by the firmware in a sensible way, for > robustness reasons. > > cheers, > Gerd >
On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: > On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: >>>>> PXB does not work with unsupported bioses, but should >>>>> not interfere with normal OS operation. >>>>> We don't ship them anymore, but it's reasonable >>>>> to keep the work-around until we update the bios in qemu. >>>> >>>> We already did, did we not? >>> Yes, we did, but Gerd preferred to keep this patch around. >>> Adding him to thread. >> >> seabios bundled with qemu isn't the only possible firmware. >> >> We have ovmf, coreboot, qboot. > > ovmf is especially interesting. Marcel, did you look at what > happens with pxb and ovmf? No, I talked to Laszlo about it, he said ovmf is not there yet. OVMF will not query the extra buses, so the devices on the extra bus will not be visible. Adding him to the thread. Thanks, Marcel > >> You might boot with old seabios for >> whatever reasons (say bisecting down something). > > But then you won't have pxb, will you? > >> IMO qemu should deal >> with pxe not being initialized by the firmware in a sensible way, for >> robustness reasons. >> >> cheers, >> Gerd >>
On Mo, 2015-06-01 at 14:17 +0200, Michael S. Tsirkin wrote: > On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: > > On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: > > > On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: > > > > On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: > > > >> PXB does not work with unsupported bioses, but should > > > >> not interfere with normal OS operation. > > > >> We don't ship them anymore, but it's reasonable > > > >> to keep the work-around until we update the bios in qemu. > > > > > > > > We already did, did we not? > > > Yes, we did, but Gerd preferred to keep this patch around. > > > Adding him to thread. > > > > seabios bundled with qemu isn't the only possible firmware. > > > > We have ovmf, coreboot, qboot. > > ovmf is especially interesting. Marcel, did you look at what > happens with pxb and ovmf? > > > You might boot with old seabios for > > whatever reasons (say bisecting down something). > > But then you won't have pxb, will you? Devices behind pxb wouldn't be working because they didn't got resources assigned, yes. But at least the resources for the primary root bus devices would not be screwed up like they are without this patch (IIRC). cheers, Gerd
On Mon, Jun 01, 2015 at 02:24:02PM +0200, Gerd Hoffmann wrote: > On Mo, 2015-06-01 at 14:17 +0200, Michael S. Tsirkin wrote: > > On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: > > > On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: > > > > On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: > > > > > On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: > > > > >> PXB does not work with unsupported bioses, but should > > > > >> not interfere with normal OS operation. > > > > >> We don't ship them anymore, but it's reasonable > > > > >> to keep the work-around until we update the bios in qemu. > > > > > > > > > > We already did, did we not? > > > > Yes, we did, but Gerd preferred to keep this patch around. > > > > Adding him to thread. > > > > > > seabios bundled with qemu isn't the only possible firmware. > > > > > > We have ovmf, coreboot, qboot. > > > > ovmf is especially interesting. Marcel, did you look at what > > happens with pxb and ovmf? > > > > > You might boot with old seabios for > > > whatever reasons (say bisecting down something). > > > > But then you won't have pxb, will you? > > Devices behind pxb wouldn't be working because they didn't got resources > assigned, yes. I mean that there's no way to get old seabios+pxb when bisecting. > But at least the resources for the primary root bus > devices would not be screwed up like they are without this patch (IIRC). > > cheers, > Gerd >
On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: > On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: > >On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: > >>On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: > >>>On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: > >>>>On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: > >>>>>PXB does not work with unsupported bioses, but should > >>>>>not interfere with normal OS operation. > >>>>>We don't ship them anymore, but it's reasonable > >>>>>to keep the work-around until we update the bios in qemu. > >>>> > >>>>We already did, did we not? > >>>Yes, we did, but Gerd preferred to keep this patch around. > >>>Adding him to thread. > >> > >>seabios bundled with qemu isn't the only possible firmware. > >> > >>We have ovmf, coreboot, qboot. > > > >ovmf is especially interesting. Marcel, did you look at what > >happens with pxb and ovmf? > No, I talked to Laszlo about it, he said ovmf is not there yet. > OVMF will not query the extra buses, so the devices on the extra bus will not be visible. > Adding him to the thread. > > Thanks, > Marcel But does OVMF need this specific patch? > > > >>You might boot with old seabios for > >>whatever reasons (say bisecting down something). > > > >But then you won't have pxb, will you? > > > >>IMO qemu should deal > >>with pxe not being initialized by the firmware in a sensible way, for > >>robustness reasons. > >> > >>cheers, > >> Gerd > >>
Hi, > > Devices behind pxb wouldn't be working because they didn't got resources > > assigned, yes. > > I mean that there's no way to get old seabios+pxb when bisecting. When bisecting in qemu (with bundled seabios) yes. But when bisection in seabios ... Anyway, at the end of the day it doesn't matter much why exactly the firmware didn't setup the pxb. I think that qemu should handle that case gracefully no matter what. cheers, Gerd
On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote: > On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: >> On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: >>> On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >>>> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>>>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: >>>>>>> PXB does not work with unsupported bioses, but should >>>>>>> not interfere with normal OS operation. >>>>>>> We don't ship them anymore, but it's reasonable >>>>>>> to keep the work-around until we update the bios in qemu. >>>>>> >>>>>> We already did, did we not? >>>>> Yes, we did, but Gerd preferred to keep this patch around. >>>>> Adding him to thread. >>>> >>>> seabios bundled with qemu isn't the only possible firmware. >>>> >>>> We have ovmf, coreboot, qboot. >>> >>> ovmf is especially interesting. Marcel, did you look at what >>> happens with pxb and ovmf? >> No, I talked to Laszlo about it, he said ovmf is not there yet. >> OVMF will not query the extra buses, so the devices on the extra bus will not be visible. >> Adding him to the thread. >> >> Thanks, >> Marcel > > But does OVMF need this specific patch? I don't think so because more than likely it doesn't scan for the extra buses, so it will not try to configure these devices. Laszlo, am I right? Thanks, Marcel > >>> >>>> You might boot with old seabios for >>>> whatever reasons (say bisecting down something). >>> >>> But then you won't have pxb, will you? >>> >>>> IMO qemu should deal >>>> with pxe not being initialized by the firmware in a sensible way, for >>>> robustness reasons. >>>> >>>> cheers, >>>> Gerd >>>> >
On Mon, Jun 01, 2015 at 02:57:02PM +0200, Gerd Hoffmann wrote: > Hi, > > > > Devices behind pxb wouldn't be working because they didn't got resources > > > assigned, yes. > > > > I mean that there's no way to get old seabios+pxb when bisecting. > > When bisecting in qemu (with bundled seabios) yes. > But when bisection in seabios ... > > Anyway, at the end of the day it doesn't matter much why exactly the > firmware didn't setup the pxb. I think that qemu should handle that > case gracefully no matter what. > > cheers, > Gerd > Testing end>base is fine. What worries me is the !base test which isn't really coming from spec since 0 is a valid pci address. Do things still work if we drop that one?
On 06/01/15 15:05, Marcel Apfelbaum wrote: > On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote: >> On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: >>> On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: >>>> On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >>>>> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>>>>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>>>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: >>>>>>>> PXB does not work with unsupported bioses, but should >>>>>>>> not interfere with normal OS operation. >>>>>>>> We don't ship them anymore, but it's reasonable >>>>>>>> to keep the work-around until we update the bios in qemu. >>>>>>> >>>>>>> We already did, did we not? >>>>>> Yes, we did, but Gerd preferred to keep this patch around. >>>>>> Adding him to thread. >>>>> >>>>> seabios bundled with qemu isn't the only possible firmware. >>>>> >>>>> We have ovmf, coreboot, qboot. >>>> >>>> ovmf is especially interesting. Marcel, did you look at what >>>> happens with pxb and ovmf? >>> No, I talked to Laszlo about it, he said ovmf is not there yet. >>> OVMF will not query the extra buses, so the devices on the extra bus >>> will not be visible. >>> Adding him to the thread. >>> >>> Thanks, >>> Marcel >> >> But does OVMF need this specific patch? > I don't think so because more than likely it doesn't scan for the extra > buses, > so it will not try to configure these devices. > Laszlo, am I right? Well, I don't know. :) First, I'm not seeing the specific patch in question (can you pls send me a URL into the web archive, or a Message-Id?) Second, recently I tested OVMF on Q35, but not just with a simple / usual command line invocation -- I tested it on a Q35 machine configured by libvirt. That's a very different animal. While it exposed a problem in OVMF's own boot order processing: https://github.com/tianocore/edk2/commit/feca17fa4b I was surprised to see that the PCI bus driver enumerated devices behind two bridges no less without any problems. So, bridges off the one root bridge should work, but several root bridges probably won't. (Exposing root bridges is the responsibility of another driver, and they are not enumerable in the usual way.) Thanks Laszlo
On 06/01/2015 04:28 PM, Laszlo Ersek wrote: > On 06/01/15 15:05, Marcel Apfelbaum wrote: >> On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote: >>> On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: >>>> On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: >>>>> On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >>>>>> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>>>>>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>>>>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: >>>>>>>>> PXB does not work with unsupported bioses, but should >>>>>>>>> not interfere with normal OS operation. >>>>>>>>> We don't ship them anymore, but it's reasonable >>>>>>>>> to keep the work-around until we update the bios in qemu. >>>>>>>> >>>>>>>> We already did, did we not? >>>>>>> Yes, we did, but Gerd preferred to keep this patch around. >>>>>>> Adding him to thread. >>>>>> >>>>>> seabios bundled with qemu isn't the only possible firmware. >>>>>> >>>>>> We have ovmf, coreboot, qboot. >>>>> >>>>> ovmf is especially interesting. Marcel, did you look at what >>>>> happens with pxb and ovmf? >>>> No, I talked to Laszlo about it, he said ovmf is not there yet. >>>> OVMF will not query the extra buses, so the devices on the extra bus >>>> will not be visible. >>>> Adding him to the thread. >>>> >>>> Thanks, >>>> Marcel >>> >>> But does OVMF need this specific patch? >> I don't think so because more than likely it doesn't scan for the extra >> buses, >> so it will not try to configure these devices. >> Laszlo, am I right? > > Well, I don't know. :) > > First, I'm not seeing the specific patch in question (can you pls send > me a URL into the web archive, or a Message-Id?) Well, there are a few patches, all this series, You can look for patches: 13/24 hw/acpi: add support for i440fx 'snooping' root busses -> acpi declarations 18/24 hw/pci: introduce PCI Expander Bridge (PXB) 19/24 hw/pci: inform bios if the system has extra pci root buses Basically we add the pxb resources to ACPI tables and then inform BIOS using etc/extra-pci-roots fw_config file that he has extra roots to scan. If the OVMF only looks for bus 0 and does not scan all possible buses it will not see PXB's root bus Thanks, Marcel > Second, recently I tested OVMF on Q35, but not just with a simple / > usual command line invocation -- I tested it on a Q35 machine configured > by libvirt. That's a very different animal. > > While it exposed a problem in OVMF's own boot order processing: > > https://github.com/tianocore/edk2/commit/feca17fa4b > > I was surprised to see that the PCI bus driver enumerated devices behind > two bridges no less without any problems. So, bridges off the one root > bridge should work, but several root bridges probably won't. (Exposing > root bridges is the responsibility of another driver, and they are not > enumerable in the usual way.) > > Thanks > Laszlo >
On 06/01/15 15:48, Marcel Apfelbaum wrote: > On 06/01/2015 04:28 PM, Laszlo Ersek wrote: >> On 06/01/15 15:05, Marcel Apfelbaum wrote: >>> On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote: >>>> On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: >>>>> On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: >>>>>> On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >>>>>>> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>>>>>>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>>>>>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: >>>>>>>>>> PXB does not work with unsupported bioses, but should >>>>>>>>>> not interfere with normal OS operation. >>>>>>>>>> We don't ship them anymore, but it's reasonable >>>>>>>>>> to keep the work-around until we update the bios in qemu. >>>>>>>>> >>>>>>>>> We already did, did we not? >>>>>>>> Yes, we did, but Gerd preferred to keep this patch around. >>>>>>>> Adding him to thread. >>>>>>> >>>>>>> seabios bundled with qemu isn't the only possible firmware. >>>>>>> >>>>>>> We have ovmf, coreboot, qboot. >>>>>> >>>>>> ovmf is especially interesting. Marcel, did you look at what >>>>>> happens with pxb and ovmf? >>>>> No, I talked to Laszlo about it, he said ovmf is not there yet. >>>>> OVMF will not query the extra buses, so the devices on the extra bus >>>>> will not be visible. >>>>> Adding him to the thread. >>>>> >>>>> Thanks, >>>>> Marcel >>>> >>>> But does OVMF need this specific patch? >>> I don't think so because more than likely it doesn't scan for the extra >>> buses, >>> so it will not try to configure these devices. >>> Laszlo, am I right? >> >> Well, I don't know. :) >> >> First, I'm not seeing the specific patch in question (can you pls send >> me a URL into the web archive, or a Message-Id?) > Well, there are a few patches, all this series, > You can look for patches: > 13/24 hw/acpi: add support for i440fx 'snooping' root busses -> acpi > declarations > 18/24 hw/pci: introduce PCI Expander Bridge (PXB) > 19/24 hw/pci: inform bios if the system has extra pci root buses > > Basically we add the pxb resources to ACPI tables and then inform BIOS > using > etc/extra-pci-roots fw_config file that he has extra roots to scan. > > If the OVMF only looks for bus 0 and does not scan all possible buses > it will not see PXB's root bus I don't know enough about PCI to reply sensibly. I can tell you that the bus range in OVMF, from "mResAperture" in "PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c", is [0..0xff], inclusive. This bus range is then exposed in the function StartBusEnumeration() to the caller (which is the PCI bus driver), as an output parameter. The StartBusEnumeration() function has the following leading comment: > Sets up the specified PCI root bridge for the bus enumeration process. > > This member function sets up the root bridge for bus enumeration and > returns the PCI bus range over which the search should be performed > in ACPI 2.0 resource descriptor format. So, there's a chance that if those busses actually exist on the virtual hardware, the drivers included by OVMF from the generic edk2 source "will just work". It is also possible that OVMF will notice no change at all. Do you have a public branch, and a matching command line? The PCI enumeration / resource allocation spews a bunch of messages in OVMF, so if you placed (on the QEMU command line) some devices on one of these nonzero buses, then their enumeration / resource allocation, determined from the log, could serve as evidence. (I think this should be testable on a non-NUMA host, and without passthrough devices as well.) Also, I checked the actual code hunks & message body for this patch (ie. 23/24) on the web. Looks like I should be able to dump the ACPI tables in the guest, and get those dumps to you for verification. OVMF does delay the ACPI download until after PCI enumeration, so the state of the guest _CRS would be (negative or positive) proof, not lack of proof. Thanks Laszlo > Thanks, > Marcel > > >> Second, recently I tested OVMF on Q35, but not just with a simple / >> usual command line invocation -- I tested it on a Q35 machine configured >> by libvirt. That's a very different animal. >> >> While it exposed a problem in OVMF's own boot order processing: >> >> https://github.com/tianocore/edk2/commit/feca17fa4b >> >> I was surprised to see that the PCI bus driver enumerated devices behind >> two bridges no less without any problems. So, bridges off the one root >> bridge should work, but several root bridges probably won't. (Exposing >> root bridges is the responsibility of another driver, and they are not >> enumerable in the usual way.) >> >> Thanks >> Laszlo >> >
On 06/01/2015 06:37 PM, Laszlo Ersek wrote: > On 06/01/15 15:48, Marcel Apfelbaum wrote: >> On 06/01/2015 04:28 PM, Laszlo Ersek wrote: >>> On 06/01/15 15:05, Marcel Apfelbaum wrote: >>>> On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote: >>>>> On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: >>>>>> On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: >>>>>>> On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >>>>>>>> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>>>>>>>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>>>>>>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote: >>>>>>>>>>> PXB does not work with unsupported bioses, but should >>>>>>>>>>> not interfere with normal OS operation. >>>>>>>>>>> We don't ship them anymore, but it's reasonable >>>>>>>>>>> to keep the work-around until we update the bios in qemu. >>>>>>>>>> >>>>>>>>>> We already did, did we not? >>>>>>>>> Yes, we did, but Gerd preferred to keep this patch around. >>>>>>>>> Adding him to thread. >>>>>>>> >>>>>>>> seabios bundled with qemu isn't the only possible firmware. >>>>>>>> >>>>>>>> We have ovmf, coreboot, qboot. >>>>>>> >>>>>>> ovmf is especially interesting. Marcel, did you look at what >>>>>>> happens with pxb and ovmf? >>>>>> No, I talked to Laszlo about it, he said ovmf is not there yet. >>>>>> OVMF will not query the extra buses, so the devices on the extra bus >>>>>> will not be visible. >>>>>> Adding him to the thread. >>>>>> >>>>>> Thanks, >>>>>> Marcel >>>>> >>>>> But does OVMF need this specific patch? >>>> I don't think so because more than likely it doesn't scan for the extra >>>> buses, >>>> so it will not try to configure these devices. >>>> Laszlo, am I right? >>> >>> Well, I don't know. :) >>> >>> First, I'm not seeing the specific patch in question (can you pls send >>> me a URL into the web archive, or a Message-Id?) >> Well, there are a few patches, all this series, >> You can look for patches: >> 13/24 hw/acpi: add support for i440fx 'snooping' root busses -> acpi >> declarations >> 18/24 hw/pci: introduce PCI Expander Bridge (PXB) >> 19/24 hw/pci: inform bios if the system has extra pci root buses >> >> Basically we add the pxb resources to ACPI tables and then inform BIOS >> using >> etc/extra-pci-roots fw_config file that he has extra roots to scan. >> >> If the OVMF only looks for bus 0 and does not scan all possible buses >> it will not see PXB's root bus > > I don't know enough about PCI to reply sensibly. > > I can tell you that the bus range in OVMF, from "mResAperture" in > "PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c", is [0..0xff], inclusive. > > This bus range is then exposed in the function StartBusEnumeration() to > the caller (which is the PCI bus driver), as an output parameter. The > StartBusEnumeration() function has the following leading comment: > >> Sets up the specified PCI root bridge for the bus enumeration process. >> >> This member function sets up the root bridge for bus enumeration and >> returns the PCI bus range over which the search should be performed >> in ACPI 2.0 resource descriptor format. > > So, there's a chance that if those busses actually exist on the virtual > hardware, the drivers included by OVMF from the generic edk2 source > "will just work". It is also possible that OVMF will notice no change at > all. > > Do you have a public branch, and a matching command line? The PCI > enumeration / resource allocation spews a bunch of messages in OVMF, so > if you placed (on the QEMU command line) some devices on one of these > nonzero buses, then their enumeration / resource allocation, determined > from the log, could serve as evidence. (I think this should be testable > on a non-NUMA host, and without passthrough devices as well.) > > Also, I checked the actual code hunks & message body for this patch (ie. > 23/24) on the web. Looks like I should be able to dump the ACPI tables > in the guest, and get those dumps to you for verification. OVMF does > delay the ACPI download until after PCI enumeration, so the state of the > guest _CRS would be (negative or positive) proof, not lack of proof. Hi Laszlo, I am sorry for the late reply. Can you please check using mst branch? git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git pxb Just add to the regular command line: -device pxb,id=bridge1,bus_nr=4 -netdev user,id=u -device e1000,id=net2,bus=bridge1,netdev=u,addr=1 Thanks a lot for the help, we mainly want to know if there is an architecture issue that will prevent the PXB to work with OVMF. Marcel > > Thanks > Laszlo > >> Thanks, >> Marcel >> >> >>> Second, recently I tested OVMF on Q35, but not just with a simple / >>> usual command line invocation -- I tested it on a Q35 machine configured >>> by libvirt. That's a very different animal. >>> >>> While it exposed a problem in OVMF's own boot order processing: >>> >>> https://github.com/tianocore/edk2/commit/feca17fa4b >>> >>> I was surprised to see that the PCI bus driver enumerated devices behind >>> two bridges no less without any problems. So, bridges off the one root >>> bridge should work, but several root bridges probably won't. (Exposing >>> root bridges is the responsibility of another driver, and they are not >>> enumerable in the usual way.) >>> >>> Thanks >>> Laszlo >>> >> >
On 06/02/15 13:37, Marcel Apfelbaum wrote: > On 06/01/2015 06:37 PM, Laszlo Ersek wrote: >> On 06/01/15 15:48, Marcel Apfelbaum wrote: >>> On 06/01/2015 04:28 PM, Laszlo Ersek wrote: >>>> On 06/01/15 15:05, Marcel Apfelbaum wrote: >>>>> On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote: >>>>>> On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: >>>>>>> On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: >>>>>>>> On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >>>>>>>>> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>>>>>>>>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>>>>>>>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum >>>>>>>>>>> wrote: >>>>>>>>>>>> PXB does not work with unsupported bioses, but should >>>>>>>>>>>> not interfere with normal OS operation. >>>>>>>>>>>> We don't ship them anymore, but it's reasonable >>>>>>>>>>>> to keep the work-around until we update the bios in qemu. >>>>>>>>>>> >>>>>>>>>>> We already did, did we not? >>>>>>>>>> Yes, we did, but Gerd preferred to keep this patch around. >>>>>>>>>> Adding him to thread. >>>>>>>>> >>>>>>>>> seabios bundled with qemu isn't the only possible firmware. >>>>>>>>> >>>>>>>>> We have ovmf, coreboot, qboot. >>>>>>>> >>>>>>>> ovmf is especially interesting. Marcel, did you look at what >>>>>>>> happens with pxb and ovmf? >>>>>>> No, I talked to Laszlo about it, he said ovmf is not there yet. >>>>>>> OVMF will not query the extra buses, so the devices on the extra bus >>>>>>> will not be visible. >>>>>>> Adding him to the thread. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcel >>>>>> >>>>>> But does OVMF need this specific patch? >>>>> I don't think so because more than likely it doesn't scan for the >>>>> extra >>>>> buses, >>>>> so it will not try to configure these devices. >>>>> Laszlo, am I right? >>>> >>>> Well, I don't know. :) >>>> >>>> First, I'm not seeing the specific patch in question (can you pls send >>>> me a URL into the web archive, or a Message-Id?) >>> Well, there are a few patches, all this series, >>> You can look for patches: >>> 13/24 hw/acpi: add support for i440fx 'snooping' root busses -> acpi >>> declarations >>> 18/24 hw/pci: introduce PCI Expander Bridge (PXB) >>> 19/24 hw/pci: inform bios if the system has extra pci root buses >>> >>> Basically we add the pxb resources to ACPI tables and then inform BIOS >>> using >>> etc/extra-pci-roots fw_config file that he has extra roots to scan. >>> >>> If the OVMF only looks for bus 0 and does not scan all possible buses >>> it will not see PXB's root bus >> >> I don't know enough about PCI to reply sensibly. >> >> I can tell you that the bus range in OVMF, from "mResAperture" in >> "PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c", is [0..0xff], >> inclusive. >> >> This bus range is then exposed in the function StartBusEnumeration() to >> the caller (which is the PCI bus driver), as an output parameter. The >> StartBusEnumeration() function has the following leading comment: >> >>> Sets up the specified PCI root bridge for the bus enumeration process. >>> >>> This member function sets up the root bridge for bus enumeration and >>> returns the PCI bus range over which the search should be performed >>> in ACPI 2.0 resource descriptor format. >> >> So, there's a chance that if those busses actually exist on the virtual >> hardware, the drivers included by OVMF from the generic edk2 source >> "will just work". It is also possible that OVMF will notice no change at >> all. >> >> Do you have a public branch, and a matching command line? The PCI >> enumeration / resource allocation spews a bunch of messages in OVMF, so >> if you placed (on the QEMU command line) some devices on one of these >> nonzero buses, then their enumeration / resource allocation, determined >> from the log, could serve as evidence. (I think this should be testable >> on a non-NUMA host, and without passthrough devices as well.) >> >> Also, I checked the actual code hunks & message body for this patch (ie. >> 23/24) on the web. Looks like I should be able to dump the ACPI tables >> in the guest, and get those dumps to you for verification. OVMF does >> delay the ACPI download until after PCI enumeration, so the state of the >> guest _CRS would be (negative or positive) proof, not lack of proof. > > Hi Laszlo, > I am sorry for the late reply. > Can you please check using mst branch? > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git pxb > Just add to the regular command line: > -device pxb,id=bridge1,bus_nr=4 -netdev user,id=u -device > e1000,id=net2,bus=bridge1,netdev=u,addr=1 > > Thanks a lot for the help, we mainly want to know if there is > an architecture issue that will prevent the PXB to work with OVMF. > Marcel I wrote a horrible patch that allowed OVMF to enumerate the e1000 NIC on the pxb, so I guess there should be no "architectural issue" preventing OVMF from using this device. Of course, making good / dynamic use of this stuff is light years away. I'll respond with more details in the thread you started on edk2-devel: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15147 Thanks Laszlo >>> >>>> Second, recently I tested OVMF on Q35, but not just with a simple / >>>> usual command line invocation -- I tested it on a Q35 machine >>>> configured >>>> by libvirt. That's a very different animal. >>>> >>>> While it exposed a problem in OVMF's own boot order processing: >>>> >>>> https://github.com/tianocore/edk2/commit/feca17fa4b >>>> >>>> I was surprised to see that the PCI bus driver enumerated devices >>>> behind >>>> two bridges no less without any problems. So, bridges off the one root >>>> bridge should work, but several root bridges probably won't. (Exposing >>>> root bridges is the responsibility of another driver, and they are not >>>> enumerable in the usual way.) >>>> >>>> Thanks >>>> Laszlo >>>> >>> >> >
On 06/02/2015 06:24 PM, Laszlo Ersek wrote: > On 06/02/15 13:37, Marcel Apfelbaum wrote: >> On 06/01/2015 06:37 PM, Laszlo Ersek wrote: >>> On 06/01/15 15:48, Marcel Apfelbaum wrote: >>>> On 06/01/2015 04:28 PM, Laszlo Ersek wrote: >>>>> On 06/01/15 15:05, Marcel Apfelbaum wrote: >>>>>> On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote: >>>>>>> On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote: >>>>>>>> On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote: >>>>>>>>> On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote: >>>>>>>>>> On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote: >>>>>>>>>>> On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote: >>>>>>>>>>>> On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum >>>>>>>>>>>> wrote: >>>>>>>>>>>>> PXB does not work with unsupported bioses, but should >>>>>>>>>>>>> not interfere with normal OS operation. >>>>>>>>>>>>> We don't ship them anymore, but it's reasonable >>>>>>>>>>>>> to keep the work-around until we update the bios in qemu. >>>>>>>>>>>> >>>>>>>>>>>> We already did, did we not? >>>>>>>>>>> Yes, we did, but Gerd preferred to keep this patch around. >>>>>>>>>>> Adding him to thread. >>>>>>>>>> >>>>>>>>>> seabios bundled with qemu isn't the only possible firmware. >>>>>>>>>> >>>>>>>>>> We have ovmf, coreboot, qboot. >>>>>>>>> >>>>>>>>> ovmf is especially interesting. Marcel, did you look at what >>>>>>>>> happens with pxb and ovmf? >>>>>>>> No, I talked to Laszlo about it, he said ovmf is not there yet. >>>>>>>> OVMF will not query the extra buses, so the devices on the extra bus >>>>>>>> will not be visible. >>>>>>>> Adding him to the thread. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcel >>>>>>> >>>>>>> But does OVMF need this specific patch? >>>>>> I don't think so because more than likely it doesn't scan for the >>>>>> extra >>>>>> buses, >>>>>> so it will not try to configure these devices. >>>>>> Laszlo, am I right? >>>>> >>>>> Well, I don't know. :) >>>>> >>>>> First, I'm not seeing the specific patch in question (can you pls send >>>>> me a URL into the web archive, or a Message-Id?) >>>> Well, there are a few patches, all this series, >>>> You can look for patches: >>>> 13/24 hw/acpi: add support for i440fx 'snooping' root busses -> acpi >>>> declarations >>>> 18/24 hw/pci: introduce PCI Expander Bridge (PXB) >>>> 19/24 hw/pci: inform bios if the system has extra pci root buses >>>> >>>> Basically we add the pxb resources to ACPI tables and then inform BIOS >>>> using >>>> etc/extra-pci-roots fw_config file that he has extra roots to scan. >>>> >>>> If the OVMF only looks for bus 0 and does not scan all possible buses >>>> it will not see PXB's root bus >>> >>> I don't know enough about PCI to reply sensibly. >>> >>> I can tell you that the bus range in OVMF, from "mResAperture" in >>> "PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c", is [0..0xff], >>> inclusive. >>> >>> This bus range is then exposed in the function StartBusEnumeration() to >>> the caller (which is the PCI bus driver), as an output parameter. The >>> StartBusEnumeration() function has the following leading comment: >>> >>>> Sets up the specified PCI root bridge for the bus enumeration process. >>>> >>>> This member function sets up the root bridge for bus enumeration and >>>> returns the PCI bus range over which the search should be performed >>>> in ACPI 2.0 resource descriptor format. >>> >>> So, there's a chance that if those busses actually exist on the virtual >>> hardware, the drivers included by OVMF from the generic edk2 source >>> "will just work". It is also possible that OVMF will notice no change at >>> all. >>> >>> Do you have a public branch, and a matching command line? The PCI >>> enumeration / resource allocation spews a bunch of messages in OVMF, so >>> if you placed (on the QEMU command line) some devices on one of these >>> nonzero buses, then their enumeration / resource allocation, determined >>> from the log, could serve as evidence. (I think this should be testable >>> on a non-NUMA host, and without passthrough devices as well.) >>> >>> Also, I checked the actual code hunks & message body for this patch (ie. >>> 23/24) on the web. Looks like I should be able to dump the ACPI tables >>> in the guest, and get those dumps to you for verification. OVMF does >>> delay the ACPI download until after PCI enumeration, so the state of the >>> guest _CRS would be (negative or positive) proof, not lack of proof. >> >> Hi Laszlo, >> I am sorry for the late reply. >> Can you please check using mst branch? >> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git pxb >> Just add to the regular command line: >> -device pxb,id=bridge1,bus_nr=4 -netdev user,id=u -device >> e1000,id=net2,bus=bridge1,netdev=u,addr=1 >> >> Thanks a lot for the help, we mainly want to know if there is >> an architecture issue that will prevent the PXB to work with OVMF. >> Marcel > > I wrote a horrible patch that allowed OVMF to enumerate the e1000 NIC on > the pxb, so I guess there should be no "architectural issue" preventing > OVMF from using this device. Of course, making good / dynamic use of > this stuff is light years away. I'll respond with more details in the > thread you started on edk2-devel: > > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15147ink Hi Laszlo, Those are wonderful news! Thank you very much for your involvement. Once the above thread will lead to an actual design, maybe I can contribute to the implementation. Michael, since Laszlo succeeded to enumerate devices behind PXB, I think we can finally merge this device into QEMU. Do you agree? Thanks, Marcel > > Thanks > Laszlohttp://thread.gmane.org/gmane.comp.bios.tianocore.devel/15147 > > >>>> >>>>> Second, recently I tested OVMF on Q35, but not just with a simple / >>>>> usual command line invocation -- I tested it on a Q35 machine >>>>> configured >>>>> by libvirt. That's a very different animal. >>>>> >>>>> While it exposed a problem in OVMF's own boot order processing: >>>>> >>>>> https://github.com/tianocore/edk2/commit/feca17fa4b >>>>> >>>>> I was surprised to see that the PCI bus driver enumerated devices >>>>> behind >>>>> two bridges no less without any problems. So, bridges off the one root >>>>> bridge should work, but several root bridges probably won't. (Exposing >>>>> root bridges is the responsibility of another driver, and they are not >>>>> enumerable in the usual way.) >>>>> >>>>> Thanks >>>>> Laszlo >>>>> >>>> >>> >> >
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index f7d2c80..895d64c 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -784,6 +784,14 @@ static Aml *build_crs(PCIHostState *host, range_base = r->addr; range_limit = r->addr + r->size - 1; + /* + * Work-around for old bioses + * that do not support multiple root buses + */ + if (!range_base || range_base > range_limit) { + continue; + } + if (r->type & PCI_BASE_ADDRESS_SPACE_IO) { aml_append(crs, aml_word_io(aml_min_fixed, aml_max_fixed, @@ -817,45 +825,66 @@ static Aml *build_crs(PCIHostState *host, range_base = pci_bridge_get_base(dev, PCI_BASE_ADDRESS_SPACE_IO); range_limit = pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_SPACE_IO); - aml_append(crs, - aml_word_io(aml_min_fixed, aml_max_fixed, - aml_pos_decode, aml_entire_range, - 0, - range_base, - range_limit, - 0, - range_limit - range_base + 1)); - crs_range_insert(io_ranges, range_base, range_limit); + + /* + * Work-around for old bioses + * that do not support multiple root buses + */ + if (range_base || range_base > range_limit) { + aml_append(crs, + aml_word_io(aml_min_fixed, aml_max_fixed, + aml_pos_decode, aml_entire_range, + 0, + range_base, + range_limit, + 0, + range_limit - range_base + 1)); + crs_range_insert(io_ranges, range_base, range_limit); + } range_base = pci_bridge_get_base(dev, PCI_BASE_ADDRESS_SPACE_MEMORY); range_limit = pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_SPACE_MEMORY); - aml_append(crs, - aml_dword_memory(aml_pos_decode, aml_min_fixed, - aml_max_fixed, aml_non_cacheable, - aml_ReadWrite, - 0, - range_base, - range_limit, - 0, - range_limit - range_base + 1)); - crs_range_insert(mem_ranges, range_base, range_limit); + + /* + * Work-around for old bioses + * that do not support multiple root buses + */ + if (range_base || range_base > range_limit) { + aml_append(crs, + aml_dword_memory(aml_pos_decode, aml_min_fixed, + aml_max_fixed, aml_non_cacheable, + aml_ReadWrite, + 0, + range_base, + range_limit, + 0, + range_limit - range_base + 1)); + crs_range_insert(mem_ranges, range_base, range_limit); + } range_base = pci_bridge_get_base(dev, PCI_BASE_ADDRESS_MEM_PREFETCH); range_limit = pci_bridge_get_limit(dev, PCI_BASE_ADDRESS_MEM_PREFETCH); - aml_append(crs, - aml_dword_memory(aml_pos_decode, aml_min_fixed, - aml_max_fixed, aml_non_cacheable, - aml_ReadWrite, - 0, - range_base, - range_limit, - 0, - range_limit - range_base + 1)); - crs_range_insert(mem_ranges, range_base, range_limit); + + /* + * Work-around for old bioses + * that do not support multiple root buses + */ + if (range_base || range_base > range_limit) { + aml_append(crs, + aml_dword_memory(aml_pos_decode, aml_min_fixed, + aml_max_fixed, aml_non_cacheable, + aml_ReadWrite, + 0, + range_base, + range_limit, + 0, + range_limit - range_base + 1)); + crs_range_insert(mem_ranges, range_base, range_limit); + } } }
PXB does not work with unsupported bioses, but should not interfere with normal OS operation. We don't ship them anymore, but it's reasonable to keep the work-around until we update the bios in qemu. Fix this by not adding PXB mem/IO chunks to _CRS if they weren't configured by BIOS. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> --- hw/i386/acpi-build.c | 87 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 58 insertions(+), 29 deletions(-)