search for: vpci

...irtio/pci.c b/virtio/pci.c index 90fcd64..c3a3113 100644 --- a/virtio/pci.c +++ b/virtio/pci.c @@ -125,7 +125,7 @@ static bool virtio_pci__io_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 p switch (offset) { case VIRTIO_PCI_HOST_FEATURES: - val = vdev->ops->get_host_features(kvm, vpci->dev); + val = vdev->ops->get_host_features(kvm, vpci->dev, 0); ioport__write32(data, val); break; case VIRTIO_PCI_QUEUE_PFN: @@ -211,7 +211,7 @@ static bool virtio_pci__io_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 switch (offset) { case VIRTIO_PCI_GUEST_FEATURES...

...irtio/pci.c b/virtio/pci.c index 90fcd64..c3a3113 100644 --- a/virtio/pci.c +++ b/virtio/pci.c @@ -125,7 +125,7 @@ static bool virtio_pci__io_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 p switch (offset) { case VIRTIO_PCI_HOST_FEATURES: - val = vdev->ops->get_host_features(kvm, vpci->dev); + val = vdev->ops->get_host_features(kvm, vpci->dev, 0); ioport__write32(data, val); break; case VIRTIO_PCI_QUEUE_PFN: @@ -211,7 +211,7 @@ static bool virtio_pci__io_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 switch (offset) { case VIRTIO_PCI_GUEST_FEATURES...

...A] -> GSI 16 (level, low) -> IRQ 20 ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 21 ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20 After I start the domU pciback: vpci: 0000:00:1d.0: assign to virtual slot 0 pciback: vpci: 0000:00:1d.1: assign to virtual slot 0 func 1 pciback: vpci: 0000:00:1d.2: assign to virtual slot 0 func 2 pciback: vpci: 0000:00:1d.3: assign to virtual slot 0 func 3 pciback: vpci: 0000:00:1d.7: assign to virtual slot 0 func 7 pciback: vpci:...

...missive mode is > potentially unsafe! > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: enabling permissive > mode configuration space accesses! > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: permissive mode is > potentially unsafe! > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.0: assign to > virtual slot 0 > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.1: assign to > virtual slot 0 func 1 > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0d.0: assign to > virtual slot 1 > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0d.1...

...ntially unsafe! > > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: enabling permissive > > mode configuration space accesses! > > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: permissive mode is > > potentially unsafe! > > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.0: assign to > > virtual slot 0 > > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.1: assign to > > virtual slot 0 func 1 > > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0d.0: assign to > > virtual slot 1 > > Dec 18 10:47:43 hive kerne...

...ntially unsafe! > > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: enabling permissive > > mode configuration space accesses! > > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: permissive mode is > > potentially unsafe! > > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.0: assign to > > virtual slot 0 > > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.1: assign to > > virtual slot 0 func 1 > > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0d.0: assign to > > virtual slot 1 > > Dec 18 10:47:43 hive kerne...

...pciback.hide=(00:1d.00)(00:1d.01)(00:1d.07) [ 0.000000] Unknown boot option `pciback.permissive'': ignoring [ 1.210945] pciback 0000:00:1d.0: seizing device [ 1.211082] pciback 0000:00:1d.1: seizing device [ 1.211215] pciback 0000:00:1d.7: seizing device [ 41.327529] pciback: vpci: 0000:00:1d.0: assign to virtual slot 0 [ 41.334528] pciback pci-2-0: 22 Couldn''t locate PCI device (0000:00:1d.0)! perhaps already in-use? [18253.731122] pciback: vpci: 0000:00:1d.0: assign to virtual slot 0 [18253.732869] pciback pci-3-0: 22 Couldn''t locate PCI device (0000:00...

...0d87547>] 0x7f5e40d87547 [ 260.150678] tun: Universal TUN/TAP device driver, 1.6 [ 260.150683] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [ 260.177987] device tap1.0 entered promiscuous mode [ 260.178016] br0: port 3(tap1.0) entering forwarding state [ 260.640363] pciback: vpci: 0000:00:02.0: assign to virtual slot 0 [ 260.641060] pciback: vpci: 0000:00:02.1: assign to virtual slot 0 func 1 [ 260.641563] pciback: vpci: 0000:00:1a.0: assign to virtual slot 1 [ 260.642101] pciback: vpci: 0000:00:1a.1: assign to virtual slot 1 func 1 [ 260.642680] pciback: vpci: 0000:00:...

...0d87547>] 0x7f5e40d87547 [ 260.150678] tun: Universal TUN/TAP device driver, 1.6 [ 260.150683] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [ 260.177987] device tap1.0 entered promiscuous mode [ 260.178016] br0: port 3(tap1.0) entering forwarding state [ 260.640363] pciback: vpci: 0000:00:02.0: assign to virtual slot 0 [ 260.641060] pciback: vpci: 0000:00:02.1: assign to virtual slot 0 func 1 [ 260.641563] pciback: vpci: 0000:00:1a.0: assign to virtual slot 1 [ 260.642101] pciback: vpci: 0000:00:1a.1: assign to virtual slot 1 func 1 [ 260.642680] pciback: vpci: 0000:00:...

...vice Feb 20 13:23:12 localhost kernel: pciback 0000:02:00.0: seizing device Feb 20 13:23:12 localhost kernel: pciback 0000:02:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Feb 20 13:23:12 localhost kernel: pciback 0000:02:00.0: PCI INT A disabled Feb 20 13:23:12 localhost kernel: pciback: vpci: 0000:02:00.1: assign to virtual slot 0 Feb 20 13:23:13 localhost kernel: pciback: vpci: 0000:02:00.0: assign to virtual slot 0 Feb 20 13:23:13 localhost kernel: pciback 0000:00:1c.3: seizing device Feb 20 13:23:13 localhost kernel: pciback: vpci: 0000:00:1c.3: assign to virtual slot 0 Feb 20 13...

Thanks to the kind person(s) who worked on this. I am using PCI passthrough right now and it works. I hope support is added for VT domains too; That would be extremely useful. So far I have tried a NIC, USB, and PCI Video. The NIC works flawlessly. USB works as long as the devices are present at the time the domain is started. Hotplugging USB devices seems not to work. If I open

...gt; in that case. > > 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),...

...gt; in that case. > > 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),...

...ossible because the way xen wants to do it is incompatible with the way centos wants to do it. I followed documentation on http://www.xen-support.com/?p=151 and tried booting with 'pciback.permissive pciback.hide=(06:00.0)'. This gives a hint in dmesg "kernel: xen-pciback: backend is vpci", and the device is still visible in dom0. So this obviously doesn't work. Following http://wiki.xen.org/wiki/Xen_PCI_Passthrough: [root at heimdall ~]# xl pci-assignable-add 06:00.0 xend is running, which may cause unpredictable results when using this xl command. Please shut down xe...

...0'' ] on_poweroff = ''destroy'' on_reboot = ''restart'' on_crash = ''restart'' xenmeister:~# dmesg | grep pciback Kernel command line: root=/dev/md0 ro console=tty0 pciback.hide=(00:06.0) pciback 0000:00:06.0: seizing device pciback: vpci: 0000:00:06.0: assign to virtual slot 0 pciback pci-4-0: 22 Couldn''t locate PCI device (0000:00:06.0)! perhaps already in-use? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

...0000:41:00.0 to 64 ACPI: PCI interrupt for device 0000:41:00.0 disabled ====================== === Host pciback dmesg (after setting it permissive) === pciback 0000:41:00.0: enabling permissive mode configuration space accesses! pciback 0000:41:00.0: permissive mode is potentially unsafe! pciback: vpci: 0000:41:00.0: assign to virtual slot 0 device vif1.0 entered promiscuous mode ADDRCONF(NETDEV_UP): vif1.0: link is not ready blkback: ring-ref 9, event-channel 28, protocol 1 (x86_64-abi) PCI: Enabling device 0000:41:00.0 (0000 -> 0002) ACPI: PCI Interrupt 0000:41:00.0[A] -> GSI 16 (level, l...

...0000:41:00.0 to 64 ACPI: PCI interrupt for device 0000:41:00.0 disabled ====================== === Host pciback dmesg (after setting it permissive) === pciback 0000:41:00.0: enabling permissive mode configuration space accesses! pciback 0000:41:00.0: permissive mode is potentially unsafe! pciback: vpci: 0000:41:00.0: assign to virtual slot 0 device vif1.0 entered promiscuous mode ADDRCONF(NETDEV_UP): vif1.0: link is not ready blkback: ring-ref 9, event-channel 28, protocol 1 (x86_64-abi) PCI: Enabling device 0000:41:00.0 (0000 -> 0002) ACPI: PCI Interrupt 0000:41:00.0[A] -> GSI 16 (level, l...

...1d.0) option to Dom0 kernel. I can see it working as both devices are detected by the lspci command and i''m using my ethernet card for managing my system. The problem is that the lsusb command do not show me my usb dongle. Here are some lines taken from my dom0 dmesg output : pciback: vpci: 0000:00:1d.0: assign to virtual slot 0 pciback: vpci: 0000:04:00.0: assign to virtual slot 1 PCI: Enabling device 0000:04:00.0 (0000 -&gt; 0003) ACPI: PCI Interrupt 0000:04:00.0[A] -&gt; GSI 17 (level, low) -&gt; IRQ 17 PCI: Setting latency timer of device 0000:04:00.0 to 64 PCI: Enabl...

...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...

...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...