Prev: Add targets to use the Coccinelle checker
Next: Fix performance issue with ondemand governor
From: H. Peter Anvin on 26 Apr 2010 17:50
>
> Agreed. The trickier part is handling any platform devices that
> request_resource against that space. But maybe we don't need to do
> anything special; just making sure we avoid it in the PCI "BIOS" code
> as Bjorn did may be sufficient.
>

Why is that hard? If a platform device does a request_resource against
that space, it's a request for specific address space and it should be
granted.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 26 Apr 2010 18:00
On Mon, 26 Apr 2010 14:44:50 -0700
"H. Peter Anvin" <hpa(a)zytor.com> wrote:

> >
> > Agreed. The trickier part is handling any platform devices that
> > request_resource against that space. But maybe we don't need to do
> > anything special; just making sure we avoid it in the PCI "BIOS" code
> > as Bjorn did may be sufficient.
> >
>
> Why is that hard? If a platform device does a request_resource against
> that space, it's a request for specific address space and it should be
> granted.

I was thinking if we made it a special resource type we'd have to
change any platform drivers to use it; i.e. it wouldn't be
IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS. That way it
wouldn't be part of the normal resource space.

But that's definitely overkill. I think Bjorn's fix is sufficient.

--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 26 Apr 2010 19:30
Sorry, sounds like we're talking about a few different things here:
1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
2) devices which sit in e820 ram or other space below 1M
3) how to hand out space from the 0-1M region

Bjorn's patch fixes (3) so that regular PCI devices don't get space
there, which makes sense.

Some devices may be in the special region, but were pointed there by
the BIOS. Generally this should be ok, so drivers requesting this
space should be allowed to get at it, but we should avoid putting
anything else there.

And below it sounds like you're talking about (1). If so, then yes I
guess we need a solution there, which will allow drivers to bind to
these "reserved" devices, even though the BIOS has marked them as off
limits, at least as far as e820 goes.

So perhaps both (1) and (2) could be put into a new, special IO
resource space, or could use a new flag, since "busy" doesn't really
reflect what's going on there very well, as Bjorn pointed out.

Jesse

On Mon, 26 Apr 2010 16:02:57 -0700
"H. Peter Anvin" <hpa(a)zytor.com> wrote:

> I don't think it's sufficient, actually. We regularly see machines where devices point into e820_reserved memory above 1 MB - because it's a platform device or because firmware (e.g. smm) is touching the device. I think Bjorn's fix is great for .34, but longer term I think we need to structure the code to actually handle reserved regions differently from occupied/forbidden regions.
>
> "Jesse Barnes" <jbarnes(a)virtuousgeek.org> wrote:
>
> >On Mon, 26 Apr 2010 14:44:50 -0700
> >"H. Peter Anvin" <hpa(a)zytor.com> wrote:
> >
> >> >
> >> > Agreed. The trickier part is handling any platform devices that
> >> > request_resource against that space. But maybe we don't need to do
> >> > anything special; just making sure we avoid it in the PCI "BIOS" code
> >> > as Bjorn did may be sufficient.
> >> >
> >>
> >> Why is that hard? If a platform device does a request_resource against
> >> that space, it's a request for specific address space and it should be
> >> granted.
> >
> >I was thinking if we made it a special resource type we'd have to
> >change any platform drivers to use it; i.e. it wouldn't be
> >IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS. That way it
> >wouldn't be part of the normal resource space.
> >
> >But that's definitely overkill. I think Bjorn's fix is sufficient.
> >
> >--
> >Jesse Barnes, Intel Open Source Technology Center
>


--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai on 26 Apr 2010 21:50
On 04/26/2010 06:27 PM, Linus Torvalds wrote:
>
>
> On Mon, 26 Apr 2010, Jesse Barnes wrote:
>>
>> Glad we agree. As I said (and echoing Bjorn), I think it would be best
>> to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
>> We want and need to do allocations from the special region, so we
>> should mark it as such.
>
> I think Bjorn's patch to pcibios_align_resource() is really good and
> clever, and I think it should take care of the need for IORESOURCE_BUSY,
> no? We do want to let devices that are _already_ allocated there insert
> their resources, it's just that we never want to allocate new ones in the
> low 1M region.

case A:
bus 0: --- bus X --- device Y
if the BIOS only assign range to to BUS X bridge with 0xB0000, and
device Y is not assigned. then with Bojorn's patch, device Y can not
get right resource allocated on first try.


>
> Do we actually have a regression left with Bjorn's patch?

also find one AMD system:

[ 6.960006] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 6.984225] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-06])
[ 7.023528] pci_root PNP0A03:00: host bridge window [io 0x0000-0x03af]
[ 7.024014] pci_root PNP0A03:00: host bridge window [io 0x03b0-0x03bb]
[ 7.028005] pci_root PNP0A03:00: host bridge window [io 0x03bc-0x03bf]
[ 7.032005] pci_root PNP0A03:00: host bridge window [io 0x03c0-0x03df]
[ 7.036005] pci_root PNP0A03:00: host bridge window [io 0x03e0-0xefff]
[ 7.040011] pci_root PNP0A03:00: host bridge window [mem 0xd8000000-0xe7ffffff]
[ 7.044005] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfe9fffff]
[ 7.048005] pci_root PNP0A03:00: host bridge window [mem 0xfec00000-0xfed0ffff]
[ 7.052005] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]

[ 0.000000] BIOS-e820: 0000000000000100 - 0000000000098c00 (usable)
[ 0.000000] BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
[ 0.000000] BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved)
[ 0.000000] BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000d7ff0000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000008028000000 (usable)

pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 26 Apr 2010 22:10
The 1 MB range is only one case of a prereserved space. It's special only in the sense that it is *always* reserved, even if the map doesn't mark it as such. Fixed (or SMM-used) resources in reserved space above 1 MB are exactly the same issue.

"Jesse Barnes" <jbarnes(a)virtuousgeek.org> wrote:

>On Mon, 26 Apr 2010 18:27:27 -0700 (PDT)
>Linus Torvalds <torvalds(a)linux-foundation.org> wrote:
>
>>
>>
>> On Mon, 26 Apr 2010, Jesse Barnes wrote:
>> >
>> > Glad we agree. As I said (and echoing Bjorn), I think it would be best
>> > to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
>> > We want and need to do allocations from the special region, so we
>> > should mark it as such.
>>
>> I think Bjorn's patch to pcibios_align_resource() is really good and
>> clever, and I think it should take care of the need for IORESOURCE_BUSY,
>> no? We do want to let devices that are _already_ allocated there insert
>> their resources, it's just that we never want to allocate new ones in the
>> low 1M region.
>>
>> Do we actually have a regression left with Bjorn's patch?
>
>No, I think we're covered. But it sounded like Peter was also
>concerned about making new allocations from the 1M space, which would
>mean we'd need something other than the IORESOURCE_BUSY bit. But maybe
>Bjorn's patch plus simply removing the IORESOURCE_BUSY line is
>sufficient for that. The downside there is that it doesn't clearly
>communicate the special nature of the 1M region.
>
>--
>Jesse Barnes, Intel Open Source Technology Center

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
 |  Next  |  Last
Pages: 1 2 3
Prev: Add targets to use the Coccinelle checker
Next: Fix performance issue with ondemand governor