Hi Omar,
> From: Omar Rizwan [mailto:omar.riz...@gmail.com]
> Sent: Friday, 7 April 2017 22:43
Did you do any testing of this? One of the reasons I never got around to
upstreaming this was that I couldn't get Raspbian working reliably (there was
some problem with stalled DMA reads from the MMC
Signed-off-by: Ishani Chugh
---
target/arm/kvm64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 609..a16abc8 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -940,7 +940,7 @@ bool kvm_arm_handle_debug(CPUState
On Fri, Apr 07, 2017 at 08:14:36AM +0200, Cédric Le Goater wrote:
> On 04/06/2017 11:53 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2017-04-06 at 14:35 +0200, Cédric Le Goater wrote:
> >> but real HW (2 sockets OpenPOWER systems, garrison and firestone)
> >> does
> >> not expose the LPC bus on t
On Fri, Apr 7, 2017 at 6:10 PM, Fam Zheng wrote:
> On Fri, 04/07 16:44, jemmy858...@gmail.com wrote:
>> From: Lidong Chen
>>
>> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default,
>> this maybe cause the qcow2 file size is bigger after migration.
>> This patch check each cluster, use
On Fri, 04/07 13:50, Stefan Hajnoczi wrote:
> On Fri, Apr 07, 2017 at 02:54:12PM +0800, Fam Zheng wrote:
> > @@ -4413,6 +4416,10 @@ void bdrv_set_aio_context(BlockDriverState *bs,
> > AioContext *new_context)
> > aio_context_acquire(new_context);
> > bdrv_attach_aio_context(bs, new_conte
On Fri, 04/07 14:05, John Snow wrote:
>
>
> On 04/07/2017 09:28 AM, Stefan Hajnoczi wrote:
> > On Fri, Apr 07, 2017 at 02:54:14PM +0800, Fam Zheng wrote:
> >> Previously, before test_block_job_start returns, the job can already
> >> complete, as a result, the transactional state of other jobs add
I can confirm that this bug is fixed in qemu 2.8.1
Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1654137
Title:
Ctrl-A b not working in 2.8.0
Status in QEMU:
New
Bug description:
Wit
On Fri, 04/07 14:26, Stefan Hajnoczi wrote:
> I wasn't expecting the patch to touch so many places. If a coroutine
> can be permanently associated with an AioContext then there's no need to
> keep assigning co->ctx on each qemu_coroutine_enter().
Maybe, but bs->job->co->ctx changes when bdrv_set_
Tested on PowerMac G5 Quad and 380% of system load and working on
Fedora 25 PPC64 host and Ubuntu Mate 17.04 guest (patched the 2.9 rc3)
The machine configuration was this
sudo ./qemu-system-ppc64 -cpu POWER8 -vga none -machine pseries-2.5,usb=off -m
2G -smp 4,cores=4,threads=1 -accel tcg,t
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> All block jobs are using block_job_defer_to_main_loop as the final
> step just before the coroutine terminates. At this point,
> block_job_enter should do nothing, but currently it restarts
> the freed coroutine.
>
> Now, the job->co states should
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> This splits the part that touches job states from the part that invokes
> callbacks. It will be a bit simpler to understand once job states will
> be protected by a different mutex than the AioContext lock.
>
Maybe easier to review then, too :)
>
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
What was the bad design that required you to fix the previous test? :)
> ---
> blockjob.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/blockjob.c b/blockjob.c
> index c9cb5b1..
pc.rom depends on pam. When pam is disabled, pc.rom is useless
Signed-off-by: Anthony Xu
---
hw/i386/pc.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 9d154c2..455f7fe 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1358,7 +
when pam is disabled, set pc.bios and isa.bios region as writeable,
and add isa.bios to system memory region.
Signed-off-by: Anthony Xu
---
hw/i386/pc.c | 2 +-
hw/i386/pc_sysfw.c | 30 +-
include/hw/i386/pc.h | 4 +++-
3 files changed, 25 insertions(+), 1
by default PAM is enabled. when PAM is disabled,
*_init_pam and *_update_pam are dummy functions
Signed-off-by: Anthony Xu
---
hw/i386/pc.c | 18 ++
hw/pci-host/piix.c | 36
hw/pci-host/q35.c| 34 +++--
Qemu creates 13 enabled memory regions and 39 disabled memory regions
for pam. in normal setup, more than half of all memory regions in
system root region are memory regions for pam. Which slow down all
memory region related operations.
This patch makes pam configurable, by default it is enabled.
split PAM SMRAM functions in piix.c
create mch_init_pam in q35.c
Signed-off-by: Anthony Xu
---
hw/pci-host/piix.c | 58 ++
hw/pci-host/q35.c | 23 +-
2 files changed, 55 insertions(+), 26 deletions(-)
diff --git a/hw/pci-h
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> Unlike test-blockjob-txn, QMP releases the reference to the transaction
> before the jobs finish. Thus, while working on the next patch,
> qemu-iotest 124 showed a failure that the unit tests did not have.
> Make the unit test just a little nastier,
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> Outside blockjob.c, the block_job_iostatus_reset function is used once
> in the monitor and once in BlockBackend. When we introduce the block
> job mutex, block_job_iostatus_reset's client is going to be the block
> layer (for which blockjob.c will
Public bug reported:
In a small hobby kernel for Raspberry Pi 2B, I am using the system timer
to control wait durations. This timer is located at 0x3f003000 and the
timer counts are located at 0x3f003004 (CLO) and 0x3f004008 (CHI).
Reading these memory locations returns 0 for both.
The basic cod
The command lines are:
[adam@os-dev ~]$ qemu-system-aarch64 -m 256 -M raspi2 -serial stdio
-kernel bin/rpi2b/kernel.elf
[adam@os-dev workspace]$ ./qemu/bin/debug/native/arm-softmmu/qemu-
system-arm -m 256 -M raspi2 -serial stdio -kernel
century/bin/rpi2b/kernel.elf
A sample kernel is also attac
On 04/07/2017 08:12 PM, John Snow wrote:
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
This is unused since commit 66a0fae ("blockjob: Don't touch BDS iostatus",
2016-05-19).
Signed-off-by: Paolo Bonzini
---
blockjob.c | 3 ---
include/block/blockjob_int.h | 3 ---
2 files ch
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> We already have different locking policies for APIs called by the monitor
> and the block job. Monitor APIs need consistency across block_job_get
> and the actual operation (e.g. block_job_set_speed), so currently there
> are explicit aio_context_ac
I meant to say you cannot run without the intel card in windows if you
have optimus. I am glad seabios somehow hides optimus.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680679
Title:
qemu canno
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> Remove use of block_job_pause/resume from outside blockjob.c, thus
> making them static. Again, one reason to do this is that
> block_job_pause/resume will have different locking rules compared
> to everything else that block.c and block/io.c use.
>
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> Outside blockjob.c, block_job_unref is only used when a block job fails
> to start, and block_job_ref is not used at all. The reference counting
> thus is pretty well hidden. Introduce a separate function to be used
> by block jobs; because block_j
On 04/07/2017 06:54 PM, Philippe Mathieu-Daudé wrote:
> Hi Paolo,
>
> On 03/23/2017 02:39 PM, Paolo Bonzini wrote:
>> !job is always checked prior to the call, drop it from here.
>
> I agree with you this is currently true, *but* block_job_user_paused()
> is exported in "block/blockjob.h" so an
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> This is unused since commit 66a0fae ("blockjob: Don't touch BDS iostatus",
> 2016-05-19).
>
> Signed-off-by: Paolo Bonzini
> ---
> blockjob.c | 3 ---
> include/block/blockjob_int.h | 3 ---
> 2 files changed, 6 deletions(-)
>
>
Your approach works ok Gerd with a migration blocker. Are you going to
send a patch?
I am afraid we would have to make this code permanent though, since
there has been several releases of this driver already, and it's much
nicer to block migration than to crash a VM.
I have reached out to wddm dr
Hi Mark, thank you for your effort on SPARC64 emulation in QEMU!
Thanks for the explanation on what might be wrong. Is there a way to
workaround the PCI problems?
Tribblix is indeed an illumos (a community fork of OpenSolaris)
distribution. Contrary to Milax, which looks abandoned to me as
OpenSo
Hi Paolo,
On 03/23/2017 02:39 PM, Paolo Bonzini wrote:
!job is always checked prior to the call, drop it from here.
I agree with you this is currently true, *but* block_job_user_paused()
is exported in "block/blockjob.h" so any future access (external to
blockdev.c) could eventually happen w
On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
> !job is always checked prior to the call, drop it from here.
>
> Signed-off-by: Paolo Bonzini
> ---
> blockjob.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/blockjob.c b/blockjob.c
> index 9b619f385..a9fb624 100644
>
Not sure we want a failure mode for pre_save().
If we go for option (a) (from comment 9), I'd add a check when reading
the commands from the ring, not at migration time, so we don't run enter
a state where pre_save() can fail in the first place. Because that will
break the windows drivers we migh
Suggested-by: Michael Roth
Signed-off-by: Philippe Mathieu-Daudé
---
Michael should I use Signed-off-by instead of the Suggested-by (since it is your
code)?
qga/commands-posix.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index fc45102a1e.
static code analyzer complain:
device_tree.c:155:18: warning: Null pointer passed as an argument to a
'nonnull' parameter
while ((de = readdir(d)) != NULL) {
^~
Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Marc-André Lureau
static code analyzer complain:
hw/usb/dev-smartcard-reader.c:816:5: warning: Null pointer passed as an
argument to a 'nonnull' parameter
memcpy(p->abData, data, len);
^~~~
Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé
---
hw/usb/dev-sm
static code analyzer complain:
qga/commands-posix.c:2127:9: warning: Null pointer passed as an argument to a
'nonnull' parameter
closedir(dp);
^~~~
Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Marc-André Lureau
---
qga/commands-
This patchset fixes three easy-to-fix unrelated clang warnings, so it was
probably better to send them separately the first time.
v2:
- hw/usb/dev-smartcard-reader.c: The first patch was treating NULL and 0 as
errors but those values are legal in some cases, i.e. no (virtual)
smart
It works using seabios. I assume that the nvidia driver cannot see
optimus, and expect an intel card also, unless I use OVMF. I do know
that you cannot run off the intel card in windows. It's a no-no. Thanks
for the bios tip. Maybe I can hide the optimus feature from OVMF and
windows.
--
You rece
I suspect the 'M' in GTX880M is the biggest contributor to the Code 43.
The fact you can get it to work once per host boot on SeaBIOS is a
fluke. If you can get custom ROMs, you might try playing with the vfio-
pci x-pci-device-id option to masquerade as a discrete card, maybe that
would avoid mob
ok, so I will research qemu and nvidia optimus. I have a custom BIOS
made by an MSI employee. I have hundreds of bios options to play with.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680679
Title
Hi Markus, Gerd.
On 03/23/2017 11:08 AM, Markus Armbruster wrote:
Gerd Hoffmann writes:
On Do, 2017-03-23 at 13:41 +0100, Markus Armbruster wrote:
Gerd Hoffmann writes:
Hi,
oops, there are hard-coded calls with NULL/0. I suppose to fix clang
warning, it would need to check if data !=
Hi Michael,
On 03/22/2017 06:22 PM, Michael Roth wrote:
Quoting Philippe Mathieu-Daudé (2017-03-22 15:48:44)
static code analyzer complain:
qga/commands-posix.c:2127:9: warning: Null pointer passed as an argument to a
'nonnull' parameter
closedir(dp);
^~~~
Reported-by
On 04/06/2017 12:55 PM, Eric Blake wrote:
On 04/06/2017 10:49 AM, Eric Blake wrote:
On 04/06/2017 10:41 AM, Dr. David Alan Gilbert (git) wrote:
From: "Dr. David Alan Gilbert"
Gcc 7 (on Fedora 26) spotted odd use of integers instead of a
boolean; it's got a point.
Signed-off-by: Dr. David Ala
My uefi build script. If you see an error or issue that could cause
error 43 please confirm it:
#!/bin/bash
cd /home/dad/qemu/qemu2
sudo ./up.sh tap0
configfile=./vfio-pci1.cfg
vfiobind() {
dev="$1"
vendor=$(cat /sys/bus/pci/devices/$dev/vendor)
device=$(cat /sys/bus/pci/dev
GTX880M - uefi firmware built in, confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680679
Title:
qemu cannot run twice
Status in QEMU:
Invalid
Bug description:
After using qemu with g
Perhaps you get Code 43 because mobile NVIDIA chips make use of Optimus
which requires significant proprietary firmware support. QEMU/VFIO has
never claimed to work with such devices. The further speculation in the
original report that QEMU corrupted something in Linux seems
unjustified, the devi
Comments #3 & #4 are not relevant to this bug and inaccurate
speculation. There is no known incompatibility between NVIDIA drivers
and OVMF. Many users, including myself, use this combination daily.
The issue is far more likely to be a VM configuration issue or lack of
UEFI support in the GPU ROM
Update 'clientname' to be 'user', which tracks better with both
the QAPI and rados variable naming.
Update 'name' to be 'image_name', as it indicates the rbd image.
Naming it 'image' would have been ideal, but we are using that for
the rados_image_t value returned by rbd_open().
Reviewed-by: Stef
Introduce check function for setting read_only flags. Will return < 0 on
error, with appropriate Error value set. Does not alter any flags.
Signed-off-by: Jeff Cody
---
block.c | 14 +-
include/block/block.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
di
This adds support for reopen in rbd, for changing between r/w and r/o.
Note, that this is only a flag change, but we will block a change from
r/o to r/w if we are using an RBD internal snapshot.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Jeff Cody
---
block/rbd.c | 21 +
1
A few block drivers will set the BDS read_only flag from their
.bdrv_open() function. This means the bs->read_only flag could
be set after we enable copy_on_read, as the BDRV_O_COPY_ON_READ
flag check occurs prior to the call to bdrv->bdrv_open().
This adds an error return to bdrv_set_read_only()
Move bdrv_is_read_only() up with its friends.
Reviewed-by: Stefan Hajnoczi
Reviewed-by: John Snow
Signed-off-by: Jeff Cody
---
block.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block.c b/block.c
index 68a18b0..a05ad48 100644
--- a/block.c
+++ b/block.c
@@ -
Signed-off-by: Jeff Cody
---
block.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/block.c b/block.c
index 1514ae9..5d560f5 100644
--- a/block.c
+++ b/block.c
@@ -2785,6 +2785,7 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state,
BlockReopenQueue *queue
The BDRV_O_ALLOW_RDWR flag allows / prohibits the changing of
the BDS 'read_only' state, but there are a few places where it
is ignored. In the bdrv_set_read_only() helper, make sure to
honor the flag.
Signed-off-by: Jeff Cody
---
block.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
Changes from v1:
Patch 2: Has v1 patch 8 (do not blindly xset bs->read_only) squashed into it
(thanks Stefan)
COW -> "copy-on-read" (Thanks John)
Drop unneeded call in vvfat, and bypass enable_write_target (Stefan)
Patch 5: Rename bdrv_try_... to bdrv_can_set_read_only
We have a helper wrapper for checking for the BDS read_only flag,
add a helper wrapper to set the read_only flag as well.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Jeff Cody
---
block.c | 5 +
block/bochs.c | 2 +-
block/cloop.c | 2 +-
block/dmg.c
NOTE: I only get gpu passthrough to work when using seabios. UEFI will
not work with modern nvidia drivers. You get the 'code 43' error because
whatever standards nvidia expects when talking to uefi are not met by
the OVMF firmware used by qemu. This issue happens to windows users
also. They had to
NOTE: Article showing windows users updating their motherboard uefi firmware to
get around code 43:
https://devtalk.nvidia.com/default/topic/861244/cuda-setup-and-installation/geforce-740m-asus-x550l-code-43-after-windows-10-update/3
--
You received this bug notification because you are a member
On 03/30/2017 05:51 AM, Marc Zyngier wrote:
> On 29/03/17 19:56, Christoffer Dall wrote:
>> On Tue, Mar 28, 2017 at 01:24:15PM -0700, Radha Mohan wrote:
>>> On Tue, Mar 28, 2017 at 1:16 PM, Christoffer Dall wrote:
Hi Radha,
On Tue, Mar 28, 2017 at 12:58:24PM -0700, Radha Mohan wro
** Changed in: qemu
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1014681
Title:
BSOD with newer host kernels (x64) and W2k8S guest (x64)
Status in QEMU:
W
On 04/04/2017 02:01 PM, Gabriel L. Somlo wrote:
As of release 10.12.4, OS X (Sierra) refuses to boot unless the
AppleSMC supports an additional I/O port, expected to provide an
error status code.
Update the [cmd|data]_write() and data_read() methods to implement
the required state machine, and a
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1678466
Title:
using x-vga=on with vfio-pci leads to segfault
Status in QEMU:
Fix Committed
On Apr 7, 2017, at 1:49 PM, luigi burdo wrote:
Tested on PowerMac G5 Quad and 380% of system load and working on
Fedora 25 PPC64 host and Ubuntu Mate 17.04 guest (patched the 2.9
rc3)
The machine configuration was this
sudo ./qemu-system-ppc64 -cpu POWER8 -vga none -machine
pseries-2.5
On 04/05/2017 05:35 AM, Mark Cave-Ayland wrote:
These aren't required since we can use the display width and height directly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/display/cg3.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
d
Hi Dave,
On 04/07/2017 11:38 AM, Dr. David Alan Gilbert wrote:
Hi,
Fedora 26 has gcc 7.0.1 which has the normal compliment
of new fussy warnings; so far I've posted :
tests/check-qdict: Fix missing brackets
slirp/smb: Replace constant strings by glib string
that fix one actual mistake and w
On 04/07/2017 06:14 AM, Alex Bennée wrote:
Sorry, I meant we should generate TCG opcodes for the translation in
gen_io_start.
Ahh OK. I think this is 2.10 stuff though right?
Definitely.
r~
On Fri, Apr 07, 2017 at 03:41:38PM +0100, Ard Biesheuvel wrote:
> Our current ACPI table generation code limits the placement of ACPI
> tables to 32-bit addressable memory, in order to be able to emit the
> root pointer (RSDP) and root table (RSDT) using table types from the
> ACPI 1.0 days.
>
> S
On 04/06/2017 11:07 PM, Nikunj A Dadhania wrote:
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 8
1 file changed, 8 insertions(+)
Reviewed-by: Richard Henderson
r~
On 04/06/2017 11:07 PM, Nikunj A Dadhania wrote:
Emulating LL/SC with cmpxchg is not correct, since it can suffer from
the ABA problem. However, portable parallel code is written assuming
only cmpxchg which means that in practice this is a viable alternative.
Signed-off-by: Nikunj A Dadhania
--
On 04/06/2017 10:21 PM, Nikunj A Dadhania wrote:
We do that in the macro:
if (len > 1) { \
gen_check_align(ctx, t0, (len) - 1);\
} \
Would we still need a barrier
On 04/07/2017 09:28 AM, Stefan Hajnoczi wrote:
> On Fri, Apr 07, 2017 at 02:54:14PM +0800, Fam Zheng wrote:
>> Previously, before test_block_job_start returns, the job can already
>> complete, as a result, the transactional state of other jobs added to
>> the same txn later cannot be handled corr
I have been told that getting this to work with a laptop is rare.
I own an MSI GT70-2PE.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680679
Title:
qemu cannot run twice
Status in QEMU:
New
B
* John Snow (js...@redhat.com) wrote:
>
>
> On 04/04/2017 03:31 AM, Thomas Huth wrote:
> > On 03.04.2017 21:09, John Snow wrote:
> >>
> >>
> >> On 03/30/2017 03:50 AM, Thomas Huth wrote:
> >>> When running certain HMP commands (like "device_del") via QMP, we
> >>> can sometimes get a QMP event in
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> Don't need to flush all VM's ram from cache, only
> flush the dirty pages since last checkpoint
>
> Cc: Juan Quintela
> Signed-off-by: Li Zhijian
> Signed-off-by: Zhang Chen
> Signed-off-by: zhanghailiang
> ---
> migration/ram.c | 10 +
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> There are several stages during loadvm/savevm process. In different stage,
> migration incoming processes different types of sections.
> We want to control these stages more accuracy, it will benefit COLO
> performance, we don't have to save
On 08/04/2017 09:16, Wang guang wrote:
> From: ZhiPeng Lu
>
> A RAM device represents a mapping to a physical device, such as to a PCI
> * MMIO BAR of an vfio-pci assigned device.
> Vhost listens to this region,and increases the region's reference count
> while passthrough?for?network adapters
On 06.04.2017 17:01, Alberto Garcia wrote:
> Hi all,
>
> over the past couple of months I discussed with some of you the
> possibility to extend the qcow2 format in order to improve its
> performance and reduce its memory requirements (particularly with very
> large images).
>
> After some discus
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> We should not load PVM's state directly into SVM, because there maybe some
> errors happen when SVM is receving data, which will break SVM.
>
> We need to ensure receving all data before load the state into SVM. We use
> an extra memory to
The command used is: qemu-system-x86_64 -drive file=../minix-img/minix_work.img
-net user,hostfwd=tcp::2-:22 -net nic,model=virtio -m 1024M
qemu 1.8.0 in this case, I'll test against 1.8.1 when it gets into the repos.
--
You received this bug notification because you are a member of qemu-
d
I experience the same while running Minix guest under an Arch Linux
host. Sometimes during heavy I/O the whole machine freezes with this
error message.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/14
An untested hack that might fail cleaner might be:
error_report("Broken driver . migration failed");
qemu_file_set_error(migrate_get_current()->to_dst_file, -EINVAL);
(untested, probably needs checking it works with savevm).
I must go around and add a return value to pre_save().
We prob
Well. qxl commands are expected to live in bar 0 (same bar where the
rings are too). vram bar was added as surface storage.
Now the windows drivers started to us vram for qxl commands. Problem is
we simply can't live-migrate such a guest. At least not without
changing the vmstate format. Whic
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> For COLO FT, both the PVM and SVM run at the same time,
> only sync the state while it needs.
>
> So here, let SVM runs while not doing checkpoint,
> Besides, change DEFAULT_MIGRATE_X_CHECKPOINT_DELAY to 200*100.
>
> Cc: Jason Wang
> Sign
On Thu, Apr 6, 2017 at 3:13 AM, Stefan Hajnoczi wrote:
> On Fri, Mar 31, 2017 at 04:41:47PM +0800, Haozhong Zhang wrote:
>>
>> Add an boolean option 'flush-hint' to device 'nvdimm'. If it's on, a
>> flush hint address structure will be constructed for each nvdimm
>> device.
>
> Users should not ne
This ensures each time the vCPU thread reads the icount we update the
master timer_state.qemu_icount field. This way as long as updates are
in BQL protected sections (which they should be) the main-loop can
never come to update the log and find time has gone backwards.
Signed-off-by: Alex Bennée
On 06.04.2017 15:04, Stefan Hajnoczi wrote:
> On Mon, Apr 03, 2017 at 06:09:33PM +0200, Max Reitz wrote:
>> +BDRVQcow2State *s = bs->opaque;
>> +uint64_t aligned_cur_size = align_offset(current_size,
>> cluster_size);
>> +uint64_t creftable_length;
>> +uint64_t i;
>
On Sat, Apr 08, 2017 at 09:24:10AM +0800, ZhiPeng Lu wrote:
> A RAM device represents a mapping to a physical device, such as to a PCI
> * MMIO BAR of an vfio-pci assigned device.
> Vhost listens to this region,and increases the region's reference count
> while passthrough?for?network adapters (Phy
As icount is only supported for single-threaded execution due to the
requirement for determinism let's remove it from the common
tcg_exec_cpu path.
Also remove the additional fiddling which shouldn't be required as the
icount counters should all be rectified as you enter the loop.
Signed-off-by:
By holding off updates to timer_state.qemu_icount we can run into
trouble when the non-vCPU thread needs to know the time. This helper
ensures we atomically update timers_state.qemu_icount based on what
has been currently executed.
Signed-off-by: Alex Bennée
---
cpus.c | 23 +++
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> We will use this notifier to help COLO to notify filter object
> to do something, like do checkpoint, or process failover event.
>
> Cc: Jason Wang
> Signed-off-by: zhanghailiang
> ---
> net/colo.c | 92
> +++
This script is a debugging tool for looking through the contents of a
replay log file. It is incomplete but should fail gracefully at events
it doesn't understand.
It currently understands two different log formats as the audio
record/replay support was merged during since MTTCG. It was written to
The lifetime of current_cpu is now the lifetime of the vCPU thread.
However get_icount_raw() can apply a fudge factor if called while code
is running to take into account the current executed instruction
count.
To ensure this is always the case we also check cpu->running.
Signed-off-by: Alex Benn
Outside of the vCPU thread icount time will only be tracked against
timers_state.qemu_icount. We no longer credit cycles until they have
completed the run. Inside the vCPU thread we adjust for passage of
time by looking at how many have run so far. This is only valid inside
the vCPU thread while it
If we find ourselves trying to add an event to the log where time has
gone backwards it is because a vCPU event has occurred and the
main-loop is not yet aware of time moving forward. This should not
happen and if it does its better to fail early than generate a log
that will have weird behaviour.
Anything that calls into HW emulation must be protected by the BQL.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Acked-by: Eduardo Habkost
---
target/i386/misc_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/i386/misc_helper.c b/target/i386/misc_helper.c
ind
This introduces the qemu-gdb command "qemu timers" which will dump the
state of the main timers in the system.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
---
scripts/qemu-gdb.py | 3 ++-
scripts/qemugdb/timers.py | 54 +++
2
Hi,
This doesn't change much from v2 earlier this week:
https://lists.nongnu.org/archive/html/qemu-devel/2017-04/msg00661.html
There was a minor improvement to the cpu_update_icount to not use a
potentially expensive atomic_add (which is CST) when you can get away
with weaker semantics with a
Since QEMU has been able to build with native Int128 support this was
broken as it attempts to fish values out of the non-existent
structure. Also the alias print was trying to make a %x out of
gdb.ValueType directly which didn't seem to work.
Signed-off-by: Alex Bennée
---
scripts/qemugdb/mtree
There is no particular reason we shouldn't update the global system
icount time as we exit each TranslationBlock run. This ensures the
main-loop doesn't have to wait until we exit to the outer loop for
executed instructions to be credited to timer_state.
The prepare_icount_for_run function is slig
1 - 100 of 275 matches
Mail list logo
