similar to: network config not working on newer libvirt

On 9/4/20 12:38 AM, daggs wrote: > Greetings, > > up until a year ago, I was running a server with Debian 10 (stable) on it with the latest versions of libvirt, qemu and kernel 4.19.x Debian 10 had to offer (both libvirt and qemu versions were really old). > > the network config was simple, one of the vm acted as a router and provided the ip for both the host and the vm. >

Greetings, I've setup an vm with openwrt in it, defined a isolated lan between the vm and the host and booted the vm up. I see the vm is up, made sure the vnic is visible in both the host and guest and added it to the br in the guest. I've issued an dhcpd call on the vnic (labeled vnic0) in the host and got an ip, see: dagg@NCC-5001D ~ $ dhcpcd vnet0 DUID

dummy0 Link encap:Ethernet HWaddr C6:C8:2A:04:FD:23 BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX

On 7/20/20 12:38 PM, daggs wrote: > Greetings, > > I've setup an vm with openwrt in it, defined a isolated lan between the vm and the host and booted the vm up. > I see the vm is up, made sure the vnic is visible in both the host and guest and added it to the br in the guest. > I've issued an dhcpd call on the vnic (labeled vnic0) in the host and got an ip, see: >

Greetings! I am trying to do a hot driver swap between the vfio-pci and nouveau drivers for my secondary Nvidia graphics card. I boot up with vfio-pci enabled. With this script I give control over the GPU to nouveau: echo "0000:01:00.0" > /sys/bus/pci/devices/0000\:01\:00.0/driver/unbind echo 0x10de 0x11c6 > /sys/bus/pci/drivers/nouveau/new_id echo 1 > /sys/bus/pci/rescan

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson <alex.williamson at redhat.com> wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson <alex.williamson at redhat.com> wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > > > Modern virtio pci devices can set

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson <alex.williamson at redhat.com> wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson <alex.williamson at redhat.com> wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > > > Modern virtio pci devices can set

On Mon, 18 Apr 2016 12:58:28 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

On Mon, 18 Apr 2016 12:58:28 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

On Tue, 30 Aug 2016 05:27:17 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

On Tue, 30 Aug 2016 05:27:17 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

Good morning, there is a typo in my description; the line <address domain='0x0' bus='0x1' slot='0x00' function='0x0'/> should be <address domain='0x0' bus='0x2' slot='0x00' function='0x0'/> That was correct in my xml-file. Isn't there anybody how can help me with that? Regards Michael Weis Von:

Greetings, I have two vms, one is a router and the other one is a client, for some reason, the client vm is unable get ip via dhcp from the router vm. here are outputs: vm1.xml: <interface type='bridge'> <mac address='52:54:00:54:78:be'/> <source bridge='virbr0'/> <model type='virtio'/> <address

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable errors are not reported to guest at all.

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable errors are not reported to guest at all.

Hi Alex, I've been playing around with VFIO and megasas (of course). What I did now was switching between VFIO and 'normal' operation, ie emulated access. megasas is happily running under VFIO, but when I do an emergency stop like killing the Qemu session the PCI device is not properly reset. IE when I load 'megaraid_sas' after unbinding the vfio_pci module the driver

Hi Alex, I've been playing around with VFIO and megasas (of course). What I did now was switching between VFIO and 'normal' operation, ie emulated access. megasas is happily running under VFIO, but when I do an emergency stop like killing the Qemu session the PCI device is not properly reset. IE when I load 'megaraid_sas' after unbinding the vfio_pci module the driver

Hi Pierre, thanks for your reply. I am using kernel 3.10.0-123.8.1.el7.x86_64. The kernel modul used after nodedev-detach is vfio-pci This is the output of lspci -vv after I did a virsh nodedev-detatch pci_0000_02_00_0 02:00.0 Ethernet controller: PLX Technology, Inc. Device 235e Subsystem: PLX Technology, Inc. Device 235e Control: I/O- Mem- BusMaster- SpecCycle- MemWINV-

This is an attempt to allow enabling IOMMU for DMA. Design: - new feature bit IOMMU_PLATFORM which means host won't bypass IOMMU - virtio core uses DMA API if it sees IOMMU_PLATFORM - add quirk for vfio to disable device unless IOMMU_PLATFORM is set or the no-iommu mode is enabled - while I'm not sure how it will be used, it seems like a good idea to also have

This is an attempt to allow enabling IOMMU for DMA. Design: - new feature bit IOMMU_PLATFORM which means host won't bypass IOMMU - virtio core uses DMA API if it sees IOMMU_PLATFORM - add quirk for vfio to disable device unless IOMMU_PLATFORM is set or the no-iommu mode is enabled - while I'm not sure how it will be used, it seems like a good idea to also have