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.
> > H
"Michael S. Tsirkin" writes:
> On Tue, Nov 18, 2014 at 03:47:16PM +0100, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > 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 goo
On 19 November 2014 07:13, Fam Zheng 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
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/config
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 functional
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 bug
"Michael S. Tsirkin" wrote:
> simple wrapper so callers don't need to know about
> dirty bitmap clients.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Juan Quintela
"Michael S. Tsirkin" 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 wrote:
> Signed-off-by: Amit Shah
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
Reviewed-by: Juan Quintela
Amit Shah wrote:
> Signed-off-by: Amit Shah
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Juan Quintela
Amit Shah wrote:
> Signed-off-by: Amit Shah
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Juan Quintela
Amit Shah wrote:
> Signed-off-by: Amit Shah
Reviewed-by: Juan Quintela
On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" 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 regula
On 18/11/2014 23:50, Peter Maydell wrote:
> On 18 November 2014 21:19, Paolo Bonzini 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 values then should
* 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 descript
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
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 bloc
On Mon, 17 Nov 2014 13:11:08 +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 cur
On Wed, 19 Nov 2014 16:28:09 +0800
zhanghailiang 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 will
work just fine with s
On Wed, 19 Nov 2014 12:51:00 +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 cor
"Michael S. Tsirkin" 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 li
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, returnin
"Michael S. Tsirkin" writes:
> On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" 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
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:
http://lists.gnu.org/archive/html/
Signed-off-by: Ekaterina Tumanova
---
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
--- a/block/block-backend.c
+++ b/block/block-b
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.
Signed-off-by
Add driver functions for geometry and blocksize detection
Signed-off-by: Ekaterina Tumanova
---
block.c | 26 ++
include/block/block.h | 20
include/block/block_int.h | 3 +++
3 files changed, 49 insertions(+)
diff --git a/bloc
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 s
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 CheckForDAS
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 th
On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" 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 id
On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
> >> "Michael S. Tsirkin" wrote:
> >> > On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
> >> >>
> >> >>
> >> >>
On 18 November 2014 20:19, Liviu Ionescu 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 not implement
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'
> Am 19.11.2014 um 06:48 schrieb Aravinda Prasad :
>
>
>
> 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
>> way.
>>
>>
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.
>
> a
"Michael S. Tsirkin" wrote:
> On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" 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. If they are the sa
"Michael S. Tsirkin" wrote:
> On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>> Since migration doesn't transport configuration, we require a compatibly
>> configured target, and that includes identical memory sizes. RAM size
>> is explicit a
On Wed, Nov 19, 2014 at 09:35:16AM +, 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 cod
On 19 November 2014 12:08, Leif Lindholm wrote:
> 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=676e1b2fcd9dbb47a59baac13d089621d22c68b
On 18 Nov 2014, at 21:46, Liviu Ionescu 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 exceptions due
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, whic
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 -
On 19 November 2014 11:37, Liviu Ionescu wrote:
>
> On 18 Nov 2014, at 21:46, Liviu Ionescu 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 rebasing branch, so yo
On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
>
>
>
> > Am 19.11.2014 um 06:48 schrieb Aravinda Prasad
> > :
> >
> >
> >
> > On Tuesday 11 November 2014 08:54 AM, David Gibson wrote:
> >
> > [..]
> >
> >>
> >> So, this may not still be possible depending on whether the K
> Am 19.11.2014 um 12:44 schrieb David Gibson :
>
>> On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
>>
>>
>>
>>> Am 19.11.2014 um 06:48 schrieb Aravinda Prasad
>>> :
>>>
>>>
>>>
>>> On Tuesday 11 November 2014 08:54 AM, David Gibson wrote:
>>>
>>> [..]
>>>
S
Don Slutz writes:
> The other callers to blk_set_enable_write_cache() in this file
> already check for s->blk == NULL.
>
> Signed-off-by: Don Slutz
> ---
>
> I think this is a bugfix that should be back ported to stable
> releases.
>
> I also think this should be done in xen's copy of QEMU for 4
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);
+tcg_gen_ext_i32_i64(t1
> Am 19.11.2014 um 13:22 schrieb Alexander Graf :
>
>
>
>
>>> Am 19.11.2014 um 12:44 schrieb David Gibson :
>>>
>>> On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
>>>
>>>
>>>
Am 19.11.2014 um 06:48 schrieb Aravinda Prasad
:
On Tuesday 11
On Wed, Nov 19, 2014 at 01:22:01PM +0100, Alexander Graf wrote:
>
>
>
> > Am 19.11.2014 um 12:44 schrieb David Gibson :
> >
> >> 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 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 each of the patches app
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 Bl
On 19 November 2014 13:06, Liviu Ionescu 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, you 'append
On Wed, Nov 19, 2014 at 11:45:15AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
> >> "Michael S. Tsirkin" wrote:
> >> > On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
>
>
> >> qemu -M pc-2.0 -L BIOS-
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
On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
>
>
> >> Since migration doesn't transport configuration, we require a compatibly
> >> configured
On Wed, Nov 19, 2014 at 09:16:09AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, Nov 18, 2014 at 03:47:16PM +0100, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > At the moment we migrate ROMs which reside in fw cfg, which allows
> >> > chan
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
On 19 Nov 2014, at 15:20, Peter Maydell 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 not used before, it will
"Michael S. Tsirkin" wrote:
> On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>> > On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote:
>> >> "Michael S. Tsirkin" writes:
>>
>>
>> >> Since migration doesn't transport configuration, we
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 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 need to maint
"Michael S. Tsirkin" 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" wrote:
> On Wed, Nov 19, 2014 at 11:45:15AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>> > On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote:
>> >> "Michael S. Tsirkin" wrote:
>> >> > On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
Paolo Bonzini 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 gene
On 17 November 2014 20: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:
>
> - it is never exposed to guest
> - block is sized on migration, making it easier to extend
>
Signed-off-by: Ekaterina Tumanova
---
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
+++ b/hw/block/hd-geometry.c
@@ -147,7 +147,8 @@ void h
Paolo Bonzini 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
>> UEFI?
>
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):
https://github.com/
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 messa
On 19 November 2014 13:19, Eric Blake 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 would be
Peter Maydell wrote:
> On 17 November 2014 20: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:
>>
>> - it is never exposed to guest
>> - block is sized on migration, maki
On 19 November 2014 14:07, Juan Quintela 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 we mark it as
On 19/11/2014 15:03, Juan Quintela wrote:
> Paolo Bonzini 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
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 of
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 19/11/2014 15:03, Juan Quintela wrote:
> > Paolo Bonzini 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 th
Peter Maydell wrote:
> On 19 November 2014 14:07, Juan Quintela 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
>>
On 19/11/2014 15:10, Peter Maydell wrote:
> On 19 November 2014 14:07, Juan Quintela 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 duri
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
---
blockdev.c | 16 +
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 t
Paolo Bonzini wrote:
> On 19/11/2014 15:03, Juan Quintela wrote:
>> Paolo Bonzini 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?
Wher
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 bdrv_chain_contains(b
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 tackl
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
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
---
blockdev.c | 4
1 file changed, 4 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index fb9a005..a7f1e09 100644
--- a/bl
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
---
Hi,
As usually with changes that
"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 an expansion for
On 19 November 2014 14:19, Paolo Bonzini 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 can't actuall
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
* 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 attribu
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)
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 micr
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: Pa
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.
G
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
qemu-
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
On 19 November 2014 14:01, Ekaterina Tumanova
wrote:
> Signed-off-by: Ekaterina Tumanova
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 current code would cause a compilation failure or why
that
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 mechanis
1 - 100 of 204 matches
Mail list logo
