On Wed, Nov 19, 2014 at 01:01:14PM +0530, Amit Shah wrote:
On (Mon) 17 Nov 2014 [22:08:46], Michael S. Tsirkin wrote:
At the moment we migrate ROMs which reside in fw cfg, which allows
changing ROM code at will, and supports migrating largish blocks early,
with good performance.
However,
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Nov 18, 2014 at 03:47:16PM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
At the moment we migrate ROMs which reside in fw cfg, which allows
changing ROM code at will, and supports migrating largish blocks
On 19 November 2014 07:13, Fam Zheng f...@redhat.com wrote:
Because which(1) is not always installed, whereas command -v is
the more native way to check for a command.
Signed-off-by: Fam Zheng f...@redhat.com
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On (Wed) 19 Nov 2014 [10:15:16], Michael S. Tsirkin wrote:
On Wed, Nov 19, 2014 at 01:01:14PM +0530, Amit Shah wrote:
On (Mon) 17 Nov 2014 [22:08:46], Michael S. Tsirkin wrote:
Note: migration stream is unaffected by these patches.
This makes it possible to enable this functionality
Hi,
Ping...?
Should this be fixed in 2.2?
Thanks,
zhanghailiang
On 2014/11/17 13:11, zhanghailiang wrote:
Hi,
Patch 1 and 2 mainly fix bug about balloon not working correctly when we do
hotplug memory. It takes 'ram_size' as VM's real RAM size which is wrong
after we hotplug memory.
This
Michael S. Tsirkin m...@redhat.com wrote:
simple wrapper so callers don't need to know about
dirty bitmap clients.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
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:
Amit Shah amit.s...@redhat.com wrote:
Signed-off-by: Amit Shah amit.s...@redhat.com
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
Reviewed-by: Juan Quintela quint...@redhat.com
Amit Shah amit.s...@redhat.com wrote:
Signed-off-by: Amit Shah amit.s...@redhat.com
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
Reviewed-by: Juan Quintela quint...@redhat.com
Amit Shah amit.s...@redhat.com wrote:
Signed-off-by: Amit Shah amit.s...@redhat.com
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Juan Quintela quint...@redhat.com
Amit Shah amit.s...@redhat.com wrote:
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
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
On 18/11/2014 23:50, Peter Maydell wrote:
On 18 November 2014 21:19, Paolo Bonzini pbonz...@redhat.com wrote:
The isa-debugexit and testdev character device do not exit with exitcode
0, in order to distinguish an exit from a system power down; the
low-order bit is always 1. The return
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 18/11/2014 21:28, Dr. David Alan Gilbert wrote:
This seems odd, since as far as I know the tunneling code is quite separate
to the migration code; I thought the only thing that the migration
code sees different is the file descriptors it
On Mo, 2014-11-17 at 20:19 +0300, Michael Tokarev wrote:
17.11.2014 18:52, Marc-André Lureau wrote:
Nothing seems to be using functions from spice-experimental.h (better
that way). Let's remove its inclusion.
Is it with current spice, or with some older spice too?
I mean, why this include
On Nov18 18:15, Markus Armbruster wrote:
Looks like you're using an old version of QEMU. drive_del has been
fixed to refuse touching a backend created with blockdev-add:
I am using the last v2.1.x version but there was indeed some commits
since
You can't destroy a backend created with
On Mon, 17 Nov 2014 13:11:08 +0800
zhanghailiang zhang.zhanghaili...@huawei.com wrote:
The global parameter 'ram_size' does not take into account
the hotplugged memory.
In some codes, we use 'ram_size' as current VM's real RAM size,
which is not correct.
Add function
On Wed, 19 Nov 2014 16:28:09 +0800
zhanghailiang zhang.zhanghaili...@huawei.com wrote:
Hi,
Ping...?
Should this be fixed in 2.2?
I'd preffer it go after memory unplug is merged to see how balooning
will fare along with it.
Also ack from Luiz could be useful to make it sure that balloning
On Wed, 19 Nov 2014 12:51:00 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Mon) 17 Nov 2014 [19:04:13], Michael S. Tsirkin wrote:
acpi build modifies internal FW CFG RAM on first access
but we forgot to mark it dirty.
If this RAM has been migrated already, it won't be
migrated again,
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
On Wed, Nov 19, 2014 at 12:51:00PM +0530, Amit Shah wrote:
On (Mon) 17 Nov 2014 [19:04:13], Michael S. Tsirkin wrote:
acpi build modifies internal FW CFG RAM on first access
but we forgot to mark it dirty.
If this RAM has been migrated already, it won't be
migrated again, returning
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
Hi folks,
I'm sorry for the recent spam. I messed up during code submission last time.
So please ignore any previous notes you received from me and answer only to
this thread.
This is the rework of the geometry+blocksize patch, which was
recently discussed here:
Signed-off-by: Ekaterina Tumanova tuman...@linux.vnet.ibm.com
---
block/block-backend.c | 10 ++
include/sysemu/block-backend.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/block/block-backend.c b/block/block-backend.c
index d0692b1..6717301 100644
---
Move the IOCTL calls that detect logical blocksize from raw_probe_alignment
into separate function (probe_logical_blocksize).
Introduce function which detect physical blocksize via IOCTL
(probe_physical_blocksize).
Both functions will be used in the next patch.
Signed-off-by: Ekaterina Tumanova
hd_geometry_guess function autodetects the drive geometry. This patch
adds a block backend call, that probes the backing device geometry.
If the inner driver method is implemented and succeeds (currently only DASDs),
the blkconf_geometry will pass-through the backing device geometry.
Add driver functions for geometry and blocksize detection
Signed-off-by: Ekaterina Tumanova tuman...@linux.vnet.ibm.com
---
block.c | 26 ++
include/block/block.h | 20
include/block/block_int.h | 3 +++
3 files changed, 49
For target-s390x, the behaviour is chosen as follows:
If no geo could be guessed from backing device, guess_disk_lchs (partition
table guessing) is called.
If this is not successful (e.g. image files) geometry is derived from the
size of the disk (as before).
We have no translation on s390, so we
This patch introduces driver methods of defining disk blocksizes
(physical and logical) and hard drive geometry.
The method is only implemented for host_device. For raw devices
driver calls child's method.
The detection will only work for DASD devices. In order to check that
a local CheckForDASD
On 19/11/2014 10:35, Dr. David Alan Gilbert wrote:
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 18/11/2014 21:28, Dr. David Alan Gilbert wrote:
This seems odd, since as far as I know the tunneling code is quite separate
to the migration code; I thought the only thing that the migration
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:
On 18 November 2014 20:19, Liviu Ionescu i...@livius.net wrote:
The usual semihosting behaviour is to process the system calls locally and
return; unfortuantelly the initial implementation dinamically changed the
target to GDB during debug sessions, which, for the usual arm-none-eabi-gdb,
is
On Mon, Nov 17, 2014 at 01:11:08PM +0800, zhanghailiang wrote:
The global parameter 'ram_size' does not take into account
the hotplugged memory.
In some codes, we use 'ram_size' as current VM's real RAM size,
which is not correct.
Add function 'get_current_ram_size' to calculate VM's
Am 19.11.2014 um 06:48 schrieb Aravinda Prasad aravi...@linux.vnet.ibm.com:
On Tuesday 11 November 2014 08:54 AM, David Gibson wrote:
[..]
So, this may not still be possible depending on whether the KVM side
of this is already merged, but it occurs to me that there's a simpler
Any suggestions here..
Thanks
Anshul Makkar
On Tue, Nov 18, 2014 at 5:34 PM, Anshul Makkar
anshul.mak...@profitbricks.com wrote:
Sorry, forgot to mention I am using git clone -b vhost-user-v5
https://github.com/virtualopensystems/qemu.git; for vhost-user backend
implementation.
and git
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 19 November 2014 12:08, Leif Lindholm leif.lindh...@linaro.org wrote:
As of Linux 3.15, the generic stdout-path property described by
ePAPR 1.1 is supported by the upstream kernel:
On 18 Nov 2014, at 21:46, Liviu Ionescu i...@livius.net wrote:
once you integrate them...
thank you for integrating them.
so can I base my next patches on them?
I'll work on another patch, to fix passing the semihosting command line down
to the armv7m code, since currently this triggers
Am 19.11.2014 um 11:17 schrieb Ekaterina Tumanova:
Hi folks,
I'm sorry for the recent spam. I messed up during code submission last time.
So please ignore any previous notes you received from me and answer only to
this thread.
This is the rework of the geometry+blocksize patch, which was
On 19/11/2014 12:39, Prof. Dr. Michael Schefczyk wrote:
Dear Paolo,
thank you very much for your prompt reply.
Hi,
please keep the replies on the mailing list. I've added the qemu-devel
mailing list, where more people should be able to see the message and
hopefully reply with something
On 19/11/2014 12:48, Prof. Dr. Michael Schefczyk wrote:
Thank you very much. To execute the backup, I run a script. For the machine
in question, it looks as follows:
#!/bin/bash
dt=`date +%y%m%d`
qemu-img snapshot -c gatewayb72 /kvm02/gatewayb72.img
qemu-img convert -f qcow2 -O qcow2
On 19 November 2014 11:37, Liviu Ionescu i...@livius.net wrote:
On 18 Nov 2014, at 21:46, Liviu Ionescu i...@livius.net wrote:
once you integrate them...
thank you for integrating them.
so can I base my next patches on them?
You can, yes. (Bear in mind that my target-arm.next
branch is a
On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
Am 19.11.2014 um 06:48 schrieb Aravinda Prasad
aravi...@linux.vnet.ibm.com:
On Tuesday 11 November 2014 08:54 AM, David Gibson wrote:
[..]
So, this may not still be possible depending on whether the
Am 19.11.2014 um 12:44 schrieb David Gibson da...@gibson.dropbear.id.au:
On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
Am 19.11.2014 um 06:48 schrieb Aravinda Prasad
aravi...@linux.vnet.ibm.com:
On Tuesday 11 November 2014 08:54 AM, David Gibson wrote:
Don Slutz dsl...@verizon.com writes:
The other callers to blk_set_enable_write_cache() in this file
already check for s-blk == NULL.
Signed-off-by: Don Slutz dsl...@verizon.com
---
I think this is a bugfix that should be back ported to stable
releases.
I also think this should be done
On 11/14/2014 01:39 PM, Richard Henderson wrote:
On 11/13/2014 06:12 PM, Bastian Koppelmann wrote:
+tcg_gen_ext_i32_i64(t3, r3);
+tcg_gen_concat_i32_i64(t2, r2_low, r2_high);
+/* extend the sign for r2 to high 64 bits */
+tcg_gen_sari_i64(t4, t2, 63);
+
Am 19.11.2014 um 13:22 schrieb Alexander Graf ag...@suse.de:
Am 19.11.2014 um 12:44 schrieb David Gibson da...@gibson.dropbear.id.au:
On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
Am 19.11.2014 um 06:48 schrieb Aravinda Prasad
aravi...@linux.vnet.ibm.com:
On Wed, Nov 19, 2014 at 01:22:01PM +0100, Alexander Graf wrote:
Am 19.11.2014 um 12:44 schrieb David Gibson da...@gibson.dropbear.id.au:
On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
Am 19.11.2014 um 06:48 schrieb Aravinda Prasad
On 19 Nov 2014, at 14:08, Peter Maydell peter.mayd...@linaro.org wrote:
... (Bear in mind that my target-arm.next
branch is a rebasing branch, so you can't git merge
or pull it; you need to fetch it and then rebase
your patchstack on it.)
I currently have two more branches in my git, for
On 11/19/2014 12:07 AM, Fam Zheng wrote:
When which(1) is not installed, we would complain perl not found
because it's the first set_prog_path check. The error message is
wrong.
Fix it by using command -v, a native way to query the existence of a
command.
Suggested-by: Eric Blake
On 19 November 2014 13:06, Liviu Ionescu i...@livius.net wrote:
I already explained, but will do it again.
Sorry if I missed that; there's a lot of mail on qemu-devel...
first, we are talking about two completely different use cases.
on the A profile you have a kernel, and when you start it,
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 01:52:35PM +0530, Amit Shah wrote:
On (Wed) 19 Nov 2014 [10:15:16], Michael S. Tsirkin wrote:
On Wed, Nov 19, 2014 at 01:01:14PM +0530, Amit Shah wrote:
On (Mon) 17 Nov 2014 [22:08:46], Michael S. Tsirkin wrote:
Note: migration stream is unaffected by these
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 Wed, Nov 19, 2014 at 09:16:09AM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Nov 18, 2014 at 03:47:16PM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m...@redhat.com writes:
At the moment we migrate ROMs which reside in fw cfg, which
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
On 19 Nov 2014, at 15:20, Peter Maydell peter.mayd...@linaro.org wrote:
Yes, we should do this. (We have to make cmdline= optional anyway,
to support old and previously working command lines.)
ok, so I'll add the optional 'cmdline=' to the newly added
'-semihosting-config'. since this was
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
On 19 November 2014 07:31, Amit Shah amit.s...@redhat.com wrote:
On (Mon) 17 Nov 2014 [22:08:46], Michael S. Tsirkin wrote:
Considering this promises to rid us of worries about ROM size considerations
once and for all, I thinking about pushing this as a kind of bugfix before
2.2, so we don't
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 19, 2014 at 01:52:35PM +0530, Amit Shah wrote:
On (Wed) 19 Nov 2014 [10:15:16], Michael S. Tsirkin wrote:
On Wed, Nov 19, 2014 at 01:01:14PM +0530, Amit Shah wrote:
On (Mon) 17 Nov 2014 [22:08:46], Michael S. Tsirkin wrote:
Note:
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
Signed-off-by: Ekaterina Tumanova tuman...@linux.vnet.ibm.com
---
hw/block/hd-geometry.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/block/hd-geometry.c b/hw/block/hd-geometry.c
index b462225..905d2c6 100644
--- a/hw/block/hd-geometry.c
+++
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
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid
leaf with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls patches,
and qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
On 19.11.2014 12:41, Paolo Bonzini wrote:
On 19/11/2014 12:39, Prof. Dr. Michael Schefczyk wrote:
Dear Paolo,
thank you very much for your prompt reply.
Hi,
please keep the replies on the mailing list. I've added the qemu-devel
mailing list, where more people should be able to see the
On 19 November 2014 13:19, Eric Blake ebl...@redhat.com wrote:
Use of -a and -o in [[]] is a bit better, but I still HIGHLY recommend
that constructs like this be rewritten as [ -n $p ] [ -x $p ] for
avoidance of confusion and prevention of copy-pasting the test to
non-bash shells. But that
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
Add dataplane support to the blockdev-snapshot-delete-internal-sync QMP
command. By acquiring the AioContext we avoid race conditions with the
dataplane thread which may also be accessing the BlockDriverState.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
blockdev.c
This patch series adds virtio-blk dataplane support for the following QMP
commands:
* eject
* change
* change-backing-file
* block_passwd
* blockdev-snapshot-delete-internal-sync
This requires acquiring and releasing the BlockDriverState's AioContext so that
the IOThread does not run while
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
Add dataplane support to the change-backing-file QMP commands. By
acquiring the AioContext we avoid race conditions with the dataplane
thread which may also be accessing the BlockDriverState.
Note that this command operates on both bs and a node in its chain
(image_bs). The
By acquiring the AioContext we avoid race conditions with the dataplane
thread which may also be accessing the BlockDriverState.
Fix up eject, change, and block_passwd in a single patch because
qmp_eject() and qmp_change_blockdev() both call eject_device(). Also
fix block_passwd while we're
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.
The BLOCK_OP_TYPE_INTERNAL_SNAPSHOT_DELETE op blocker exists but was
never used! Let's fix that so snapshot delete can be blocked.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
blockdev.c | 4
1 file changed, 4 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index
Tighten ISA level checks down to MIPS II that many of our instructions
are missing. Also make sure any 64-bit instruction enables are only
applied to 64-bit processors, that is ones that implement at least the
MIPS III ISA.
Signed-off-by: Maciej W. Rozycki ma...@codesourcery.com
---
Hi,
As
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
Yes! My level of knowledge is that one uses the qcow2 format in order to be
able to create live snapshots/backups. Otherwise one would tend to use the more
efficient raw format. Is this not correct and did I apply the backup mechanism
in the wrong way?
-Ursprüngliche Nachricht-
Von:
As of Linux 3.15, the generic stdout-path property described by
ePAPR 1.1 is supported by the upstream kernel:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of/base.c?id=676e1b2fcd9dbb47a59baac13d089621d22c68b8
ARM virt still sets the legacy linux,stdout-path.
Dear Paolo,
Thank you very much. To execute the backup, I run a script. For the machine in
question, it looks as follows:
#!/bin/bash
dt=`date +%y%m%d`
qemu-img snapshot -c gatewayb72 /kvm02/gatewayb72.img
qemu-img convert -f qcow2 -O qcow2 /kvm02/gatewayb72.img
/backup/gatewayb72$dt.img
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
On 19 November 2014 14:01, Ekaterina Tumanova
tuman...@linux.vnet.ibm.com wrote:
Signed-off-by: Ekaterina Tumanova tuman...@linux.vnet.ibm.com
Could you give the compiler error/warning message, please
(and the compiler version)?
These changes look sensible but it's not clear to me why
the
On 19/11/2014 14:52, Peter Maydell wrote:
It certainly seems pretty risky to introduce this change with
only two weeks to go til release; I wouldn't want to merge it
without a strong consensus from everybody involved that it
really needed to go in for 2.2.
I think there's consensus (you,
On 19/11/2014 13:07, Prof. Dr. Michael Schefczyk wrote:
Yes! My level of knowledge is that one uses the qcow2 format in order
to be able to create live snapshots/backups. Otherwise one would tend
to use the more efficient raw format. Is this not correct and did I
apply the backup mechanism
I think I know what is happening here. But you are pointing at the
wrong change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled() is
returning false in pc_machine_initfn. Where as in pc_init1 is is
returning true.
1 - 100 of 203 matches
Mail list logo
