Re: [libvirt] [PATCH RESEND v2 0/4] re-introduce

ual patch mails: https://listman.redhat.com/archives/libvir-list/2022-March/229089.html Anyone else who responds to any of the mail on this thread should fix the qemu-devel address accordingly. On 3/8/22 10:33 AM, Laine Stump wrote: On 3/8/22 1:39 AM, Ani Sinha wrote: Changelog: v2 - rebased

Re: [PATCH] failover: allow to pause the VM during the migration

On 9/30/21 1:09 PM, Laurent Vivier wrote: If we want to save a snapshot of a VM to a file, we used to follow the following steps: 1- stop the VM: (qemu) stop 2- migrate the VM to a file: (qemu) migrate "exec:cat > snapshot" 3- resume the VM: (qemu) cont After that we can restore

Re: [RFC] adding a generic QAPI event for failed device hotunplug

On 3/11/21 8:19 PM, David Gibson wrote: On Thu, Mar 11, 2021 at 05:50:42PM -0300, Daniel Henrique Barboza wrote: On 3/9/21 3:22 AM, Markus Armbruster wrote: Cc: Paolo and Julia in addition to Igor, because the thread is wandering towards DeviceState member pending_deleted_event. Cc: Laine

Re: [PATCH V2] Add a new PIIX option to control PCI hot unplugging of devices on non-root buses

On 5/21/20 9:23 AM, Igor Mammedov wrote: On Thu, 21 May 2020 06:07:25 -0400 "Michael S. Tsirkin" wrote: On Thu, May 21, 2020 at 09:32:17AM +0200, Igor Mammedow wrote: On Wed, 20 May 2020 12:13:35 -0400 "Michael S. Tsirkin" wrote: On Wed, May 20, 2020 at 02:20:12PM +0200, Igor Mammedow

Re: [PATCH] Add a new PIIX option to control PCI hot unplugging of devices on non-root buses

On 4/17/20 12:35 PM, Ani Sinha wrote: +Laine On Apr 17, 2020, at 9:39 PM, Michael S. Tsirkin wrote: Problem is, I think this is not something we can support with pcie or shpc. I'm reluctant to add features that only ACPI can support, we are trying to phase that out. Hmm. I see. We use

Re: [PATCH v2] pcie_root_port: Add enable_hotplug option

On 2/19/20 9:55 AM, Julia Suvorova wrote: Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt manage it and restrict unplug for the whole machine. This is going to prevent user-initiated unplug in guests (Windows mostly). Hotplug is enabled by default. Usage: -device

Re: [PATCH] pcie_root_port: Add disable_hotplug option

On 2/18/20 1:40 PM, Julia Suvorova wrote: On Tue, Feb 18, 2020 at 6:18 PM Laine Stump wrote: On 2/18/20 11:17 AM, Julia Suvorova wrote: Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt to manage it and restrict unplug for the entire machine. This is going to prevent user

Re: [PATCH] pcie_root_port: Add disable_hotplug option

On 2/18/20 11:17 AM, Julia Suvorova wrote: Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt to manage it and restrict unplug for the entire machine. This is going to prevent user-initiated unplug in guests (Windows mostly). Usage: -device

Re: Disabling PCI "hot-unplug" for a guest (and/or a single PCI device)

On 2/4/20 1:43 PM, Daniel P. Berrangé wrote: On Mon, Feb 03, 2020 at 05:19:51PM -0500, Laine Stump wrote: Although I've never experienced it, due to not running Windows guests, I've recently learned that a Windows guest permits a user (hopefully only one with local admin privileges??!) to &quo

Disabling PCI "hot-unplug" for a guest (and/or a single PCI device)

Although I've never experienced it, due to not running Windows guests, I've recently learned that a Windows guest permits a user (hopefully only one with local admin privileges??!) to "hot-unplug" any PCI device. I've also learned that some hypervisor admins don't want to permit admins of the

Re: [PATCH v7 0/11] add failover feature for assigned network devices

On 11/4/19 4:21 PM, Parav Pandit wrote: Patches are great to see failover capability enabled on the netdevice. However it's very difficult to test it without having libvirt support. Can we please have the necessary libvirt enhancements? I'm working on libvirt support, and will make sure to

Re: [PATCH v5 02/11] pci: add option for net failover

On 10/23/19 5:15 PM, Alex Williamson wrote: On Wed, 23 Oct 2019 22:31:37 +0200 Jens Freimann wrote: On Wed, Oct 23, 2019 at 02:02:11PM -0600, Alex Williamson wrote: On Wed, 23 Oct 2019 21:30:35 +0200 Jens Freimann wrote: On Wed, Oct 23, 2019 at 12:06:48PM -0600, Alex Williamson wrote:

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On 6/12/19 7:59 AM, Jens Freimann wrote: On Wed, Jun 12, 2019 at 11:11:23AM +0200, Daniel P. Berrangé wrote: On Tue, Jun 11, 2019 at 11:42:54AM -0400, Laine Stump wrote: On 5/17/19 8:58 AM, Jens Freimann wrote: > > Command line example: > > qemu-system-x86_64 -enable-kvm -m

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On 6/11/19 11:51 AM, Michael S. Tsirkin wrote: On Tue, Jun 11, 2019 at 11:42:54AM -0400, Laine Stump wrote: On 5/17/19 8:58 AM, Jens Freimann wrote: This is another attempt at implementing the host side of the net_failover concept (https://www.kernel.org/doc/html/latest/networking

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On 5/17/19 8:58 AM, Jens Freimann wrote: This is another attempt at implementing the host side of the net_failover concept (https://www.kernel.org/doc/html/latest/networking/net_failover.html) Changes since last RFC: - work around circular dependency of commandline options. Just add

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

On 6/4/19 9:43 AM, Jens Freimann wrote: On Mon, Jun 03, 2019 at 04:36:48PM -0300, Eduardo Habkost wrote: On Mon, Jun 03, 2019 at 10:24:56AM +0200, Jens Freimann wrote: On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote: > On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On 6/3/19 2:12 PM, Michael S. Tsirkin wrote: On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote: On 5/28/19 10:54 PM, Michael S. Tsirkin wrote: On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote: On 5/21/2019 11:49 AM, Jens Freimann wrote: On Tue, May 21, 2019 at 07:37

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

On 6/3/19 4:24 AM, Jens Freimann wrote: On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote: On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote: On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote: > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

On 5/28/19 10:54 PM, Michael S. Tsirkin wrote: On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote: On 5/21/2019 11:49 AM, Jens Freimann wrote: On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote: On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote: On Mon,

Re: [Qemu-devel] [PATCH 0/2] network announce; interface selection

On 5/23/19 10:58 AM, Dr. David Alan Gilbert (git) wrote: From: "Dr. David Alan Gilbert" Laine asked for some extra features on the network announce support; this is the first one of them. It allows you to send an announce on a subset of the interfaces. Note since we've still only got one

Re: [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices

On 10/16/2018 01:02 PM, Daniel P. Berrangé wrote: > On Mon, Oct 15, 2018 at 03:14:04PM -0300, Eduardo Habkost wrote: >> On Sun, Oct 14, 2018 at 05:35:12PM -0400, Michael S. Tsirkin wrote: >>> On Fri, Oct 12, 2018 at 11:54:35PM -0300, Eduardo Habkost wrote: The current virtio-*-pci device

Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0

ed, Aug 22, 2018 at 12:36:27PM +0200, Andrea Bolognani wrote: >>>>> On Tue, 2018-08-21 at 14:21 -0400, Laine Stump wrote: >>>>>> On 08/17/2018 06:35 AM, Andrea Bolognani wrote: >>>>>>> If we decide we want to explicitly spell out the option

Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0

On 08/17/2018 06:35 AM, Andrea Bolognani wrote: > On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote: >> On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote: >>> 5) Some guest OSes that we still want to support (and which would >>> otherwise work ok

[Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0

(Several of us started an offline discussion on this topic, and it quickly became complicated, so we decided it should continue upstream. Here is a synopsis of the discussion so far (as *I've* interpreted it, so corrections are welcome and apologies in advance for anything I got wrong!) Some of

Re: [Qemu-devel] [PATCH v3 5/5] docs: update documentation considering PCIE-PCI bridge

On 08/03/2017 06:29 AM, Marcel Apfelbaum wrote: > On 03/08/2017 5:41, Laine Stump wrote: >> On 08/02/2017 01:58 PM, Marcel Apfelbaum wrote: >>> On 02/08/2017 19:26, Michael S. Tsirkin wrote: >>>> On Wed, Aug 02, 2017 at 06:36:29PM +0300, Marcel Apfelbaum wrote: >&

Re: [Qemu-devel] [PATCH v3 5/5] docs: update documentation considering PCIE-PCI bridge

On 08/02/2017 01:58 PM, Marcel Apfelbaum wrote: > On 02/08/2017 19:26, Michael S. Tsirkin wrote: >> On Wed, Aug 02, 2017 at 06:36:29PM +0300, Marcel Apfelbaum wrote: Can dmi-pci support shpc? why doesn't it? For compatibility? >>> >>> I don't know why, but the fact that it doesn't

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On 06/29/2017 03:44 PM, Alex Williamson wrote: > On Thu, 29 Jun 2017 14:50:15 -0400 > Laine Stump <la...@redhat.com> wrote: > >> On 06/28/2017 08:24 PM, Michael Roth wrote: >>> Hi everyone. Hoping to get some feedback on this approach, or some >>> altern

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On 06/28/2017 08:24 PM, Michael Roth wrote: > Hi everyone. Hoping to get some feedback on this approach, or some > alternatives proposed below, to the following issue: > > Currently libvirt immediately attempts to rebind a managed device back to the > host driver when it receives a DEVICE_DELETED

Re: [Qemu-devel] Proposal PCI/PCIe device placement on PAPR guests

On 01/12/2017 11:35 AM, Michael Roth wrote: Quoting Laine Stump (2017-01-12 08:52:10) On 01/12/2017 05:31 AM, Andrea Bolognani wrote: On Mon, 2017-01-09 at 10:46 +1100, David Gibson wrote: * To allow for hotplugged devices, libvirt should also add a number of additional, empty vPHBs

Re: [Qemu-devel] Proposal PCI/PCIe device placement on PAPR guests

On 01/12/2017 05:31 AM, Andrea Bolognani wrote: On Mon, 2017-01-09 at 10:46 +1100, David Gibson wrote: * To allow for hotplugged devices, libvirt should also add a number of additional, empty vPHBs (the PAPR spec allows for hotplug of PHBs, but this is not yet implemented in

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

On 12/15/2016 05:12 AM, Marcel Apfelbaum wrote: On 12/14/2016 10:10 PM, Laine Stump wrote: On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote: Be aware that 1 slot doesn't necessarily refer to only one device, we can have a multi-function device. Is that a fixed thing? I mean, is it always

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote: On 12/13/2016 06:00 PM, Eduardo Habkost wrote: On Tue, Dec 13, 2016 at 04:15:18PM +0200, Marcel Apfelbaum wrote: On 12/13/2016 02:42 PM, Eduardo Habkost wrote: On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote: Quick interface

Re: [Qemu-devel] [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

(Sorry for any duplicates. I sent it from the wrong address the first time) On 12/01/2016 11:18 PM, David Gibson wrote: On Fri, Nov 25, 2016 at 02:46:21PM +0100, Andrea Bolognani wrote: On Wed, 2016-11-23 at 16:00 +1100, David Gibson wrote: Existing libvirt versions assume that pseries guests

Re: [Qemu-devel] [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On 12/01/2016 11:18 PM, David Gibson wrote: On Fri, Nov 25, 2016 at 02:46:21PM +0100, Andrea Bolognani wrote: On Wed, 2016-11-23 at 16:00 +1100, David Gibson wrote: Existing libvirt versions assume that pseries guests have a legacy PCI root bus, and will base their PCI address allocation / PCI

Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default

On 11/03/2016 07:08 AM, Marcel Apfelbaum wrote: On 11/02/2016 06:01 PM, Laine Stump wrote: On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote: The shpc component is optional while ACPI hotplug is used for hot-plugging PCI devices into a PCI-PCI bridge. Disabling the shpc by default will make slot

Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default

On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote: The shpc component is optional while ACPI hotplug is used for hot-plugging PCI devices into a PCI-PCI bridge. Disabling the shpc by default will make slot 0 usable at boot time and not only for hot-plug, without loosing any functionality. Older

Re: [Qemu-devel] [PATCH V4] docs: add PCIe devices placement guidelines

On 10/31/2016 12:18 PM, Marcel Apfelbaum wrote: + +2.2.1 Plugging a PCI Express device into a PCI Express Root Port: + -device ioh3420,id=root_port1,slot=x[,chassis=y][,bus=pcie.0][,addr=z] \ + -device ,bus=root_port1 + Note that (slot, chassis) pair is mandatory and

Re: [Qemu-devel] [libvirt-users] pci-assign fails with read error on config-space file

On 10/28/2016 07:28 AM, Henning Schild wrote: Hey, i am running an unusual setup where i assign pci devices behind the back of libvirt. I have two options to do that: 1. a wrapper script for qemu that takes care of suid-root and appends arguments for pci-assign 2. virsh qemu-monitor-command ...

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 10/04/2016 12:43 PM, Laszlo Ersek wrote: On 10/04/16 18:10, Laine Stump wrote: On 10/04/2016 11:40 AM, Laszlo Ersek wrote: On 10/04/16 16:59, Daniel P. Berrange wrote: On Mon, Sep 05, 2016 at 06:24:48PM +0200, Laszlo Ersek wrote: All valid *high-level* topology goals should be permitted

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 10/04/2016 12:10 PM, Laine Stump wrote: On 10/04/2016 11:40 AM, Laszlo Ersek wrote: Small correction to your wording though: you don't want to attach the DMI-PCI bridge to the PXB device, but to the extra root bus provided by the PXB. This made me realize something - the root bus

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 10/04/2016 11:45 AM, Alex Williamson wrote: On Tue, 4 Oct 2016 15:59:11 +0100 "Daniel P. Berrange" wrote: On Mon, Sep 05, 2016 at 06:24:48PM +0200, Laszlo Ersek wrote: On 09/01/16 15:22, Marcel Apfelbaum wrote: +2.3 PCI only hierarchy +== +Legacy

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 10/04/2016 11:40 AM, Laszlo Ersek wrote: On 10/04/16 16:59, Daniel P. Berrange wrote: On Mon, Sep 05, 2016 at 06:24:48PM +0200, Laszlo Ersek wrote: On 09/01/16 15:22, Marcel Apfelbaum wrote: +2.3 PCI only hierarchy +== +Legacy PCI devices can be plugged into pcie.0 as

Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration

On 09/28/2016 03:59 PM, Neo Jia wrote: On Wed, Sep 28, 2016 at 07:45:38PM +, Tian, Kevin wrote: From: Neo Jia [mailto:c...@nvidia.com] Sent: Thursday, September 29, 2016 3:23 AM On Thu, Sep 22, 2016 at 03:26:38PM +0100, Daniel P. Berrange wrote: On Thu, Sep 22, 2016 at 08:19:21AM -0600,

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 09/07/2016 03:39 PM, Marcel Apfelbaum wrote: On 09/07/2016 08:55 PM, Laine Stump wrote: On 09/07/2016 04:06 AM, Marcel Apfelbaum wrote: On 09/07/2016 09:21 AM, Gerd Hoffmann wrote: Hi, ports, if that's allowed). For example: - 1-32 ports needed: use root ports only - 33-64 ports

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 09/07/2016 03:04 AM, Gerd Hoffmann wrote: Hi, Side note for usb: In practice you don't want to use the tons of uhci/ehci controllers present in the original q35 but plug xhci into one of the pcie root ports instead (unless your guest doesn't support xhci). I've wondered about that

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 09/07/2016 04:06 AM, Marcel Apfelbaum wrote: On 09/07/2016 09:21 AM, Gerd Hoffmann wrote: Hi, ports, if that's allowed). For example: - 1-32 ports needed: use root ports only - 33-64 ports needed: use 31 root ports, and one switch with 2-32 downstream ports I expect you rarely need

Re: [Qemu-devel] [libvirt] qapi DEVICE_DELETED event issued *before* instance_finalize?!

On 09/05/2016 10:18 PM, Alex Williamson wrote: On Mon, 5 Sep 2016 11:36:55 +0200 Paolo Bonzini wrote: On 05/09/2016 11:23, Markus Armbruster wrote: On the other hand, it is clearly documented that the DEVICE_DELETED event is sent as soon as guest acknowledges completion

Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

On 09/06/2016 07:35 AM, Gerd Hoffmann wrote: While talking about integrated devices: There is docs/q35-chipset.cfg, which documents how to mimic q35 with integrated devices as close and complete as possible. Usage: qemu-system-x86_64 -M q35 -readconfig docs/q35-chipset.cfg $args Side note

Re: [Qemu-devel] [libvirt] qapi DEVICE_DELETED event issued *before* instance_finalize?!

On 09/05/2016 05:36 AM, Paolo Bonzini wrote: On 05/09/2016 11:23, Markus Armbruster wrote: On the other hand, it is clearly documented that the DEVICE_DELETED event is sent as soon as guest acknowledges completion of device removal. So libvirt's buggy if we'd follow documentation strictly. But

Re: [Qemu-devel] [libvirt] [PATCH v7 0/4] Add Mediated device support

On 09/02/2016 05:44 PM, Paolo Bonzini wrote: On 02/09/2016 22:19, John Ferlan wrote: We don't have such a pool for GPU's (yet) - although I suppose they could just become a class of storage pools. The issue being nodedev device objects are not saved between reboots. They are generated on the

Re: [Qemu-devel] [libvirt] [PATCH v7 0/4] Add Mediated device support

On 09/01/2016 12:59 PM, Alex Williamson wrote: On Thu, 1 Sep 2016 18:47:06 +0200 Michal Privoznik wrote: On 31.08.2016 08:12, Tian, Kevin wrote: From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Wednesday, August 31, 2016 12:17 AM Hi folks, At KVM Forum

Re: [Qemu-devel] [libvirt] [RFC] libvirt vGPU QEMU integration

On 08/24/2016 06:29 PM, Daniel P. Berrange wrote: On Thu, Aug 18, 2016 at 09:41:59AM -0700, Neo Jia wrote: Hi libvirt experts, I am starting this email thread to discuss the potential solution / proposal of integrating vGPU support into libvirt for QEMU. Some quick background, NVIDIA is

Re: [Qemu-devel] [libvirt] [RFC] libvirt vGPU QEMU integration

On 08/18/2016 12:41 PM, Neo Jia wrote: Hi libvirt experts, I am starting this email thread to discuss the potential solution / proposal of integrating vGPU support into libvirt for QEMU. Thanks for the detailed description. This is very helpful. Some quick background, NVIDIA is

Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device?

On 08/19/2016 11:43 AM, Andrea Bolognani wrote: On Thu, 2016-08-18 at 08:38 +0200, Andrew Jones wrote: Finally, FWIW, with a guest kernel of 4.6.4-301.fc24.aarch64. The following qemu command line works for me. (notice the use of PCIe), and my network interface gets labeled enp0s1. $QEMU

Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device?

On 08/18/2016 08:43 AM, Kevin Zhao wrote: Hi Laine, Thanks :-) I also has a little questions below. On 18 August 2016 at 01:00, Laine Stump <la...@redhat.com> wrote: On 08/17/2016 12:13 PM, Andrew Jones wrote: On Wed, Aug 17, 2016 at 08:08:11PM +0800, Kevin Zhao wrote:

Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device?

On 08/18/2016 08:10 AM, Marcel Apfelbaum wrote: On 08/17/2016 08:00 PM, Laine Stump wrote: What I'm not sure about is whether we should always auto-add an extra pcie-*-root to be sure a device can be hotplugged, or if we should admit that 1 available slot isn't good enough for all

Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device?

On 08/18/2016 03:41 AM, Andrew Jones wrote: On Wed, Aug 17, 2016 at 01:00:05PM -0400, Laine Stump wrote: On 08/17/2016 12:13 PM, Andrew Jones wrote: On Wed, Aug 17, 2016 at 08:08:11PM +0800, Kevin Zhao wrote: Hi all, Now I'm investigating net device hot plug and disk hotplug for AArch64

Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device?

On 08/17/2016 12:13 PM, Andrew Jones wrote: On Wed, Aug 17, 2016 at 08:08:11PM +0800, Kevin Zhao wrote: Hi all, Now I'm investigating net device hot plug and disk hotplug for AArch64. For virtio , the default address is virtio-mmio. After Libvirt 1.3.5, user can explicitly specify the

Re: [Qemu-devel] [PATCH V2 0/4] hw/pcie: Multi-root support for Q35

On 11/16/2015 05:37 AM, Michael S. Tsirkin wrote: On Mon, Nov 16, 2015 at 12:34:11PM +0200, Marcel Apfelbaum wrote: On 11/16/2015 12:11 PM, Paolo Bonzini wrote: On 16/11/2015 11:10, Marcel Apfelbaum wrote: What would you lose? Hotplug? Without the bridge? Yes. However the user can add it

[Qemu-devel] which machinetypes have an integrated/implied IDE controller?

For a long time, libvirt assumed by default that all types of virtual machines had an integrated IDE controller named "ide" that wasn't specified on the qemu commandline. Since that caused problems specifically for the Q35 machine type (which has an *ahci* controller that it perplexingly calls

Re: [Qemu-devel] [libvirt] [RFC 0/7] Live Migration with Pass-through Devices proposal

On 05/19/2015 05:07 AM, Michael S. Tsirkin wrote: On Wed, Apr 22, 2015 at 10:23:04AM +0100, Daniel P. Berrange wrote: On Fri, Apr 17, 2015 at 04:53:02PM +0800, Chen Fan wrote: backgrond: Live migration is one of the most important features of virtualization technology. With regard to recent

Re: [Qemu-devel] [libvirt] [RFC 0/7] Live Migration with Pass-through Devices proposal

On 04/22/2015 12:22 AM, Chen Fan wrote: Hi Laine, Thanks for your review for my patches. and do you know that solarflare's patches have made some update version since https://www.redhat.com/archives/libvir-list/2012-November/msg01324.html ? if not, I hope to go on to complete this

Re: [Qemu-devel] [libvirt] [RFC 0/7] Live Migration with Pass-through Devices proposal

On 04/22/2015 01:20 PM, Dr. David Alan Gilbert wrote: * Daniel P. Berrange (berra...@redhat.com) wrote: On Wed, Apr 22, 2015 at 06:12:25PM +0100, Dr. David Alan Gilbert wrote: * Daniel P. Berrange (berra...@redhat.com) wrote: On Wed, Apr 22, 2015 at 06:01:56PM +0100, Dr. David Alan Gilbert

Re: [Qemu-devel] [libvirt] [RFC 0/7] Live Migration with Pass-through Devices proposal

On 04/23/2015 04:34 AM, Chen Fan wrote: On 04/20/2015 06:29 AM, Laine Stump wrote: On 04/17/2015 04:53 AM, Chen Fan wrote: - on destination side, check whether need to hotplug new NIC according to specified XML. usually, we use migrate --xml command option to specify the destination

Re: [Qemu-devel] [libvirt] [RFC 0/7] Live Migration with Pass-through Devices proposal

On 04/17/2015 04:53 AM, Chen Fan wrote: backgrond: Live migration is one of the most important features of virtualization technology. With regard to recent virtualization techniques, performance of network I/O is critical. Current network I/O virtualization (e.g. Para-virtualized I/O,

Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(tp, NULL); forever

On 01/13/2015 05:01 PM, Gerhard Wiesinger wrote: On 13.01.2015 22:16, Paolo Bonzini wrote: On 13/01/2015 22:14, Gerhard Wiesinger wrote: I also had a look at the kernel code again: http://lxr.free-electrons.com/source/kernel/time/timekeeping.c?v=3.17#L493 499 do { 500

Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On 05/23/2014 06:50 AM, Marcelo Tosatti wrote: On Thu, May 22, 2014 at 01:33:14PM -0600, Eric Blake wrote: [Adding qemu] On 05/22/2014 05:07 AM, Laine Stump wrote: commit e31b5cf393857 attempted to fix libvirt's VIR_DOMAIN_EVENT_ID_RTC_CHANGE, which is documentated to always s/documentated

Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On 05/23/2014 12:17 PM, Laine Stump wrote: *However*, this discussion forced me to investigate some of the basic assumptions that I'd been making when coming in to fix this bug. In particular, my assumption was that the value of adjustment that was set in the status would be preserved across

Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On 05/23/2014 05:54 PM, Eric Blake wrote: On 05/23/2014 04:19 AM, Laine Stump wrote: On 05/23/2014 12:17 PM, Laine Stump wrote: *However*, this discussion forced me to investigate some of the basic assumptions that I'd been making when coming in to fix this bug. In particular, my assumption

Re: [Qemu-devel] Attaching PCI devices to the PCIe root complex

On 09/30/2013 05:55 AM, Markus Armbruster wrote: Michael S. Tsirkin m...@redhat.com writes: I never heard of a pci/pci express one but it's not impossible I think. PCI on one side of the card, PCIe on the other, and a switchable backplate? Weird :) Again, I can't see why we'd want to model

Re: [Qemu-devel] Attaching PCI devices to the PCIe root complex

On 09/25/2013 04:48 AM, Marcel Apfelbaum wrote: On Wed, 2013-09-25 at 10:01 +0300, Michael S. Tsirkin wrote: On Tue, Sep 24, 2013 at 06:01:02AM -0400, Laine Stump wrote: When I added support for the Q35-based machinetypes to libvirt, I specifically prohibited attaching any PCI devices

Re: [Qemu-devel] Attaching PCI devices to the PCIe root complex

On 09/25/2013 06:00 AM, Michael S. Tsirkin wrote: On Wed, Sep 25, 2013 at 05:39:37AM -0400, Laine Stump wrote: However it is done, each controller will need to have two sets of flags - one for what it can plug into, and one for what can be plugged into it. Not just into it - what can

[Qemu-devel] Attaching PCI devices to the PCIe root complex

When I added support for the Q35-based machinetypes to libvirt, I specifically prohibited attaching any PCI devices (with the exception of graphics controllers) to the PCIe root complex, and had planned to prevent attaching them to PCIe root ports (ioh3420 device) and PCIe downstream switch ports

Re: [Qemu-devel] default slot used for vga device on q35 machines

On 08/02/2013 02:49 AM, Gerd Hoffmann wrote: Hi, qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server -vnc :15 -vga std -usb Then ran query-pci in the qmp monitor and found that the vga device is put at slot 1 instead of slot 2. My questions: 1) Is this difference

Re: [Qemu-devel] default slot used for vga device on q35 machines

On 08/02/2013 03:23 AM, Markus Armbruster wrote: Gerd Hoffmann kra...@redhat.com writes: Hi, qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server -vnc :15 -vga std -usb Then ran query-pci in the qmp monitor and found that the vga device is put at slot 1 instead of slot

[Qemu-devel] default slot used for vga device on q35 machines

libvirt makes an assumption that if you specify -vga qxl instead of -device qxl-vga,..., the vga device will be connected to slot 2. I learned this in a recent discussion about a bug caused by switching over to using the former syntax (in order to support multiheaded QXL):

[Qemu-devel] listing bus option in output of qemu -device $devname, ?

I was just talking to Michael Tsirkin on IRC about determining which devices accepted a bus option, and asked why this option doesn't show up in the output of qemu -device $devname,? (as happens for addr, etc). He said this is an old bug, and asked that I send mail to the list as a reminder that

Re: [Qemu-devel] q35 machine type and libvirt.

On 02/06/2013 02:13 PM, Laine Stump wrote: Now that qemu is getting the q35 machine type, libvirt needs to support it. In an attempt to make sure that libvirt actually does something useful with qemu's new machine type, I'm revisiting this topic and trying to get a more thorough understanding

[Qemu-devel] q35 machine type and libvirt.

Now that qemu is getting the q35 machine type, libvirt needs to support it. As far as I understand, from libvirt's point of view, q35 is just another x86_64 system, but with a different set of implicit devices, and possibly some extra rules limiting which devices can be plugged into which

Re: [Qemu-devel] [libvirt] [Qemu PATCH v2] add a boot option to do strict boot

On 01/09/2013 10:22 AM, Daniel P. Berrange wrote: On Wed, Jan 09, 2013 at 08:14:07AM -0700, Eric Blake wrote: On 01/09/2013 01:39 AM, Amos Kong wrote: Current seabios will try to boot from selected devices first, if they are all failed, seabios will also try to boot from un-selected devices.

Re: [Qemu-devel] [libvirt] Problems using netdev_del+netdev_add w/o corresponding device_del+device_add

On 10/15/2012 05:25 AM, Daniel P. Berrange wrote: On Mon, Oct 15, 2012 at 10:30:07AM +0200, Stefan Hajnoczi wrote: On Sat, Oct 13, 2012 at 04:47:14PM -0400, Laine Stump wrote: Here is the sequence sent to disconnect only the host side, then reconnect it with a new tap device. (although the fd

Re: [Qemu-devel] Problems using netdev_del+netdev_add w/o corresponding device_del+device_add

On 10/13/2012 04:47 PM, Laine Stump wrote: I am attempting to enhance libvirt's virDomainUpdateDeviceFlags() API to support changing just about anything about the host side of a PCI network device without actually detaching the PCI device from the guest. Here is a patch I sent to the libvirt

[Qemu-devel] Problems using netdev_del+netdev_add w/o corresponding device_del+device_add

I am attempting to enhance libvirt's virDomainUpdateDeviceFlags() API to support changing just about anything about the host side of a PCI network device without actually detaching the PCI device from the guest. Here is a patch I sent to the libvirt mailing list that I had thought would accomplish

Re: [Qemu-devel] QEMU fstatfs(2) and libvirt SELinux policy

On 03/09/2012 09:16 AM, Jiri Denemark wrote: Hi. On Fri, Mar 09, 2012 at 11:32:47 +, Stefan Hajnoczi wrote: ... static __inline__ int platform_test_xfs_fd(int fd) { struct statfs buf; if (fstatfs(fd, buf) 0) return 0; return (buf.f_type ==

Re: [Qemu-devel] [PATCH 3/4] net: split hostname and service by last colon

On 03/02/2012 05:35 AM, Kevin Wolf wrote: Am 02.03.2012 10:58, schrieb Amos Kong: On 02/03/12 11:38, Amos Kong wrote: --- a/net.c +++ b/net.c @@ -84,7 +84,7 @@ static int get_str_sep(char *buf, int buf_size, const char **pp, int sep) const char *p, *p1; int len; p = *pp;

[Qemu-devel] Re: [PATCH] migration: Issue 'cont' only on successful incoming migration

On 07/26/2010 10:23 AM, Luiz Capitulino wrote: On Sat, 24 Jul 2010 13:01:24 +0530 Amit Shahamit.s...@redhat.com wrote: On (Fri) Jul 23 2010 [15:08:18], Luiz Capitulino wrote: diff --git a/monitor.c b/monitor.c index 45fd482..d12a7b5 100644 --- a/monitor.c +++ b/monitor.c @@ -1056,6 +1056,10

Re: [Qemu-devel] [Bug 524447] Re: virsh save is very slow

Bug description: As reported here: http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html virsh save is very slow - it writes the image at around 1MB/sec on my test system. (I think I saw a bug report for this issue on Fedora's bugzilla, but I can't find it now...) Here's

[Qemu-devel] race condition when exec'ing qemu -incoming followed by monitor cont

(Please forgive (and correct!) any inaccuracies in my description of qemu's workings - I've only recently started looking at it directly, rather than through the lens of libvirt) libvirt implements a domain restore operation by: 0) start with a previously saved domain image in a file 1) open

Re: [Qemu-devel] race condition when exec'ing qemu -incoming followed by monitor cont

On 04/09/2010 12:03 PM, Laine Stump wrote: (Please forgive (and correct!) any inaccuracies in my description of qemu's workings - I've only recently started looking at it directly, rather than through the lens of libvirt) libvirt implements a domain restore operation by: 0) start