Re: [PATCH v2 21/21] efi: Allow disabling PCI busmastering on bridges during boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 21 Dec 2019 at 23:54, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
>
> On Sat, Dec 21, 2019 at 01:24:16PM -0800, Matthew Garrett wrote:
> > On Sat, Dec 21, 2019 at 8:44 AM Ard Biesheuvel
> > <ard.biesheuvel@xxxxxxxxxx> wrote:
> > > Point taken. I like Arvind's suggestion but we need to take care not
> > > to disable the device producing the GOP. Beyond that, it should be
> > > possible to disable all devices that are behind PCI bridges. It does
> > > mean we need to decode the secondary/subordinate bus values from the
> > > config space and take them into account when iterating over the PCI
> > > handle list.
>
> Why do we need to look at the bus numbers? Shouldn't it be just looping
> and disabling everything that's a regular device in the first pass
> (possibly excluding devices that are producing GOP/UGA), and then going
> over it again to disable the bus-master settings on bridges?
>

Yeah, that would work I guess

> Also, why do we restrict the bus-master disable to only PCI/PCI bridges?
> Shouldn't we also disable bus-mastering on all the other PCI-xxx
> bridges?
>

Practically, on PCIe systems, PCI/PCI bridges are the only thing we
need to care about, since that is how PCIe root ports are modelled.


> >
> > The device producing the GOP is the device that I'm most afraid of, to
> > be honest.I'd naively expect that anything presenting a linear
> > framebuffer will probably leave it up at disconnect time, and we're
> > definitely not using DMA to access that framebuffer.
>
> At least on my system, disconnecting the GOP device does leave the
> display up, and the framebuffer remains active (ie writing to it updates
> the display). It wouldn't be surprising if this doesn't work for all
> GPUs though.
>

Disconnecting a device should result in the protocols installed by the
driver to be removed again, and this also applies to the GOP protocol.
Whether or not the framebuffer is still live after that point is not
entirely relevant.

But if the GOP it produces is not BltOnly and its framebuffer address
doesn't intersect system memory, it should be safe to disable DMA on
such devices.

So in summary, we'll need to do

for each PCI I/O handle {
  if (bus == 0 || // not behind a bridge
      type == bridge)
    ignore;
  else
    disconnect();
}

for each PCI I/O handle {
  if (type == bridge)
    disable BM bit;
}

Disregarding bus 0 means all the 'special' devices integrated into the
root complex are disregarded as well, which seems safer to me.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux