created | 2019-08-29T06:59:07Z |
---|---|
begin | 2019-08-06T09:00:00Z |
end | 2019-08-06T12:00:00Z |
path | src/sys |
commits | 4 |
date | 2019-08-06T09:36:54Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/if_vmx.c | log | diff | annotate |
message |
if the rx ring gets empty and can't be filled, retry in the future there have been several reports that vmx gets stuck sometimes and only comes good after it's taken down and up again. hopefully this fixes that issue. |
date | 2019-08-06T10:09:37Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/if_vmx.c | log | diff | annotate |
message | i replaced a misplaced tab with g, not a space. make this work again. |
date | 2019-08-06T10:15:27Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/if_vmx.c | log | diff | annotate |
src/sys/dev/pci/if_vmxreg.h | log | diff | annotate | |
message |
have a go at using msi interrupts. vmx has an interesting feature where config in the hypervisor can say what type of interrupts the guest should configure for the nic, with the options of auto, msix, msi, and intx. depending on this, the driver should try to map the type specified and fall back from there. also interesting is that my guest gets "auto" from the hypervisor, which i fall through to msi with, but an msi interrupt cannot be mapped. i cannot see any msi interrupts in this guest actually. there must be something funky at the platform level that we don't like, and that prevents msi from being mapped. if msi does get mapped, we should be able to avoid a register read on every interrupt. that should probably provide a noticable performance improvement if we can ever take advantage of it. |
date | 2019-08-06T10:54:40Z | |||
---|---|---|---|---|
author | dlg | |||
files | src/sys/dev/pci/if_vmx.c | log | diff | annotate |
message | remove some debug cruft i should have removed before the last commit. |