[libvirt] [PATCH 0/8] Hostdev-hybrid patches

[Shradha Shah]

>>> * 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list