On Thu, Jun 17, 2021 at 01:00:14PM +1000, David Gibson wrote: > On Thu, Jun 10, 2021 at 06:37:31PM +0200, Jean-Philippe Brucker wrote: > > On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote: > > > For the qemu case, I would imagine a two stage fallback: > > > > > > 1) Ask for the exact IOMMU capabilities (including pagetable > > > format) that the vIOMMU has. If the host can supply, you're > > > good > > > > > > 2) If not, ask for a kernel managed IOAS. Verify that it can map > > > all the IOVA ranges the guest vIOMMU needs, and has an equal or > > > smaller pagesize than the guest vIOMMU presents. If so, > > > software emulate the vIOMMU by shadowing guest io pagetable > > > updates into the kernel managed IOAS. > > > > > > 3) You're out of luck, don't start. > > > > > > For both (1) and (2) I'd expect it to be asking this question *after* > > > saying what devices are attached to the IOAS, based on the virtual > > > hardware configuration. That doesn't cover hotplug, of course, for > > > that you have to just fail the hotplug if the new device isn't > > > supportable with the IOAS you already have. > > > > Yes. So there is a point in time when the IOAS is frozen, and cannot take > > in new incompatible devices. I think that can support the usage I had in > > mind. If the VMM (non-QEMU, let's say) wanted to create one IOASID FD per > > feature set it could bind the first device, freeze the features, then bind > > Are you thinking of this "freeze the features" as an explicitly > triggered action? I have suggested that an explicit "ENABLE" step > might be useful, but that hasn't had much traction from what I've > seen. Seems like we do need an explicit enable step for the flow you described above: a) Bind all devices to an ioasid. Each bind succeeds. b) Ask for a specific set of features for this aggregate of device. Ask for (1), fall back to (2), or abort. c) Boot the VM d) Hotplug a device, bind it to the ioasid. We're long past negotiating features for the ioasid, so the host needs to reject the bind if the new device is incompatible with what was requested at (b) So a successful request at (b) would be the point where we change the behavior of bind. Since the kernel needs a form of feature check in any case, I still have a preference for aborting the bind at (a) if the device isn't exactly compatible with other devices already in the ioasid, because it might be simpler to implement in the host, but I don't feel strongly about this. > > I'd like to understand better where the difficulty lies, with migration. > > Is the problem, once we have a guest running on physical machine A, to > > make sure that physical machine B supports the same IOMMU properties > > before migrating the VM over to B? Why can't QEMU (instead of the user) > > select a feature set on machine A, then when time comes to migrate, query > > all information from the host kernel on machine B and check that it > > matches what was picked for machine A? Or is it only trying to > > accommodate different sets of features between A and B, that would be too > > difficult? > > There are two problems > > 1) Although it could be done in theory, it's hard, and it would need a > huge rewrite to qemu's whole migration infrastructure to do this. > We'd need a way of representing host features, working out which sets > are compatible with which others depending on what things the guest is > allowed to use, encoding the information in the migration stream and > reporting failure. None of this exists now. > > Indeed qemu requires that you create the (stopped) machine on the > destination (including virtual hardware configuration) before even > attempting to process the incoming migration. It does not for the > most part transfer the machine configuration in the migration stream. > Now, that's generally considered a flaw with the design, but fixing it > is a huge project that no-one's really had the energy to begin despite > the idea being around for years. > > 2) It makes behaviour really hard to predict for management layers > above. Things like oVirt automatically migrate around a cluster for > load balancing. At the moment the model which works is basically that > you if you request the same guest features on each end of the > migration, and qemu starts with that configuration on each end, the > migration should work (or only fail for transient reasons). If you > can't know if the migration is possible until you get the incoming > stream, reporting and exposing what will and won't work to the layer > above also becomes an immensely fiddly problem. That was really useful, thanks. One thing I'm worried about is the user having to know way too much detail about IOMMUs in order to pick a precise configuration. The Arm SMMUs have a lot of small features that implementations can mix and match and that a user shouldn't have to care about, and there are lots of different implementations by various vendors. I suppose QEMU can offer a couple of configurations with predefined sets of features, but it seems easy to end up with a config that gets rejected because it is slightly different than the hardware. Anyway this is a discussion we can have once we touch on the features in GET_INFO, I don't have a precise idea at the moment. Thanks, Jean
