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

[Shradha Shah]

On 09/14/2012 12:05 PM, Laine Stump wrote:
> On 09/13/2012 06:16 AM, Shradha Shah wrote:
>> On 09/11/2012 08:07 PM, Laine Stump wrote:
>>> If so, one issue I have is that one of the devices (the
>>> pci-passthrough?) doesn't have its guest-side PCI address visible
>>> anywhere in the guest's XML, does it? This is problematic, because
>>> management applications (and libvirt itself) expect to be able to scan
>>> the list of devices to learn what PCI slots are occupied on the guest,
>>> and where they can add new devices.
>> Actually the guest PCI address of the pci-passthrough device i.e. The VF
>> is visible in the guest's XML when the guest is running. The VF will be plugged
>> into the guest only when the guest is running or when the guest is not being 
>> migrated hence will be visible in the guest XML.
> 
> But there's only a place for one guest-side PCI address in each device
> element. Where is it showing up?

The guest PCI address of the pci-passthrough device is visible in <hostdev>
device element and that of the virtio-net is visible in the <interface>
device element.

> 
> Also, we really need for the same PCI address to be used each time the
> device is attached; although there may not appear to be a need for that
> now, past experience has shown that changing the PCI slot of a device
> over time inevitably leads to a problem somewhere with something :-/
> 
> Due to this, the general complexity of what's being done vs. what's
> being added, and also time/review bandwidth constraints I think that at
> least for this release we can't take the full hostdev-hybrid device
> patchset (really I think it will need to be re-thought and probably a
> different approach taken for specifying the two devices).
> 
> However, the "ephemeral" attribute for <hostdev>, <interface
> type='hostdev'> and <forward mode='hostdev'> is fairly straightforward
> and provides generally useful new functionality (especially if it is
> expanded as mentioned to work for save/restore as well as migration) -
> with just this part of your patch, we can still get all of the desired
> functionality at the level of libvirt XML (with the two limitations of
> 1) networks limited to a single PF, and 2) duplicated mac addresses must
> be manually specified).
> 
> How difficult would it be to create a patch with just that part of the
> functionality (plus the additional save/restore tweak)? If you could do
> that before the freeze on Tuesday AM we might be able to get it into
> 0.10.2 (which will be what Fedora 18 is based on).

I can provide the required patches over the weekend. 
>