* [PULL 0/2] M68k for 6.2 patches @ 2021-11-09 11:15 Laurent Vivier 2021-11-09 11:15 ` [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 Laurent Vivier ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Laurent Vivier @ 2021-11-09 11:15 UTC (permalink / raw) To: qemu-devel; +Cc: Laurent Vivier The following changes since commit 85549204552b624fe254831537e7a0f6450228b8: Merge remote-tracking branch 'remotes/juanquintela/tags/migration-20211109-pull-request' into staging (2021-11-09 09:41:31 +0100) are available in the Git repository at: git://github.com/vivier/qemu-m68k.git tags/m68k-for-6.2-pull-request for you to fetch changes up to 6ed25621f2890d8f1c3b9e6f7a0e91c841aea1f8: hw: m68k: virt: Add compat machine for 6.2 (2021-11-09 12:14:18 +0100) ---------------------------------------------------------------- m68k pull request 20211109 Add virt machine types for 6.1 and 6.2 ---------------------------------------------------------------- Laurent Vivier (2): hw: m68k: virt: Add compat machine for 6.1 hw: m68k: virt: Add compat machine for 6.2 hw/m68k/virt.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) -- 2.31.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 11:15 [PULL 0/2] M68k for 6.2 patches Laurent Vivier @ 2021-11-09 11:15 ` Laurent Vivier 2021-11-09 12:34 ` BALATON Zoltan 2021-11-09 11:15 ` [PULL 2/2] hw: m68k: virt: Add compat machine for 6.2 Laurent Vivier 2021-11-09 15:07 ` [PULL 0/2] M68k for 6.2 patches Richard Henderson 2 siblings, 1 reply; 11+ messages in thread From: Laurent Vivier @ 2021-11-09 11:15 UTC (permalink / raw) To: qemu-devel; +Cc: Laurent Vivier, qemu-stable Add the missing machine type for m68k/virt Cc: qemu-stable@nongnu.org Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211106194158.4068596-2-laurent@vivier.eu> Signed-off-by: Laurent Vivier <laurent@vivier.eu> --- hw/m68k/virt.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c index 4e8bce5aa6f7..0d9e3f83c169 100644 --- a/hw/m68k/virt.c +++ b/hw/m68k/virt.c @@ -304,7 +304,14 @@ type_init(virt_machine_register_types) } \ type_init(machvirt_machine_##major##_##minor##_init); +static void virt_machine_6_1_options(MachineClass *mc) +{ +} +DEFINE_VIRT_MACHINE(6, 1, true) + static void virt_machine_6_0_options(MachineClass *mc) { + virt_machine_6_1_options(mc); + compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len); } -DEFINE_VIRT_MACHINE(6, 0, true) +DEFINE_VIRT_MACHINE(6, 0, false) -- 2.31.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 11:15 ` [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 Laurent Vivier @ 2021-11-09 12:34 ` BALATON Zoltan 2021-11-09 12:55 ` Daniel P. Berrangé 0 siblings, 1 reply; 11+ messages in thread From: BALATON Zoltan @ 2021-11-09 12:34 UTC (permalink / raw) To: Laurent Vivier; +Cc: qemu-devel, qemu-stable On Tue, 9 Nov 2021, Laurent Vivier wrote: > Add the missing machine type for m68k/virt > > Cc: qemu-stable@nongnu.org > Signed-off-by: Laurent Vivier <laurent@vivier.eu> > Message-Id: <20211106194158.4068596-2-laurent@vivier.eu> > Signed-off-by: Laurent Vivier <laurent@vivier.eu> > --- > hw/m68k/virt.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c > index 4e8bce5aa6f7..0d9e3f83c169 100644 > --- a/hw/m68k/virt.c > +++ b/hw/m68k/virt.c > @@ -304,7 +304,14 @@ type_init(virt_machine_register_types) > } \ > type_init(machvirt_machine_##major##_##minor##_init); > > +static void virt_machine_6_1_options(MachineClass *mc) > +{ > +} > +DEFINE_VIRT_MACHINE(6, 1, true) > + > static void virt_machine_6_0_options(MachineClass *mc) > { > + virt_machine_6_1_options(mc); > + compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len); > } > -DEFINE_VIRT_MACHINE(6, 0, true) > +DEFINE_VIRT_MACHINE(6, 0, false) I don't understand how these compat machines work but if these are empty and essentially the same as the previous version why do we add a new version in every release? Wouldn't it be enough to add new version when there was an incompatible change? I mean, instead of listing machine and getting a lot of virt-6.1, virt-6.0, virt-5.2,... or so, we'd only get versions that are actually different such as virt-7.0, virt-5.2, virt-5.0 (maybe they are called differently, just an example) with the versionless alias always pointing to the latest. Then when QEMU is updated one can see if there was any change so should update the VM or keep using the older versions. Or does it work like that and I'm missing it completely? Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 12:34 ` BALATON Zoltan @ 2021-11-09 12:55 ` Daniel P. Berrangé 2021-11-09 19:58 ` BALATON Zoltan 0 siblings, 1 reply; 11+ messages in thread From: Daniel P. Berrangé @ 2021-11-09 12:55 UTC (permalink / raw) To: BALATON Zoltan; +Cc: qemu-stable, Laurent Vivier, qemu-devel On Tue, Nov 09, 2021 at 01:34:49PM +0100, BALATON Zoltan wrote: > On Tue, 9 Nov 2021, Laurent Vivier wrote: > > Add the missing machine type for m68k/virt > > > > Cc: qemu-stable@nongnu.org > > Signed-off-by: Laurent Vivier <laurent@vivier.eu> > > Message-Id: <20211106194158.4068596-2-laurent@vivier.eu> > > Signed-off-by: Laurent Vivier <laurent@vivier.eu> > > --- > > hw/m68k/virt.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c > > index 4e8bce5aa6f7..0d9e3f83c169 100644 > > --- a/hw/m68k/virt.c > > +++ b/hw/m68k/virt.c > > @@ -304,7 +304,14 @@ type_init(virt_machine_register_types) > > } \ > > type_init(machvirt_machine_##major##_##minor##_init); > > > > +static void virt_machine_6_1_options(MachineClass *mc) > > +{ > > +} > > +DEFINE_VIRT_MACHINE(6, 1, true) > > + > > static void virt_machine_6_0_options(MachineClass *mc) > > { > > + virt_machine_6_1_options(mc); > > + compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len); > > } > > -DEFINE_VIRT_MACHINE(6, 0, true) > > +DEFINE_VIRT_MACHINE(6, 0, false) > > I don't understand how these compat machines work but if these are empty and > essentially the same as the previous version why do we add a new version in > every release? Wouldn't it be enough to add new version when there was an > incompatible change? I mean, instead of listing machine and getting a lot of > virt-6.1, virt-6.0, virt-5.2,... or so, we'd only get versions that are > actually different such as virt-7.0, virt-5.2, virt-5.0 (maybe they are > called differently, just an example) with the versionless alias always > pointing to the latest. Then when QEMU is updated one can see if there was > any change so should update the VM or keep using the older versions. Or does > it work like that and I'm missing it completely? It doesn't work like that, and that's a good thing. The versioned machine types are for management applications that want to guarantee an ABI across hosts. When a mgmt app wants to set a new baseline for their QEMU machine types, it is way clearer if every versioned machine type across all target arches supports the same versions, regardless of whether there were any changes or not. ie if an app wants to set QEMU 6.1.0 as the baseline, they want to be able to set virt-6.1 for aarch64, for mips, for riscv, instead of having to figure out which versions exists for each arch 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 :| ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 12:55 ` Daniel P. Berrangé @ 2021-11-09 19:58 ` BALATON Zoltan 2021-11-09 21:27 ` Peter Maydell 2021-11-10 14:35 ` Daniel P. Berrangé 0 siblings, 2 replies; 11+ messages in thread From: BALATON Zoltan @ 2021-11-09 19:58 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: qemu-stable, Laurent Vivier, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3860 bytes --] On Tue, 9 Nov 2021, Daniel P. Berrangé wrote: > On Tue, Nov 09, 2021 at 01:34:49PM +0100, BALATON Zoltan wrote: >> On Tue, 9 Nov 2021, Laurent Vivier wrote: >>> Add the missing machine type for m68k/virt >>> >>> Cc: qemu-stable@nongnu.org >>> Signed-off-by: Laurent Vivier <laurent@vivier.eu> >>> Message-Id: <20211106194158.4068596-2-laurent@vivier.eu> >>> Signed-off-by: Laurent Vivier <laurent@vivier.eu> >>> --- >>> hw/m68k/virt.c | 9 ++++++++- >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c >>> index 4e8bce5aa6f7..0d9e3f83c169 100644 >>> --- a/hw/m68k/virt.c >>> +++ b/hw/m68k/virt.c >>> @@ -304,7 +304,14 @@ type_init(virt_machine_register_types) >>> } \ >>> type_init(machvirt_machine_##major##_##minor##_init); >>> >>> +static void virt_machine_6_1_options(MachineClass *mc) >>> +{ >>> +} >>> +DEFINE_VIRT_MACHINE(6, 1, true) >>> + >>> static void virt_machine_6_0_options(MachineClass *mc) >>> { >>> + virt_machine_6_1_options(mc); >>> + compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len); >>> } >>> -DEFINE_VIRT_MACHINE(6, 0, true) >>> +DEFINE_VIRT_MACHINE(6, 0, false) >> >> I don't understand how these compat machines work but if these are empty and >> essentially the same as the previous version why do we add a new version in >> every release? Wouldn't it be enough to add new version when there was an >> incompatible change? I mean, instead of listing machine and getting a lot of >> virt-6.1, virt-6.0, virt-5.2,... or so, we'd only get versions that are >> actually different such as virt-7.0, virt-5.2, virt-5.0 (maybe they are >> called differently, just an example) with the versionless alias always >> pointing to the latest. Then when QEMU is updated one can see if there was >> any change so should update the VM or keep using the older versions. Or does >> it work like that and I'm missing it completely? > > It doesn't work like that, and that's a good thing. > > The versioned machine types are for management applications that want > to guarantee an ABI across hosts. When a mgmt app wants to set a new > baseline for their QEMU machine types, it is way clearer if every > versioned machine type across all target arches supports the same > versions, regardless of whether there were any changes or not. > > ie if an app wants to set QEMU 6.1.0 as the baseline, they want > to be able to set virt-6.1 for aarch64, for mips, for riscv, > instead of having to figure out which versions exists for each > arch With a bit more logic the management app could easily implement this either by dereferencing the alias when creating the VM, say virt is an alias of virt-6,0 in QEMU 6.2 then put virt-6.0 in the VM config which then will work on anyting newer than QEMU 6.0. Or record the QEMU version in VM config when creating the VM saying this needs at least QEMU 6.1 then if there's no virt-6.1 or virt points to something newer then go back to the biggest version less than 6.1 (this might be more difficult due to changes in QEMU versioning but if we assume that at least they are increasing numbers it should be possible to find the largest version less than 6.1 for example). That way when a user types -machine help they won't get a large list of useless versioned machines that are mostly the same anyway. This looks like a case that a lazy management sofrware pollutes the human interface while it could handle it itself. But that's just my opinion, I don't use these too much so don't care too much either. It just looked like something that is putting a burden both on users and debelopers (having to add more compatiblity stuff to code that's already heavy on boilerplate) for something that could be handled within the management software. But maybe it's too late to change at this point. Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 19:58 ` BALATON Zoltan @ 2021-11-09 21:27 ` Peter Maydell 2021-11-09 23:33 ` BALATON Zoltan 2021-11-10 14:35 ` Daniel P. Berrangé 1 sibling, 1 reply; 11+ messages in thread From: Peter Maydell @ 2021-11-09 21:27 UTC (permalink / raw) To: BALATON Zoltan Cc: qemu-devel, Daniel P. Berrangé, qemu-stable, Laurent Vivier On Tue, 9 Nov 2021 at 20:01, BALATON Zoltan <balaton@eik.bme.hu> wrote: > But maybe it's too late to change at this point. Massively too late. We've been using this versioned-machine scheme for over a decade, and the upheaval of changing the way it works now would be rather out of proportion purely to tidy up the list of machines in the help output... -- PMM ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 21:27 ` Peter Maydell @ 2021-11-09 23:33 ` BALATON Zoltan 2021-11-10 14:27 ` Peter Maydell 0 siblings, 1 reply; 11+ messages in thread From: BALATON Zoltan @ 2021-11-09 23:33 UTC (permalink / raw) To: Peter Maydell Cc: qemu-devel, Daniel P. Berrangé, qemu-stable, Laurent Vivier On Tue, 9 Nov 2021, Peter Maydell wrote: > On Tue, 9 Nov 2021 at 20:01, BALATON Zoltan <balaton@eik.bme.hu> wrote: >> But maybe it's too late to change at this point. > > Massively too late. We've been using this versioned-machine > scheme for over a decade, and the upheaval of changing the > way it works now would be rather out of proportion purely to > tidy up the list of machines in the help output... Well it's more than just tidy up the list, as not adding identical machines would have saved maintenance of adding these, lines of code in code base that do nothing just making it harder to read and also would be easier for users but these benefits are maybe less than the effort to change it now so then it's too late (not because how long it's been done this way but how much effort would be to change for how much benefit). I'm OK with that, was just wondering so asked it to clarify. Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 23:33 ` BALATON Zoltan @ 2021-11-10 14:27 ` Peter Maydell 0 siblings, 0 replies; 11+ messages in thread From: Peter Maydell @ 2021-11-10 14:27 UTC (permalink / raw) To: BALATON Zoltan Cc: qemu-devel, Daniel P. Berrangé, qemu-stable, Laurent Vivier On Tue, 9 Nov 2021 at 23:33, BALATON Zoltan <balaton@eik.bme.hu> wrote: > > On Tue, 9 Nov 2021, Peter Maydell wrote: > > On Tue, 9 Nov 2021 at 20:01, BALATON Zoltan <balaton@eik.bme.hu> wrote: > >> But maybe it's too late to change at this point. > > > > Massively too late. We've been using this versioned-machine > > scheme for over a decade, and the upheaval of changing the > > way it works now would be rather out of proportion purely to > > tidy up the list of machines in the help output... > > Well it's more than just tidy up the list, as not adding identical > machines would have saved maintenance of adding these, lines of code in > code base that do nothing just making it harder to read and also would be > easier for users but these benefits are maybe less than the effort to > change it now so then it's too late (not because how long it's been done > this way but how much effort would be to change for how much benefit). I'm > OK with that, was just wondering so asked it to clarify. The other reason for always adding these machine types, which I forgot about yesterday, is that it decouples the "add new machine type" part from "incompatible changes in devices" part. We add the new machine types as a boilerplate change to all versioned machines at the start of a release cycle. Then later on when a particular device needs a change that's only enabled in the newer machine versions, we make that change in the device and add the property setting to the hw_compat_6_1[] array in hw/core/machine.c. That causes it to be automatically used for every versioned machine type that uses that device. If we only added new versioned machines "on demand", then for every device change like that we would need to identify all the machine types which have that device or could use that device, and then add the new versioned machine at that point. I think that would be easy to forget to do for all the machines, or to accidentally not identify every versioned machine that can use the device. -- PMM ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 2021-11-09 19:58 ` BALATON Zoltan 2021-11-09 21:27 ` Peter Maydell @ 2021-11-10 14:35 ` Daniel P. Berrangé 1 sibling, 0 replies; 11+ messages in thread From: Daniel P. Berrangé @ 2021-11-10 14:35 UTC (permalink / raw) To: BALATON Zoltan; +Cc: qemu-stable, Laurent Vivier, qemu-devel On Tue, Nov 09, 2021 at 08:58:58PM +0100, BALATON Zoltan wrote: > On Tue, 9 Nov 2021, Daniel P. Berrangé wrote: > > On Tue, Nov 09, 2021 at 01:34:49PM +0100, BALATON Zoltan wrote: > > > On Tue, 9 Nov 2021, Laurent Vivier wrote: > > > > Add the missing machine type for m68k/virt > > > > > > > > Cc: qemu-stable@nongnu.org > > > > Signed-off-by: Laurent Vivier <laurent@vivier.eu> > > > > Message-Id: <20211106194158.4068596-2-laurent@vivier.eu> > > > > Signed-off-by: Laurent Vivier <laurent@vivier.eu> > > > > --- > > > > hw/m68k/virt.c | 9 ++++++++- > > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c > > > > index 4e8bce5aa6f7..0d9e3f83c169 100644 > > > > --- a/hw/m68k/virt.c > > > > +++ b/hw/m68k/virt.c > > > > @@ -304,7 +304,14 @@ type_init(virt_machine_register_types) > > > > } \ > > > > type_init(machvirt_machine_##major##_##minor##_init); > > > > > > > > +static void virt_machine_6_1_options(MachineClass *mc) > > > > +{ > > > > +} > > > > +DEFINE_VIRT_MACHINE(6, 1, true) > > > > + > > > > static void virt_machine_6_0_options(MachineClass *mc) > > > > { > > > > + virt_machine_6_1_options(mc); > > > > + compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len); > > > > } > > > > -DEFINE_VIRT_MACHINE(6, 0, true) > > > > +DEFINE_VIRT_MACHINE(6, 0, false) > > > > > > I don't understand how these compat machines work but if these are empty and > > > essentially the same as the previous version why do we add a new version in > > > every release? Wouldn't it be enough to add new version when there was an > > > incompatible change? I mean, instead of listing machine and getting a lot of > > > virt-6.1, virt-6.0, virt-5.2,... or so, we'd only get versions that are > > > actually different such as virt-7.0, virt-5.2, virt-5.0 (maybe they are > > > called differently, just an example) with the versionless alias always > > > pointing to the latest. Then when QEMU is updated one can see if there was > > > any change so should update the VM or keep using the older versions. Or does > > > it work like that and I'm missing it completely? > > > > It doesn't work like that, and that's a good thing. > > > > The versioned machine types are for management applications that want > > to guarantee an ABI across hosts. When a mgmt app wants to set a new > > baseline for their QEMU machine types, it is way clearer if every > > versioned machine type across all target arches supports the same > > versions, regardless of whether there were any changes or not. > > > > ie if an app wants to set QEMU 6.1.0 as the baseline, they want > > to be able to set virt-6.1 for aarch64, for mips, for riscv, > > instead of having to figure out which versions exists for each > > arch > > With a bit more logic the management app could easily implement this either > by dereferencing the alias when creating the VM, say virt is an alias of > virt-6,0 in QEMU 6.2 then put virt-6.0 in the VM config which then will work > on anyting newer than QEMU 6.0. Or record the QEMU version in VM config when > creating the VM saying this needs at least QEMU 6.1 then if there's no > virt-6.1 or virt points to something newer then go back to the biggest > version less than 6.1 (this might be more difficult due to changes in QEMU > versioning but if we assume that at least they are increasing numbers it > should be possible to find the largest version less than 6.1 for example). > That way when a user types -machine help they won't get a large list of > useless versioned machines that are mostly the same anyway. This looks like > a case that a lazy management sofrware pollutes the human interface while it > could handle it itself. But that's just my opinion, I don't use these too > much so don't care too much either. It just looked like something that is > putting a burden both on users and debelopers (having to add more > compatiblity stuff to code that's already heavy on boilerplate) for > something that could be handled within the management software. But maybe > it's too late to change at this point. On the contrary, the way we handle this today *reduces* the burden on everyone involved both QEMU, management apps & users. The amount of code in QEMU for a machine type with zero back compat properties is tiny. Simply having this is less burden for QEMU that having to check whether we need it or not when adding breaking changes. Whether a machine type has back compat props or not is irrelevant to the end user / mgmt app, as machine types are opaque objects. They can simply decide to use a particular machine type version baseline, and be confident it will "do the right thing" on all targets. 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 :| ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PULL 2/2] hw: m68k: virt: Add compat machine for 6.2 2021-11-09 11:15 [PULL 0/2] M68k for 6.2 patches Laurent Vivier 2021-11-09 11:15 ` [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 Laurent Vivier @ 2021-11-09 11:15 ` Laurent Vivier 2021-11-09 15:07 ` [PULL 0/2] M68k for 6.2 patches Richard Henderson 2 siblings, 0 replies; 11+ messages in thread From: Laurent Vivier @ 2021-11-09 11:15 UTC (permalink / raw) To: qemu-devel; +Cc: Laurent Vivier Add the missing machine type for m68k/virt Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20211106194158.4068596-3-laurent@vivier.eu> Signed-off-by: Laurent Vivier <laurent@vivier.eu> --- hw/m68k/virt.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c index 0d9e3f83c169..978c26e025a7 100644 --- a/hw/m68k/virt.c +++ b/hw/m68k/virt.c @@ -304,10 +304,17 @@ type_init(virt_machine_register_types) } \ type_init(machvirt_machine_##major##_##minor##_init); +static void virt_machine_6_2_options(MachineClass *mc) +{ +} +DEFINE_VIRT_MACHINE(6, 2, true) + static void virt_machine_6_1_options(MachineClass *mc) { + virt_machine_6_2_options(mc); + compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len); } -DEFINE_VIRT_MACHINE(6, 1, true) +DEFINE_VIRT_MACHINE(6, 1, false) static void virt_machine_6_0_options(MachineClass *mc) { -- 2.31.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PULL 0/2] M68k for 6.2 patches 2021-11-09 11:15 [PULL 0/2] M68k for 6.2 patches Laurent Vivier 2021-11-09 11:15 ` [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 Laurent Vivier 2021-11-09 11:15 ` [PULL 2/2] hw: m68k: virt: Add compat machine for 6.2 Laurent Vivier @ 2021-11-09 15:07 ` Richard Henderson 2 siblings, 0 replies; 11+ messages in thread From: Richard Henderson @ 2021-11-09 15:07 UTC (permalink / raw) To: Laurent Vivier, qemu-devel On 11/9/21 12:15 PM, Laurent Vivier wrote: > The following changes since commit 85549204552b624fe254831537e7a0f6450228b8: > > Merge remote-tracking branch 'remotes/juanquintela/tags/migration-20211109-pull-request' into staging (2021-11-09 09:41:31 +0100) > > are available in the Git repository at: > > git://github.com/vivier/qemu-m68k.git tags/m68k-for-6.2-pull-request > > for you to fetch changes up to 6ed25621f2890d8f1c3b9e6f7a0e91c841aea1f8: > > hw: m68k: virt: Add compat machine for 6.2 (2021-11-09 12:14:18 +0100) > > ---------------------------------------------------------------- > m68k pull request 20211109 > > Add virt machine types for 6.1 and 6.2 > > ---------------------------------------------------------------- > > Laurent Vivier (2): > hw: m68k: virt: Add compat machine for 6.1 > hw: m68k: virt: Add compat machine for 6.2 > > hw/m68k/virt.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) Applied, thanks. r~ ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-11-10 14:37 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-09 11:15 [PULL 0/2] M68k for 6.2 patches Laurent Vivier 2021-11-09 11:15 ` [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 Laurent Vivier 2021-11-09 12:34 ` BALATON Zoltan 2021-11-09 12:55 ` Daniel P. Berrangé 2021-11-09 19:58 ` BALATON Zoltan 2021-11-09 21:27 ` Peter Maydell 2021-11-09 23:33 ` BALATON Zoltan 2021-11-10 14:27 ` Peter Maydell 2021-11-10 14:35 ` Daniel P. Berrangé 2021-11-09 11:15 ` [PULL 2/2] hw: m68k: virt: Add compat machine for 6.2 Laurent Vivier 2021-11-09 15:07 ` [PULL 0/2] M68k for 6.2 patches Richard Henderson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.