So I should start out upfront by saying that I'm aware that the reality is that people do want to do passthrough with this kind of hardware, and that's not an unreasonable thing to do. I just don't really like the way that pushes the software into having to do ugly things... Overall I'll let Eric call the shots about how well this feature fits into our sysbus-fdt support; he knows this code much better than I do. (I would have preferred us not to have sysbus-fdt passthrough at all, in an ideal world :-)) On Wed, 9 Jan 2019 at 16:30, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Wed, Jan 9, 2019 at 5:03 PM Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > > whitelists for the devices we want to allow passthrough of and > > that we've tested to work. > > In the end, this will become a loooooong list (SoC x devices)... Well, yes, but it deters people from trying to do passthrough with hardware that's not designed in a way that makes passthrough reasonably supportable at a software level. > Reality is that on embedded, on-SoC devices are usually not on a PCI bus. > But IOMMUs are present, and virtualization is wanted. I don't insist on PCI. Probeable, and consistent in terms of what they provide and how you interact with them, is what we want. Embedded on-SoC devices are generally neither. (The host kernel could in theory provide an API that exposed only devices that were safely pass-through-able in a consistent way, I suppose, but it doesn't, or we wouldn't be having to fish through the device tree nodes making guesses about what's safe to allow and what isn't and having heuristics about not providing clocks info being ok if we think the clock might only be used for power management...) thanks -- PMM
