Displaying 11 results from an estimated 11 matches for "pci_device_header".
2014 Sep 21
2
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
...To complicate things, lkvm does not use a distinct subsystem vendor ID,
> in spite of the fact the virtio spec always required this explicitly.
I think I may be a bit confused here, but AFAIK we do set subsystem vendor
ID properly for our virtio-pci devices?
vpci->pci_hdr = (struct pci_device_header) {
.vendor_id = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET),
.device_id = cpu_to_le16(device_id),
[...]
.subsys_vendor_id = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET),
Thanks,
Sasha
2014 Sep 21
2
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
...To complicate things, lkvm does not use a distinct subsystem vendor ID,
> in spite of the fact the virtio spec always required this explicitly.
I think I may be a bit confused here, but AFAIK we do set subsystem vendor
ID properly for our virtio-pci devices?
vpci->pci_hdr = (struct pci_device_header) {
.vendor_id = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET),
.device_id = cpu_to_le16(device_id),
[...]
.subsys_vendor_id = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET),
Thanks,
Sasha
2014 Sep 21
1
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
...t; > in spite of the fact the virtio spec always required this explicitly.
>> >
>> > I think I may be a bit confused here, but AFAIK we do set subsystem vendor
>> > ID properly for our virtio-pci devices?
>> >
>> > vpci->pci_hdr = (struct pci_device_header) {
>> > .vendor_id = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET),
>> > .device_id = cpu_to_le16(device_id),
>> > [...]
>> > .subsys_vendor_id = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_RE...
2014 Sep 21
1
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
...t; > in spite of the fact the virtio spec always required this explicitly.
>> >
>> > I think I may be a bit confused here, but AFAIK we do set subsystem vendor
>> > ID properly for our virtio-pci devices?
>> >
>> > vpci->pci_hdr = (struct pci_device_header) {
>> > .vendor_id = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET),
>> > .device_id = cpu_to_le16(device_id),
>> > [...]
>> > .subsys_vendor_id = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_RE...
2014 Sep 21
0
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
...es not use a distinct subsystem vendor ID,
> > in spite of the fact the virtio spec always required this explicitly.
>
> I think I may be a bit confused here, but AFAIK we do set subsystem vendor
> ID properly for our virtio-pci devices?
>
> vpci->pci_hdr = (struct pci_device_header) {
> .vendor_id = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET),
> .device_id = cpu_to_le16(device_id),
> [...]
> .subsys_vendor_id = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET),
>
>
> Tha...
2014 Sep 18
3
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
On Monday 01 September 2014 09:37:30, Michael S. Tsirkin wrote:
> Why do we need INT#x?
> How about setting IRQF_SHARED for the config interrupt
> while using MSI-X? You'd have to read ISR to check that the
> interrupt was intended for your device.
The virtio 0.9.5 spec says that ISR is "unused" when in MSI-X mode. I
don't think that you can depend on the device to
2014 Sep 18
3
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
On Monday 01 September 2014 09:37:30, Michael S. Tsirkin wrote:
> Why do we need INT#x?
> How about setting IRQF_SHARED for the config interrupt
> while using MSI-X? You'd have to read ISR to check that the
> interrupt was intended for your device.
The virtio 0.9.5 spec says that ISR is "unused" when in MSI-X mode. I
don't think that you can depend on the device to
2015 Nov 18
2
[RFC] kvmtool: add support for modern virtio-pci
...56a 100644
--- a/include/kvm/pci.h
+++ b/include/kvm/pci.h
@@ -4,6 +4,7 @@
#include <linux/types.h>
#include <linux/kvm.h>
#include <linux/pci_regs.h>
+#include <linux/virtio_pci.h>
#include <endian.h>
#include "kvm/devices.h"
@@ -81,7 +82,12 @@ struct pci_device_header {
u8 min_gnt;
u8 max_lat;
struct msix_cap msix;
- u8 empty[136]; /* Rest of PCI config space */
+ struct virtio_pci_cap common_cap;
+ struct virtio_pci_notify_cap notify_cap;
+ struct virtio_pci_cap isr_cap;
+ struct virtio_pci_cap device_cap;
+ struct virtio_pci_cfg_cap pci_cap;
+ u8 emp...
2015 Nov 18
2
[RFC] kvmtool: add support for modern virtio-pci
...56a 100644
--- a/include/kvm/pci.h
+++ b/include/kvm/pci.h
@@ -4,6 +4,7 @@
#include <linux/types.h>
#include <linux/kvm.h>
#include <linux/pci_regs.h>
+#include <linux/virtio_pci.h>
#include <endian.h>
#include "kvm/devices.h"
@@ -81,7 +82,12 @@ struct pci_device_header {
u8 min_gnt;
u8 max_lat;
struct msix_cap msix;
- u8 empty[136]; /* Rest of PCI config space */
+ struct virtio_pci_cap common_cap;
+ struct virtio_pci_notify_cap notify_cap;
+ struct virtio_pci_cap isr_cap;
+ struct virtio_pci_cap device_cap;
+ struct virtio_pci_cfg_cap pci_cap;
+ u8 emp...
2017 Apr 07
34
[RFC 0/3] virtio-iommu: a paravirtualized IOMMU
This is the initial proposal for a paravirtualized IOMMU device using
virtio transport. It contains a description of the device, a Linux driver,
and a toy implementation in kvmtool. With this prototype, you can
translate DMA to guest memory from emulated (virtio), or passed-through
(VFIO) devices.
In its simplest form, implemented here, the device handles map/unmap
requests from the guest. Future
2017 Apr 07
34
[RFC 0/3] virtio-iommu: a paravirtualized IOMMU
This is the initial proposal for a paravirtualized IOMMU device using
virtio transport. It contains a description of the device, a Linux driver,
and a toy implementation in kvmtool. With this prototype, you can
translate DMA to guest memory from emulated (virtio), or passed-through
(VFIO) devices.
In its simplest form, implemented here, the device handles map/unmap
requests from the guest. Future