---
cpus.c |1 +
1 file changed, 1 insertion(+)
diff --git a/cpus.c b/cpus.c
index 1104d61..4c53747 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1417,6 +1417,7 @@ void qmp_memsave(int64_t addr, int64_t size, const char
*filename,
return;
}
+cpu_synchronize_state(cpu);
while
calling "memsave' through the qmp makes a zero filled dump. the hmp still works
properly because hmp_memsave calls cpu_synchronize_state before calling
qmp_memsave.
---
Andrey Karpov (1):
synchronize state of the cpu before memory reading
cpus.c |1 +
1 file changed, 1 insertion(+)
Hi guys,
This bug has reported in a very long time. I have tested v1.7.0, v1.7.1 and
even v2.0.0rc1, v2.0.0rc2.
The bug is still there. This is very easy to reproduce. I dunno why it is not
fixed until today.
I think living-snapshot is a very important feature for Qemu. Somebody can take
a lo
On Wed, Apr 9, 2014 at 11:28 AM, Peter Crosthwaite
wrote:
> On Wed, Mar 26, 2014 at 10:47 AM, Alistair Francis
> wrote:
>> This patch introduces a new command line argument that allows
>> sysbus devices to be attached via the command line.
>>
>> This allows devices to be added after the machine i
D'oh, sorry. I generated that patch against my qemu tree at the bad_commit^.
That won't apply to the tree... this should.
>From 0d818e334f6db88b2770e9a1076ae1e68c41e460 Mon Sep 17 00:00:00 2001
From: Serge Hallyn
Date: Tue, 8 Apr 2014 22:14:20 -0500
Subject: [PATCH 1/1] kvm_physical_sync_dirty_
On Wed, Apr 9, 2014 at 1:15 PM, Alistair Francis
wrote:
> This is an extension of my 'zynq_slcr: Change the comma to a
> underscore' patch.
You shouldn't reference previous versions of patches in the commit
message proper (you can talk about that stuff below the ---). Make the
message a self cont
ENOENT (iiuc) means the kernel has an empty dirty bitmap for this
slot. Don't abort in that case. This appears to solve the bug
reported at
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1303926
which first showed up with commit b533f658a98325d: fix return check for
KVM_GET_DIRTY_LOG ioctl
This is an extension of my 'zynq_slcr: Change the comma to a
underscore' patch. This changes the commas in Zynq peripherals
to full stops. This matches other Xilinx peripherals and also
makes command line argument parsing possible.
Signed-off-by: Alistair Francis
---
Thanks to Peter Crosthwaite f
Looking at arch/x86/kvm/x86.c, ENOENT (only) happens when
memslot->dirty_bitmap is NULL in kvm_vm_ioctl_get_dirty_log().
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1303926
Title:
qemu-system-x86
It seems reasonable that if we are requesting writing a dirty bitmap,
and kernel says it's not dirty, we ignore that failure? I.e. ignore
ENOENT?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1303926
From: Nathan Rossi
Clear the BMCR Reset when writing to registers.
Signed-off-by: Nathan Rossi
[ PC:
* Trivial style fixes to commit message
]
Signed-off-by: Peter Crosthwaite
---
hw/net/xilinx_axienet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/net/xilinx_axienet.c b/hw/net
On Wed, Apr 9, 2014 at 7:42 AM, Beniamino Galvani wrote:
> On Mon, Apr 07, 2014 at 07:05:18PM -0700, Peter Crosthwaite wrote:
>> Add support for 16, 32 and 64 bit width FIFOs. The push and pop
>> functions are patched to accept uint64_t always to support up to 64bit
>> integer elements. The elemen
On Wed, Apr 9, 2014 at 4:48 AM, Beniamino Galvani wrote:
> On Mon, Apr 07, 2014 at 07:04:43PM -0700, Peter Crosthwaite wrote:
>> This prepares support for generalising FIFO support to more integer
>> widths.
>>
>> Signed-off-by: Peter Crosthwaite
>>
>> [...]
>>
>> --- a/include/qemu/fifo8.h
>> ++
On Wed, Apr 9, 2014 at 11:14 AM, Peter Crosthwaite
wrote:
> On Wed, Mar 26, 2014 at 1:05 PM, Alistair Francis
> wrote:
>> This patch changes the comma in the "xilinx,zynq_slcr" to an
>> underscore. This matches every other xilinx* peripheral and
>> also makes parsing the device via the command li
On Wed, Mar 26, 2014 at 10:47 AM, Alistair Francis
wrote:
> This patch introduces a new command line argument that allows
> sysbus devices to be attached via the command line.
>
> This allows devices to be added after the machine init but
> before anything is booted
>
> The new argument is -sysbus
(which means my comment #8 is off track - the caller in this case is
checking the return value, then aborting - and this is the exact same
backtrace as we get anyway)
** Changed in: qemu (Ubuntu)
Assignee: Serge Hallyn (serge-hallyn) => (unassigned)
--
You received this bug notification bec
At the point when the ioctl fails, this is the backtrace:
(gdb) where
#0 kvm_physical_sync_dirty_bitmap (section=0x7fffd820) at
/home/serge/src/qemu/kvm-all.c:446
#1 0x5580e30c in kvm_log_sync (listener=,
section=) at /home/serge/src/qemu/kvm-all.c:803
#2 0x5581390e in mem
ping...
On 04/03/2014 08:16 PM, Christian Borntraeger wrote:
On 01/04/14 15:25, Christian Borntraeger wrote:
On 01/04/14 10:33, Qiao Nuohan wrote:
Dumping guest memory is available to specify the dump format now. This patch
adds options '-z|-l|-s' to HMP command dump-guest-memory to specify du
On Wed, Mar 26, 2014 at 1:05 PM, Alistair Francis
wrote:
> This patch changes the comma in the "xilinx,zynq_slcr" to an
> underscore. This matches every other xilinx* peripheral and
> also makes parsing the device via the command line possible.
>
I think its actually a case of this being slightly
Pretty sure that commit b533f658a98325d0e47b36113bd9f5bcc046fdae is the
first bad commit.
This is interesting. The commit is correct in that kvm_vm_ioctl()
returns -errno, not -1, on error. However, the caller,
kvm_physical_sync_dirty_bitmap, on seeing the error, shortcuts some
extra errors to r
CC Beniamino - hes done some recent PHY work. And Stefan for net.
On Fri, Apr 4, 2014 at 4:55 PM, Peter Crosthwaite
wrote:
> Phys must respond to address 0 by specification. Implement.
>
> Signed-off-by: Nathan Rossi
> Signed-off-by: Peter Crosthwaite
> ---
>
> hw/net/cadence_gem.c | 4 ++--
>
On 04/09/2014 12:59 AM, Alexander Graf wrote:
> On 04/08/2014 02:19 PM, Michael Mueller wrote:
>> On Tue, 08 Apr 2014 21:47:39 +1000
>> Alexey Kardashevskiy wrote:
>>
>>> On 04/08/2014 08:32 PM, Michael Mueller wrote:
On Tue, 08 Apr 2014 20:04:42 +1000
Alexey Kardashevskiy wrote:
>
On Wed, Apr 9, 2014 at 7:22 AM, Don Slutz wrote:
>
> On 04/08/14 05:10, Markus Armbruster wrote:
>>
>> Peter Crosthwaite writes:
>>
>>> On Tue, Apr 8, 2014 at 5:14 PM, Markus Armbruster
>>> wrote:
Peter Crosthwaite writes:
> There is a utility helper for dealing with 8 bit fi
To get it out of the default GPIO list. This allows child devices to
use the un-named GPIO namespace without having to be SSI aware. That
is, there is no more need for machines to know about the obscure
policy where GPIO 0 is the SSI chip-select and GPIO 1..N are the
concrete class GPIOs (defined l
Implement named GPIOs on the Device layer. Listifies the existing GPIOs
stuff using string keys. Legacy un-named GPIOs are preserved by using
a NULL name string - they are just a single matchable element in the
name list.
Signed-off-by: Peter Crosthwaite
---
hw/core/qdev.c | 82
An API similar to the existing qdev_get_gpio_in() except gets outputs.
Useful for testing or debugging code which may wish to override the
hardware generated value of of a GPIO with a user specified value
(E.G. interrupt injection).
Signed-off-by: Peter Crosthwaite
---
hw/core/qdev.c |
This series implements Named GPIOs on the qdev level. Patch 2 is the
feature presentation.
First patch is a developer-centric patch I have had in my tree for a
while. I include it so it picks up the change pattern in P2.
Last patch I give a useful example of the features use (an SSI
cleanup).
P
(Re-send because missing reply-to-all)
Really appreciate your time and valuable input Eric. I almost didn't submit
any patches, so there is quite a lot to learn about it.
I'd agree with you on this, but memsave/pmemsave function are using stdio,
thus I was trying to be consistent with them.
>
On 04/08/2014 08:46 AM, Takashi Iwai wrote:
> The current code shows annoying behavior where the X pointer can move
> out of the window during the input grab in the absolute mode. Due to
> this, the pointer in qemu window looks as if frozen until the real
> (invisible) X pointer comes back to the
On 04/08/2014 06:55 AM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> ui/gtk.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/ui/gtk.c b/ui/gtk.c
> index c85aea3..7a7e432 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -1432,10 +1432,12 @@ static GtkWi
Hm, bisect is pointing at 6ff45f01c734e1ad051f19913449e2577c9f4b7d
which is very unlikely. I'll have to keep playing.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1303926
Title:
qemu-system-x86_6
On Mon, Apr 07, 2014 at 07:05:18PM -0700, Peter Crosthwaite wrote:
> Add support for 16, 32 and 64 bit width FIFOs. The push and pop
> functions are patched to accept uint64_t always to support up to 64bit
> integer elements. The element width is set at creation time.
>
> The backing storage for a
On 04/08/14 05:10, Markus Armbruster wrote:
Peter Crosthwaite writes:
On Tue, Apr 8, 2014 at 5:14 PM, Markus Armbruster wrote:
Peter Crosthwaite writes:
There is a utility helper for dealing with 8 bit fifos. This should be
applicable to other integer widths as well. These two patches
ge
On 4/8/2014 2:58 PM, Alexander Graf wrote:
> On 04/08/2014 09:56 PM, Tom Musta wrote:
>> On 4/6/2014 3:55 PM, Alexander Graf wrote:
>>
>>
>>> @@ -806,6 +838,10 @@ clk_setup_cb cpu_ppc_tb_init (CPUPPCState *env,
>>> uint32_t freq)
>>> tb_env = g_malloc0(sizeof(ppc_tb_t));
>>> env->tb_e
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
third release candidate for the QEMU 2.0 release. This release is meant
for testing purposes and should not be used in a production environment.
http://wiki.qemu.org/download/qemu-2.0.0-rc2.tar.bz2
You can help impr
2f487a3d40faff1772e14da6b921900915501f9a was ok, so bisecting right now.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1303926
Title:
qemu-system-x86_64 crashed with SIGABRT
Status in QEMU:
New
On 8 April 2014 21:27, Paolo Bonzini wrote:
> I agree, and in fact we should also use DEVICE_NATIVE_ENDIAN less, not more.
> Unfortunately, forwarding accesses from one address space to another via
> MMIO accessors requires DEVICE_NATIVE_ENDIAN, and that in turn requires
> target-endianness ldl_p/
** Also affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1303926
Title:
qemu-system-x86_64 crashed with SIGABRT
Status in QEMU:
New
Status
On 04/08/2014 12:45 PM, Eric Blake wrote:
> On 04/08/2014 10:26 AM, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1002813
>>
>> If qemuDomainBlockResize() is passed a size not on a KiB boundary - that
>> is passed a size based in bytes (VIR_DOMAIN_BLOCK_RESIZE_BYTES), then
>>
Am 08.04.2014 um 15:15 schrieb Max Reitz :
> On 07.03.2014 23:55, Max Reitz wrote:
>> Implement this function in the same way as raw_bsd does: Acknowledge
>> that this is a passthrough driver (always return BDRV_BLOCK_OFFSET_VALID
>> and BDRV_BLOCK_DATA and derive the offset directly from the sec
On 28 March 2014 16:19, Paolo Bonzini wrote:
> This patch introduces a configure option to disable the stack protector
> entirely, and conditional stack protector flag selection (in order,
> based on availability): -fstack-protector-strong, -fstack-protector-all,
> no stack protector.
I've just n
Il 08/04/2014 14:55, Peter Maydell ha scritto:
On 8 April 2014 19:39, Paolo Bonzini wrote:
So the fix could be to compile prep.c per-target (and change to
DEVICE_NATIVE_ENDIAN too).
That seems like the wrong direction -- we should be
making fewer files per-target, not more.
I agree, and in
On 04/08/2014 09:56 PM, Tom Musta wrote:
On 4/6/2014 3:55 PM, Alexander Graf wrote:
@@ -806,6 +838,10 @@ clk_setup_cb cpu_ppc_tb_init (CPUPPCState *env, uint32_t
freq)
tb_env = g_malloc0(sizeof(ppc_tb_t));
env->tb_env = tb_env;
tb_env->flags = PPC_DECR_UNDERFLOW_TRIGGERED;
+
On 4/6/2014 3:55 PM, Alexander Graf wrote:
> @@ -806,6 +838,10 @@ clk_setup_cb cpu_ppc_tb_init (CPUPPCState *env, uint32_t
> freq)
> tb_env = g_malloc0(sizeof(ppc_tb_t));
> env->tb_env = tb_env;
> tb_env->flags = PPC_DECR_UNDERFLOW_TRIGGERED;
> +if (env->insns_flags & PPC_SEGM
On 04/08/2014 01:30 PM, Baojun Wang wrote:
Your subject line is extremely long. In general, we strive for
something less than 60 characters, so that 'git shortlog -30' can
display the entire line in an 80-column terminal. Also, the subject
mentions pmemsave, but your commit mentions pmemload - i
I found this could be useful to have qemu-softmmu as a cross debugger (launch
with -s -S command line option), then if we can have a command to load guest
physical memory, we can use cross gdb to do some target debug which gdb cannot
do directly.
Many thanks to Eric Blake for review the patch.
--
Inspect only bit 16 for the Little Endian test. Correct comment preceding
the target_disas() function.
Signed-off-by: Tom Musta
---
V2: new
disas.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/disas.c b/disas.c
index 79e6944..a427d18 100644
--- a/disas.c
+++ b/
Fix disassembly in the QEMU monitor for Little Endian codes. Also fix the
comment
and tighten up a flag check in the closely related disassembler code for
tracing.
V2: Fixed target_disas comment and bit decoding.
V3: Make monitor_disas flag documentation refer to target_disas documentation.
Tom
The monitor support for disassembling instructions does not honor the MSR[LE]
bit for PowerPC processors.
This change enhances the monitor_disas() routine by supporting a flag bit
for Little Endian mode. Bit 16 is used since that bit was used in the
analagous guest disassembly routine target_disa
On 8 April 2014 19:39, Paolo Bonzini wrote:
> So the fix could be to compile prep.c per-target (and change to
> DEVICE_NATIVE_ENDIAN too).
That seems like the wrong direction -- we should be
making fewer files per-target, not more.
>> Worse, we have two versions of the ldl_p()/stl_p() &c
>> func
On Mon, Apr 07, 2014 at 07:04:43PM -0700, Peter Crosthwaite wrote:
> This prepares support for generalising FIFO support to more integer
> widths.
>
> Signed-off-by: Peter Crosthwaite
>
> [...]
>
> --- a/include/qemu/fifo8.h
> +++ b/include/qemu/fifo.h
> @@ -9,102 +9,103 @@ typedef struct {
>
Il 08/04/2014 10:37, Peter Maydell ha scritto:
I think it's actually worse than that. address_space_read/write
have an API which requires you to pass them a buffer which is
in guest CPU endianness. This means they cannot be used from
target-independent source files (like hw/pci-host/prep.c)
becau
On 04/08/2014 12:17 PM, Baojun Wang wrote:
> fix an error in qmp-commands.hx
When sending a v2 patch, it's better to explicitly label it as v2 in the
subject line.
Here's some more hints about the best way to send patches:
http://wiki.qemu.org/Contribute/SubmitAPatch
--
Eric Blake eblake red
On 04/08/2014 11:17 AM, Baojun Wang wrote:
> Hi list,
>
> Is it possible to add a monitor command ``pmemload'' as pmemsave?
> I found this could be useful to have qemu-softmmu as a cross debugger
> (launch with -s -S command line option), then if we can have a command to
> load guest physical memo
fix an error in qmp-commands.hx
On Tue, Apr 8, 2014 at 10:17 AM, Baojun Wang wrote:
> Hi list,
>
> Is it possible to add a monitor command ``pmemload'' as pmemsave?
> I found this could be useful to have qemu-softmmu as a cross debugger
> (launch with -s -S command line option), then if we can
On 8 April 2014 18:24, Richard Henderson wrote:
> On 04/08/2014 08:51 AM, Peter Maydell wrote:
>> The raven_io_read() and raven_io_write() functions pass and
>> return values in little-endian format (since the IO op struct
>> is marked DEVICE_LITTLE_ENDIAN); however they were storing the
>> values
From: Petar Jovanovic
Implementations of system calls getrusage and wait4 have not previously
handled correctly cases when incorrect address of struct rusage is
passed.
This change makes sure return values are correctly set for these cases.
Signed-off-by: Petar Jovanovic
---
linux-user/syscall
On 04/08/2014 08:51 AM, Peter Maydell wrote:
> The raven_io_read() and raven_io_write() functions pass and
> return values in little-endian format (since the IO op struct
> is marked DEVICE_LITTLE_ENDIAN); however they were storing the
> values in the buffer to pass to address_space_read/write()
>
Hi list,
Is it possible to add a monitor command ``pmemload'' as pmemsave?
I found this could be useful to have qemu-softmmu as a cross debugger
(launch with -s -S command line option), then if we can have a command to
load guest physical memory, we can use cross gdb to do some target debug
which
On 04/08/2014 06:50 AM, Max Reitz wrote:
> Add tests to qemu-iotest 020 for committing through a two-layer backing
> file chain with qemu-img commit utilizing the -b option.
>
> The newly added output in 020.out is basically the same as for the
> already existing single-layer pass, but with anothe
On 8 April 2014 16:51, Peter Maydell wrote:
> This fixes the endianness test failure on bigendian hosts.
> HOWEVER I have not actually tested it with a guest :-)
Alex found me a prep kernel. It seems to have issues with
its userspace, but; without this patch, when we probe the
IDE devices we get:
On 04/08/2014 06:50 AM, Max Reitz wrote:
> Introduce a new parameter for qemu-img commit which may be used to
> explicitly specify the backing file unto which an image should be
s/unto/into/
> committed if the backing chain has more than a single layer.
>
> Signed-off-by: Max Reitz
> ---
> qem
On 04/08/2014 09:34 AM, Kevin Wolf wrote:
> Am 08.04.2014 um 14:50 hat Max Reitz geschrieben:
>> Implement progress output for the commit command by querying the
>> progress of the block job.
>>
>> Signed-off-by: Max Reitz
>> Reviewed-by: Eric Blake
>> ---
>>
>> info = block_job_query
On 04/08/2014 10:26 AM, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1002813
>
> If qemuDomainBlockResize() is passed a size not on a KiB boundary - that
> is passed a size based in bytes (VIR_DOMAIN_BLOCK_RESIZE_BYTES), then
> depending on the source format (qcow2 or qed), the
On 04/08/2014 09:14 AM, Kevin Wolf wrote:
> Am 08.04.2014 um 14:50 hat Max Reitz geschrieben:
>> qemu-img should use QMP commands whenever possible in order to ensure
>> feature completeness of both online and offline image operations. As
>> qemu-img itself has no access to QMP (since this would ba
On 04/08/2014 06:50 AM, Max Reitz wrote:
> As speed is an optional parameter for the QMP block-commit command, it
> should be set to 0 if not given (as it is undefined if has_speed is
> false), that is, the speed should not be limited.
>
> Signed-off-by: Max Reitz
> ---
> blockdev.c | 3 +++
> 1
On 04/08/2014 06:50 AM, Max Reitz wrote:
> Allow QMP users to manipulate the granularity used in the block-commit
> command.
>
> Signed-off-by: Max Reitz
> ---
> +++ b/include/block/block_int.h
> @@ -426,6 +426,7 @@ void stream_start(BlockDriverState *bs, BlockDriverState
> *base,
> * @top:
* (chenliang0...@icloud.com) wrote:
>
> ?? 2014??4??810:29??Dr. David Alan Gilbert (git)
> ??
>
> > From: "Dr. David Alan Gilbert"
> >
> > Make qemu_peek_buffer repeatedly call fill_buffer until it gets
> > all the data it requires, or until there is an error.
> >
> > At th
The raven_io_read() and raven_io_write() functions pass and
return values in little-endian format (since the IO op struct
is marked DEVICE_LITTLE_ENDIAN); however they were storing the
values in the buffer to pass to address_space_read/write()
in host-endian order, which meant that on big-endian ho
Am 08.04.2014 um 14:50 hat Max Reitz geschrieben:
> Implement progress output for the commit command by querying the
> progress of the block job.
>
> Signed-off-by: Max Reitz
> Reviewed-by: Eric Blake
> ---
> qemu-img-cmds.hx | 4 ++--
> qemu-img.c | 33 +++--
On Thu, Apr 03, 2014 at 01:18:24PM +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> QEMU only mmap MSIX_PAGE_SIZE memory for all pci devices in
> assigned_dev_register_msix_mmio(), meanwhile the set the one
> page memmory to zero, so the rest memory will be random value
> (maybe etnry.da
On Thu, Apr 03, 2014 at 01:18:23PM +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> when map MSI-X table memory failed, the dev->msix_table not be
> set to NULL, the assigned_dev_unregister_msix_mmio() will case
> a segfault when munmap the failed dev->msix_table.
>
> Signed-off-by: Gon
Am 08.04.2014 um 14:50 hat Max Reitz geschrieben:
> qemu-img should use QMP commands whenever possible in order to ensure
> feature completeness of both online and offline image operations. As
> qemu-img itself has no access to QMP (since this would basically require
> just everything being linked
Am 08.04.2014 um 14:50 hat Max Reitz geschrieben:
> Allow QMP users to manipulate the granularity used in the block-commit
> command.
>
> Signed-off-by: Max Reitz
Granularity is a strange name for live commit, especially on non-active
layers where it's really just the buffer size. Not that I hav
Am 08.04.2014 um 14:50 hat Max Reitz geschrieben:
> As speed is an optional parameter for the QMP block-commit command, it
> should be set to 0 if not given (as it is undefined if has_speed is
> false), that is, the speed should not be limited.
>
> Signed-off-by: Max Reitz
Should this be Cc: qem
On 04/08/2014 02:19 PM, Michael Mueller wrote:
On Tue, 08 Apr 2014 21:47:39 +1000
Alexey Kardashevskiy wrote:
On 04/08/2014 08:32 PM, Michael Mueller wrote:
On Tue, 08 Apr 2014 20:04:42 +1000
Alexey Kardashevskiy wrote:
On 04/08/2014 07:47 PM, Michael Mueller wrote:
On Tue, 08 Apr 2014 11
On 7 April 2014 20:31, Paolo Bonzini wrote:
> I think if you are using address_space_read/write
> then you must use DEVICE_NATIVE_ENDIAN
I think it's actually worse than that. address_space_read/write
have an API which requires you to pass them a buffer which is
in guest CPU endianness. This mean
From: "Dr. David Alan Gilbert"
Make qemu_peek_buffer repeatedly call fill_buffer until it gets
all the data it requires, or until there is an error.
At the moment, qemu_peek_buffer will try one qemu_fill_buffer if there
isn't enough data waiting, however the kernel is entitled to return
ju
Hi, mst and alex.
Ping... These two bug fix can be accepted for KVM pci-assign ? Thanks.
BTW, I have finished the testing work of the Emulex Corporation
OneConnect NIC (Lancer) Nic by vfio-pci, and the pass-troughed VF works well.
My environment of testing as follows:
Host: 3.12.16-0.6.6-defa
On Mon, Apr 07, 2014 at 02:57:08PM -0400, Kevin O'Connor wrote:
> On Mon, Apr 07, 2014 at 02:05:21PM -0400, Gabriel L. Somlo wrote:
> > On Mon, Apr 07, 2014 at 11:23:44AM -0400, Kevin O'Connor wrote:
> > > So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file
> > > with the valid anc
On 8 April 2014 13:24, Michael S. Tsirkin wrote:
> The following changes since commit 55519a4b244e4822774b593e36647ecf7598286b:
>
> Merge remote-tracking branch 'remotes/afaerber/tags/qom-devices-for-2.0'
> into staging (2014-04-07 17:57:23 +0100)
>
> are available in the git repository at:
>
>
On 07.03.2014 23:55, Max Reitz wrote:
Implement this function in the same way as raw_bsd does: Acknowledge
that this is a passthrough driver (always return BDRV_BLOCK_OFFSET_VALID
and BDRV_BLOCK_DATA and derive the offset directly from the sector
index) and add BDRV_BLOCK_RAW to the returned valu
On 8 April 2014 13:06, Gerd Hoffmann wrote:
> Hi,
>
> Finally sorted things, with this patch the gtk ui behavior
> in relative mouse mode is consistent with everybody else
> (sdl, virt-viewer, ...).
>
> please pull,
> Gerd
>
> The following changes since commit 55519a4b244e4822774b593e36647ecf
Introduce a new parameter for qemu-img commit which may be used to
explicitly specify the backing file unto which an image should be
committed if the backing chain has more than a single layer.
Signed-off-by: Max Reitz
---
qemu-img-cmds.hx | 4 ++--
qemu-img.c | 22 +++---
Implement progress output for the commit command by querying the
progress of the block job.
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
---
qemu-img-cmds.hx | 4 ++--
qemu-img.c | 33 +++--
qemu-img.texi| 2 +-
3 files changed, 34 insertions(+), 5 de
qemu-img should use QMP commands whenever possible in order to ensure
feature completeness of both online and offline image operations. As
qemu-img itself has no access to QMP (since this would basically require
just everything being linked into qemu-img), imitate QMP's
implementation of block-comm
qemu-img should use QMP commands whenever possible in order to ensure
feature completeness of both online and offline image operations. For
the "commit" command, this is relatively easy, so implement it first
(in the hope that indeed others will follow).
As qemu-img does not have access to QMP (du
As speed is an optional parameter for the QMP block-commit command, it
should be set to 0 if not given (as it is undefined if has_speed is
false), that is, the speed should not be limited.
Signed-off-by: Max Reitz
---
blockdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/blockdev.c b
Allow QMP users to manipulate the granularity used in the block-commit
command.
Signed-off-by: Max Reitz
---
block/commit.c| 16 +---
block/mirror.c| 4 ++--
blockdev.c| 23 +--
include/block/block_int.h | 6 --
qapi-s
The current code shows annoying behavior where the X pointer can move
out of the window during the input grab in the absolute mode. Due to
this, the pointer in qemu window looks as if frozen until the real
(invisible) X pointer comes back to the window again.
For avoiding such an unexpected lag,
ACPI0004 seems too new:
Windows XP complains about an unrecognized device.
This is a regression since 1.7.
Use PNP0A06 instead - Generic Container Device.
Signed-off-by: Michael S. Tsirkin
Reviewed-By: Igor Mammedov
---
hw/i386/acpi-dsdt-cpu-hotplug.dsl | 2 +-
1 file changed, 1 insertion(+), 1
The following changes since commit 55519a4b244e4822774b593e36647ecf7598286b:
Merge remote-tracking branch 'remotes/afaerber/tags/qom-devices-for-2.0' into
staging (2014-04-07 17:57:23 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for
On Tue, 08 Apr 2014 21:47:39 +1000
Alexey Kardashevskiy wrote:
> On 04/08/2014 08:32 PM, Michael Mueller wrote:
> > On Tue, 08 Apr 2014 20:04:42 +1000
> > Alexey Kardashevskiy wrote:
> >
> >> On 04/08/2014 07:47 PM, Michael Mueller wrote:
> >>> On Tue, 08 Apr 2014 11:23:14 +1000
> >>> Alexey Ka
From: Takashi Iwai
This patch changes the behavior in the relative mode to be compatible
with other UIs, namely, grabbing the input at the first left click.
It improves the usability a lot; otherwise you have to press ctl-alt-G
or select from menu at each time you want to move the pointer. Also,
Hi,
Finally sorted things, with this patch the gtk ui behavior
in relative mouse mode is consistent with everybody else
(sdl, virt-viewer, ...).
please pull,
Gerd
The following changes since commit 55519a4b244e4822774b593e36647ecf7598286b:
Merge remote-tracking branch 'remotes/afaerber/ta
For C code, it does not recommend to define a local variable in the
middle of code block without "{...}". The original author may want to
zero members not mentioned in structure assignment.
So recommend to use structure initializing block "{...}" for structure
assignment in the middle of code bloc
In function, if no additional resources to free before quit, commonly,
need not use additional local variable 'res' to notice about it. So
remove it to simplify code.
Signed-off-by: Chen Gang
---
vl.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/vl.c b/vl.c
index
Normal "if (...) {...} else {...}" is enough in "while(...) {...}", not
need additional useless 'continue'.
Signed-off-by: Chen Gang
---
vl.c |1 -
1 file changed, 1 deletion(-)
diff --git a/vl.c b/vl.c
index 9975e5a..7505002 100644
--- a/vl.c
+++ b/vl.c
@@ -3034,7 +3034,6 @@ int main(int a
In "vl.c", at least, we can simplify the code below, so can let readers
read professional C code (especially for new readers, which often start
reading code at main function).
- remove useless 'continue' in main().
- remove redundant local variable 'res' in get_boot_device().
- remove local v
08.04.2014 14:57, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On 8 April 2014 09:52, Michael Tokarev wrote:
>>> Well. At least one of them is entirely safe (hw/ide/ahci.c).
>>> Another - xbzrle.c - looks okay, and even maybe fixing a bug.
>>> And this int128 thing is okay too, except
1 - 100 of 160 matches
Mail list logo
