On Thu, 19 Jul 2018 12:49:23 +0800 Peter Xu <peterx@xxxxxxxxxx> wrote: > On Wed, Jul 18, 2018 at 11:36:40AM +0200, Cornelia Huck wrote: > > On Wed, 18 Jul 2018 14:48:03 +0800 > > Peter Xu <peterx@xxxxxxxxxx> wrote: > > > I totally have no idea on whether people would like to use vfio-pci > > > and the balloon device at the same time. After all vfio-pci are > > > majorly for performance players, then I would vaguely guess that they > > > don't really care thin provisioning of memory at all, hence the usage > > > scenario might not exist much. Is that the major reason that we'd > > > just like to disable it (which makes sense to me)? > > > > Don't people use vfio-pci as well if they want some special > > capabilities from the passed-through device? (At least that's the main > > use case for vfio-ccw, not any performance considerations.) > > Good to know these. > > Out of topic: could I further ask what's these capabilities, and why > these capabilities can't be emulated (or hard to be emulated) if we > don't care about performance? For vfio-ccw, the (current) main use case is ECKD DASD. While this is basically a block device, it has some useful features (path failover, remote copy, exclusive locking) that are not replicated by any emulated device (and I'm not sure how to do this, either). It also has things like a weird disk layout, which we _could_ emulate, but I'm not sure why we would do that (it is mainly interesting if you want to share a disk with a traditional mainframe OS). Other usecases I'm thinking about are related to the on-list-but-not-yet-merged vfio-ap crypto adapter support: Using a crypto adapter that has been certified without needing to make keys available to the OS, getting real randomness out of the card and so on. Generally, I'd think anything that needs complicated transformations, interaction with other ecosystems or exploiting reliability features might be a case for using assignment: not just because of performance, but also because you don't need to reinvent the wheel.
