Public bug reported:
When using Gdb to remote-debug a program and manually setting its PC to
point to an address containing an invalid instruction and then doing a
single step, Qemu will never return control to the remote Gdb.
For instance, let's say address 0x114 contains an invalid instruction.
>> Public bug reported:
>>
>> When using Gdb to remote-debug a program and manually setting its PC to
>> point to an address containing an invalid instruction and then doing a
>> single step, Qemu will never return control to the remote Gdb.
>>
>> For instance, let's say address 0x114 contains an i
Notice there are actually two sides to this problem: not only the
internal exception instruction isn't being processed, but also when we
go back to the cpu_exec loop the syndrome exception won't have any
actual effect since we won't compute the new PC we need in order to jump
to the exception handl
Just wanted to add: after doing some testing, it seems that if we simply
don't mask out external interrupts when single-stepping we don't even
need to do the syndrome value check. As the interrupt corresponding to
the syndrome exception won't be masked, it'll correctly compute the new
PC in do_inte
** No longer affects: qemu (Gentoo Linux)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1488363
Title:
qemu 2.4.0 hangs using vfio for pci passthrough of graphics card
Status in QEMU:
New
Bug d
Version 2.4.1 is affected too, but regression mentioned by Peter Maloney
solve this problem.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1488363
Title:
qemu 2.4.0 hangs using vfio for pci passthr
** Also affects: qemu (Gentoo Linux)
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/1488363
Title:
qemu 2.4.0 hangs using vfio for pci passthrough of grap
IBM opened up a little bit and makes the beta of AIX 6 available to anyone.
Maybe this is an opportunity to get AIX running on QEMU.
At the moment QEMU does not yet understand the AIX cd boot format.
I tried to boot it using the -kernel option b
I tried to boot it in the following ways, but that d
l
summary:
- it takes ages
- it is slow
-> it works, but it is not usable.
Martin
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
e it is
> > repeatedly attempting and failing to use the accelerated kernel
> > interface?
Hm... the emulator did work, but I can't tell if any part was failing.
I could not find any evidence in the log files.
I'll give an update as soon as I will have tried Win98.
Martin
will be
broken and compatible after a major change in qemu ...
Another choice would be the pure rc (just 'item = value' lines) without any
supersmart blocks.
xml style or rc style, please no hack in betweeen :)
martin
Giuseppe Della Bianca wrote:
Hi.
My idea is this:
- qe
I shouldn't write posts at 7-8am
should be
s/Certainly better every/Certainly better than every/
s/broken and compatible/broken and incompatible/
sry :) , you probably understood anyway what i meant ...
martin
martin wrote:
If we'd go for a config file at all with such a c
This shouldn't be "Expired", since the bug is likely still there.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1364501
Title:
Gdb hangs when trying to single-step after an invalid instruction
Sta
I honestly don't know, since it's been so long. I'm guessing that if
the code hasn't been touched the issue is still there. In any case, I
don't think this should be closed without you (or anyone, really)
trying to reproduce it again. I posted a detailed explanation of why
the bug happens, so you c
ine' isn't compatible with
older versions and different builds of QEMU.
Should I file a bug or do we have to drop '-M' for this situations?
Have a nice day,
Martin
On 08/22/2012 05:15 PM, Jan Kiszka wrote:
> On 2012-08-22 17:05, Martin Kletzander wrote:
>> Hi everybody,
>>
>> while coding the support for Jason's dump-guest-core option I realized
>> there is (probably) a problem with the way QEMU parses additional
>
Hello Chris, or anyone else affected,
Accepted qemu-kvm into lucid-proposed. The package will build now and be
available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
Patch removed, as it was bogus and your workflow is weird, so I'll post
a better patch to the devel list
** Patch removed: "esp.c.patch"
https://bugs.launchpad.net/qemu/+bug/1014099/+attachment/3192942/+files/esp.c.patch
--
You received this bug notification because you are a member of qemu-
_cb = handle_s_without_atn;
return;
}
@@ -296,7 +296,7 @@ static void handle_s_without_atn(ESPStat
static void handle_satn_stop(ESPState *s)
{
-if (!s->dma_enabled) {
+if (s->dma && !s->dma_enabled) {
s->dma_cb = handle_satn_stop;
return;
}
I filed a ticket in the bugtracker for it: #1014099.
Martin
On Sun, Jun 17, 2012 at 11:55:20PM +0200, Martin Husemann wrote:
> The NetBSD driver sometimes uses commands without DMA (for example a simple
> TEST_UNIT_READY). On esp hardware, the command has a DMA bit (if dma is to
> be used), and when writing to the command register, the s->d
I sent the patch on May 16 (http://lists.nongnu.org/archive/html/qemu-
devel/2012-05/msg02373.html). I haven't seen any response.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/806656
Title:
Tight P
{
if (s->dmaregs[0] & DMA_INTR) {
s->dmaregs[0] &= ~DMA_INTR;
if (s->dmaregs[0] & DMA_INTREN) {
trace_sparc32_dma_set_irq_lower();
qemu_irq_lower(s->irq);
}
}
}
}
Thanks,
Martin
Ah, my eyes get bad - please disregard, foudn the DMA_INTREN vs. DMA_INTR
differences :-(
Martin
http://patchwork.ozlabs.org/patch/390074/
It is a rather simple patch adding support for the Pause key in the GTK
UI. It should not cause any regressions. Please apply. Thanks.
M.D.
On 16-09-2014 16:04, Martin Decky wrote:
Special handing of the Pause key. Implemented in a similar way as in
but then I realise that the real device
hangs of an AMBA bus so my next idea was to write a PCI driver for 802.15.4 on
the guest making it possible to write a PCI virtual QEMU device.
I just wanted to confirm that this is possible and whether there is a better
solution?
Many Thanks,
Martin.
Hi Christopher,
Thanks for the reply, I will take a look at the Versatile Express code.
- Martin.
On 01/10/14 17:41, Christopher Covington wrote:
Hi Martin,
On 10/01/2014 09:50 AM, Martin Townsend wrote:
Hi,
I'm looking into creating a virtualised test bed for an 802.15.4 ne
On Tue, Oct 7, 2014 at 11:13 AM, Alistair Francis wrote:
> The Netduino 2 machine won't run unless the reset_pc is based
> on the ELF entry point.
>
> Signed-off-by: Alistair Francis
> Signed-off-by: Peter Crosthwaite
> ---
> V2:
> - Malloc straight away, thanks to Peter C
>
> hw/arm/armv7m.c
cdrom:a" confusion or something like
that?
Here are the relevant excerpts from the boot messages - I can make the
test image available, or just use a daily build HEAD image from
NetBSD.org.
I can also easily try patches or try to fix the bug myself, if you could
give me a hint where this o
ountl(unsigned long) __constfunc;
"unsigned" looks better to me for a non negative count, but maybe a
configure test and using the system libs would be preferable?
Martin
not use an unsigned return value for your homegrown version?
- would it be preferable to use official/optimized versions if
available?
Thanks,
Martin
On Thu, Apr 25, 2013 at 08:36:55PM +0200, Martin Husemann wrote:
> Ok, I can fix the namespace issue (which is real) easily.
Turns out to be a bit harder: qemu does not define (as far as I can tell)
any restricting macro (_POSIX_C_SOURCE or whatever).
Should it?
Martin
When calling qemu_system_reset after startup on a Cortex-M CPU, the initial
values of PC, MSP and the Thumb bit weren't set correctly. In particular,
since Thumb was 0, an Usage Fault would arise immediately after trying to
excecute any instruction on a Cortex-M.
Signed-off-by: Martin G
It's actually fine for me with current utopic's 2.1+dfsg-2ubuntu2. I
tested both the default graphics card as well as "-vga vmware".
** Changed in: qemu (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subs
written to
the disks several hours before the crash was corrupted, which makes me think
that it was never fsync()-ed to the non-volatile storage.
Is it safe in this setup to use cache=writeback? Or, should I use
cache=writethrough instead?
Thanks,
Andrew Martin
Ping http://patchwork.ozlabs.org/patch/379134/
On Mon, Aug 11, 2014 at 1:50 PM, Martin Galvan <
martin.gal...@tallertechnologies.com> wrote:
> When calling qemu_system_reset after startup on a Cortex-M CPU, the
> initial values of PC, MSP and the Thumb bit weren't set correctly
On Tue, Aug 19, 2014 at 10:06 AM, Peter Maydell
wrote:
>
> On 11 August 2014 17:50, Martin Galvan
> wrote:
> > When calling qemu_system_reset after startup on a Cortex-M CPU, the initial
> > values of PC, MSP and the Thumb bit weren't set correctly. In particular,
>
On Tue, Aug 19, 2014 at 11:16 AM, Peter Maydell
wrote:
> On 19 August 2014 14:25, Martin Galvan
> wrote:
>> On Tue, Aug 19, 2014 at 10:06 AM, Peter Maydell
>> wrote:
>>> I'm afraid this looks like the wrong fix for the problem you're seeing.
>>> Th
- Original Message -
> From: "Stefan Hajnoczi"
> To: "Andrew Martin"
> Cc: qemu-devel@nongnu.org
> Sent: Tuesday, August 19, 2014 9:59:25 AM
> Subject: Re: [Qemu-devel] Using cache=writeback safely on qemu 1.4.0 and later
>
> If you strace -f t
ed GSoC project from this year), and if admin API gets
added, there will be many APIs and ideas how to expand it.
Martin
Stefan
signature.asc
Description: Digital signature
- Original Message -
> From: "Stefan Hajnoczi"
> To: "Andrew Martin"
> Cc: "qemu-devel"
> Sent: Thursday, August 21, 2014 7:59:50 AM
> Subject: Re: [Qemu-devel] Using cache=writeback safely on qemu 1.4.0 and later
>
> > When the di
On Tue, Aug 26, 2014 at 10:33:27AM +0100, Stefan Hajnoczi wrote:
On Mon, Aug 25, 2014 at 5:40 PM, Marina Zhurakhinskaya
wrote:
- Original Message -
From: "Stefan Hajnoczi"
To: "Martin Kletzander"
Cc: "qemu-devel" , libvir-l...@redhat.com, "kv
On Tue, Aug 26, 2014 at 11:27:41AM +0100, Stefan Hajnoczi wrote:
On Tue, Aug 26, 2014 at 10:39 AM, Martin Kletzander wrote:
On Tue, Aug 26, 2014 at 10:33:27AM +0100, Stefan Hajnoczi wrote:
On Mon, Aug 25, 2014 at 5:40 PM, Marina Zhurakhinskaya
wrote:
- Original Message -
From
- Original Message -
> From: "Paolo Bonzini"
> To: "Andrew Martin" , "Stefan Hajnoczi"
>
> Cc: "qemu-devel"
> Sent: Tuesday, August 26, 2014 2:03:18 AM
> Subject: Re: Using cache=writeback safely on qemu 1.4.0 and later
>
- Original Message -
> From: "Paolo Bonzini"
> To: "Andrew Martin"
> Cc: "Stefan Hajnoczi" , "qemu-devel"
>
> Sent: Wednesday, August 27, 2014 9:34:27 AM
> Subject: Re: Using cache=writeback safely on qemu 1.4.0 and later
>
x281654 object_unref - -
0x280a4b object_unparent - -
0x13ad93 qdev_free - -
0x13acde qdev_simple_unplug_cb - -
0x13aac8 qdev_unplug - -
0x268b56 qmp_device_del - -
....
Signed-off-by: Martin Cerveny
---
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index a594e95..1c62263 100644
--- a/hw/usb/red
ssage appears:
"unable to execute QEMU command 'device_add': 'usb-host' is not a valid
device model name"
Then the guest will not start.
I try it with different usb devices (iphone, stick, hdd), always the
same error.
Are there any news / hints about this ?
Hi,
as far as I can see from the rpm specs of the opensuse rpm package the
--enable-libusb is set .
Regards
Martin
Am 18.05.2014 06:52, schrieb Gonglei (Arei):
Hi,
From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed,
re-implemented by libusbx. So you should
or: internal error: early end of file from monitor: possible
problem:
qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0:
'usb-host' is not a valid device model name
Regards
Martin
Am 18.05.2014 06:52, schrieb Gonglei (Arei):
Hi,
From qemu-1.7 release version, the
x27;device_add': 'usb-host' is not a
valid device model name"
Then the guest will not start.
I try it with different usb devices (iphone, stick, hdd), always the
same error.
Are there any news / hints about this ?
Regards
Martin
To manage notifications about th
When calling qemu_system_reset after startup on a Cortex-M CPU, the
initial values of PC, MSP and the Thumb bit weren't set correctly. In
particular, since Thumb was 0, a Usage Fault would arise immediately
after trying to excecute any instruction on a Cortex-M.
Signed-off-by: Martin G
Once again, you're right. I'll fix that right away and send v3.
On Fri, Sep 5, 2014 at 2:43 PM, Peter Maydell wrote:
> On 4 September 2014 19:12, Martin Galvan
> wrote:
>
> Thanks for this patch. I think it's generally right
> but could use a little tweaking for s
tex-M.
Signed-off-by: Martin Galvan
---
Changed in v3: Fixed a few style issues.
Changed in v2: We're not adding initial_MSP and
initial_PC to the CPU state. Instead, we're loading the initial values
using ldl_phys.
target-arm/cpu.c | 34 +++---
1 f
On Sat, Sep 6, 2014 at 8:00 AM, Peter Crosthwaite
wrote:
> On Sat, Sep 6, 2014 at 8:42 PM, Peter Maydell
> wrote:
>> On 6 September 2014 03:45, Peter Crosthwaite
>> wrote:
>>> CC Alistair who is into ARMv7M
>>>
>>> On Sat, Sep
>> @@ -259,7 +272,13 @@ qemu_irq *armv7m_init(MemoryRegion *system_memory,
>> vmstate_register_ram_global(hack);
>> memory_region_add_subregion(system_memory, 0xf000, hack);
>>
>> -qemu_register_reset(armv7m_reset, cpu);
>> +reset_args = (ARMV7MResetArgs) {
>> +.cpu =
On Tue, Sep 9, 2014 at 8:43 PM, Alistair Francis wrote:
> On Wed, Sep 10, 2014 at 12:03 AM, Martin Galvan
> wrote:
>>>> @@ -259,7 +272,13 @@ qemu_irq *armv7m_init(MemoryRegion *system_memory,
>>>> vmstate_register_ram_global(hack);
>>>>
've added an additional flag, SSTEP_EXCEPTION,
that will be set in the exception_with_syndrome instruction generated
when trying to translate the invalid instruction and will be cleared
after checking for cpu->singlestep_enabled in cpu_exec.
Signed-off-by: Martin Galvan
---
The long
On Thu, Sep 11, 2014 at 8:52 PM, Richard Henderson wrote:
> On 09/11/2014 03:13 PM, Peter Maydell wrote:
> In particular, I'd expect the invalid exception to be recognized, and then the
> cpu loop exited, before the single-step exception could overwrite it. E.g.
> how
> things work on alpha:
>
>
On Fri, Sep 12, 2014 at 12:37 PM, Richard Henderson wrote:
> Alpha do_interrupt doesn't mess with cpu->interrupt_request at all, and
> doesn't
> generate two calls to do_interrupt. The one call finds the vector for the
> given interrupt, modifies the PC, and swaps to the shadow register bank.
>
haviour be? I think we should return
control back to gdb, but we shouldn't try to translate that
instruction again. How could we handle this in a clean way?
On Fri, Sep 12, 2014 at 12:50 PM, Martin Galvan
wrote:
> On Fri, Sep 12, 2014 at 12:37 PM, Richard Henderson wrote:
>> Alpha do_
Special handing of the Pause key. Implemented in a similar way as in
ui/sdl.c.
Signed-off-by: Martin Decky
---
ui/gtk.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 2345d7e..e52cab1 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -931,6 +931,12 @@ static gboolean
Is this still an issue in the -vmware package 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/918791
Title:
qemu-kvm dies when using vmvga driver and unity in the guest
Status in QEMU:
New
St
Hello Jamie, or anyone else affected,
Accepted qemu-kvm into oneiric-proposed. The package will build now and
be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
these
instructions are only available with SSE2, but QEMU is checking for SSE. The
check for the related sfence instruction is correct (it works with SSE).
This trival patch fixes the test:
Signed-off-by: Martin Simmons
--- a/target-i386/translate.c 2011-06-03 16:17:18.270208646 +0100
+++ b/t
Public bug reported:
The NetBSD ncr53c9x.c driver does a TEST_UNIT_READY command with SELATN
but dma disabled sometimes (early during bus enumeration). This is fine,
as the command will not produce nor consume any data, and works on real
hardware.
However, the qemu emulation does not allow this (
** Patch added: "esp.c.patch"
https://bugs.launchpad.net/bugs/1014099/+attachment/3192643/+files/esp.c.patch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1014099
Title:
hw/esp.c does not prope
Guess I understand the code now - so here is a working version - though
it may be considered slightly hackish
** Patch added: "esp.c.patch"
https://bugs.launchpad.net/qemu/+bug/1014099/+attachment/3192942/+files/esp.c.patch
** Patch removed: "esp.c.patch"
https://bugs.launchpad.net/qemu/+
Hi,
I could reproduce it and I bisected it down to this commit.
12d4536f7d911b6d87a766ad7300482ea663cea2 is the first bad commit
commit 12d4536f7d911b6d87a766ad7300482ea663cea2
Author: Anthony Liguori
Date: Mon Aug 22 08:24:58 2011 -0500
-martin
On 22.02.2012 20:53, Stefan Hajnoczi wrote
9bc1] trace: fix
out-of-tree builds
git bisect good d9cd446b4f6ff464f9520898116534de988d9bc1
# bad: [12d4536f7d911b6d87a766ad7300482ea663cea2] main: force enabling
of I/O thread
git bisect bad 12d4536f7d911b6d87a766ad7300482ea663cea2
-martin
On 28.02.2012 18:05, Stefan Hajnoczi wrote:
On Tu
Hi Stefan,
you are right, the performance for the commits 0b9b128530b and
4fefc55ab04d are both good.
What is the best approach to stay in the qemu-kvm.git history?
-martin
On 29.02.2012 09:38, Stefan Hajnoczi wrote:
I suggest testing both of the qemu-kvm.git merge commits, 0b9b128530b
and
** Changed in: qemu-kvm (Ubuntu)
Milestone: ubuntu-12.04-beta-1 => ubuntu-12.04-beta-2
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/918791
Title:
qemu-kvm dies when using vmvga driver and unit
An application test with high cpu load gives the timing statistics give:
bare metal
virtual percent
X4560 cpu50m28s
54m0s 107%
91
bw=61386KB/s iops=15346
v1.0
bw=43599KB/s iops=10899
bw=46288KB/s iops=11572
master
bw=60678KB/s iops=15169
bw=62733KB/s iops=15683
-martin
with "ondemand" except the one where I changed it to
"performance"
Do you want a v0.14.1 test with the governor on "performance"?
-martin
;
The qemu command was.
qemu-system-x86_64 --enable-kvm -m 512 -boot c \
-drive file=/home/martin/vmware/bisect_kvm/hda.img,cache=none,if=virtio
-drive file=/dev/ram0,cache=none,if=virtio
-drive file=/dev/sda2,cache=none,if=virtio
Host Kernel 3.3.0+rc4
Guest Kernel 3.0.0-16-generic ubuntu kerne
Public bug reported:
This bug exists in 0.14.1 and also in 9312805d33e8b (Jun 17, 2011) in
the master git repo.
The "Tight PNG" encoding is a derivative of the "Tight" encoding that
replaces zlib encoded rects with PNG encoded data instead. However, when
the "Tight PNG" encoding is disabled (--di
** Patch added: "The "Tight PNG" encoding should only be used when
--enable-vnc-png is set."
https://bugs.launchpad.net/bugs/806656/+attachment/2194428/+files/0001-vnc-disable-tight-png-when-not-enable-vnc-png.patch
--
You received this bug notification because you are a member of qemu-
deve
Fixed upstream, thanks Eric! Marking as affecting Ubuntu, as even
trusty's qemu does not have that fix yet. For the record, lp:platform-
api uses posix timers for the sensor emulation, so running its tests
will reproduce this qemu problem (and verify its fix).
** Also affects: qemu (Ubuntu)
Imp
Unfortunately it is still not working with these two patches. The
"Unsupported syscall: 257" is gone, but now it fails on EINVAL. I attach
a little test C file which uses a timer. It works fine on x86 and a
real arm machine, but under QEMU I get:
$ gcc -o timer_test -Wall timer_test.c -lrt
$ ./
rid of the magic.
Signed-off-by: Martin Husemann
---
include/exec/softmmu_template.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/exec/softmmu_template.h b/include/exec/softmmu_template.h
index c6a5440..8712dcd 100644
--- a/include/exec/softmmu_template.h
+++ b
Introduce 'query-chardev-backends' QMP command which lists all
supported character device backends.
Signed-off-by: Martin Kletzander
---
qapi-schema.json | 22 ++
qemu-char.c | 19 +++
qmp-commands.hx | 41 ++
Introduce 'query-chardev-backends' QMP command which lists all
supported character device backends.
Signed-off-by: Martin Kletzander
---
v2:
- Version changed from "1.8.0" to "2.0"
qapi-schema.json | 22 ++
qemu-char.c | 19
On Fri, Jan 31, 2014 at 10:20:42AM -0700, Eric Blake wrote:
> On 01/31/2014 09:49 AM, Martin Kletzander wrote:
> > Introduce 'query-chardev-backends' QMP command which lists all
> > supported character device backends.
> >
> > Signed-off-by: Martin Kletz
Introduce 'query-chardev-backends' QMP command which lists all
supported character device backends.
Signed-off-by: Martin Kletzander
---
v3:
- Omit commas at the end of list in JSON
v2:
- Version changed from "1.8.0" to "2.0"
qapi-schema.json | 22 +
15919.html
The full command-line with backtrace of all the threads (with
abort()-ing thread being thread #1 follows. Let me know if I can help
anyhow.
Thanks,
Martin
Command-line:
qemu-system-x86_64 -name rhel7 -S -machine \
pc-i440fx-1.7,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge
On Tue, Feb 04, 2014 at 11:40:41AM +1000, Peter Crosthwaite wrote:
> On Tue, Feb 4, 2014 at 4:45 AM, Dr. David Alan Gilbert
> wrote:
> > (cc'ing in Peter Crosthwaite and Michael Tokarev due to a serial fifo change
> > - see below!)
> >
> > * Martin Kle
On Tue, Feb 04, 2014 at 07:05:24AM +0100, Martin Kletzander wrote:
> On Tue, Feb 04, 2014 at 11:40:41AM +1000, Peter Crosthwaite wrote:
> > On Tue, Feb 4, 2014 at 4:45 AM, Dr. David Alan Gilbert
> > wrote:
> > > (cc'ing in Peter Crosthwaite and Michael Tokarev due t
On Mon, Feb 10, 2014 at 10:49:35PM -0800, Peter Crosthwaite wrote:
> This was guarding against a full fifo rather than an empty fifo when
> popping. Fix.
>
> Signed-off-by: Peter Crosthwaite
> ---
Reviewed-by: Martin Kletzander
With this patch qemu doesn't crash in my use
int8_t.
The attached patch fixes this.
Martin
Do not rely on int8_t (and friends) not being preprocessor symbols (or
symbols expanding to themselves). On NetBSD (for example) the
glue(u, SDATA_TYPE) results in u__int8_t, which is undefined. There is no
way to stop cpp expanding inner macros, so
Hello
I'm new to the list and I'm looking to do some qemu hacking... so I'm
reading through the sources. I've noticed that when e.g. helper functions
for instructions need to read from the memory of the guest address space
(for instance, based on an address passed in an operand) they use macros of
I still regularly get this. The workaround is to open a terminal, which
causes the cursor shape to change. Once that is done, the cursor stays
visible.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/12
Confirmed, this works now. Thanks! Closing, as this only affected the
PPA.
** Changed in: qemu (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1285
Hello,
I'm a researcher from Ben-Gurion Univeristy, working on various security
aspects for virtual machines. A colleague of mine Dr. Alexander Binun has
mailed you a few times recently.
My question is quite simple. Does the order of the VMs in the vm_list has
any importance?
Or more specifically:
Signed-off-by: Martin Simmons
diff --git a/gdbstub.c b/gdbstub.c
index d1b5afd..6a73a35 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -823,7 +823,9 @@ static int gdb_handle_packet(GDBState *s, const char
*line_buf)
action = *p++;
signal = 0;
if (ac
>>>>> On Tue, 4 Nov 2014 19:09:43 +, Peter Maydell said:
>
> On 4 November 2014 17:51, Martin Simmons wrote:
> > While using qemu with gdb "target remote" to debug an application that uses
> > fork and exec, the qemu process receives SIGSTOP every
>>>>> On Wed, 5 Nov 2014 14:17:36 +, Peter Maydell said:
>
> On 5 November 2014 13:50, Martin Simmons wrote:
> >>>>>> On Tue, 4 Nov 2014 19:09:43 +, Peter Maydell said:
> >> The if() statement should have braces for our coding style,
On Tue, Apr 14, 2015 at 10:07:00AM -0600, Eric Blake wrote:
[adding qemu]
On 04/14/2015 09:58 AM, Marc-André Lureau wrote:
Hi
On Tue, Apr 14, 2015 at 4:25 PM, Martin Kletzander
wrote:
Is this not exposed in any way in QEMU? Do we really need to use this
(what we're trying to
thing for output (the output volume setting behaves
acceptably for the default QEMU settings, see above). Please comment.
Regards
Martin
--- qemu-2.1.3/hw/audio/hda-codec-common.h 2015-04-20 14:44:18.621197997 +0200
+++ qemu-2.1.3/hw/audio/hda-codec-common.h.new 2015-04-20 14:43:24.852627519 +02
e similar ranges for input amplifiers.
Signed-off-by: Martin Wilck
---
hw/audio/hda-codec-common.h | 23 +++
hw/audio/hda-codec.c| 23 +--
2 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/hw/audio/hda-codec-common.h b/hw/audio/hda-
t to become effective
in the "new" environment, because the guest will still assume 1dB
stepping.
Other than that, I can't see what might go wrong during a migration -
but maybe I am overlooking something? I have no environment to test
migration, so my thoughts above are just the
officialy minimum supported ?
Thanks for explanation of python status.
M.C>
On Thu, 14 May 2015, Paolo Bonzini wrote:
On 13/05/2015 14:14, Martin Cerveny wrote:
for item in items:
if item['type'].startswith('child<'):
-list_node(path + &#
1 - 100 of 1313 matches
Mail list logo
