T
Teralios
Gast
@ZeroStrat
der Tweet ist durchaus interessant, aber wir müssen hier jetzt durchaus etwas aufpassen. Wir haben bereits festgestellt, dass es
Das Addressmapping ist jedoch nicht in der
Nur muss ich jetzt auch ehrlich dazu sagen, dass wir jetzt in einem Bereich sind, in dem ich mich eben auch nicht mehr auskenne und auch nur noch raten kann. Das Problem ist, dass wir hier nicht nur im PCI-Subsystem sind, sondern ebenso in dem DMA-Subsystem - hier finde ich Hinweise auf die Maskierung von Adressen mit Bit-Masken alleine wegen der Sicherheit. Im VFIO-System finde ich diese Hinweise, damit die Adressen in CPU gemappt werden. Zum Beispiel hier:
Und genau das ist hier der Punkt: Auch im weiteren Verlauf finden sich diese Hinweise, wenn mit Memory-Adressen gearbeitet wird und dass diese für PCI und die BAR-Breite oder für die CPU und MMIO usw. transformiert werden.
Wir wissen also: Die Adresse werden per Masken verarbeitet. Wir wissen ebenso, wenn möglich werden die Funktionen der CPU genutzt. Wir wissen ebenso: Sie sind nicht notwendig, es gibt ein »Workaround« dafür und jetzt kommt das Letzte: Wir wissen nun, dass rBAR - mit Workaround - keinen nennenswerten Leistungsvorteil bringt, wenn man aber rBAR aktiviert und die langsamen Codes nutzt, langsamer ist, als wenn man den Workaround nutzt.
Nur: Wir bewegen uns jetzt wirklich auf Systemprogrammierung und da kenne ich mich eben nicht aus, ich kenne die Grundlagen, die Techniken, aber nicht die Feinheiten! Sehe ich mir den Code an, wende mein Grundlagenwissen an, gehe ich durch die Dateien, finde ich die »Bestätigungen« für unseren Verdacht, gleichzeitig findet man aber eben nicht den finalen Beweis, denn dafür ist das viel zu aufwendig.
Die anderen haben es leicht, die müssen nur schreiben, dass es nicht stimmt, warum es nicht stimmt, sagt von den ja keiner. Würden die wirklich »wissenschaftlich« arbeiten, dann käme wenigstens ein: Deswegen liegt ihr falsch. Nur die meisten, die sagen das wir falsch liegen, haben noch weniger Ahnung als wir, die sagen nur pauschal alles falsch, weil sie es falsch haben wollen!
der Tweet ist durchaus interessant, aber wir müssen hier jetzt durchaus etwas aufpassen. Wir haben bereits festgestellt, dass es
pext und pdep nicht braucht, aber dass diese Funktionen verwendet werden, sofern sie vorhanden sind, weil die PCI-Kommunikation auch über diese Masken arbeitet.Das Addressmapping ist jedoch nicht in der
pci.c, sondern das ist im Treiber (amdgpu) und da wird es dann kompliziert und auch hier ist es so, dass ich über viele Dateien hinweg den Hinweis finde, dass für die VRAM-Verwaltung entsprechende Maskierungsfunktionen genutzt und gesetzt werden. Hier wird es zum Beispiel erneut angedeutet: amdgpu_mes.h. Es geht dann von hier aus dann in den Bereich DMA und ebenso VFIO und zum Beispiel hier findet man dann wieder den Verweis darauf, dass Adressen maskiert werden: sta2x11-fixup.c werden. Geh ich dann auf die passenden Compiler-Anweisungen, wird wieder, wenn möglich pdep und pext verwendet, es gibt aber eben auch alternative Funktionen.Nur muss ich jetzt auch ehrlich dazu sagen, dass wir jetzt in einem Bereich sind, in dem ich mich eben auch nicht mehr auskenne und auch nur noch raten kann. Das Problem ist, dass wir hier nicht nur im PCI-Subsystem sind, sondern ebenso in dem DMA-Subsystem - hier finde ich Hinweise auf die Maskierung von Adressen mit Bit-Masken alleine wegen der Sicherheit. Im VFIO-System finde ich diese Hinweise, damit die Adressen in CPU gemappt werden. Zum Beispiel hier:
Code:
static void vfio_bar_fixup(struct vfio_pci_device *vdev)
{
struct pci_dev *pdev = vdev->pdev;
int i;
__le32 *vbar;
u64 mask;
if (!vdev->bardirty)
return;
vbar = (__le32 *)&vdev->vconfig[PCI_BASE_ADDRESS_0];
for (i = 0; i < PCI_STD_NUM_BARS; i++, vbar++) {
int bar = i + PCI_STD_RESOURCES;
if (!pci_resource_start(pdev, bar)) {
*vbar = 0; /* Unmapped by host = unimplemented to user */
continue;
}
mask = ~(pci_resource_len(pdev, bar) - 1);
*vbar &= cpu_to_le32((u32)mask);
*vbar |= vfio_generate_bar_flags(pdev, bar);
if (*vbar & cpu_to_le32(PCI_BASE_ADDRESS_MEM_TYPE_64)) {
vbar++;
*vbar &= cpu_to_le32((u32)(mask >> 32));
i++;
}
}
vbar = (__le32 *)&vdev->vconfig[PCI_ROM_ADDRESS];
/*
* NB. REGION_INFO will have reported zero size if we weren't able
* to read the ROM, but we still return the actual BAR size here if
* it exists (or the shadow ROM space).
*/
if (pci_resource_start(pdev, PCI_ROM_RESOURCE)) {
mask = ~(pci_resource_len(pdev, PCI_ROM_RESOURCE) - 1);
mask |= PCI_ROM_ADDRESS_ENABLE;
*vbar &= cpu_to_le32((u32)mask);
} else if (pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW) {
mask = ~(0x20000 - 1);
mask |= PCI_ROM_ADDRESS_ENABLE;
*vbar &= cpu_to_le32((u32)mask);
} else
*vbar = 0;
vdev->bardirty = false;
}Und genau das ist hier der Punkt: Auch im weiteren Verlauf finden sich diese Hinweise, wenn mit Memory-Adressen gearbeitet wird und dass diese für PCI und die BAR-Breite oder für die CPU und MMIO usw. transformiert werden.
Wir wissen also: Die Adresse werden per Masken verarbeitet. Wir wissen ebenso, wenn möglich werden die Funktionen der CPU genutzt. Wir wissen ebenso: Sie sind nicht notwendig, es gibt ein »Workaround« dafür und jetzt kommt das Letzte: Wir wissen nun, dass rBAR - mit Workaround - keinen nennenswerten Leistungsvorteil bringt, wenn man aber rBAR aktiviert und die langsamen Codes nutzt, langsamer ist, als wenn man den Workaround nutzt.
Nur: Wir bewegen uns jetzt wirklich auf Systemprogrammierung und da kenne ich mich eben nicht aus, ich kenne die Grundlagen, die Techniken, aber nicht die Feinheiten! Sehe ich mir den Code an, wende mein Grundlagenwissen an, gehe ich durch die Dateien, finde ich die »Bestätigungen« für unseren Verdacht, gleichzeitig findet man aber eben nicht den finalen Beweis, denn dafür ist das viel zu aufwendig.
Die anderen haben es leicht, die müssen nur schreiben, dass es nicht stimmt, warum es nicht stimmt, sagt von den ja keiner. Würden die wirklich »wissenschaftlich« arbeiten, dann käme wenigstens ein: Deswegen liegt ihr falsch. Nur die meisten, die sagen das wir falsch liegen, haben noch weniger Ahnung als wir, die sagen nur pauschal alles falsch, weil sie es falsch haben wollen!
