aboutsummaryrefslogtreecommitdiff
path: root/hw/virtio/virtio-pmem-pci.c
AgeCommit message (Collapse)AuthorFilesLines
2019-07-12virtio pmem: remove transitional namesPankaj Gupta1-2/+0
Remove transitional & non transitional names for virtio pmem. Only virtio 1.0 and up is supported. Signed-off-by: Pankaj Gupta <pagupta@redhat.com> Message-Id: <20190712073554.21918-4-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2019-07-12virtio pmem: fix wrong mem region conditionPankaj Gupta1-1/+1
Coverity reported memory region returns zero for non-null value. This is because of wrong arguments to '?:' , fixing this. Signed-off-by: Pankaj Gupta <pagupta@redhat.com> Message-Id: <20190712073554.21918-2-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2019-07-04virtio-pci: Proxy for virtio-pmemPankaj Gupta1-0/+131
We need a proxy device for virtio-pmem, and this device has to be the actual memory device so we can cleanly hotplug it. Forward memory device class functions either to the actual device or use properties of the virtio-pmem device to implement these in the proxy. virtio-pmem will only be compiled for selected, supported architectures (that can deal with virtio/pci devices being memory devices). An architecture that is prepared for that can simply enable CONFIG_VIRTIO_PMEM to make it work. As not all architectures support memory devices (and CONFIG_VIRTIO_PMEM will be enabled per supported architecture), we have to move the PCI proxy to a separate file. Signed-off-by: Pankaj Gupta <pagupta@redhat.com> [ split up patches, memory-device changes, move pci proxy] Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190619094907.10131-5-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>