On 20/11/2014 15:04, Michael S. Tsirkin wrote:
On Thu, Nov 20, 2014 at 02:35:14PM +0100, Markus Armbruster wrote:
What am I missing here that can justify the complexity of partially
overriding target configuration in the migration stream plus
infrastructure for resizing memory?
The
Hi,
I don't know why RHEL7 SeaBIOS does not work on RHEL6. But note that
it's a really old version (0.12).
Hmm, works for me on a quick smoke test. Do you remember what exactly
broke and which version it was? Maybe the 1.7.2 - 1.7.5 update fixed
it?
Or was it live-migration by chance?
On 20/11/2014 09:12, Gerd Hoffmann wrote:
Hi,
I don't know why RHEL7 SeaBIOS does not work on RHEL6. But note that
it's a really old version (0.12).
Hmm, works for me on a quick smoke test. Do you remember what exactly
broke and which version it was? Maybe the 1.7.2 - 1.7.5 update
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 18, 2014 at
On Thu, Nov 20, 2014 at 02:35:14PM +0100, Markus Armbruster wrote:
What am I missing here that can justify the complexity of partially
overriding target configuration in the migration stream plus
infrastructure for resizing memory?
The justification is that sizing it properly is an unsolved
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
On 17/11/2014 21:08, Michael S. Tsirkin wrote:
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
On 17/11/2014 21:08, Michael S. Tsirkin wrote:
Add API to manage on-device RAM.
This looks just like regular RAM
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
I very much prefer to have
user-controlled ACPI information (coming from the command-line)
byte-for-byte identical for a given machine type. Patches for that have
been on the list
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
On 17/11/2014 21:08, Michael S. Tsirkin wrote:
Add API to manage
On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
I very much prefer to have
user-controlled ACPI information (coming from the command-line)
byte-for-byte
On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
qemu -M pc-2.0 -L BIOS-2.0.bin
And that way for every version and every bios.
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
Since migration doesn't transport configuration, we require a compatibly
configured target, and that includes identical memory sizes. RAM
On Wed, Nov 19, 2014 at 11:45:15AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
qemu -M
On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
Since migration doesn't transport configuration, we require a compatibly
On 19/11/2014 14:28, Michael S. Tsirkin wrote:
qemu-2.0 -M pc-2.0 - qemu-2.2 -M pc-2.0
what BIOS should the second qemu use? the one that existed on qemu-2.0
time or the one that existed on qemu-2.2 time? You can allow for
bugfixes, but not for big changes like moving where the
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
Since migration doesn't
On 19/11/2014 14:49, Juan Quintela wrote:
Real hardware lets users update firmware and so should virtual hardware.
But you can hibernate your laptop, update the firmware, and reboot?
Where the change can be anyting, like moving from traditional BIOS to
UEFI?
Wait wait wait. I totally
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:45:15AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 10:19:22AM
Paolo Bonzini pbonz...@redhat.com wrote:
Am I missing a part of the discussion? When we migrate, the second QEMU
uses the BIOS from the first.
So:
qemu-2.0 -M pc-2.0 - qemu-2.2 -M pc-2.0
uses 2.0 BIOS
qemu-2.2 -M pc-2.0 - qemu-2.0 -M pc-2.0
uses 2.2 BIOS
Both should work, in
On 17 November 2014 20:08, Michael S. Tsirkin m...@redhat.com wrote:
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
- it is never exposed to guest
- block is sized on migration, making it easier to
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 14:49, Juan Quintela wrote:
Real hardware lets users update firmware and so should virtual hardware.
But you can hibernate your laptop, update the firmware, and reboot?
Where the change can be anyting, like moving from traditional BIOS to
Peter Maydell peter.mayd...@linaro.org wrote:
On 17 November 2014 20:08, Michael S. Tsirkin m...@redhat.com wrote:
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
- it is never exposed to guest
- block
On 19 November 2014 14:07, Juan Quintela quint...@redhat.com wrote:
My understanding is that it is a trick. We have internal memory for a
device that is needed for the emulation, but not showed to the guest.
And it is big enough that we want to save it during the live stage of
migration, so
On 19/11/2014 15:03, Juan Quintela wrote:
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 14:49, Juan Quintela wrote:
Real hardware lets users update firmware and so should virtual hardware.
But you can hibernate your laptop, update the firmware, and reboot?
Where the change can be
Since we've wondered off the actual ACPI table stuff into general
ROM sizing, I'd like to propose some concrete fixes:
1) We explicitly name the bios file in a .romfile attribute for
all ROMs.
2) The code that uses .romfile has an expansion for $MACHINETYPE
3) We actually symlink all
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:03, Juan Quintela wrote:
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 14:49, Juan Quintela wrote:
Real hardware lets users update firmware and so should virtual hardware.
But you can hibernate your laptop, update
Peter Maydell peter.mayd...@linaro.org wrote:
On 19 November 2014 14:07, Juan Quintela quint...@redhat.com wrote:
My understanding is that it is a trick. We have internal memory for a
device that is needed for the emulation, but not showed to the guest.
And it is big enough that we want to
On 19/11/2014 15:10, Peter Maydell wrote:
On 19 November 2014 14:07, Juan Quintela quint...@redhat.com wrote:
My understanding is that it is a trick. We have internal memory for a
device that is needed for the emulation, but not showed to the guest.
And it is big enough that we want to
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 15:03, Juan Quintela wrote:
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 14:49, Juan Quintela wrote:
Real hardware lets users update firmware and so should virtual hardware.
But you can hibernate your laptop, update the
On 19/11/2014 14:57, Juan Quintela wrote:
Shipping a separate BIOS for different machine types is unrealistic and
pointless. It would also be a good terrain for bug reports, unless you
also do things like forbid creating -device megasas-gen2 on 2.1 because
it was introduced in 2.2.
Dr. David Alan Gilbert dgilb...@redhat.com wrote:
Since we've wondered off the actual ACPI table stuff into general
ROM sizing, I'd like to propose some concrete fixes:
1) We explicitly name the bios file in a .romfile attribute for
all ROMs.
2) The code that uses .romfile has an
On 19 November 2014 14:19, Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 15:10, Peter Maydell wrote:
Would it be feasible to just have the migration code provide
an API for registering things to be migrated in the live
migration stage, rather than creating memory regions which
you
On 19/11/2014 15:13, Dr. David Alan Gilbert wrote:
Since we've wondered off the actual ACPI table stuff into general
ROM sizing, I'd like to propose some concrete fixes:
1) We explicitly name the bios file in a .romfile attribute for
all ROMs.
2) The code that uses .romfile has
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:13, Dr. David Alan Gilbert wrote:
Since we've wondered off the actual ACPI table stuff into general
ROM sizing, I'd like to propose some concrete fixes:
1) We explicitly name the bios file in a .romfile attribute for
On 19/11/2014 15:26, Dr. David Alan Gilbert wrote:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:13, Dr. David Alan Gilbert wrote:
Since we've wondered off the actual ACPI table stuff into general
ROM sizing, I'd like to propose some concrete fixes:
1) We explicitly
On 19/11/2014 15:16, Dr. David Alan Gilbert wrote:
Consider the similar case on real hardware:
boot
update microcode RPM
s4
turn on
CPU microcode is installed early by the kernel, before looking for a
hibernation image to resume from, so the CPU microcode after resume from
On 19/11/2014 15:21, Peter Maydell wrote:
But in any case this is really just memory that is auto-resized on
migration. And it can work even if it is mapped in memory, as long as
your resize callback (or some post_load code executed while migrating
devices) does something useful to
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:26, Dr. David Alan Gilbert wrote:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:13, Dr. David Alan Gilbert wrote:
Since we've wondered off the actual ACPI table stuff into general
ROM sizing, I'd like to
On Wed, Nov 19, 2014 at 01:58:54PM +, Peter Maydell wrote:
On 17 November 2014 20:08, Michael S. Tsirkin m...@redhat.com wrote:
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
- it is never exposed
On Wed, Nov 19, 2014 at 02:10:36PM +, Peter Maydell wrote:
On 19 November 2014 14:07, Juan Quintela quint...@redhat.com wrote:
My understanding is that it is a trick. We have internal memory for a
device that is needed for the emulation, but not showed to the guest.
And it is big
On Wed, Nov 19, 2014 at 03:30:59PM +0100, Paolo Bonzini wrote:
On 19/11/2014 15:21, Peter Maydell wrote:
But in any case this is really just memory that is auto-resized on
migration. And it can work even if it is mapped in memory, as long as
your resize callback (or some post_load
On Wed, Nov 19, 2014 at 02:59:12PM +, Dr. David Alan Gilbert wrote:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:26, Dr. David Alan Gilbert wrote:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:13, Dr. David Alan Gilbert wrote:
Since
On Wed, Nov 19, 2014 at 03:20:07PM +0100, Juan Quintela wrote:
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 15:03, Juan Quintela wrote:
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 14:49, Juan Quintela wrote:
Real hardware lets users update firmware and so should
On Wed, Nov 19, 2014 at 02:51:38PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
Michael S.
* Michael S. Tsirkin (m...@redhat.com) wrote:
On Wed, Nov 19, 2014 at 02:59:12PM +, Dr. David Alan Gilbert wrote:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 19/11/2014 15:26, Dr. David Alan Gilbert wrote:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On
On Wed, Nov 19, 2014 at 03:18:01PM +0100, Juan Quintela wrote:
Peter Maydell peter.mayd...@linaro.org wrote:
On 19 November 2014 14:07, Juan Quintela quint...@redhat.com wrote:
My understanding is that it is a trick. We have internal memory for a
device that is needed for the emulation,
On Wed, Nov 19, 2014 at 02:44:32PM +0100, Paolo Bonzini wrote:
So:
qemu-2.0 -M pc-2.0 - qemu-2.2 -M pc-2.0
uses 2.0 BIOS
qemu-2.2 -M pc-2.0 - qemu-2.0 -M pc-2.0
uses 2.2 BIOS
Both should work, in general. BIOS is rarely the reason for
incompatibilities. However, breakage
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 14:57, Juan Quintela wrote:
Shipping a separate BIOS for different machine types is unrealistic and
pointless. It would also be a good terrain for bug reports, unless you
also do things like forbid creating -device megasas-gen2 on 2.1
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 02:51:38PM +0100, Juan Quintela wrote:
Actually yes: devices that want this functionality need to call
the new API.
At the point where API is called, would be the best place to
put in an explanation why it should be
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 15:10, Peter Maydell wrote:
It does already, for example PPC uses it for its IOMMU tables.
But in any case this is really just memory that is auto-resized on
migration. And it can work even if it is mapped in memory, as long as
your
On 19/11/2014 17:39, Juan Quintela wrote:
Paolo Bonzini pbonz...@redhat.com wrote:
On 19/11/2014 14:57, Juan Quintela wrote:
Shipping a separate BIOS for different machine types is unrealistic and
pointless. It would also be a good terrain for bug reports, unless you
also do things like
On 19/11/2014 17:27, Kevin O'Connor wrote:
On Wed, Nov 19, 2014 at 02:44:32PM +0100, Paolo Bonzini wrote:
So:
qemu-2.0 -M pc-2.0 - qemu-2.2 -M pc-2.0
uses 2.0 BIOS
qemu-2.2 -M pc-2.0 - qemu-2.0 -M pc-2.0
uses 2.2 BIOS
Both should work, in general. BIOS is rarely the reason for
On 19/11/2014 17:45, Juan Quintela wrote:
Absolutely. And that is why callers get a callback notifying them about
resize.
See? You are arriving at my design step by step :)
Then why we ever wonder about assingning the space on the 1st place?
Just got it from the migration stream?
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
- it is never exposed to guest
- block is sized on migration, making it easier to extend
without breaking migration compatibility or wasting
virtual
On Mon, Nov 17, 2014 at 10:08:53PM +0200, Michael S. Tsirkin wrote:
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
- it is never exposed to guest
- block is sized on migration, making it easier to
On 17/11/2014 21:08, Michael S. Tsirkin wrote:
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
- block is sized on migration, making it easier to extend
without breaking migration compatibility or
On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
On 17/11/2014 21:08, Michael S. Tsirkin wrote:
Add API to manage on-device RAM.
This looks just like regular RAM from migration POV,
but has two special properties internally:
- block is sized on migration, making
58 matches
Mail list logo
