On 6/28/19 5:06 AM, Cornelia Huck wrote:
> On Thu, 27 Jun 2019 19:57:04 -0600
> Alex Williamson wrote:
>
>> On Thu, 27 Jun 2019 15:15:02 -0600
>> Alex Williamson wrote:
>>
>>> On Thu, 27 Jun 2019 09:38:32 -0600
>>> Alex Williamson wrote:
> On 6/27/19 8:26 AM, Cornelia Huck wrote:
>>
On 6/27/19 11:38 AM, Alex Williamson wrote:
> On Thu, 27 Jun 2019 11:00:31 -0400
> Matthew Rosato wrote:
>
>> On 6/27/19 8:26 AM, Cornelia Huck wrote:
>>> On Wed, 26 Jun 2019 19:53:50 -0600
>>> Alex Williamson wrote:
>>>
>>>> On Wed,
On 6/27/19 8:26 AM, Cornelia Huck wrote:
> On Wed, 26 Jun 2019 19:53:50 -0600
> Alex Williamson wrote:
>
>> On Wed, 26 Jun 2019 08:37:20 -0600
>> Alex Williamson wrote:
>>
>>> On Wed, 26 Jun 2019 11:58:06 +0200
>>> Cornelia Huck wrote:
>>>
On Tue, 25 Jun 2019 16:52:51 -0600
Alex Wi
On 6/13/19 9:54 AM, Cornelia Huck wrote:
> On Fri, 7 Jun 2019 14:30:48 -0400
> Tony Krowiak wrote:
>
>> On 6/7/19 10:56 AM, Cornelia Huck wrote:
>>> On Thu, 6 Jun 2019 12:45:29 -0400
>>> Matthew Rosato wrote:
>>>
>>>> On 6/6/19 10:44 A
On 6/6/19 10:44 AM, Cornelia Huck wrote:
> This patch adds a very rough implementation of additional config data
> for mdev devices. The idea is to make it possible to specify some
> type-specific key=value pairs in the config file for an mdev device.
> If a device is started automatically, the dev
On 07/07/2017 04:07 AM, Longpeng(Mike) wrote:
> As virtio-crypto has been supported in QEMU 2.8 and the frontend
> driver has been merged in linux 4.10, so it's necessary to support
> virtio-crypto in libvirt.
>
> ---
Hi Mike,
Seems like this topic has gone quiet.. Is there a v5 in the works?
om John, so I'll leave it to his judgment.
Regardless, code still looks good to me so you can feel free to keep my
reviewed-by tag for the set, whether patches 1-3 are squashed or not.
Reviewed-by: Matthew Rosato
>
> docs/formatdomain.html.in | 10 +++---
> docs/sch
ocess.c b/src/qemu/qemu_process.c
> index 0028283..a19e71a 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -3182,6 +3182,9 @@ int qemuProcessStopCPUs(virQEMUDriverPtr driver,
> if (ret < 0)
> goto cleanup;
>
> +/* de-activate netdevs after stopping CPUs */
> +ignore_value(qemuInterfaceStopDevices(vm->def));
> +
> if (priv->job.current)
> ignore_value(virTimeMillisNow(&priv->job.current->stopped));
>
Reviewed by: Matthew Rosato
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
qemuInterfaceStartDevices(vm->def) < 0)
> goto cleanup;
>
> VIR_DEBUG("Using lock state '%s'", NULLSTR(priv->lockState));
>
I agreed to this in a separate thread & code looks good so:
Reviewed by: Matthew Rosato
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 12/11/2014 01:35 PM, Laine Stump wrote:
> On 09/16/2014 04:50 PM, Matthew Rosato wrote:
>>
>> #include "cpu/cpu.h"
>> #include "datatypes.h"
>> @@ -2947,6 +2948,12 @@ qemuProcessStartCPUs(virQEMUDriverPtr driver,
>> virDomainObjPtr vm,
&
r MAC registration until right before
the guest can actually use the device -- In other words, right
before starting guest CPUs.
Signed-off-by: Matthew Rosato
---
src/Makefile.am |3 +-
src/conf/domain_conf.h |2 ++
src/lxc/lxc_process.c |4 ++-
src/qemu/qemu_comm
called for any reason that the system would be initializing,
as well as potentially after a failed migration.
Matthew Rosato (1):
network: Bring netdevs online later
src/Makefile.am |3 +-
src/conf/domain_conf.h |2 ++
src/lxc/lxc_process.c |4 ++-
src/qemu
On 09/16/2014 04:50 PM, Matthew Rosato wrote:
> Currently, MAC registration occurs during device creation, which is
> early enough that, during live migration, you end up with duplicate
> MAC addresses on still-running source and target devices, even though
> the target device isn'
r MAC registration until right before
the guest can actually use the device -- In other words, right
before starting guest CPUs.
Signed-off-by: Matthew Rosato
---
Associated BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1081461
Changes for v3:
* Some minor formatting fixes.
* in qemuNetworkIfaceConnect
On 08/28/2014 09:56 AM, Martin Kletzander wrote:
> On Wed, Aug 27, 2014 at 10:34:14AM -0400, Matthew Rosato wrote:
>> Currently, MAC registration occurs during device creation, which is
>> early enough that, during live migration, you end up with duplicate
>> MAC addresses on
On 08/28/2014 08:45 AM, Martin Kletzander wrote:
> On Wed, Aug 27, 2014 at 10:34:13AM -0400, Matthew Rosato wrote:
>> Currently, there is one flag passed in during macvtap creation
>> (withTap) -- Let's convert this field to an unsigned int flag
>> field for future expa
tDef
during qemuPhysIfaceConnect. As Laine mentioned, could use this field in
a future patch to eliminate passing virNetDevVPortProfileOp everywhere.
* Add qemu_interface.c and qemu_interface.h to encapsulate new functions.
Matthew Rosato (2):
util: Introduce flags field for macvtap crea
r MAC registration until right before
the guest can actually use the device -- In other words, right
before starting guest CPUs.
Signed-off-by: Matthew Rosato
---
src/Makefile.am |3 +-
src/conf/domain_conf.h |2 ++
src/lxc/lxc_process.c |4 ++-
src/qemu/qemu_comm
Currently, there is one flag passed in during macvtap creation
(withTap) -- Let's convert this field to an unsigned int flag
field for future expansion.
Signed-off-by: Matthew Rosato
---
src/lxc/lxc_process.c |4 ++--
src/qemu/qemu_command.c |6 --
src
On 07/23/2014 09:49 AM, Martin Kletzander wrote:
> On Tue, Jul 01, 2014 at 02:00:57PM -0400, Matthew Rosato wrote:
>> Defer MAC registration until net devices are actually going
>> to be used by the guest. This patch does so by setting the
>> devices online just befor
On 07/23/2014 10:08 AM, Eric Blake wrote:
> On 07/23/2014 07:49 AM, Martin Kletzander wrote:
>> On Tue, Jul 01, 2014 at 02:00:57PM -0400, Matthew Rosato wrote:
>>> Defer MAC registration until net devices are actually going
>>> to be used by the guest. This p
On 07/23/2014 08:56 AM, Martin Kletzander wrote:
> On Tue, Jul 01, 2014 at 02:00:56PM -0400, Matthew Rosato wrote:
>> Currently, there is one flag passed in during macvtap creation
>> (withTap) -- Let's convert this field to an unsigned int flag
>> field for future expa
On 07/01/2014 02:00 PM, Matthew Rosato wrote:
> The following patchset introduces code to defer setting netdevs online
> (and therefore registering MACs) until right before beginning guest
> CPU execution. The first patch introduces some infrastructure changes
> in preparation o
virNetDevVPortProfileOp in virDomainNetDef
during qemuPhysIfaceConnect. As Laine mentioned, could use this field in
a future patch to eliminate passing virNetDevVPortProfileOp everywhere.
* Add qemu_interface.c and qemu_interface.h to encapsulate new functions.
Matthew Rosato (2):
util: Introduce flags
Defer MAC registration until net devices are actually going
to be used by the guest. This patch does so by setting the
devices online just before starting guest CPUs.
Signed-off-by: Matthew Rosato
---
src/Makefile.am |1 +
src/conf/domain_conf.h |2 ++
src/lxc
Currently, there is one flag passed in during macvtap creation
(withTap) -- Let's convert this field to an unsigned int flag
field for future expansion.
Signed-off-by: Matthew Rosato
---
src/lxc/lxc_process.c |2 +-
src/qemu/qemu_command.c |3 ++-
src/util/virnetdevmacv
On 06/09/2014 08:55 AM, Laine Stump wrote:
> On 06/04/2014 05:55 PM, Matthew Rosato wrote:
>> Defer MAC registration until net devices are actually going
>> to be used by the guest. This patch does so by setting the
>> devices online just before starting guest CPUs.
>
ne/Wangrui, is this the sort of thing you had in mind?
Previous thread:
https://www.redhat.com/archives/libvir-list/2014-May/msg00427.html
Associated BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1081461
Signed-off-by: Matthew Rosato
---
src/qemu/qemu_command.c
On 05/05/2014 12:33 PM, Matthew Rosato wrote:
> On 05/05/2014 12:26 PM, Matthew Rosato wrote:
>> When generating macvtaps via virNetDevMacVLanCreateWithVPortProfile,
>> the macvtap device is unconditionally set to the up state. However,
>> during migration, this results in
On 05/05/2014 12:26 PM, Matthew Rosato wrote:
> When generating macvtaps via virNetDevMacVLanCreateWithVPortProfile,
> the macvtap device is unconditionally set to the up state. However,
> during migration, this results in a case where both the source and
> target system are simul
the target macvtap up until later in the
migration to shrink this window.
Signed-off-by: Matthew Rosato
---
src/qemu/qemu_migration.c | 18 ++
src/util/virnetdevmacvlan.c | 11 ---
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/qemu
On 07/01/2013 06:42 PM, Laine Stump wrote:
On 07/01/2013 11:04 AM, Viktor Mihajlovski wrote:
From: Matthew Rosato
If an error occurs during qemuDomainAttachNetDevice after the macvtap
was created in qemuPhysIfaceConnect, the macvtap device gets left behind.
This patch adds code to the cleanup
32 matches
Mail list logo
