On Tue, Aug 07, 2018 at 04:40:33PM -0600, Alex Williamson wrote: > Maybe some of these will evolve over time, SVA efforts are working on > some of these interfaces, but apparently device assignment users have > been getting along just fine without ballooning for many years. But not any more I think. It takes all the running you can do, to keep in the same place. Overcommit with device specific drivers is one of the things that containers do better than VMs. If VMs had a better overcommit story with PT devices, it would be interesting IMHO. > With > physical devices, or even modern VFs, it seems hard to push density > beyond what we can handle with memory hotplug. Perhaps as we get into > scalable IOV type approaches we can opt-in more mediated devices by > default. I'm not sure what does mediated have to do with it though. It seems weird to fix internal Linux or even system call interfaces being inadequate with custom hardware. > It seems like we're just going around in circles here though, > anything more than preventing QEMU from shooting itself is a long term > goal touching multiple levels of the stack. It's just QEMU and the kernel, I don't see why any other levels would be involved. And it looks like we both agree it is a bug in the current VTD emulation even though current guests do not trigger it. I agree it's more work than just blocking things out, I am not making an argument for nacking this specific patch, but I do hope this thread motivates someone to look into it. -- MST
