* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Wed, 5 Apr 2023 at 15:56, Dr. David Alan Gilbert
> wrote:
> >
> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > > I think on balance I would go for:
> > > * remove (ie deprecate-and-dr
tb', for consistency
>(then 'info status' matches the QMP query-status)
If it's pretty obscure, then the qom-set/get is fine; as long
as there is a way to do it, then just make sure in the commit
message you say what the replacement command is.
Dave
> In particular, the fact that messing with this obscure debug
> functionality requires updating the reference-output for a
> bunch of io tests that have no interest at all in it rather
> suggests that even if we did want to expose this to QMP that
> the query-status command is the wrong place to do it.
>
> thanks
> -- PMM
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
tests/qtest/test-hmp.c
> @@ -64,6 +64,7 @@ static const char *hmp_cmds[] = {
> "screendump /dev/null",
> "sendkey x",
> "singlestep on",
> +"one-insn-per-tb on",
OK, it wouldn't be bad if this list got a bit back into near alph
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, May 12, 2022 at 05:58:46PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Wed, May 11, 2022 at 07:31:45PM +0200, Claudio Fontana wrote:
> > > > Th
t can save and restore with differing number of threads,
> > and can even dynamically change the number of threads
> > in the middle of the save/restore operation
> >
> > As David G has pointed out the impl is not trivial on the QEMU
> > side, but from what I understand of the migration code, it is
> > certainly viable. Most importantly I think it puts us in a
> > better position for long term feature enhancements later by
> > taking the middle man (libvirt) out of the equation, letting
> > QEMU directly know what medium it is saving/restoring to/from.
> >
> >
> > With regards,
> > Daniel
> > --
> > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange
> > :|
> > |: https://libvirt.org -o-https://fstop138.berrange.com
> > :|
> > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange
> > :|
> >
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Dave
> * Add a migration capability "bypass-cache" to
> indicate we want O_DIRECT to bypass host I/O
> cache. Again limited to some migration protocols
>
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Mon, Apr 25, 2022 at 01:33:41PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Mon, Apr 25, 2022 at 12:04:37PM +0100, Dr. David Alan Gilbert wrote:
> > > &g
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Mon, Apr 25, 2022 at 12:04:37PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > I'm worried that we could be taking ourselves down a dead-end by
> > > trying to o
n disk to match the RAM page
> location.
Hmm so what I'm not sure of is whether it makes sense to use the normal
migration flow/code for this or not; and you're suggesting a few
possibly contradictory things.
Adding a file: protocol would be pretty easy (whether it went via
the blockdev layer or not); g
* Claudio Fontana (cfont...@suse.de) wrote:
> On 4/7/22 3:57 PM, Claudio Fontana wrote:
> > On 4/7/22 3:53 PM, Dr. David Alan Gilbert wrote:
> >> * Claudio Fontana (cfont...@suse.de) wrote:
> >>> On 4/5/22 10:35 AM, Dr. David Alan Gilbert wrote:
> >>>&g
* Claudio Fontana (cfont...@suse.de) wrote:
> On 4/5/22 10:35 AM, Dr. David Alan Gilbert wrote:
> > * Claudio Fontana (cfont...@suse.de) wrote:
> >> On 3/28/22 10:31 AM, Daniel P. Berrangé wrote:
> >>> On Sat, Mar 26, 2022 at 04:49:46PM +0100, Claudio Fontana wro
dio Fontana wrote:
> >>>> On 3/17/22 4:03 PM, Dr. David Alan Gilbert wrote:
> >>>>> * Claudio Fontana (cfont...@suse.de) wrote:
> >>>>>> On 3/17/22 2:41 PM, Claudio Fontana wrote:
> >>>>>>> On 3/17/22 11:25 AM, Daniel P. Ber
~5 mbps qemu to netcat socket to /dev/null
> ~35500 mbps virsh save to /dev/null
>
> Seems it is not proportional to cpu speed by the looks of it (not a totally
> fair comparison because the VM sizes are different).
It might be closer to RAM or cache bandwidth limited though; for an extra copy.
Dave
> Ciao,
>
> C
>
> >>
> >> In the above tests with libvirt, were you using the
> >> --bypass-cache flag or not ?
> >
> > No, I do not. Tests with ramdisk did not show a notable difference for me,
> >
> > but tests with /dev/null were not possible, since the command line is not
> > accepted:
> >
> > # virsh save centos7 /dev/null
> > Domain 'centos7' saved to /dev/null
> > [OK]
> >
> > # virsh save centos7 /dev/null --bypass-cache
> > error: Failed to save domain 'centos7' to /dev/null
> > error: Failed to create file '/dev/null': Invalid argument
> >
> >
> >>
> >> Hopefully use of O_DIRECT doesn't make a difference for
> >> /dev/null, since the I/O is being immediately thrown
> >> away and so ought to never go into I/O cache.
> >>
> >> In terms of the comparison, we still have libvirt iohelper
> >> giving QEMU a pipe, while your test above gives QEMU a
> >> UNIX socket.
> >>
> >> So I still wonder if the delta is caused by the pipe vs socket
> >> difference, as opposed to netcat vs libvirt iohelper code.
> >
> > I'll look into this aspect, thanks!
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* James Bottomley (j...@linux.ibm.com) wrote:
> On Wed, 2022-03-09 at 16:42 +0000, Dr. David Alan Gilbert wrote:
> > * Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
> > >
> > > On 3/3/22 12:20 PM, Daniel P. Berrangé wrote:
> > > > On Fri, Feb 25,
t thing for SEV(-ES) and I think it can be extended
> to SEV-SNP as well. This would close that gap and make it feasible to do
> the decryption in the kernel.
With the direct boot setup, it feels like using 'clevis' in the initrd
would be the right way to wire things to disk decryption.
[ https://github.com/latchset/clevis ]
It would need a 'pin' writing for SNP that then did whatever
communication mechanism we settled on.
(A clevis pin might also be the way to wire the simple disk key from
your EFI/SEV mechanism up to LUKS? )
Dave
> There might be reasons to do the measurement earlier, however. For
> instance, it is easier to keep track of the hashes of fewer things (just
> the firmware vs the firmware + initrd + kernel + cmdline). As you say
> networking becomes a bit of an issue if you do the attestation in
> firmware. Using a local device that is handled by libvirt could be a
> good solution.
>
> I'm sure we could come up with a protocol that is general enough to
> handle both pre-attestation and runtime attestation, but there
> definitely are some differences. For instance with pre-attestation we
> know that there will basically be two calls from management app to
> attestation server. This is defined by the way that we inject secrets.
> With SNP things are much more flexible. We can setup a persistent
> connection between the guest and the attestation server and ask for
> secrets throughout the runtime of the guest. It might take some thinking
> to reconcile these approaches and could put some dependencies on how the
> guest is supposed to behave, which isn't really our business (although a
> firmware-based solution could be reasonable).
>
> -Tobin
> >
> > Regards,
> > Daniel
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Mar 02, 2022 at 07:38:52PM +0000, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Tue, Mar 01, 2022 at 07:54:32PM +0000, Dr. David Alan Gilbert (git)
> > > wrote:
&g
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, Mar 01, 2022 at 07:54:32PM +0000, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Declare the intent to require a machine type to be specified on x86
> > system emulati
From: "Dr. David Alan Gilbert"
Declare the intent to require a machine type to be specified on x86
system emulation.
Signed-off-by: Dr. David Alan Gilbert
---
docs/about/deprecated.rst | 8
1 file changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/
.features]:
> -raise QAPISemError(
> - self.info, "feature 'deprecated' is not supported for types")
> +for feat in self.features:
> +if feat.is_special():
> +raise QAPISemError(
> +self.info,
> +f"feature '{feat.name}' is not supported for types")
>
> def describe(self):
> assert self.meta
> @@ -726,7 +728,7 @@ class QAPISchemaFeature(QAPISchemaMember):
> role = 'feature'
>
> def is_special(self):
> -return self.name in ('deprecated')
> +return self.name in ('deprecated', 'unstable')
>
>
> class QAPISchemaObjectTypeMember(QAPISchemaMember):
> --
> 2.31.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
he old drawbacks,
> but adds a new one: While using x- makes it very obvious for a human
> user that this is an unstable feature, a feature flag in the schema will
> almost certainly go unnoticed in manual use.
Agreed, I'd keep the x- as well.
Having said that, the x- represents a few different things (that we
don't currently distinguish):
- experimental
- for internal use
- for debugging/human use
Dave
> Kevin
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
t 30d2a17b4, Dec 2019), dropped in 6.0 (commit
> > f862ddbb1, just weeks ago). pc-1.3 was a bit over seven years old when
> > we released 5.0. pc-2.4 will be six years old by the time we release
> > 6.1. Fair game?
>
> As a data-point, libvirt will be dropping support for (release, not the machine type) in the upcomming release. I'm not sure
> whether that justifies more deprecation though.
What qemu features will you then be relying on?
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
git immediately after release. Then for every change to
> > master, we would have to run the test again for every historic
> > machine type version and compare to the recorded ABI record.
>
> Like Michael said we don't know that something is broken until it's
> too late and this particular case it's not even broken (strictly speaking
> change is correct) and is not even a part of ABI (it's ACPI code, i.e.
> firmware).
>
> Problem is in the way virtio drivers enumerate devices, which makes the same
> device appear as a new one. We can work around issue on hypervisor side so
> user
> won't loose network connectivity or would be able to boot guest after QEMU
> upgrade.
>
> We can suggest user re-installing their Windows (method that fixes almost all
> Win issues)
> or to try to make it pain-less for user in these rare cases, by upgrading to
> new QEMU (or fixed stable) which has workaround, so only the first few has to
> suffer.
>
> (I think downstreams would even more benefit from this, there were similar
> problems
> there before).
>
> Yes, It surely will expand test matrix, but it should be limited to specific
> cases
> we implemented fixups for.
My suggestion from a long while ago (which no one liked) was to
include the source qemu version and then have a quirks list of things to
fix up.
Dave
> >
> > Regards,
> > Daniel
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
s and help
> > >>> accessible. In order for help to be printed to the monitor instead of
> > >>> stdout, the printf() calls in the help functions are changed to
> > >>> qemu_printf().
> > >>>
> > >>> Signed-off-by: Kevin
ly the right thing to do.
Reviewed-by: Dr. David Alan Gilbert
> ---
> docs/devel/migration.rst| 2 +-
> docs/rdma.txt | 2 +-
> docs/system/deprecated.rst | 10 ---
> docs/system/removed-features.rst| 20 ++
> docs/xbz
lp
> accessible. In order for help to be printed to the monitor instead of
> stdout, the printf() calls in the help functions are changed to
> qemu_printf().
>
> Signed-off-by: Kevin Wolf
Reviewed-by: Dr. David Alan Gilbert
> ---
> monitor/hmp-cmds.c | 17 ++---
es',
> + 'sev-guest': { 'type': 'SevGuestProperties',
> + 'if': 'defined(CONFIG_SEV)' },
>'throttle-group': 'ThrottleGroupProperties',
>'tls-creds-anon': 'TlsCredsAnonProperties',
>'tls-creds-psk': 'TlsCredsPskProperties',
> --
> 2.29.2
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> This is only semantically useful for QMP.
>
> Signed-off-by: Daniel P. Berrangé
Reviewed-by: Dr. David Alan Gilbert
> ---
> docs/system/deprecated.rst | 7 ---
> docs/system/removed-features.rst | 6 ++
&g
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> The VNC ACL concept has been replaced by the pluggable "authz" framework
> which does not use monitor commands.
>
> Signed-off-by: Daniel P. Berrangé
This looks OK to me, so:
Reviewed-by: Dr. David Alan Gilbert
howev
b/hw/core/machine-hmp-cmds.c
> @@ -46,18 +46,6 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)
> qapi_free_CpuInfoFastList(cpu_list);
> }
>
> -void hmp_cpu_add(Monitor *mon, const QDict *qdict)
> -{
> -int cpuid;
> -Error *err = NULL;
> -
> -
r...
> > > >
> > > > > >
> > > > > > pv_mode={val2:string:"none+ppgtt","none+context","none+ppgtt+context"}
> > > > > >
> > > >
> > > > I'm lost on this one though. I think maybe it's indicating that it's
> > > > compatible with any of these, so do we need to list it? Couldn't this
> > > > be handled by Sean's version proposal where the minor version
> > > > represents feature compatibility?
> > > yes, it's indicating that it's compatible with any of these.
> > > Sean's version proposal may also work, but it would be painful for
> > > vendor driver to maintain the versions when multiple similar features
> > > are involved.
> >
> > This is something vendor drivers need to consider when adding and
> > removing features.
> >
> > > > > > interface_version={val3:int:2,3}
> > > >
> > > > What does this turn into in a few years, 2,7,12,23,75,96,...
> > > >
> > > is a range better?
> >
> > I was really trying to point out that sparseness becomes an issue if
> > the vendor driver is largely disconnected from how their feature
> > addition and deprecation affects migration support. Thanks,
> >
> ok. we'll use the x.y.z scheme then.
>
> Thanks
> Yan
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
aggregation attribute. If we
> need to explicitly list every aggregation value and the resulting type,
> I think we run aground of what aggregation was trying to avoid anyway,
> so we might need to pick a language that defines variable substitution
> or some kind of tagging. For
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Wed, 15 Jul 2020 16:20:41 +0800
> Yan Zhao wrote:
>
> > On Tue, Jul 14, 2020 at 02:59:48PM -0600, Alex Williamson wrote:
> > > On Tue, 14 Jul 2020 18:19:46 +0100
> > > "Dr. David Alan Gilbert"
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Tue, 14 Jul 2020 18:19:46 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > On Tue, 14 Jul 2020 11:21:29 +0100
> > > Daniel P. Berran
d on a given device. This puts the job of
> > reporting compatible versions directly under the responsibility of the
> > vendor who writes the kernel driver for it. They are the ones with the
> > best knowledge of the hardware they've built and the rules around its
> > compatibility.
>
> The version string discussed previously is the version string that
> represents a given device, possibly including driver information,
> configuration, etc. I think what you're asking for here is an
> enumeration of every possible version string that a given device could
> accept as an incoming migration stream. If we consider the string as
> opaque, that means the vendor driver needs to generate a separate
> string for every possible version it could accept, for every possible
> configuration option. That potentially becomes an excessive amount of
> data to either generate or manage.
>
> Am I overestimating how vendors intend to use the version string?
>
> We'd also need to consider devices that we could create, for instance
> providing the same interface enumeration prior to creating an mdev
> device to have a confidence level that the new device would be a valid
> target.
>
> We defined the string as opaque to allow vendor flexibility and because
> defining a common format is hard. Do we need to revisit this part of
> the discussion to define the version string as non-opaque with parsing
> rules, probably with separate incoming vs outgoing interfaces? Thanks,
>
> Alex
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > > > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > > > > On Wed, 29 Apr 2020 20:39:50 -0400
> > > > > Yan Zhao wrote:
> > > > >
> > > > > > On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Al
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Fri, 5 Jun 2020 11:22:24 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > On Wed, 3 Jun 2020 01:24:43 -0400
> > > Yan Zhao wrote:
>
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Wed, Apr 29, 2020 at 04:22:01PM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > On Tue, Apr 28, 2020 at 10:14:37PM +0800, Dr. David Alan Gilbert wrote:
> > > > * Yan Zha
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Tue, Apr 28, 2020 at 10:14:37PM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > On Mon, Apr 27, 2020 at 11:37:43PM +0800, Dr. David Alan Gilbert wrote:
> > > > * Yan Zha
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Mon, Apr 27, 2020 at 11:37:43PM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > On Sat, Apr 25, 2020 at 03:10:49AM +0800, Dr. David Alan Gilbert wrote:
> > > > * Yan Zha
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Sat, Apr 25, 2020 at 03:10:49AM +0800, Dr. David Alan Gilbert wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > On Tue, Apr 21, 2020 at 08:08:49PM +0800, Tian, Kevin wrote:
> > > > > From: Yan Zhao
> > &g
vendor driver should ensure that
> > > > > the
> > > > > migration compatibility from migration_version under mdev_type should
> > > be
> > > > > consistent with that from migration_version under device node" ?
> > > > >
> > > > > > (It obviously cannot be a prereq for what I called (3) above.)
> > > > > >
> > > > > > >
> > > > > > > > Does userspace need to check (1) or can it completely rely on
> > > > > > > > (2), if
> > > > > > > > it so chooses?
> > > > > > > >
> > > > > > > I think it can completely reply on (2) if compatibility check
> > > > > > > before
> > > > > > > mdev creation is not required.
> > > > > > >
> > > > > > > > If devices with a different mdev type are indeed compatible, it
> > > seems
> > > > > > > > userspace can only find out after the devices have actually been
> > > > > > > > created, as (1) does not apply?
> > > > > > > yes, I think so.
> > > > > >
> > > > > > How useful would it be for userspace to even look at (1) in that
> > > > > > case?
> > > > > > It only knows if things have a chance of working if it actually goes
> > > > > > ahead and creates devices.
> > > > > >
> > > > > hmm, is it useful for userspace to test the migration_version under
> > > > > mdev
> > > > > type before it knows what mdev device to generate ?
> > > > > like when the userspace wants to migrate an mdev device in src vm,
> > > > > but it has not created target vm and the target mdev device.
> > > > >
> > > > > > >
> > > > > > > > One of my worries is that the existence of an attribute with the
> > > same
> > > > > > > > name in two similar locations might lead to confusion. But
> > > > > > > > maybe it
> > > > > > > > isn't a problem.
> > > > > > > >
> > > > > > > Yes, I have the same feeling. but as (2) is for sysfs interface
> > > > > > > consistency, to make it transparent to userspace tools like
> > > > > > > libvirt,
> > > > > > > I guess the same name is necessary?
> > > > > >
> > > > > > What do we actually need here, I wonder? (1) and (2) seem to serve
> > > > > > slightly different purposes, while (2) and what I called (3) have
> > > > > > the
> > > > > > same purpose. Is it important to userspace that (1) and (2) have the
> > > > > > same name?
> > > > > so change (1) to migration_type_version and (2) to
> > > > > migration_instance_version?
> > > > > But as they are under different locations, could that location imply
> > > > > enough information?
> > > > >
> > > > >
> > > > > Thanks
> > > > > Yan
> > > > >
> > > > >
> > > >
> > > ___
> > > intel-gvt-dev mailing list
> > > intel-gvt-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ty verification. Thanks,
> >
> Hi Alex
> Got it!
> Thanks for reminding of this. And as now we have vfio-pci implementing
> vendor ops to allow live migration of pass-through devices, is it
> necessary to implement similar sysfs node for those devices?
> or do you think just PCI IDs of those devices are enough for libvirt to
> know device compatibility ?
Wasn't the problem that we'd have to know how to check for things like:
a) Whether different firmware versions in the device were actually
compatible
b) Whether minor hardware differences were compatible - e.g. some
hardware might let you migrate to the next version of hardware up.
Dave
> Thanks
> Yan
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
on Human Monitor Protocol (HMP) commands
>
> -@subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove' (since
> 3.1)
> -
> -The @option{[hub_id name]} parameter tuple of the 'hostfwd_add' and
> -'hostfwd_remove' HMP commands has been replaced by @option{netdev_id}.
> -
>
* Thomas Huth (th...@redhat.com) wrote:
> On 05/12/2019 11.41, Thomas Huth wrote:
> > It's been deprecated since QEMU v3.1.0. Time to finally remove it now.
> >
> > Signed-off-by: Thomas Huth
For hmp:
Acked-by: Dr. David Alan Gilbert
would want an ack from Samuel (or ma
params = "[hub_id name]|[netdev_id]
> [tcp|udp]:[hostaddr]:hostport",
> +.args_type = "arg1:s,arg2:s?",
> + .params = "[netdev_id] [tcp|udp]:[hostaddr]:hostport",
> .help = "remove host-to-guest TCP or UDP redirection&q
stination doesn't have an MSR that should be there according to the
> kernel.
Ah OK, yes.
Dave
> Paolo
>
> Il mar 6 ago 2019, 18:22 Dr. David Alan Gilbert ha
> scritto:
>
> > * Paolo Bonzini (pbonz...@redhat.com) wrote:
> > > host-passthrough documentat
hang or crash upon resuming execution on the destination host.
If libvirt is driving qemu with 'exact' on the cpu option, under what
situation would it hang/crash on the destination?
All of the microcode changes I think have caused a flag to appear, and
thus it would be required on the d
QEMU will provide expected behavior and fail if
> it can't use user provided backing file.
>
> Signed-off-by: Igor Mammedov
Ah yes that's useful because it's a mess for postcopy.
Reviewed-by: Dr. David Alan Gilbert
> ---
> PS:
> Patch is written on top of
> [PATCH v4
tes the devices are incompatible or the target
> > doesn't support migration versions. "
> > 2. vendor driver should log detailed error reasons in kernel log.
>
> Two questions:
> - How reasonable is it to refer to the system log in order to find out
> what exactly went wrong?
> - If detailed error reporting is basically done to the syslog, do
> different error codes still provide useful information? Or should the
> vendor driver decide what it wants to do?
I don't see error codes as being that helpful; if we can't actually get
an error message back up the stack (which was my preference), then I guess
syslog is as good as it will get.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
U & clients MUST format integer fields as strings
> if their value can not fit in a 32-bit integer.
>
>- QEMU & clients MAY format integer fields as strings
> even if their value can fit in 32-bit integer
>
>- QEMU & client MUST p
dirty to say a given field will have different encoding
> depending on the value. If apps need to deal with string encoding, they
> might as well just use it for all values in a given field.
Yeh, 1 is horrid; it's too easy to miss a case which forgot to handle
the 2^53-1 because we hadn't
* Cornelia Huck (coh...@redhat.com) wrote:
> On Thu, 9 May 2019 17:48:26 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Cornelia Huck (coh...@redhat.com) wrote:
> > > On Thu, 9 May 2019 16:48:57 +0100
> > > "Dr. David Alan Gilbert" wrote
* Cornelia Huck (coh...@redhat.com) wrote:
> On Thu, 9 May 2019 16:48:57 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Cornelia Huck (coh...@redhat.com) wrote:
> > > On Tue, 7 May 2019 15:18:26 -0600
> > > Alex Williamson wrote:
> > >
&g
d error for 'cannot migrate at all' vs 'cannot migrate between
> those two particular devices'. Userspace might want to do different
> things (e.g. trying with different device pairs).
Trying to stuff these things down an errno seems a bad idea; we can't
get much information that way.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
t;>> QMP sending all integers in decimal is inconvenient for some values,
> >>> such as addresses. QMP sending all (large) integers in hexadecimal
> >>> would be inconvenient for other values.
> >>>
> >>> Let's keep it simple & stupid. If
; 1. removed 32 common part of version string
> (Alex Williamson)
> 2. do not register version attribute for GVT not supporting live
> migration.(Cornelia Huck)
> 3. for platforms out of gen8, gen9, return -EINVAL --> -ENODEV for
> incompatible. (Cornelia Huck)
>
> Cc: Alex Williamso
ve to start decoding (2) by hand when debugging.
Dave
> Regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
option, how it's solved on libvirt
> > > side currently?
> > >
> > > For example I don't see anything introspection related when we have been
> > > removing deprecated options recently.
> >
> > Right, with other stuff we deprecate we've had a simpler time, as it
> > either didn't affect migration at all, or the new replacement stuff
> > was fully compatible with the migration data stream. IOW, libvirt
> > could unconditionally use the new feature as soon as it saw that it
> > exists in QEMU. We didn't have any machine type dependancy to deal
> > with before now.
>
> We couldn't have done that. How we would migrate from older qemu?
>
> Anyway, now that I look into this (esp. git log) I came accross:
>
> commit f309db1f4d51009bad0d32e12efc75530b66836b
> Author: Michal Privoznik
> AuthorDate: Thu Dec 18 12:36:48 2014 +0100
> Commit: Michal Privoznik
> CommitDate: Fri Dec 19 07:44:44 2014 +0100
>
> qemu: Create memory-backend-{ram,file} iff needed
>
> Or this 7832fac84741d65e851dbdbfaf474785cbfdcf3c. We did try to generated
> newer cmd line but then for various reasong (e.g. avoiding triggering a qemu
> bug) we turned it off and make libvirt default to older (now deprecated) cmd
> line.
>
> Frankly, I don't know how to proceed. Unless qemu is fixed to allow
> migration from deprecated to new cmd line (unlikely, if not impossible,
> right?) then I guess the only approach we can have is that:
>
> 1) whenever so called cold booting a new machine (fresh, brand new start of
> a new domain) libvirt would default to modern cmd line,
>
> 2) on migration, libvirt would record in the migration stream (or status XML
> or wherever) that modern cmd line was generated and thus it'll make the
> destination generate modern cmd line too.
>
> This solution still suffers a couple of problems:
> a) migration to older libvirt will fail as older libvirt won't recognize the
> flag set in 2) and therefore would default to deprecated cmd line
> b) migrating from one host to another won't modernize the cmd line
>
> But I guess we have to draw a line somewhere (if we are not willing to write
> those migration patches).
What's interesting here is that this problem isn't really machine-type
related; so providing introspection on the machine type doesn't
immediately help. What we're actually trying to do here is (mis)use a
machine type as a proxy for knowing that both sides are new enough to
handle the new command line.
That's an OK thing to do, and if we did have introspection we could
add a fudge flag to say it's allowed now.
Dave
> Michal
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
sign RAM to a NUMA
> > > node
> > > +using parameter @option{memdev}, which does the same as @option{mem} and
> > > has
> > > +an ability to actualy manage node RAM on the host side. Use parameter
> > > +@option{memdev} with @var{memory-backend-ram} backend as
few years?
I don't see any harm warning that it's deprecated and you really should
try not to use it.
Dave
> Regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
* Peter Krempa (pkre...@redhat.com) wrote:
> On Tue, Oct 09, 2018 at 19:34:43 +0200, Markus Armbruster wrote:
> > Cc: libvir-list for review of the compatibility argument below.
> >
> > Daniel Henrique Barboza writes:
> >
> > > Hey David,
> > >
>
their
> > >> name :-P). For that we can use status/migration XML as I suggested
> > >> earlier.
> > >>
> > >> Once again, status XML is not editable by user [*] and is used solely by
> > >> libvirtd to store runtime information for a running domain (and backend
> > >> used falls into that category).
> > >
> > > Why not do this transparent memfd-usage in a seperate series?
> >
> > Depends what we want libvirt to be. If we want it to be mere XML->qemu
> > cmd line generator, then we can expose all qemu settings as they are. If
> > we want it to have some logic built in (so that mgmt applications can
> > offload some decisions to it), then we can't expose all qemu settings.
> >
> > I my ideal world, I'd like to tell libvirt "I want a machine that uses
> > hugepages of this size" and let libvirt figure out the best command line
> > to fulfil my request (either use -file or -memfd or even -ram + -mem-path).
> >
> > On the other hand, I don't want to discourage you from posting patches,
> > so this is the point where I will no longer object. I pointed out my
> > objections enough :-)
>
> I see the benefit in using memfd whenever possible. But I also see a
> benefit in being able to request its usage explcitely. That's why I
> think the 2 approaches are compatible.
>
> Thanks!
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Tue, 11 Sep 2018 17:30:31 +0400
> Marc-André Lureau wrote:
>
> > Hi
> >
> > On Tue, Sep 11, 2018 at 5:14 PM, Igor Mammedov wrote:
> > > On Tue, 11 Sep 2018 12:49:12 +0100
> > > "Dr. David Alan G
* Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> Hi
>
> On Tue, Sep 11, 2018 at 3:26 PM, Dr. David Alan Gilbert
> wrote:
> > * Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> >> Hi
> >>
> >> On Tue, Sep 11, 2018 at 2:32 PM, Dr.
* Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> Hi
>
> On Tue, Sep 11, 2018 at 2:32 PM, Dr. David Alan Gilbert
> wrote:
> > * Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> >> Hi
> >>
> >> On Tue, Sep 11, 2018 at 12:37 PM, Michal
d, since they use the same
> "broken" name, but not with -ram.
>
> I don't know how we can solve this migration issue without breaking
> things further. Any idea David?
>
> > Or is memfd going to be used only for hugepages + > type='anonymous'/> case (which is not allowed now and thus migration
> > scenario I'm describing can't happen)?
>
> With those patches, memfd is used for anonymous memory (shared or not,
> hpt or not) with an explicit numa configuration.
>
> thanks
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
aswell-3.1 is not runnable and the
> user asked for Haswell".
Use the highest that works.
> * Ordering/preference info, e.g.: "Haswell-3.1 is better than
> Haswell-3.0, prefer the latter"
Higher is better.
The only thing that worries me about a numbering scheme is that
it's now more difficult for a user to know whether they've got
the type with a fix for a particular vulnerability.
We're going to have to say something like:
'For the new XYZ vulnerability make sure you're using
Haswell-3.2 or later, SkyLake-2.6 or later, Westmere-4.8 or later
.'
which all gets a bit confusing.
Dave
> --
> Eduardo
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
t gets a VM started
on it, and then they try and migrate it to one of the older machines.
Now if there was something that could take the CPU defintions from all
the machines in the cluster and tell it which to use/which problems
they had then that might make sense. It would be best for each
high
why they've
> added it in the first place.
There was some worry that doing it by default would be a subtle API
change; personally I didn't really see it as a problem, but since people
were worried I made it switchable.
See:
https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg01300.html
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
>
>
> On 4/26/2018 1:22 AM, Dr. David Alan Gilbert wrote:
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> >> On Wed, 25 Apr 2018 21:00:39 +0530
> >> Kirti Wankhede <kwankh...@nvidia.com> wrote
rd and we
> should let the driver return an error when it receives an incompatible
> migration stream, aborting the migration?
It's a bit nasty; if you've hit the 'evacuate host' button then what
happens when you've got some incompatible hosts.
Dave
> > > One more try... we have a vfio_group fd. This is created by the bus
> > > drivers calling vfio_add_group_dev() and registers a struct device, a
> > > struct vfio_device_ops, and private data. Typically we only wire the
> > > device_ops to the resulting file descriptor we get from
> > > VFIO_GROUP_GET_DEVICE_FD, but could we enable sort of a nested ioctl
> > > through the group fd? The ioctl would need to take a string arg to
> > > match to a device name, plus an ioctl cmd and arg for the device_ops
> > > ioctl. The group ioctl would need to filter cmds to known, benign
> > > queries. We'd also need to verify that the allowed ioctls have no
> > > dependencies on setup done in device_ops.open().
> >
> > So these ioctls would be called without devices open() call, doesn't
> > this seem to be against file operations standard?
>
> vfio_device_ops is modeled largely after file operations, but I don't
> think we're bound by that for the interaction between vfio-core and the
> vfio bus drivers. We could make a separate callback for unprivileged
> ioctls, but that seems like more work per driver when we really want to
> maintain the identical API, we just want to provide a more limited
> interface and change the calling point.
>
> An issue I thought of for migration though is that this path wouldn't
> have access to the migration region and therefore if we place a header
> within that region containing the compatibility and versioning
> information, the user still couldn't access it. This doesn't seem to
> be a blocker though as we could put that information within the region
> capability that defines the region as used for migration. Possibly a
> device could have multiple migration regions with different formats
> for backwards compatibility, of course then we'd need a way to
> determine which to use and which combinations have been validated.
> Thanks,
>
> Alex
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
a separate command is that the command
could be marked OOB with Peter's new series and never take the lock.
Dave
> Markus, Eric: from the QAPI point of view, is it OK to remove
> fields between QEMU versions, as long as we follow our
> deprecation policy?
>
> --
> Eduardo
>
GO limit the
> secret to the specific VM? For example, what prevents hypervisor
> from launching two VMs with the same GO's DH, getting measurement
> from 1st one but injecting the secret into the second one?
Isn't that the 'trusted channel nonce currently associated with the
guest' in the
t
> > use the qemu:args tag ? (step 6)
> > c) what existing communicate interface can be used between libvirt and qemu
> > to get the measurement ? can we add a new qemu monitor command
> > 'get_sev_measurement' to get the measurement ? (step 10)
> > d) how to pass the secret blob from libvirt to qemu ? should we consider
> > adding a new object (sev-guest-secret) -- libvirt can add the object through
> > qemu monitor.
> >
> >
> > [1] https://marc.info/?l=kvm=150092661105069=2
> > [2] https://marc.info/?l=qemu-devel=148901186615642=2
> > [3] https://lists.01.org/pipermail/edk2-devel/2017-July/012220.html
> > [4] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> >
> > Thanks
> >
> > Brijesh
> >
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
s stateful interface.
IMHO Yi's fix (once reworked) is the right fix - it removes the
use of that piece of state, when the optional parameter is used.
(OK, so it needs rework not to change that state and to
come to some agreement as to what to use instead of cpu index number
etc).
Dave
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
ile(net),
> virDomainNetGetActualVlan(net),
> - 0, NULL,
> + net->mtu, mtu,
> tap_create_flags) < 0) {
> virDomainAuditNetD
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Mon, Jan 09, 2017 at 11:35:54AM +0000, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > A recent glibc commit[1] added a blacklist to ensure it won't use
> > > TSX on hosts that are
include/hw/i386/pc.h | 6 ++
> target/i386/cpu.h| 1 +
> hw/i386/pc_piix.c| 15 ---
> hw/i386/pc_q35.c | 13 +++--
> target/i386/cpu.c| 32 ++--
> target/i386/kvm.c| 17 +++++++++
> 6 files changed, 69 i
an
> > > > > alternative version of patch 4/4 to cover your use case, I will
> > > > > strongly recommend libvirt developers to support configuring TSC
> > > > > frequency if they want to support invtsc + migration without
> > > > > surprising/unpredictable restrictions on migratability.
> > > >
> > > > Well, alright. If you make the TSC frequency of the host
> > > > available to mgmt software as you describe, and write the steps mgmt
> > > > software should take, i'm good.
> > >
> > > I plan to. The problem is that the mechanism to query the host
> > > frequency may be unavailable in the first version.
> >
> > Well just export KVM_GET_TSC_KHZ in a QMP command right? Its pretty
> > easy.
>
> I plan to expose it as part of query-cpu-model-expansion (work in
> progress, right now) when querying the "host" CPU model.
>
> >
> > Let me know if you need any help coding or testing.
>
> Thanks!
>
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
:|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com
+0100, Dr. David Alan Gilbert wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Tue, May 19, 2015 at 10:15:17AM -0400, Laine Stump wrote:
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
* Peter Krempa (pkre...@redhat.com) wrote:
On Wed, May 13, 2015 at 09:08:39 +0100, Dr. David Alan Gilbert wrote:
* Peter Krempa (pkre...@redhat.com) wrote:
On Wed, May 13, 2015 at 11:36:26 +0800, Chen Fan wrote:
my main goal is to add support migration with host NIC
passthrough
* Peter Krempa (pkre...@redhat.com) wrote:
On Wed, May 13, 2015 at 09:40:23 +0100, Dr. David Alan Gilbert wrote:
* Peter Krempa (pkre...@redhat.com) wrote:
On Wed, May 13, 2015 at 09:08:39 +0100, Dr. David Alan Gilbert wrote:
* Peter Krempa (pkre...@redhat.com) wrote:
On Wed, May 13
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Wed, May 13, 2015 at 10:00:42AM +0100, Dr. David Alan Gilbert wrote:
* Peter Krempa (pkre...@redhat.com) wrote:
On Wed, May 13, 2015 at 09:40:23 +0100, Dr. David Alan Gilbert wrote:
* Peter Krempa (pkre...@redhat.com) wrote
* Laine Stump (la...@redhat.com) wrote:
On 05/13/2015 04:28 AM, Peter Krempa wrote:
On Wed, May 13, 2015 at 09:08:39 +0100, Dr. David Alan Gilbert wrote:
* Peter Krempa (pkre...@redhat.com) wrote:
On Wed, May 13, 2015 at 11:36:26 +0800, Chen Fan wrote:
my main goal is to add support
* Laine Stump (la...@redhat.com) wrote:
On 05/13/2015 10:42 AM, Dr. David Alan Gilbert wrote:
* Laine Stump (la...@redhat.com) wrote:
On 05/13/2015 04:28 AM, Peter Krempa wrote:
On Wed, May 13, 2015 at 09:08:39 +0100, Dr. David Alan Gilbert wrote:
* Peter Krempa (pkre...@redhat.com) wrote
: move the domain xml handling forward to stop CPU
managedsave: add managedsave support for ephemeral host devices
Peter
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
* 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 wrote:
* Daniel P. Berrange (berra...@redhat.com
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Wed, Apr 22, 2015 at 06:01:56PM +0100, Dr. David Alan Gilbert wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
On Fri, Apr 17, 2015 at 04:53:02PM +0800, Chen Fan wrote:
backgrond:
Live migration is one of the most important
automatically; I'd assume it would be possible to add a rule somewhere
that said anything with the same ID would automatically be added to the bond.
However, I agree that you might be able to avoid having to do anything in the
guest agent.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester
+1-919-301-3266
Libvirt virtualization library http://libvirt.org
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
years ago already.
It's amazing what different combinations of QEMU people have
out there; and it seems reasonable to let Alex fix this problem
if it helps him; there's no reason to deny others the same fix.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list
* Eric Blake (ebl...@redhat.com) wrote:
On 09/24/2014 02:09 PM, Dr. David Alan Gilbert wrote:
This right here is a problem. Qemu has explicitly documented that
anything beginning with x- may be subject to change or going away in a
later release, so libvirt policy has been to delay any
the VM.
BTW, it's going to work in simple cases, when there's no lock daemon in
use, only basic Linux bridge support is used, etc., which is why it
works just fine for you. But we need to count with all the non-simple
cases too.
Jirka
--
Dr. David Alan Gilbert / dgilb...@redhat.com
Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
it wants to give up and use the version on
the source that's still paused.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
96 matches
Mail list logo
