[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] q35 machine type and libvirt.

Alex Williamson <alex williamson redhat com> writes:

> On Wed, 2013-02-27 at 13:20 -0500, Laine Stump wrote:
>> On 02/06/2013 02:13 PM, Laine Stump wrote:
>> > Now that qemu is getting the q35 machine type, libvirt needs to support it.
>> In an attempt to make sure that libvirt actually does something useful
>> with qemu's new machine type, I'm revisiting this topic and trying to
>> get a more thorough understanding.
>> I've developed my own list of what I *think* are the reasons for wanting
>> a new machine type in qemu (and from that it should be more apparent
>> what libvirt needs to do with it), and am wondering how far off the mark
>> I am:
> Right, somehow libvirt needs to know or qemu needs to tell it something
> about the devices it's plugging in.  If you were to grab your trust
> 10/100Mbps Legacy PCI ethernet card and try to plug it into a
> motherboard you'd quickly notice that you can only plug it into certain
> slots.  This is the same problem.  PCI device are attached to a legacy
> PCI bus, which means it needs to be behind a PCIe-to-PCI bridge.  Legacy
> Endpoints and Endpoints are plugin PCIe cards, so they need to be
> plugged in behind a PCIe switch or root port.  Integrated Endpoints are
> motherboard components, per the spec, they shouldn't even really be
> hotplug-able.  They attach directly to the root complex.

We could do this with QOM. The chipset could have a set of link
properties for the integrated devices.  For instance:

  Link<E1000> integrated_nic;
  Link<StdVGA> integrated_vga;

We should prevent PCI bus plugging for slots "owned" by integrated
devices.  libvirt has a way to probe for links that it can add including
what types are allowed for it.


Anthony Liguori

>>    * support some new emulated chipset devices?
> -M q35 + -device ioh3420 (root port) + -device i82801b11-bridge
> (pcie-to-pci bridge)
>>    * Anything else specific required to passthrough pcie devices?
> I just sent out an RFC asking about VGA routing, it's possible libvirt
> will need to understand some concept of a primary VGA device and specify
> it somehow to QEMU.
> It's also possible (probable) that we'll make assigned devices able to
> mangle PCIe types to make it more flexible where they can be attached
> (for instance you may not want to have your HD audio device exposed as a
> root complex device if that disables hotplug, so we may mangle it to
> look like a regular endpoint.  Windows is picky about root complex
> devices, so we may also mangle endpoint to integrated endpoint as well).
> Also need to be aware that all PCIe "buses" except the root complex are
> actually point-to-point links, so a root port connects to one PCIe
> device (which may be multifunction).  PCIe switches are needed to get
> fan out to connect multiple devices, one device per downstream port.  It
> would be interesting how much we can abuse the topology in a virtual
> system, but it's probably best not to confuse guests.  Thanks,
> Alex

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]