Hi,
On 2023/7/20 03:32, Bjorn Helgaas wrote:
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Bar.
4) It is device-agnostic, thus it has to waste the effort to iterate all
of the PCI Bar to find the VRAM aperture.
5) It has invented lots of methods to determine which one is the default
boot device, but this is still a policy because it doesn't give the
user a choice to override.
I don't think we need a list of*potential* problems. We need an
example of the specific problem this will solve, i.e., what currently
does not work?
This version do allow the arbitration service works on non-x86 arch,
which also allow me remove a arch-specific workaround.
I will give more detail at the next version.
But I want to provide one more drawback of vgaarb here:
(6) It does not works for non VGA-compatible PCI(e) display controllers.
Because, currently, vgaarb deal with PCI VGA compatible devices only.
See another my patch set [1] for more elaborate discussion.
It also ignore PCI_CLASS_NOT_DEFINED_VGA as Maciej puts it[2].
While my approach do not required the display controller to be
VGA-compatible to enjoy the arbitration service.
What do you think then?
[1] https://patchwork.freedesktop.org/patch/546690/?series=120548&rev=1
[2] https://lkml.org/lkml/2023/6/18/315
