qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v7 7/8] virtio-pci-blk : Switch to new API.


From: Andreas Färber
Subject: Re: [Qemu-devel] [RFC PATCH v7 7/8] virtio-pci-blk : Switch to new API.
Date: Wed, 12 Dec 2012 18:53:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Am 12.12.2012 15:25, schrieb Peter Maydell:
> How will the PCI transport's PCI vendor/device/class IDs be
> set (a) when a virtio-blk backend is created and separately
> plugged into a virtio-pci transport (b) for the legacy
> virtio-pci-blk? [ideally the answer to (b) should be "in the
> same way as for (a)"]

The obvious answer would be that PCI properties need to be set on the
PCI device, not an a VirtioDevice sitting on a virtio-bus.

I.e., with the proposed refactoring we'd have on the virtio-bus:

- VirtioDevice
  + VirtioBlockDevice
  + VirtioSCSIDevice - has-a scsi-bus
  ...

In turn that means that every VirtioDevice to be exposed as PCI device
to the guest needs it own PCIDevice exposing a private virtio-bus.

- PCIDevice
  - VirtioPCIDevice - has-a virtio-bus
    + virtio-blk-pci - has-a VirtioBlockDevice on its virtio-bus
    + virtio-scsi-pci - has-a VirtioSCSIDevice on its virtio-bus
    ...

This also happens to solve most of the migration compatibility pretty
nicely because the wapping PCI devices would be used almost as before,
some state may need to be forwarded to the VirtioDevice.

Finally supplying a public device_initialize() or so would be helpful
for the latter since VMState cannot cross pointers IIRC. I'll look into
that part since inlining the old qdev functions cripples my Tegra work.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]