On 31/01/2015 00:55, Alex Williamson wrote:
> Commit d8d95814609e replaced a number of memory_region_destroy()
> calls with object_unparent() calls. The logic appears to be that
> subregions need to be unparented, but the base region is destroyed
> with the device object. Doing hotplug testing
On 2015-01-05 12:37, Jan Kiszka wrote:
> On 2015-01-05 12:22, Stefan Hajnoczi wrote:
>> Commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 ("machine: remove
>> qemu_machine_opts global list") removed option descriptions from the
>> -machine QemuOptsList to avoid repeating MachineState's QOM properties
Hello,
Qemu 2.1.0 is currently crashing with the log
[2015-01-30T08:17:29.512340Z] handle_qmp_command:5100 qmp_cmd_name:
migrate_cancel
[2015-01-30T08:17:29.857114Z] handle_qmp_command:5110 qmp_cmd_name:
block-job-cancel, qmp_cmd_arguments: {"device": "drive-scsi0-0-0-0"}
[2015-01-30T08:17:29.8
From: Jan Kiszka
With this patch QEMU handles qAttached request from gdb. When QEMU
replies 1, GDB sends a "detach" command at the end of a debugging
session otherwise GDB sends "kill".
The default value for qAttached is 1 on system emulation and 0 on user
emulation.
Based on original version b
From: Fabien Chouteau
The requirements described in this patch are implemented by "Add GDB
qAttached support".
This reverts commit 00e94dbc7fd0110b0555d59592b004333adfb4b8.
Signed-off-by: Fabien Chouteau
Signed-off-by: Jan Kiszka
---
gdbstub.c | 2 --
1 file changed, 2 deletions(-)
diff --g
On Fri, 30 Jan 2015, Peter Maydell wrote:
> > Hmm, so perhaps my idea for a later improvement:
> >
> >> Eventually we might want to move the new inline functions into a
> >> separate header to be included from softfloat.h instead of softfloat.c,
> >> but let's make changes one step at a time.
>
On 31 January 2015 at 11:56, Maciej W. Rozycki wrote:
> On Fri, 30 Jan 2015, Peter Maydell wrote:
>
>> > Hmm, so perhaps my idea for a later improvement:
>> >
>> >> Eventually we might want to move the new inline functions into a
>> >> separate header to be included from softfloat.h instead of s
On Sat, Jan 31, 2015 at 07:07:16AM +, Xu, Quan wrote:
>
>
> > -Original Message-
> > From: xen-devel-boun...@lists.xen.org
> > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Wei Liu
> > Sent: Friday, January 30, 2015 8:26 PM
> > To: Chen, Tiejun
> > Cc: Wei Liu; ian.campb...@ci
On Fri, 2015-01-30 at 08:40 +0100, Jan Kiszka wrote:
> Adding Knut to CC as he particularly looked into and fixed the bridging
> issues or the vtd emulation. I will have to refresh my memories first.
Thanks for cc'ing me, Jan -
Yes I did some work specifically to serve my need of being able to use
On Sat, 31 Jan 2015, Peter Maydell wrote:
> >> > Hmm, so perhaps my idea for a later improvement:
> >> >
> >> >> Eventually we might want to move the new inline functions into a
> >> >> separate header to be included from softfloat.h instead of softfloat.c,
> >> >> but let's make changes one ste
On Sat, 2015-01-31 at 09:43 +0100, Paolo Bonzini wrote:
>
> On 31/01/2015 00:55, Alex Williamson wrote:
> > Commit d8d95814609e replaced a number of memory_region_destroy()
> > calls with object_unparent() calls. The logic appears to be that
> > subregions need to be unparented, but the base regi
Hi,
I'm trying to debug qemu when it executes a simple arm executable. Where is
in the qemu code when executing a single arm asm instruction?
Thanks
Attila
*** This bug is a duplicate of bug 1346917 ***
https://bugs.launchpad.net/bugs/1346917
Just wanted to add that upgrading my kernel to a newer version fixed the
problem for me, too.
Host: 2x E5-2620V2, Ubuntu 14.04 LTS
Guest: 24 virtual cores, Windows Server 2008 R2
Before fix:
sudo uname -a
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Saturday, January 31, 2015 10:33 PM
> To: Xu, Quan
> Cc: Wei Liu; Chen, Tiejun; ian.campb...@citrix.com; m...@redhat.com; Ian
> Jackson;
> qemu-devel@nongnu.org; xen-de...@lists.xen.org; Gerd Hoffmann
> Subject: Re
On 31 January 2015 at 12:25, Attila Csosz wrote:
> I'm trying to debug qemu when it executes a simple arm executable. Where is
> in the qemu code when executing a single arm asm instruction?
QEMU works in two phases:
(1) we translate ARM code into x86 instructions
(2) we run the instructions cr
Where is the arm-to-x86 call in QEMU code? Which tool/library call
generates this code?
Attila
On Sat, Jan 31, 2015 at 5:43 PM, Peter Maydell
wrote:
> On 31 January 2015 at 12:25, Attila Csosz wrote:
> > I'm trying to debug qemu when it executes a simple arm executable. Where
> is
> > in the
On 31 January 2015 at 16:50, Attila Csosz wrote:
> Where is the arm-to-x86 call in QEMU code? Which tool/library call generates
> this code?
We generate the code in target-arm/translate.c (actually we generate
a TCG intermediate representation which is subsequently turned into
x86 instructions by
On Fri, Jan 30, 2015 at 12:46:41PM +0100, Igor Mammedov wrote:
> On Wed, 28 Jan 2015 17:16:17 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Jan 28, 2015 at 02:34:48PM +, Igor Mammedov wrote:
> > > Use build_append_namestring() instead of build_append_nameseg()
> > > So user won't have to
Where is the arm-to-tcg translation?
Attila
On Sat, Jan 31, 2015 at 5:59 PM, Peter Maydell
wrote:
> On 31 January 2015 at 16:50, Attila Csosz wrote:
> > Where is the arm-to-x86 call in QEMU code? Which tool/library call
> generates
> > this code?
>
> We generate the code in target-arm/transla
Am 30.01.2015 um 22:30 schrieb Max Reitz:
> On 2015-01-30 at 16:05, Peter Lieven wrote:
>> Am 30.01.2015 um 18:16 schrieb Max Reitz:
>>> On 2015-01-30 at 09:33, Peter Lieven wrote:
this patch finally introduces multiread support to virtio-blk. While
multiwrite support was there for a long
Am 30.01.2015 um 22:15 schrieb Kevin Wolf:
> Am 30.01.2015 um 22:05 hat Peter Lieven geschrieben:
>> Am 30.01.2015 um 18:16 schrieb Max Reitz:
>>> On 2015-01-30 at 09:33, Peter Lieven wrote:
this patch finally introduces multiread support to virtio-blk. While
multiwrite support was there
On Sat, 2015-01-31 at 15:42 +0100, Knut Omang wrote:
> I agree with you that they are two distinct problems, with perhaps a
> 3rd problem of how to generalize this to other devices than PCI devices?
>
> Right now the
> handling of requester IDs across bridges seems very rudimentary in the
> QEM
On 31/01/2015 16:10, Alex Williamson wrote:
>> Explicit object_unparent() is only needed if you recreate the memory
>> region during the lifetime of the object. This is rarely needed, and it
>> is simple to spot if it's needed. If you do memory_region_init* outside
>> the realize function, most
23 matches
Mail list logo
