>>> * At migration time, since guests with attached pci-passthrough devices >>> can't be migrated, the pci-passthrough device (which is found by >>> searching the hostdev array for items with the "ephemeral" flag set) is >>> detached. This reduces the bond interface on the guest to only having >>> the virtio-net device, so traffic now passes through that device - it's >>> slower, but connectivity is maintained. >> And if this is the case, it means that 1) the guest must be aware that >> it is virtualized, and 2) can detect when it is being migrated. > > Unless I'm misunderstanding, the guest doesn't explicitly know that it's > virtualized or that it's being migrated - the guest OS just knows that > one of its PCI devices has been unplugged, and later that it's being > re-plugged (of course since there's a special driver on the guest, at > least that bit has a pretty good idea that it's in a virtual machine; > but that's no different from the virtio-net guest driver (not to mention > the guest agent)). I'm guessing that the migration will (should, > anyway) fail if the guest OS fails to detach the device in a timely fashion. The migration will fail if the guest OS fails to detach the device in a timely fashion. >> The >> ideal virtualization is one in where the guest doesn't have to be aware >> of anything, but the goal of this patch is not ideal guest behavior, so >> much as faster performance by explicitly making virtualization a leaky >> interface where the guest has to cooperate. >> >> Assuming I'm correct, does that have any security implications on the >> host? Or are we okay even if the guest is malicious, because the worst >> the guest can do is use the slower interface rather than the faster >> pci-passthrough device? > > > I think the only completely new functionality provided by these patches > is the "ephemeral" flag, which makes it possible for the pci-passthrough > device to be auto-detached to allow migration. So any *new* security > concern would be related to that capability. > > Otherwise, I don't see this as any different than defining the two > devices separately, which is already possible with existing libvirt. The hostdev-hybrid model can be configured using manual steps and 2 devices separately with existing libvirt device types. >The > single hostdev-hybrid "two-in-one" device does provide a convenience > factor beyond just shortening the config - the PF to use for the > virtio-net device is automatically derived from the VF that's allocated > for the pci-passthrough device (in my mind that's the one thing that > makes it desirable to have this special device type rather than just > adding the "ephemeral" flag to hostdev and requiring guest > configurations to have two separate device entries. Am I missing > something else?) but it would still be possible to use existing device > types to provide the same virtual hardware to the guest, and the guest > could use that hardware in the same manner. > > >>> I have other questions beyond that, but either don't understand the code >>> enough yet to verbalize them, or will ask them next to the associated code. >> Seconded :) >> > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list