[illumos-gate] 17503 mac_sw_lso() should handle mac_sw_cksum() failures -- Patrick Mooney <pmooney⊙pc>

Hi, is anyone actively working in AMD pci passthrough?

neirac - I'm not aware of anybody working on that.

Hmmm, thought maybe one of @Woodstock or Patrick might have been. Last thing we need is duplicate effort.

if I remember, the effort isn't so much the passthrough

you might want to ask instead if anyone is working on fixing the amd iommu support, but I think the answer is still no

I assume you could cheat like intel does, though, if you had to, but I don't know.

if you were to do the iommu fully though, I'm interested in that, to the degree it'd be nice if the way we all did it was general.

all i've ever heard is 'it's horrible and broken' without any explanation of how/why

the way it plugs into the system is pretty shocking

I think that's because the org chart was literally Intel doing the intel one, AMD doing the AMD one, and Sun hoping for the best in the middle

richlowe: Yeah... Intel was notorious for their isolation demands (/me remember Itanic), and I don't know if it got any better/worse in an AMD64 world.

i don't think the existing amd iommu support deserves fixing, and neither does the intel one

bhyve has its own private intel iommu driver for passthru, we ported that from freebsd back in 2017

Woodstock: the problem we all have is that _that_ opinion is pretty prevalent, but nobody remembers why or what is broken with it

the same should be done for the private amd iommu bits in freebsd bhyve

and outside of PCI passthrough, the IOMMU has uses

anyway, the tension is that if we use the iommu properly the bhyve support needs to be redone

back then i worked together with the guy who wrote the amd iommu driver, and he just didn't finish fixing all the nasty issues before the lawnmower came

ok, so a collection of them, not one specific?

so even if you fix it, it may not support anything past the AMD K10

if the architecture is bad, and the code is bad, I definitely agree

but still think patching it into bhyve is probably not going to work long term

i didn't know back then what the bugs where, but I have tried it on a system that should have supported it and it failed miserably

perfect! that's literally what I've been trying to talk someone into doing for ages

So PROPER iommu is a burn-it-to-the-ground project?

Woodstock: maybe file a bug saying that? and that we should probably remove the existing code that misleads people?

the intel iommu driver at least kind of works for normal device isolation, i tried that when we were evaluating our options for bhyve. some drivers may have issues, but those are bugs of those drivers.

that seems sane to me at least, maybe wait to see if Dan does.

ok, so intel works but the architecture is still oof

unless that architecture is just what turns out to be necessary

I've no strong opinions here. @neirac (who seems to have disappeared?) was asking me about it, and I sent him here.

so if someone tasked me to get passthru working on AMD, I'd port the bhyve amd iommu bits from freebsd as i have done with the intel bits :)

Woodstock: yeah... I was thinking someone might've been mid-working-on exactly what you just described.

as far as i recall porting the intel bits wasn't terribly hard

i guess i need to clarify: I was around at AMD when AMD wrote the iommu driver for opensolaris for the then-new K10 chips, and that code definitely hasn't been working and hasn't been touched since 2010

the freebsd amd iommu code probably works well, but i have never tried it

I remember when it was you@AMD.

lately i began noticing that i'm apparently getting old. it was 13 years ago that I left AMD to join Nexenta :)

Woodstock: if someone ported the bhyve stuff for passthrough, what would happen if actual system-level iommu support appeared?

they can't cooexist right? (I'm not saying one approach or the other, anymore, just confirming I'm not an idiot)

cooexist, like pigeons. smh.

FWIW, we are probably going to be dealing with the AMD interrupt remapping over the next 1-2q.

Which does touch that.

i'd be surprised if that could coexist

rmustacc: Thank you for that data point. As mentioned earlier, there's some interest in it and we're happy to help if we can.

That's a different part.

Though both IOMMU related.

While we're not immediately looking at the isolation parts (but do need to longer term), we can't have it be passthrough or increase NCPU.

Not saying it will be that way, but something we're going to have to be mindful of here.

in my initial inspection of the code, I assumed it required porting the amd parts src.illumos.org/source/xref/illumos…el/io/vmm/amd/amdvi_hw.c?r=32640292 like was done for vmm_vtd