From: H. Peter Anvin on
On 05/28/2010 10:10 AM, Mike Travis wrote:
>
>
> H. Peter Anvin wrote:
>> On 05/28/2010 09:53 AM, Mike Travis wrote:
>>> Any further consideration for this patch, or has it been rejected?
>>
>> Well, it's really up to Jesse, but as far as I can see, this patch is a
>> net loss of functionality and doesn't actually add anything. Without
>> this patch, some resources that were not assigned by BIOS will be
>> unreachable. With this patch, *all* resources that were not assigned by
>> BIOS will be unreachable...
>>
>> -hpa
>>
>
> Apparently you're missing the point of the patch? The patch is needed
> because BIOS is purposely not assigning I/O BAR's to devices that won't
> use them, freeing up the resource for devices that do need them. Where
> is the "all" resources that are not reachable?
>

No, the patch isn't needed for those.

Without your patch:

- Devices assigned by BIOS remain assigned;
- Devices not assigned by BIOS get assigned until address space
exhausted.

With your patch:

- Devices assigned by BIOS remain assigned;
- Devices not assigned by BIOS never get assigned at all.

What am I missing here?

-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: Mike Travis on


H. Peter Anvin wrote:
> On 05/28/2010 10:10 AM, Mike Travis wrote:
>>
>> H. Peter Anvin wrote:
>>> On 05/28/2010 09:53 AM, Mike Travis wrote:
>>>> Any further consideration for this patch, or has it been rejected?
>>> Well, it's really up to Jesse, but as far as I can see, this patch is a
>>> net loss of functionality and doesn't actually add anything. Without
>>> this patch, some resources that were not assigned by BIOS will be
>>> unreachable. With this patch, *all* resources that were not assigned by
>>> BIOS will be unreachable...
>>>
>>> -hpa
>>>
>> Apparently you're missing the point of the patch? The patch is needed
>> because BIOS is purposely not assigning I/O BAR's to devices that won't
>> use them, freeing up the resource for devices that do need them. Where
>> is the "all" resources that are not reachable?
>>
>
> No, the patch isn't needed for those.
>
> Without your patch:
>
> - Devices assigned by BIOS remain assigned;
> - Devices not assigned by BIOS get assigned until address space
> exhausted.
>
> With your patch:
>
> - Devices assigned by BIOS remain assigned;
> - Devices not assigned by BIOS never get assigned at all.
>
> What am I missing here?
>
> -hpa
>

BIOS still assigns the MMIO BAR's so the devices are alive.
--
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
On 05/31/2010 04:12 AM, Mike Travis wrote:
>
> BIOS still assigns the MMIO BAR's so the devices are alive.

OK, so it sounds like the *real* problem is our behavior on address
space exhaustion: it is rather common that a driver will only use one
BAR/address space, and sometimes can even choose which address space to
use. The right thing would be to defer error until a particular BAR is
requested by the device driver, but I'm not sure if our interfaces
permits that (and I'm on my way to the airport right now so I can't
check...)

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
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
On 06/01/2010 03:49 PM, Bjorn Helgaas wrote:
>>
>> BIOS still assigns the MMIO BAR's so the devices are alive.
>
> I'm sorry; I don't follow this. BIOS assigns MMIO BARs regardless
> of whether we have your patch.
>

I'm assuming that that Mike is implying is that the allocation code runs
out of I/O space and as a result shuts down the entire device.

-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: H. Peter Anvin on
On 06/02/2010 05:45 PM, Bjorn Helgaas wrote:
> On Wednesday, June 02, 2010 01:31:18 am H. Peter Anvin wrote:
>> On 06/01/2010 03:49 PM, Bjorn Helgaas wrote:
>>>>
>>>> BIOS still assigns the MMIO BAR's so the devices are alive.
>>>
>>> I'm sorry; I don't follow this. BIOS assigns MMIO BARs regardless
>>> of whether we have your patch.
>>
>> I'm assuming that that Mike is implying is that the allocation code runs
>> out of I/O space and as a result shuts down the entire device.
>
> Yeah, that's why I asked about a deeper problem. There's not really a
> "shut down this device" flag, so the only way I can think of that we
> might make a device completely unusable is if we release all the device
> resources and then fail to reassign them.
>
> A concrete example, e.g., a dmesg log, would go a long ways toward
> clarifying this.
>

That's what I thought, which I guess means my original question to Mike
still stands...

-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/