similar to: Re: [Qemu-devel] VFIO PCIe Extended Capabilities

On Wed, 13 May 2020 00:35:47 +0000 "Derrick, Jonathan" <jonathan.derrick at intel.com> wrote: > Hi Alex, > > I'm probably not getting the translation technical details correct. > > On Mon, 2020-05-11 at 16:59 -0600, Alex Williamson wrote: > > On Mon, 11 May 2020 15:01:27 -0400 > > Jon Derrick <jonathan.derrick at intel.com> wrote: > >

On Thu, Jan 16, 2014 at 08:55:53AM +0000, WANG Cheng D wrote: > Dear Daniel, > > The thirty-party PCIe card is based on the Xilinx’ FPGA which is off the shelf, the main features are as follows: > 1) x8 Gen3, 8Gb/s per lane/direction > 2) MSI and legacy interrupt support > 3) Scatter-gather packet DMA engine provide by Northwest Logic > We hope multiple Linux Containers to

Dear Daniel, The thirty-party PCIe card is based on the Xilinx’ FPGA which is off the shelf, the main features are as follows: 1) x8 Gen3, 8Gb/s per lane/direction 2) MSI and legacy interrupt support 3) Scatter-gather packet DMA engine provide by Northwest Logic We hope multiple Linux Containers to access the PCIe card in time division mode, for example, during slot 1, lxc1 read/write the PCIe

Dear Daniel, I found that lxc driver doesn't support hostdev with type of 'pci'. As you mentioned before, I tried to expose the device node (the PCIe card) to the container, my XML is as follow: <devices> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address bus='0x01' slot='0x00'

On Mon, 11 May 2020 15:01:27 -0400 Jon Derrick <jonathan.derrick at intel.com> wrote: > The VMD endpoint provides a real PCIe domain to the guest, including Please define VMD. I'm sure this is obvious to many, but I've had to do some research. The best TL;DR summary I've found is Keith's original commit 185a383ada2e adding the controller to Linux. If there's

On 2016?08?30? 10:27, Michael S. Tsirkin wrote: > Legacy virtio devices always bypassed an IOMMU, so using them with vfio was > never safe. And it actually won't work since GPA is assumed in the device. So I'm not sure this is must since we should get a IOMMU fault in this case. > This adds a quirk detecting these and disabling VFIO unless the > noiommu mode is used. At

On 11/15/2013 03:35 PM, Thomas Kuther wrote: > Hello, > > I'm trying to migrate a working qemu command line configuration to > libvirt. > The part I'm currently failing on is: > > $ qemu-system-x86_64 -M Q35 ... -device vfio-pci,host=05:00.0,bus=pcie.0 > > The right way to translate this into libvirt XML seems to be using > <hostdev>, but I seem to be

Am 19.11.2013 11:36, schrieb Laine Stump: > On 11/15/2013 03:35 PM, Thomas Kuther wrote: >> Hello, >> >> I'm trying to migrate a working qemu command line configuration to >> libvirt. >> The part I'm currently failing on is: >> >> $ qemu-system-x86_64 -M Q35 ... -device >> vfio-pci,host=05:00.0,bus=pcie.0 >> >> The right

Does it make sense to integrate these PCI ids as part of the phantom device? Right now we have a parameter where one can specify them, but this is a nice complete list of the actual devices. ----- Forwarded message from Andrew Cooks <acooks@gmail.com> ----- Date: Wed, 24 Jul 2013 23:03:37 +0800 From: Andrew Cooks <acooks@gmail.com> To: Alex Williamson

On Wed, 13 May 2020 19:26:34 +0000 "Derrick, Jonathan" <jonathan.derrick at intel.com> wrote: > On Wed, 2020-05-13 at 11:55 -0600, Alex Williamson wrote: > > On Wed, 13 May 2020 00:35:47 +0000 > > "Derrick, Jonathan" <jonathan.derrick at intel.com> wrote: > > > > > Hi Alex, > > > > > > > [snip] > >

Hello, I'm trying to migrate a working qemu command line configuration to libvirt. The part I'm currently failing on is: $ qemu-system-x86_64 -M Q35 ... -device vfio-pci,host=05:00.0,bus=pcie.0 The right way to translate this into libvirt XML seems to be using <hostdev>, but I seem to be unable to plug it into the pcie-root port This is how the interesting part looks like when

On Fri, Apr 24, 2020 at 4:35 PM Peter Crowther <peter.crowther@melandra.com> wrote: > > On Fri, 24 Apr 2020 at 21:10, Mauricio Tavares <raubvogel@gmail.com> wrote: >> >> Let's say I have libvirt >> >> [root@vmhost2 ~]# virsh version >> [...] >> >> Running hypervisor: QEMU 2.12.0 >> [root@vmhost2 ~]# >> [...] > > When

flight 21952 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop

flight 21930 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21930/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7

flight 21993 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21993/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 8

Dear all, I have a thirty-party PCIe card in my host which can work properly in native mode. I wonder if this card can be shared by multiple containers. As far as the network interface is concerned, too many efforts have been made for it. Two dedicated cgroup resource schedulers/subsystem(net_cls, net_prio) have been provided at the kernel level, and libvirt has also done a lot of work on

On Wed, 2018-10-17 at 10:50 +0800, Han Han wrote: > In libvirt, I found pcie-expander-bus controller doesn't support pcie-to-pci-bridge and pcie-switch-upstream-port. [...] > # virsh -k0 -K0 define /tmp/c.xml Aside: the -k and -K virsh options are documented as -k | --keepalive-interval=NUM keepalive interval in seconds, 0 for disable -K |

On 10/17/2018 08:56 AM, Andrea Bolognani wrote: > On Wed, 2018-10-17 at 10:50 +0800, Han Han wrote: >> In libvirt, I found pcie-expander-bus controller doesn't support pcie-to-pci-bridge and pcie-switch-upstream-port. > [...] >> # virsh -k0 -K0 define /tmp/c.xml > Aside: the -k and -K virsh options are documented as > > -k | --keepalive-interval=NUM >

On 2014/11/6 9:59, Shannon Zhao wrote: > > > On 2014/11/5 16:43, Eric Auger wrote: >> On 10/27/2014 12:23 PM, Li Liu wrote: >>> >>> >>> On 2014/10/27 17:37, Peter Maydell wrote: >>>> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS

On 2014/10/27 17:37, Peter Maydell wrote: > On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >> To get the interrupt reason to support such VIRTIO_NET_F_STATUS >> features I add a new register offset VIRTIO_MMIO_ISRMEM which >> will help to establish a shared memory region between qemu and >> virtio-mmio device. Then the interrupt reason can