Re: [PULL 00/39] Migration 20231024 patches
On Fri, 27 Oct 2023 at 00:25, Juan Quintela wrote: > > Stefan Hajnoczi wrote: > > On Tue, 24 Oct 2023 at 23:45, Juan Quintela wrote: > >> > >> The following changes since commit > >> a95260486aa7e78d7c7194eba65cf03311ad94ad: > >> > >> Merge tag 'pull-tcg-20231023' of https://gitlab.com/rth7680/qemu into > >> staging (2023-10-23 14:45:46 -0700) > >> > >> are available in the Git repository at: > >> > >> https://gitlab.com/juan.quintela/qemu.git > >> tags/migration-20231024-pull-request > >> > >> for you to fetch changes up to 088f7f03da3f5b3487091302b795c22b1bfe56fb: > >> > >> migration: Deprecate old compression method (2023-10-24 13:48:24 +0200) > >> > >> > >> Migration Pull request (20231024) > >> > >> Hi > >> > >> In this PULL: > >> - vmstate registration fixes (thomas, juan) > >> - start merging vmstate_section_needed changes (marc) > >> - migration depreactions (juan) > >> - migration documentation for backwards compatibility (juan) > >> > >> Please apply. > > > > Hi Juan, > > I'm seeing CI failures: > > https://gitlab.com/qemu-project/qemu/-/pipelines/1048630760 > > start with s390x: > > Errors: > > 32/840 qemu:qtest+qtest-s390x / qtest-s390x/qom-test > ERROR 50.27s killed by signal 6 SIGABRT > 104/840 qemu:qtest+qtest-s390x / qtest-s390x/test-hmp > ERROR 51.55s killed by signal 6 SIGABRT > 189/840 qemu:qtest+qtest-s390x / qtest-s390x/boot-serial-test > ERROR 54.07s killed by signal 6 SIGABRT > 192/840 qemu:qtest+qtest-s390x / qtest-s390x/qos-test > ERROR 51.29s killed by signal 6 SIGABRT > 519/840 qemu:qtest+qtest-s390x / qtest-s390x/test-filter-mirror > ERROR 50.36s killed by signal 6 SIGABRT > 520/840 qemu:qtest+qtest-s390x / qtest-s390x/test-netfilter > ERROR 51.03s killed by signal 6 SIGABRT > 522/840 qemu:qtest+qtest-s390x / qtest-s390x/device-plug-test > ERROR 50.99s killed by signal 6 SIGABRT > 523/840 qemu:qtest+qtest-s390x / qtest-s390x/test-filter-redirector > ERROR 54.14s killed by signal 6 SIGABRT > 524/840 qemu:qtest+qtest-s390x / qtest-s390x/drive_del-test > ERROR 53.40s killed by signal 6 SIGABRT > 525/840 qemu:qtest+qtest-s390x / qtest-s390x/virtio-ccw-test > ERROR 54.67s killed by signal 6 SIGABRT > 526/840 qemu:qtest+qtest-s390x / qtest-s390x/device-introspect-test > ERROR 51.15s killed by signal 6 SIGABRT > 527/840 qemu:qtest+qtest-s390x / qtest-s390x/cpu-plug-test > ERROR 51.21s killed by signal 6 SIGABRT > 535/840 qemu:qtest+qtest-s390x / qtest-s390x/qmp-test > ERROR 51.18s killed by signal 6 SIGABRT > 534/840 qemu:qtest+qtest-s390x / qtest-s390x/machine-none-test > ERROR 51.21s killed by signal 6 SIGABRT > 533/840 qemu:qtest+qtest-s390x / qtest-s390x/qmp-cmd-test > ERROR 51.22s killed by signal 6 SIGABRT > 549/840 qemu:qtest+qtest-s390x / qtest-s390x/readconfig-test > ERROR 51.20s killed by signal 6 SIGABRT > 644/840 qemu:block / io-qcow2-001 > ERROR 0.32s exit status 1 > 645/840 qemu:block / io-qcow2-002 > ERROR 0.32s exit status 1 > 646/840 qemu:block / io-qcow2-003 > ERROR 0.34s exit status 1 > 647/840 qemu:block / io-qcow2-004 > ERROR 0.31s exit status 1 > 648/840 qemu:block / io-qcow2-005 > ERROR 0.43s exit status 1 > 649/840 qemu:block / io-qcow2-007 > ERROR 0.34s exit status 1 > 650/840 qemu:block / io-qcow2-008 > ERROR 0.63s exit status 1 > 651/840 qemu:block / io-qcow2-009 > ERROR 0.32s exit status 1 > 652/840 qemu:block / io-qcow2-010 > ERROR 0.30s exit status 1 > 654/840 qemu:block / io-qcow2-011 > ERROR 0.31s exit status 1 > 655/840 qemu:block / io-qcow2-012 > ERROR 0.36s exit status 1 > 657/840 qemu:block / io-qcow2-013 > ERROR 0.51s exit status 1 > 658/840 qemu:block / io-qcow2-017 > ERROR
Re: [PATCH v3 28/28] docs: update Xen-on-KVM documentation
On Thu, 2023-10-26 at 10:25 +0100, David Woodhouse wrote:
>
> > So it would have been entirely possible to use -initrd 'bzImage
> > console=hvc0 root=/dev/xvda1' if Xen worked like that.
>
> Xen does allow that too. I didn't realise our multiboot loader did though.
>
> So yes, you *can* use -initrd 'bzImage root=/dev/xvda1'.
>
> And you can even load more than one module, it seems. Separate them by
> commas, so -initrd 'bzImage,initrd.img' should work.
>
> You can even do both at the same time. If you have commas on the kernel
> command line, *double* them:
>
> -initrd 'bzImage root=/dev/xvda earlyprintk=xen,,keep,initrd.img'
>
> I'll update the documentation accordingly.
https://git.infradead.org/users/dwmw2/qemu.git/commitdiff/0b13c0ae39b
+Booting Xen PV guests
+-
+
+Booting PV guest kernels is possible by using the Xen PV shim (a version of Xen
+itself, designed to run inside a Xen HVM guest and provide memory management
+services for one guest alone).
+
+The Xen binary is provided as the ``-kernel`` and the guest kernel itself (or
+PV Grub image) as the ``-initrd`` image, which actually just means the first
+multiboot "module". For example:
+
+.. parsed-literal::
+
+ |qemu_system| --accel kvm,xen-version=0x40011,kernel-irqchip=split \\
+ -chardev stdio,id=char0 -device xen-console,chardev=char0 \\
+ -display none -m 1G -kernel xen -initrd bzImage \\
+ -append "pv-shim console=xen,pv -- console=hvc0 root=/dev/xvda1" \\
+ -drive file=${GUEST_IMAGE},if=xen
+
+The Xen image must be built with the ``CONFIG_XEN_GUEST`` and
``CONFIG_PV_SHIM``
+options, and as of Xen 4.17, Xen's PV shim mode does not support using a serial
+port; it must have a Xen console or it will panic.
+
+The example above provides the guest kernel command line after a separator
+(" ``--`` ") on the Xen command line, and does not provide the guest kernel
+with an actual initramfs, which would need to listed as a second multiboot
+module. For more complicated alternatives, see the
+:ref:`documentation ` for the ``-initrd`` option.
+
I also fixed up the -initrd documentation so that it actually mentions
how to quote commas, using a Xen PV launch as an example:
``-initrd "file1 arg=foo,file2"``
This syntax is only available with multiboot.
-Use file1 and file2 as modules and pass arg=foo as parameter to the
-first module.
+Use file1 and file2 as modules and pass ``arg=foo`` as parameter to the
+first module. Commas can be provided in module parameters by doubling
+them on the command line to escape them:
+
+``-initrd "bzImage earlyprintk=xen,,keep root=/dev/xvda1,initrd.img"``
+Multiboot only. Use bzImage as the first module with
+"``earlyprintk=xen,keep root=/dev/xvda1``" as its command line,
+and initrd.img as the second module.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PULL 20/39] hw/s390x/s390-stattrib: Simplify handling of the "migration-enabled" property
On 24/10/2023 15.12, Juan Quintela wrote:
From: Thomas Huth
There's no need for dedicated handlers here if they don't do anything
special.
Acked-by: David Hildenbrand
Reviewed-by: Eric Farman
Acked-by: Juan Quintela
Signed-off-by: Thomas Huth
Signed-off-by: Juan Quintela
Message-ID: <20231020150554.664422-3-th...@redhat.com>
---
hw/s390x/s390-stattrib.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
index 220e845d12..52f9fc036e 100644
--- a/hw/s390x/s390-stattrib.c
+++ b/hw/s390x/s390-stattrib.c
@@ -13,6 +13,7 @@
#include "qemu/units.h"
#include "migration/qemu-file.h"
#include "migration/register.h"
+#include "hw/qdev-properties.h"
#include "hw/s390x/storage-attributes.h"
#include "qemu/error-report.h"
#include "exec/ram_addr.h"
@@ -340,6 +341,10 @@ static void s390_stattrib_realize(DeviceState *dev, Error
**errp)
}
}
+static Property s390_stattrib_props[] = {
+DEFINE_PROP_BOOL("migration-enabled", S390StAttribState,
migration_enabled, true),
This needs a DEFINE_PROP_END_OF_LIST() here, too ... sorry for that!
/me is looking for his brown paper-bags...
Thomas
+};
+
static void s390_stattrib_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
@@ -347,22 +352,7 @@ static void s390_stattrib_class_init(ObjectClass *oc, void
*data)
dc->hotpluggable = false;
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
dc->realize = s390_stattrib_realize;
-}
-
-static inline bool s390_stattrib_get_migration_enabled(Object *obj,
- Error **errp)
-{
-S390StAttribState *s = S390_STATTRIB(obj);
-
-return s->migration_enabled;
-}
-
-static inline void s390_stattrib_set_migration_enabled(Object *obj, bool value,
-Error **errp)
-{
-S390StAttribState *s = S390_STATTRIB(obj);
-
-s->migration_enabled = value;
+device_class_set_props(dc, s390_stattrib_props);
}
static SaveVMHandlers savevm_s390_stattrib_handlers = {
@@ -383,10 +373,6 @@ static void s390_stattrib_instance_init(Object *obj)
register_savevm_live(TYPE_S390_STATTRIB, 0, 0,
_s390_stattrib_handlers, sas);
-object_property_add_bool(obj, "migration-enabled",
- s390_stattrib_get_migration_enabled,
- s390_stattrib_set_migration_enabled);
-object_property_set_bool(obj, "migration-enabled", true, NULL);
sas->migration_cur_gfn = 0;
}
Re: [PULL 19/39] hw/s390x/s390-skeys: Don't call register_savevm_live() during instance_init()
On 24/10/2023 15.12, Juan Quintela wrote:
From: Thomas Huth
Since the instance_init() function immediately tries to set the
property to "true", the s390_skeys_set_migration_enabled() tries
to register a savevm handler during instance_init(). However,
instance_init() functions can be called multiple times, e.g. for
introspection of devices. That means multiple instances of devices
can be created during runtime (which is fine as long as they all
don't get realized, too), so the "Prevent double registration of
savevm handler" check in the s390_skeys_set_migration_enabled()
function does not work at all as expected (since there could be
more than one instance).
Thus we must not call register_savevm_live() from an instance_init()
function at all. Move this to the realize() function instead. This
way we can also get rid of the property getter and setter functions
completely, simplifying the code along the way quite a bit.
Acked-by: David Hildenbrand
Reviewed-by: Eric Farman
Acked-by: Juan Quintela
Signed-off-by: Thomas Huth
Signed-off-by: Juan Quintela
Message-ID: <20231020150554.664422-2-th...@redhat.com>
---
hw/s390x/s390-skeys.c | 35 ---
1 file changed, 8 insertions(+), 27 deletions(-)
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index 5024faf411..8e9d9e41e8 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -12,6 +12,7 @@
#include "qemu/osdep.h"
#include "qemu/units.h"
#include "hw/boards.h"
+#include "hw/qdev-properties.h"
#include "hw/s390x/storage-keys.h"
#include "qapi/error.h"
#include "qapi/qapi-commands-misc-target.h"
@@ -432,58 +433,38 @@ static int s390_storage_keys_load(QEMUFile *f, void
*opaque, int version_id)
return ret;
}
-static inline bool s390_skeys_get_migration_enabled(Object *obj, Error **errp)
-{
-S390SKeysState *ss = S390_SKEYS(obj);
-
-return ss->migration_enabled;
-}
-
static SaveVMHandlers savevm_s390_storage_keys = {
.save_state = s390_storage_keys_save,
.load_state = s390_storage_keys_load,
};
-static inline void s390_skeys_set_migration_enabled(Object *obj, bool value,
-Error **errp)
+static void s390_skeys_realize(DeviceState *dev, Error **errp)
{
-S390SKeysState *ss = S390_SKEYS(obj);
-
-/* Prevent double registration of savevm handler */
-if (ss->migration_enabled == value) {
-return;
-}
-
-ss->migration_enabled = value;
+S390SKeysState *ss = S390_SKEYS(dev);
if (ss->migration_enabled) {
register_savevm_live(TYPE_S390_SKEYS, 0, 1,
_s390_storage_keys, ss);
-} else {
-unregister_savevm(VMSTATE_IF(ss), TYPE_S390_SKEYS, ss);
}
}
-static void s390_skeys_instance_init(Object *obj)
-{
-object_property_add_bool(obj, "migration-enabled",
- s390_skeys_get_migration_enabled,
- s390_skeys_set_migration_enabled);
-object_property_set_bool(obj, "migration-enabled", true, NULL);
-}
+static Property s390_skeys_props[] = {
+DEFINE_PROP_BOOL("migration-enabled", S390SKeysState, migration_enabled,
true),
This needs a DEFINE_PROP_END_OF_LIST() here ... mea culpa!
Thomas
+};
static void s390_skeys_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
dc->hotpluggable = false;
+dc->realize = s390_skeys_realize;
+device_class_set_props(dc, s390_skeys_props);
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
}
static const TypeInfo s390_skeys_info = {
.name = TYPE_S390_SKEYS,
.parent= TYPE_DEVICE,
-.instance_init = s390_skeys_instance_init,
.instance_size = sizeof(S390SKeysState),
.class_init= s390_skeys_class_init,
.class_size= sizeof(S390SKeysClass),
Re: [PULL 00/39] Migration 20231024 patches
Stefan Hajnoczi wrote: > On Tue, 24 Oct 2023 at 23:45, Juan Quintela wrote: >> >> The following changes since commit a95260486aa7e78d7c7194eba65cf03311ad94ad: >> >> Merge tag 'pull-tcg-20231023' of https://gitlab.com/rth7680/qemu into >> staging (2023-10-23 14:45:46 -0700) >> >> are available in the Git repository at: >> >> https://gitlab.com/juan.quintela/qemu.git >> tags/migration-20231024-pull-request >> >> for you to fetch changes up to 088f7f03da3f5b3487091302b795c22b1bfe56fb: >> >> migration: Deprecate old compression method (2023-10-24 13:48:24 +0200) >> >> >> Migration Pull request (20231024) >> >> Hi >> >> In this PULL: >> - vmstate registration fixes (thomas, juan) >> - start merging vmstate_section_needed changes (marc) >> - migration depreactions (juan) >> - migration documentation for backwards compatibility (juan) >> >> Please apply. > > Hi Juan, > I'm seeing CI failures: > https://gitlab.com/qemu-project/qemu/-/pipelines/1048630760 start with s390x: Errors: 32/840 qemu:qtest+qtest-s390x / qtest-s390x/qom-test ERROR 50.27s killed by signal 6 SIGABRT 104/840 qemu:qtest+qtest-s390x / qtest-s390x/test-hmp ERROR 51.55s killed by signal 6 SIGABRT 189/840 qemu:qtest+qtest-s390x / qtest-s390x/boot-serial-test ERROR 54.07s killed by signal 6 SIGABRT 192/840 qemu:qtest+qtest-s390x / qtest-s390x/qos-test ERROR 51.29s killed by signal 6 SIGABRT 519/840 qemu:qtest+qtest-s390x / qtest-s390x/test-filter-mirror ERROR 50.36s killed by signal 6 SIGABRT 520/840 qemu:qtest+qtest-s390x / qtest-s390x/test-netfilter ERROR 51.03s killed by signal 6 SIGABRT 522/840 qemu:qtest+qtest-s390x / qtest-s390x/device-plug-test ERROR 50.99s killed by signal 6 SIGABRT 523/840 qemu:qtest+qtest-s390x / qtest-s390x/test-filter-redirector ERROR 54.14s killed by signal 6 SIGABRT 524/840 qemu:qtest+qtest-s390x / qtest-s390x/drive_del-test ERROR 53.40s killed by signal 6 SIGABRT 525/840 qemu:qtest+qtest-s390x / qtest-s390x/virtio-ccw-test ERROR 54.67s killed by signal 6 SIGABRT 526/840 qemu:qtest+qtest-s390x / qtest-s390x/device-introspect-test ERROR 51.15s killed by signal 6 SIGABRT 527/840 qemu:qtest+qtest-s390x / qtest-s390x/cpu-plug-test ERROR 51.21s killed by signal 6 SIGABRT 535/840 qemu:qtest+qtest-s390x / qtest-s390x/qmp-test ERROR 51.18s killed by signal 6 SIGABRT 534/840 qemu:qtest+qtest-s390x / qtest-s390x/machine-none-test ERROR 51.21s killed by signal 6 SIGABRT 533/840 qemu:qtest+qtest-s390x / qtest-s390x/qmp-cmd-test ERROR 51.22s killed by signal 6 SIGABRT 549/840 qemu:qtest+qtest-s390x / qtest-s390x/readconfig-test ERROR 51.20s killed by signal 6 SIGABRT 644/840 qemu:block / io-qcow2-001 ERROR 0.32s exit status 1 645/840 qemu:block / io-qcow2-002 ERROR 0.32s exit status 1 646/840 qemu:block / io-qcow2-003 ERROR 0.34s exit status 1 647/840 qemu:block / io-qcow2-004 ERROR 0.31s exit status 1 648/840 qemu:block / io-qcow2-005 ERROR 0.43s exit status 1 649/840 qemu:block / io-qcow2-007 ERROR 0.34s exit status 1 650/840 qemu:block / io-qcow2-008 ERROR 0.63s exit status 1 651/840 qemu:block / io-qcow2-009 ERROR 0.32s exit status 1 652/840 qemu:block / io-qcow2-010 ERROR 0.30s exit status 1 654/840 qemu:block / io-qcow2-011 ERROR 0.31s exit status 1 655/840 qemu:block / io-qcow2-012 ERROR 0.36s exit status 1 657/840 qemu:block / io-qcow2-013 ERROR 0.51s exit status 1 658/840 qemu:block / io-qcow2-017 ERROR 0.37s exit status 1 659/840 qemu:block / io-qcow2-018 ERROR 0.31s exit status 1 660/840 qemu:block / io-qcow2-019 ERROR
Re: [PATCH v3 28/28] docs: update Xen-on-KVM documentation
On Thu, 2023-10-26 at 10:26 +0200, Kevin Wolf wrote:
>
> > > > > +.. parsed-literal::
> > > > > +
> > > > > + |qemu_system| --accel kvm,xen-version=0x40011,kernel-irqchip=split
> > > > > \\
> > > > > + -chardev stdio,id=char0 -device xen-console,chardev=char0 \\
> > > > > + -display none -m 1G -kernel xen -initrd bzImage \\
> > > > > + -append "pv-shim console=xen,pv -- console=hvc0
> > > > > root=/dev/xvda1" \\
> > > > > + -drive file=${GUEST_IMAGE},if=xen
> > > > Is the space between -- and console= intentionsl?
> > > Yes, that one is correct. The -- is how you separate Xen's command line
> > > (on the left) from the guest kernel command line (on the right).
> >
> > To expand on this a bit.
> >
> > Multiboot1 supports multiple modules but only a single command line. As
> > one of the modules passed to Xen is the dom0 kernel, we need some way to
> > pass it's command line, hence the " -- ".
>
> That's not right, even Multiboot 1 contains a 'string' field in the
> module structure that is defined to typically hold a command line. The
> exact meaning is OS dependent, so Xen could use it however it wants.
>
> In QEMU (and I believe this is the same behaviour as in GRUB),
> everything before the space in an -initrd argument is treated as a
> filename to load, everything after it is just passed as the command
> line.
>
> So it would have been entirely possible to use -initrd 'bzImage
> console=hvc0 root=/dev/xvda1' if Xen worked like that.
Xen does allow that too. I didn't realise our multiboot loader did though.
So yes, you *can* use -initrd 'bzImage root=/dev/xvda1'.
And you can even load more than one module, it seems. Separate them by
commas, so -initrd 'bzImage,initrd.img' should work.
You can even do both at the same time. If you have commas on the kernel
command line, *double* them:
-initrd 'bzImage root=/dev/xvda earlyprintk=xen,,keep,initrd.img'
I'll update the documentation accordingly.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] hw/ide/ahci: trigger either error IRQ or regular IRQ, not both
On Wed, Oct 11, 2023 at 03:12:20PM +0200, Niklas Cassel wrote:
> From: Niklas Cassel
>
> According to AHCI 1.3.1, 5.3.8.1 RegFIS:Entry, if ERR_STAT is set,
> we jump to state ERR:FatalTaskfile, which will raise a TFES IRQ
> unconditionally, regardless if the I bit is set in the FIS or not.
>
> Thus, we should never raise a normal IRQ after having sent an error
> IRQ.
>
> NOTE: for QEMU platforms that use SeaBIOS, this patch depends on QEMU
> commit 784155cdcb02 ("seabios: update submodule to git snapshot"), and
> QEMU commit 14f5a7bae4cb ("seabios: update binaries to git snapshot").
>
> Signed-off-by: Niklas Cassel
> ---
> hw/ide/ahci.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index fcc5476e9e..7676e2d871 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -897,11 +897,10 @@ static bool ahci_write_fis_d2h(AHCIDevice *ad, bool
> d2h_fis_i)
> pr->tfdata = (ad->port.ifs[0].error << 8) |
> ad->port.ifs[0].status;
>
> +/* TFES IRQ is always raised if ERR_STAT is set, regardless of I bit. */
> if (d2h_fis[2] & ERR_STAT) {
> ahci_trigger_irq(ad->hba, ad, AHCI_PORT_IRQ_BIT_TFES);
> -}
> -
> -if (d2h_fis_i) {
> +} else if (d2h_fis_i) {
> ahci_trigger_irq(ad->hba, ad, AHCI_PORT_IRQ_BIT_DHRS);
> }
>
> --
> 2.41.0
>
Gentle ping :)
Kind regards,
Niklas
Re: [PATCH v3 28/28] docs: update Xen-on-KVM documentation
Am 25.10.2023 um 20:56 hat Andrew Cooper geschrieben:
> On 25/10/2023 7:26 pm, David Woodhouse wrote:
> > On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
> >> On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> >>> +
> >>> +Booting Xen PV guests
> >>> +-
> >>> +
> >>> +Booting PV guest kernels is possible by using the Xen PV shim (a version
> >>> of Xen
> >>> +itself, designed to run inside a Xen HVM guest and provide memory
> >>> management
> >>> +services for one guest alone).
> >>> +
> >>> +The Xen binary is provided as the ``-kernel`` and the guest kernel
> >>> itself (or
> >>> +PV Grub image) as the ``-initrd`` image, which actually just means the
> >>> first
> >>> +multiboot "module". For example:
> >>> +
> >>> +.. parsed-literal::
> >>> +
> >>> + |qemu_system| --accel kvm,xen-version=0x40011,kernel-irqchip=split \\
> >>> + -chardev stdio,id=char0 -device xen-console,chardev=char0 \\
> >>> + -display none -m 1G -kernel xen -initrd bzImage \\
> >>> + -append "pv-shim console=xen,pv -- console=hvc0 root=/dev/xvda1"
> >>> \\
> >>> + -drive file=${GUEST_IMAGE},if=xen
> >> Is the space between -- and console= intentionsl?
> > Yes, that one is correct. The -- is how you separate Xen's command line
> > (on the left) from the guest kernel command line (on the right).
>
> To expand on this a bit.
>
> Multiboot1 supports multiple modules but only a single command line. As
> one of the modules passed to Xen is the dom0 kernel, we need some way to
> pass it's command line, hence the " -- ".
That's not right, even Multiboot 1 contains a 'string' field in the
module structure that is defined to typically hold a command line. The
exact meaning is OS dependent, so Xen could use it however it wants.
In QEMU (and I believe this is the same behaviour as in GRUB),
everything before the space in an -initrd argument is treated as a
filename to load, everything after it is just passed as the command
line.
So it would have been entirely possible to use -initrd 'bzImage
console=hvc0 root=/dev/xvda1' if Xen worked like that.
> Multiboot2 and PVH support a command line per module, which is the
> preferred way to pass the commandlines, given a choice.
Multiboot 2 seems to integrate the string in a variable length module
structure instead of just having a pointer in a fixed length one, but
the model behind it is essentially the same as before.
Kevin
Re: [PATCH 1/6] qemu-img: rebase: stop when reaching EOF of old backing file
On 10/26/23 09:32, Michael Tokarev wrote: > 01.06.2023 22:28, Andrey Drobyshev via: >> In case when we're rebasing within one backing chain, and when target >> image >> is larger than old backing file, bdrv_is_allocated_above() ends up >> setting >> *pnum = 0. As a result, target offset isn't getting incremented, and we >> get stuck in an infinite for loop. Let's detect this case and proceed >> further down the loop body, as the offsets beyond the old backing size >> need >> to be explicitly zeroed. > > Ping? Has this been forgotten? It's a few months already.. > > /mjt Hi Michael, It's not forgotten, there's already v3 of this series and it's already taken to the block branch by Kevin: https://lists.nongnu.org/archive/html/qemu-block/2023-09/msg00593.html Andrey
Re: [PATCH 1/6] qemu-img: rebase: stop when reaching EOF of old backing file
01.06.2023 22:28, Andrey Drobyshev via: In case when we're rebasing within one backing chain, and when target image is larger than old backing file, bdrv_is_allocated_above() ends up setting *pnum = 0. As a result, target offset isn't getting incremented, and we get stuck in an infinite for loop. Let's detect this case and proceed further down the loop body, as the offsets beyond the old backing size need to be explicitly zeroed. Ping? Has this been forgotten? It's a few months already.. /mjt
Re: [PATCH v2 1/2] hw/ide: reset: cancel async DMA operation before resetting state
06.09.2023 16:09, Fiona Ebner wrote:
If there is a pending DMA operation during ide_bus_reset(), the fact
that the IDEState is already reset before the operation is canceled
can be problematic. In particular, ide_dma_cb() might be called and
then use the reset IDEState which contains the signature after the
reset. When used to construct the IO operation this leads to
ide_get_sector() returning 0 and nsector being 1. This is particularly
bad, because a write command will thus destroy the first sector which
often contains a partition table or similar.
Traces showing the unsolicited write happening with IDEState
0x5595af6949d0 being used after reset:
ahci_port_write ahci(0x5595af6923f0)[0]: port write [reg:PxSCTL] @ 0x2c:
0x0300
ahci_reset_port ahci(0x5595af6923f0)[0]: reset port
ide_reset IDEstate 0x5595af6949d0
ide_reset IDEstate 0x5595af694da8
ide_bus_reset_aio aio_cancel
dma_aio_cancel dbs=0x7f64600089a0
dma_blk_cb dbs=0x7f64600089a0 ret=0
dma_complete dbs=0x7f64600089a0 ret=0 cb=0x5595acd40b30
ahci_populate_sglist ahci(0x5595af6923f0)[0]
ahci_dma_prepare_buf ahci(0x5595af6923f0)[0]: prepare buf limit=512 prepared=512
ide_dma_cb IDEState 0x5595af6949d0; sector_num=0 n=1 cmd=DMA WRITE
dma_blk_io dbs=0x7f6420802010 bs=0x5595ae2c6c30 offset=0 to_dev=1
dma_blk_cb dbs=0x7f6420802010 ret=0
(gdb) p *qiov
$11 = {iov = 0x7f647c76d840, niov = 1, {{nalloc = 1, local_iov = {iov_base =
0x0,
iov_len = 512}}, {__pad = "\001\000\000\000\000\000\000\000\000\000\000",
size = 512}}}
(gdb) bt
#0 blk_aio_pwritev (blk=0x5595ae2c6c30, offset=0, qiov=0x7f6420802070, flags=0,
cb=0x5595ace6f0b0 , opaque=0x7f6420802010)
at ../block/block-backend.c:1682
#1 0x5595ace6f185 in dma_blk_cb (opaque=0x7f6420802010, ret=)
at ../softmmu/dma-helpers.c:179
#2 0x5595ace6f778 in dma_blk_io (ctx=0x5595ae0609f0,
sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512,
io_func=io_func@entry=0x5595ace6ee30 ,
io_func_opaque=io_func_opaque@entry=0x5595ae2c6c30,
cb=0x5595acd40b30 , opaque=0x5595af6949d0,
dir=DMA_DIRECTION_TO_DEVICE) at ../softmmu/dma-helpers.c:244
#3 0x5595ace6f90a in dma_blk_write (blk=0x5595ae2c6c30,
sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512,
cb=cb@entry=0x5595acd40b30 ,
opaque=opaque@entry=0x5595af6949d0)
at ../softmmu/dma-helpers.c:280
#4 0x5595acd40e18 in ide_dma_cb (opaque=0x5595af6949d0, ret=)
at ../hw/ide/core.c:953
#5 0x5595ace6f319 in dma_complete (ret=0, dbs=0x7f64600089a0)
at ../softmmu/dma-helpers.c:107
#6 dma_blk_cb (opaque=0x7f64600089a0, ret=0) at ../softmmu/dma-helpers.c:127
#7 0x5595ad12227d in blk_aio_complete (acb=0x7f6460005b10)
at ../block/block-backend.c:1527
#8 blk_aio_complete (acb=0x7f6460005b10) at ../block/block-backend.c:1524
#9 blk_aio_write_entry (opaque=0x7f6460005b10) at ../block/block-backend.c:1594
#10 0x5595ad258cfb in coroutine_trampoline (i0=,
i1=) at ../util/coroutine-ucontext.c:177
Signed-off-by: Fiona Ebner
Reviewed-by: Philippe Mathieu-Daudé
Ping? Has this bugfix been lost somehow?
/mjt
Re: [PATCH v2] hw/ide/ahci: fix legacy software reset
05.10.2023 13:04, Niklas Cassel:
From: Niklas Cassel
Legacy software contains a standard mechanism for generating a reset to a
Serial ATA device - setting the SRST (software reset) bit in the Device
Control register.
Serial ATA has a more robust mechanism called COMRESET, also referred to
as port reset. A port reset is the preferred mechanism for error
recovery and should be used in place of software reset.
Commit e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
improved the handling of PxCI, such that PxCI gets cleared after handling
a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after
receiving an arbitrary FIS).
However, simply clearing PxCI after a non-NCQ, or NCQ command, is not
enough, we also need to clear PxCI when receiving a SRST in the Device
Control register.
This fixes an issue for FreeBSD where the device would fail to reset.
The problem was not noticed in Linux, because Linux uses a COMRESET
instead of a legacy software reset by default.
Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
Reported-by: Marcin Juszkiewicz
Signed-off-by: Niklas Cassel
Ping? This bugfix hasn't landed in master still.. :(
/mjt
