On 2013-05-23 14:05, David Gibson wrote:
On Tue, May 21, 2013 at 12:57:16PM +0200, Paolo Bonzini wrote:
The old-style IOMMU lets you check whether an access is valid in a
given DMAContext. There is no equivalent for AddressSpace in the
memory API, implement it with a lookup of the dispatch
On 2013-05-23 20:04, Peter Maydell wrote:
On 21 May 2013 11:57, Paolo Bonzini pbonz...@redhat.com wrote:
+bool address_space_valid(AddressSpace *as, hwaddr addr, int len, bool
is_write)
+{
+AddressSpaceDispatch *d = as-dispatch;
+MemoryRegionSection *section;
+int l;
+
On 2013-05-24 08:13, Jan Kiszka wrote:
On 2013-05-23 20:04, Peter Maydell wrote:
On 21 May 2013 11:57, Paolo Bonzini pbonz...@redhat.com wrote:
+bool address_space_valid(AddressSpace *as, hwaddr addr, int len, bool
is_write)
+{
+AddressSpaceDispatch *d = as-dispatch
On 2013-05-24 12:50, Peter Maydell wrote:
On 24 May 2013 07:13, Jan Kiszka jan.kis...@web.de wrote:
I'll also have a use for it: replace isa_is_ioport_assigned.
That seems like it's something different: it's asking
has some other bit of QEMU registered a handler for
this ioport
On 2013-05-21 12:57, Paolo Bonzini wrote:
Using phys_page_find to translate an AddressSpace to a MemoryRegionSection
is unwieldy. It requires to pass the page index rather than the address,
and later memory_region_section_addr has to be called. Replace
memory_region_section_addr with a
On 2013-05-25 09:47, Paolo Bonzini wrote:
Il 25/05/2013 08:40, Jan Kiszka ha scritto:
On 2013-05-21 12:57, Paolo Bonzini wrote:
Using phys_page_find to translate an AddressSpace to a
MemoryRegionSection is unwieldy. It requires to pass the page
index rather than the address, and later
On 2013-05-25 13:20, Paolo Bonzini wrote:
Il 25/05/2013 12:19, Jan Kiszka ha scritto:
addr -= section-offset_within_address_space;
-len = MIN(section-size - addr, len);
^
This is the size of a section minus an offset in the section
On 2013-05-26 10:56, Paolo Bonzini wrote:
Il 25/05/2013 13:30, Jan Kiszka ha scritto:
On 2013-05-25 13:20, Paolo Bonzini wrote:
Il 25/05/2013 12:19, Jan Kiszka ha scritto:
addr -= section-offset_within_address_space; -len =
MIN(section-size - addr, len
On 2013-05-26 11:01, Paolo Bonzini wrote:
Il 25/05/2013 13:30, Jan Kiszka ha scritto:
On 2013-05-25 13:20, Paolo Bonzini wrote:
Il 25/05/2013 12:19, Jan Kiszka ha scritto:
addr -= section-offset_within_address_space; -len =
MIN(section-size - addr, len
On 2013-05-27 09:20, Paolo Bonzini wrote:
Il 26/05/2013 11:02, Jan Kiszka ha scritto:
Nice patches. Only one thing, how is .impl.unaligned different
from the existing .valid.unaligned?
See memory.h: valid controls is an unaligned access traps or gets
processed, impl manages if it is passed
On 2013-05-27 10:19, Paolo Bonzini wrote:
Il 27/05/2013 09:23, Jan Kiszka ha scritto:
On 2013-05-27 09:20, Paolo Bonzini wrote:
Il 26/05/2013 11:02, Jan Kiszka ha scritto:
Nice patches. Only one thing, how is .impl.unaligned different
from the existing .valid.unaligned?
See memory.h: valid
On 2013-05-28 05:51, Michael Tokarev wrote:
There are quite a few leftover declarations in slirp/misc.h.
Remove them.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
slirp/misc.h | 14 --
1 file changed, 14 deletions(-)
I'm not entirely sure we should do this, since
On 2013-05-30 19:58, 李春奇 Arthur Chunqi Li wrote:
Hi there,
I'm now reading codes of kvm-unit-tests and I found that some of the
test cases for x86 is only designed for x86_64 (including access.flat,
apic.flat, emulator.flat, idt_test.flat and so on). I wonder why these
cases are not designed
, the guest kernel has to
manage access to this I/O port anyway.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/i386/kvmvapic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/i386/kvmvapic.c b/hw/i386/kvmvapic.c
index 1c2dbf5..2d87600 100644
--- a/hw/i386/kvmvapic.c
+++ b/hw
On 2013-09-19 11:34, Gerd Hoffmann wrote:
The usb-host code has been rewritten for qemu 1.5 to use libusb,
the old code has been left in as temporary fallback. Now we are
two releases further out, targeting the 1.7 release. No major
issues with the new code poped up until now. Time to
On 2013-10-03 18:05, Peter Maydell wrote:
On 3 October 2013 23:09, Juergen Lock qem...@jelal.kn-bremen.de wrote:
Local variable CPUClass *cc needs to be reloaded after return from longjmp
too. (This fixes the mips-softmmu crash observed on FreeBSD when qemu is
built with clang.)
On 2013-10-07 09:16, Gerd Hoffmann wrote:
On Mi, 2013-10-02 at 15:14 +0200, Jan Kiszka wrote:
On 2013-09-19 11:34, Gerd Hoffmann wrote:
The usb-host code has been rewritten for qemu 1.5 to use libusb,
the old code has been left in as temporary fallback. Now we are
two releases further out
On 2009-06-18 22:50, Jean-Christophe DUBOIS wrote:
From: Jean-Christophe Dubois jcd@jcd-laptop.(none)
Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---
slirp/socket.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/slirp/socket.c
On 2013-10-28 20:18, Stefan Weil wrote:
Am 18.09.2013 09:48, schrieb Jan Kiszka:
On 2013-09-18 09:26, Peter Maydell wrote:
[...]
And gcc's documentation of the 'noreturn' attribute specifically
says it does not affect the exceptional path where the function
returns via longjmp.
OK
On 2013-10-31 20:31, Stefan Weil wrote:
Reloading of local variables after sigsetjmp is only needed for some
buggy compilers.
The code which should reload these variables causes compiler warnings
with gcc 4.7 when compiler optimizations are enabled:
cpu-exec.c:204:15: error:
variable
On 2013-10-31 21:48, John Arbuckle wrote:
Public bug reported:
The AC97 sound card does not work. It stops QEMU on startup. The cause
appears to be some kind of deadlock.
Steps to reproduce:
Just add -soundhw ac97 to QEMU's arguments. Example: qemu-system-ppc -soundhw
ac97
The
On 2013-09-04 16:27, Paolo Bonzini wrote:
Il 04/09/2013 16:22, Sebastian Ottlik ha scritto:
This patchset disabels all use of SO_REUSEADDR on Windows. On Windows systems
the default behavior is equivalent to SO_REUSEADDR on other operating
systems. SO_REUSEADDR can still be set but results in
On 2013-09-09 18:58, Peter Maydell wrote:
On 9 September 2013 17:54, Jan Kiszka jan.kis...@siemens.com wrote:
DMA requests from one device to another targeting anything else but
RAM-backed regions will have to be rejected by QEMU in the future. We
cannot map this sanely on a per-device locking
On 2013-09-09 18:34, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2013 at 05:02:15PM +0100, Peter Maydell wrote:
On 9 September 2013 17:00, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote:
On 9 September 2013 15:51, Marcel Apfelbaum
On 2013-09-09 19:41, Peter Maydell wrote:
On 9 September 2013 18:27, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
Other communication between devices requiring to take the target
device's
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter Maydell wrote:
Why is a DMA request any different from any other communication
between two devices?
Other communication between devices requiring to take
On 2013-09-09 20:59, Peter Maydell wrote:
On 9 September 2013 19:49, Jan Kiszka jan.kis...@siemens.com wrote:
Well, even if you resolve the locking issues in all the interesting
devices (not impossible, just pretty costly in several regards), you
cannot reasonably allow device A talking
On 2013-09-09 20:03, Paolo Bonzini wrote:
Il 09/09/2013 19:27, Jan Kiszka ha scritto:
On 2013-09-09 19:14, Peter Maydell wrote:
On 9 September 2013 18:09, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-09-09 18:58, Peter Maydell wrote:
Why is a DMA request any different from any other
No need to write out the timeout early, keep it local until we are done.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
slirp/slirp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/slirp/slirp.c b/slirp/slirp.c
index fe16367..bad8dad 100644
--- a/slirp/slirp.c
changes up to 426e3e6ce1abdb0d85faefbfac3cf4dcc7f224a3:
slirp: clean up slirp_update_timeout (2013-09-17 12:26:05 +0200)
Jan Kiszka (1):
slirp: clean up slirp_update_timeout
Liu Ping Fan (3):
slirp: make timeout local
From: Liu Ping Fan qemul...@gmail.com
Each slirp has its own time to caculate timeout.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
slirp/slirp.c | 22 ++
slirp/slirp.h | 3 +++
2 files changed, 13 insertions
Ping Fan pingf...@linux.vnet.ibm.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
main-loop.c | 3 +--
slirp/libslirp.h | 3 +--
slirp/slirp.c| 28
stubs/slirp.c| 6 +-
4 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/main
From: Liu Ping Fan qemul...@gmail.com
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
slirp/slirp.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/slirp/slirp.c b/slirp/slirp.c
index b3ef4fe
On 2013-09-17 12:50, Jan Kiszka wrote:
The following changes since commit 2d1fe1873a984d1c2c89ffa3d12949cafc718551:
Merge remote-tracking branch 'pmaydell/tags/pull-target-arm-20130910' into
staging (2013-09-11 14:46:52 -0500)
are available in the git repository at:
git
On 2013-08-13 16:22, Stefan Hajnoczi wrote:
On Tue, Aug 13, 2013 at 03:45:44PM +0200, Jan Kiszka wrote:
On 2013-08-13 15:39, Alex Bligh wrote:
Jan,
On 13 Aug 2013, at 14:25, Jan Kiszka wrote:
To my understanding, the use case behind the current behavior is
qemu_aio_wait() which is only
On 2013-09-17 19:03, Stefan Weil wrote:
'cpu' and 'env' are not modified after sigsetjmp. Therefore they will
still have their last value after longjmp restored the stack context.
The code which should reload both variables causes a compiler warning:
cpu-exec.c:204:15: error:
variable
On 2013-09-17 18:38, Alex Bligh wrote:
On 17 Sep 2013, at 17:19, Paolo Bonzini wrote:
Il 17/09/2013 18:09, Jan Kiszka ha scritto:
On 2013-08-13 16:22, Stefan Hajnoczi wrote:
On Tue, Aug 13, 2013 at 03:45:44PM +0200, Jan Kiszka wrote:
Yeah:
-/* No AIO operations? Get us out of here
On 2013-09-17 23:24, Peter Maydell wrote:
On 17 September 2013 18:03, Stefan Weil s...@weilnetz.de wrote:
could you please review this patch which removes code added by you earlier?
I have run tests with the old code and assertions to see whether the values
were really smashed. They never
On 2013-09-18 09:26, Peter Maydell wrote:
On 18 September 2013 08:06, Jan Kiszka jan.kis...@web.de wrote:
On 2013-09-17 23:24, Peter Maydell wrote:
On 17 September 2013 18:03, Stefan Weil s...@weilnetz.de wrote:
could you please review this patch which removes code added by you earlier?
I
On 2013-09-22 10:11, Liu Ping Fan wrote:
This lets the read-side access run outside the BQL.
In fact, not only BQL. Didn't the original commit provide a changlog
about the content of this patch? Otherwise, briefly describe use cases
and maybe the typical invocation pattern.
Signed-off-by:
On 2013-09-22 10:11, Liu Ping Fan wrote:
QEMU_CLOCK_VIRTUAL may be read outside BQL. This will make its
foundation, i.e. timers_state exposed to race condition.
Using private lock to protect it.
After this patch, reading QEMU_CLOCK_VIRTUAL is thread safe
unless use_icount is true, in which
On 2013-09-22 10:11, Liu Ping Fan wrote:
This emulates Win32 manual-reset events using futexes or conditional
variables. Typical ways to use them are with multi-producer,
single-consumer data structures, to test for a complex condition whose
elements come from different threads:
for
On 2013-09-22 10:11, Liu Ping Fan wrote:
After disabling the QemuClock, we should make sure that no QemuTimers
are still in flight. To implement that with light overhead, we resort
to QemuEvent. The caller of disabling will wait on QemuEvent of each
timerlist.
Note,
On 2013-09-25 20:08, Hu Yaohui wrote:
Hi All,
I am trying to debug guest OS through qemu with kvm enabled.
Following is what I have done:
1: fire the qemu-kvm
snip
sudo qemu-system-x86_64 -hda vdisk.img -m 4096 -smp 2 -vnc :2 -boot c -s
/snip
2: wait until login into guest OS (ubuntu
On 2013-09-26 16:14, Hu Yaohui wrote:
Hi Jan,
Thanks for your reply.
On Thu, Sep 26, 2013 at 2:08 AM, Jan Kiszka jan.kis...@web.de wrote:
On 2013-09-25 20:08, Hu Yaohui wrote:
Hi All,
I am trying to debug guest OS through qemu with kvm enabled.
Following is what I have done:
1: fire
On 2013-09-26 20:53, Hu Yaohui wrote:
Hi Jan,
I am working on some Nested VM related projects. Some other teammates have
made the modifications to the kvm module.
And these modifications cannot cause the misguided INT3?
Most of my work depends on his.
If I could not use Qemu Debug method.
On 2013-07-25 07:47, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 15:26 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-22 at 10:34 -0500, Anthony Liguori wrote:
Really nice series. I'd prefer we simply got rid of the endianness
flag
entirely but this is a good step.
On 2013-07-25 13:44, Stefan Hajnoczi wrote:
On Tue, Jul 23, 2013 at 10:51:06AM +0800, liu ping fan wrote:
On Mon, Jul 22, 2013 at 2:28 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-22 06:38, liu ping fan wrote:
On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh a...@alex.org.uk wrote:
Liu
On 2013-07-25 14:21, Alex Bligh wrote:
--On 25 July 2013 14:05:30 +0200 Stefan Hajnoczi stefa...@gmail.com
wrote:
Alex Bligh's series gives each AioContext its own rt_clock. This avoids
the need for synchronization in the simple case. If we require timer
access between threads then we
On 2013-07-25 14:35, Paolo Bonzini wrote:
Il 25/07/2013 14:32, Jan Kiszka ha scritto:
On 2013-07-25 14:21, Alex Bligh wrote:
--On 25 July 2013 14:05:30 +0200 Stefan Hajnoczi stefa...@gmail.com
wrote:
Alex Bligh's series gives each AioContext its own rt_clock. This avoids
the need
On 2013-07-25 14:41, Stefan Hajnoczi wrote:
On Thu, Jul 25, 2013 at 2:38 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-25 14:35, Paolo Bonzini wrote:
Il 25/07/2013 14:32, Jan Kiszka ha scritto:
On 2013-07-25 14:21, Alex Bligh wrote:
--On 25 July 2013 14:05:30 +0200 Stefan Hajnoczi
On 2013-07-25 15:02, Paolo Bonzini wrote:
Il 25/07/2013 14:48, Jan Kiszka ha scritto:
The concept of clocks (with start/stop property) and active timers shall
not be mixed, they are independent.
Are you referring to this in particular:
void pause_all_vcpus(void)
{
CPUState *cpu
On 2013-07-25 15:31, Stefan Hajnoczi wrote:
On Thu, Jul 25, 2013 at 3:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-25 15:02, Paolo Bonzini wrote:
Il 25/07/2013 14:48, Jan Kiszka ha scritto:
The concept of clocks (with start/stop property) and active timers shall
not be mixed
On 2013-07-25 20:53, Alex Bligh wrote:
--On 25 July 2013 14:32:59 +0200 Jan Kiszka jan.kis...@siemens.com wrote:
I would happily at a QEMUClock of each type to AioContext. They are
after
all pretty lightweight.
What's the point of adding tones of QEMUClock instances? Considering
.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
v2: Rebase over master
gdbstub.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 35ca7c2..4a6cc51 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -42,6 +42,12 @@
#include sysemu/kvm.h
On 2013-07-27 16:10, Andreas Färber wrote:
Am 24.07.2013 09:48, schrieb Andreas Färber:
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/arm/musicpal.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/hw/arm/musicpal.c b/hw/arm/musicpal.c
index
, musicpal_lcd_gpio_brigthness_in, 3);
+qdev_init_gpio_in(dev-qdev, musicpal_lcd_gpio_brightness_in, 3);
return 0;
}
Reviewed-by: Jan Kiszka jan.kis...@web.de
signature.asc
Description: OpenPGP digital signature
On 2013-07-29 16:59, Andreas Färber wrote:
Am 16.07.2013 17:31, schrieb Paolo Bonzini:
From: Jan Kiszka jan.kis...@siemens.com
This restore the behavior prior to b018ddf633 which accidentally changed
the return code to 0. Specifically guests probing for register existence
were affected
Hi Igor,
just noticed by chance that error handling in cpu_x86_create is likely
broken after your changes. Any error after cpu = ...object_new() will
not properly release the CPU object again nor report NULL to the caller.
That means errors should slip through, no? And cpu_x86_init looks similar.
Hi all,
I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
version. Under certain load, our tap backend stops reading from the char
device, and that even if we reset the guest. The frontend device
(pcnet32) is able to receive (can_receive would return 0), but the
tap's fd is
On 2013-08-01 19:15, Jan Kiszka wrote:
Hi all,
I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
version. Under certain load, our tap backend stops reading from the char
device, and that even if we reset the guest. The frontend device
(pcnet32) is able to receive
On 2013-08-02 09:33, Stefan Hajnoczi wrote:
On Thu, Aug 01, 2013 at 07:24:13PM +0200, Jan Kiszka wrote:
On 2013-08-01 19:15, Jan Kiszka wrote:
Hi all,
I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
version. Under certain load, our tap backend stops reading from
On 2013-08-02 13:46, Stefan Hajnoczi wrote:
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
I was digging into the involved code and found something fishy:
net/tap.c:
static void tap_send(void *opaque)
{
...
size = qemu_send_packet_async(s-nc, buf, size
On 2013-07-30 14:21, Igor Mammedov wrote:
On Tue, 30 Jul 2013 13:00:40 +0200
Jan Kiszka jan.kis...@siemens.com wrote:
Hi Igor,
just noticed by chance that error handling in cpu_x86_create is likely
broken after your changes. Any error after cpu = ...object_new() will
not properly release
On 2013-08-02 14:45, Jan Kiszka wrote:
On 2013-08-02 13:46, Stefan Hajnoczi wrote:
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
I was digging into the involved code and found something fishy:
net/tap.c:
static void tap_send(void *opaque)
{
...
size
On 2013-08-02 14:45, Jan Kiszka wrote:
On 2013-08-02 13:46, Stefan Hajnoczi wrote:
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
I was digging into the involved code and found something fishy:
net/tap.c:
static void tap_send(void *opaque)
{
...
size
From: Jan Kiszka jan.kis...@siemens.com
Each networking client has a queue for packets that could not yet be
delivered to that client. Calling this queue send_queue is highly
confusing as it has nothing to to with packets send from this client but
to it. Avoid this confusing by renaming
From: Jan Kiszka jan.kis...@siemens.com
Analogously to other NICs, we have to inform the network layer when
the can_receive handler will no longer report 0. Without this, we may
get stuck waiting on queued incoming packets.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/net/pcnet.c
From: Jan Kiszka jan.kis...@siemens.com
This reverts commit 9b8c69243585a32d14b9bb9fcd52c37b0b5a1b71.
The commit was wrong: We only return -1 on invalid accesses, not on
valid but unbacked ones. This broke various corner cases.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
memory.c
From: Jan Kiszka jan.kis...@siemens.com
Accesses to unassigned io ports shall return -1 on read and be ignored
on write. Ensure these properties via dedicated ops, decoupling us from
the memory core's handling of unassigned accesses.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
exec.c
On 2013-08-05 10:45, Andreas Färber wrote:
Am 05.08.2013 00:04, schrieb Aurélien Jarno:
On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote:
Am 27.07.2013 22:58, schrieb Stefan Weil:
Am 27.07.2013 22:43, schrieb Andreas Färber:
Am 27.07.2013 21:37, schrieb Stefan Weil:
Am 27.07.2013
On 2013-08-05 11:34, Andreas Färber wrote:
Am 03.08.2013 10:31, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
Accesses to unassigned io ports shall return -1 on read and be ignored
on write. Ensure these properties via dedicated ops, decoupling us from
the memory core's
On 2013-08-05 11:59, Peter Maydell wrote:
On 5 August 2013 10:34, Andreas Färber afaer...@suse.de wrote:
Am 03.08.2013 10:31, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
Accesses to unassigned io ports shall return -1 on read and be ignored
on write. Ensure these properties
On 2013-08-05 12:36, Peter Maydell wrote:
On 5 August 2013 11:30, Jan Kiszka jan.kis...@web.de wrote:
On 2013-08-05 11:59, Peter Maydell wrote:
Or do you mean that if we had:
[ system memory region, with its own default read/write ops ]
I cannot imagine how this could work. The system
On 2013-08-05 12:51, Peter Maydell wrote:
On 5 August 2013 11:44, Jan Kiszka jan.kis...@web.de wrote:
On 2013-08-05 12:36, Peter Maydell wrote:
On 5 August 2013 11:30, Jan Kiszka jan.kis...@web.de wrote:
On 2013-08-05 11:59, Peter Maydell wrote:
Or do you mean that if we had:
[ system
On 2013-08-05 13:35, Andreas Färber wrote:
Am 05.08.2013 13:03, schrieb Jan Kiszka:
On 2013-08-05 12:51, Peter Maydell wrote:
On 5 August 2013 11:44, Jan Kiszka jan.kis...@web.de wrote:
On 2013-08-05 12:36, Peter Maydell wrote:
On 5 August 2013 11:30, Jan Kiszka jan.kis...@web.de
wrote
).
Therefore cpu_x86_create() must unref the new X86CPU itself, and
pc_new_cpu() must check for an Error rather than NULL return value.
While at it, clean up a superfluous NULL check.
Reported-by: Jan Kiszka jan.kis...@siemens.com
Cc: qemu-sta...@nongnu.org
Cc: Igor Mammedov imamm...@redhat.com
On 2013-08-08 17:23, Peter Maydell wrote:
On 3 August 2013 09:31, Jan Kiszka jan.kis...@web.de wrote:
From: Jan Kiszka jan.kis...@siemens.com
This reverts commit 9b8c69243585a32d14b9bb9fcd52c37b0b5a1b71.
The commit was wrong: We only return -1 on invalid accesses, not on
valid but unbacked
On 2013-08-08 17:13, Peter Maydell wrote:
On 16 July 2013 13:45, Jan Kiszka jan.kis...@siemens.com wrote:
This restore the behavior prior to b018ddf633 which accidentally changed
the return code to 0. Specifically guests probing for register existence
were affected by this.
Signed-off
On 2013-08-08 17:33, Peter Maydell wrote:
On 3 August 2013 09:31, Jan Kiszka jan.kis...@web.de wrote:
--- a/ioport.c
+++ b/ioport.c
@@ -44,6 +44,22 @@ typedef struct MemoryRegionPortioList {
MemoryRegionPortio ports[];
} MemoryRegionPortioList;
+static uint64_t unassigned_io_read
On 2013-08-08 23:41, Alex Bligh wrote:
This patch series adds support for timers attached to an AioContext clock
which get called within aio_poll.
In doing so it removes alarm timers and moves to use ppoll where possible.
This patch set 'sort of' passes make check (see below for caveat)
On 2013-08-09 10:24, liu ping fan wrote:
Hi Jan, do you work on pushing hpet onto dedicated thread? If you do,
I will cease my current work.
No, the HPET is not needed for our current use case, just the MC146818.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence
This just binds both patches properly together and fixes up the return
value size of unassigned_io_read as suggested. Please merge before the
1.6 release.
Jan Kiszka (2):
memory: Provide separate handling of unassigned io ports accesses
Revert memory: Return -1 again on reads from unsigned
Accesses to unassigned io ports shall return -1 on read and be ignored
on write. Ensure these properties via dedicated ops, decoupling us from
the memory core's handling of unassigned accesses.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
exec.c|3 ++-
include/exec
This reverts commit 9b8c69243585a32d14b9bb9fcd52c37b0b5a1b71.
The commit was wrong: We only return -1 on invalid accesses, not on
valid but unbacked ones. This broke various corner cases.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
memory.c |2 +-
1 files changed, 1 insertions
On 2013-11-01 11:10, Michael Tokarev wrote:
01.11.2013 13:54, Michael Büsch wrote:
On Fri, 01 Nov 2013 13:32:49 +0400
Michael Tokarev m...@tls.msk.ru wrote:
That looks right. Are you okay adding your Signed-off-by to the patch
you initially submitted? If yes, I'll make a formal patch
On 2013-10-07 18:53, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Targets like ppc64 support different typed of KVM, one which use
hypervisor mode and the other which doesn't. Add a new machine
property kvm_type that helps in selecting the respective ones
On 2013-08-14 13:29, Jan Kiszka wrote:
This was once introduced by commit 100d9891d6 but was never used in-tree
and then got broken by commit 32e0c8260d. Time to clean up.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/timer/mc146818rtc.c |9 +
1 files changed, 1
On 2013-11-04 14:30, Alexander Graf wrote:
On 04.11.2013, at 14:28, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-10-07 18:53, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Targets like ppc64 support different typed of KVM, one which use
hypervisor
This feature was already deprecated back then in qemu-kvm, ie. before
pci-assign went upstream. assigned_dev_ioport_rw will never be invoked
with resource_fd 0.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/i386/kvm/pci-assign.c | 56 +---
1
On 2013-11-04 14:55, Michael Tokarev wrote:
04.11.2013 00:06, Jan Kiszka wrote:
On 2013-11-01 11:10, Michael Tokarev wrote:
[]
If Jan picks it up, that's fine. If not, I think it can go
to the trivial patches queue.
Works fine, applied to queues/slirp.
Okay, thank you Jan
On 2013-11-05 17:01, Frederich, Jens wrote:
Hi all,
we're currently evaluating different RTOS systems (Windows CE, Intime, RTX,
etc.).
One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one
QEMU
On 2013-11-05 21:20, Jens Frederich wrote:
On 2013-11-05 17:01, Frederich, Jens wrote:
Hi all,
we're currently evaluating different RTOS systems (Windows CE, Intime, RTX,
etc.).
One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
works fine, Linux RT has good latency and
On 2013-11-06 16:08, Aneesh Kumar K.V wrote:
Jan Kiszka jan.kis...@siemens.com writes:
On 2013-10-07 18:53, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Targets like ppc64 support different typed of KVM, one which use
hypervisor mode and the other which
On 2013-10-09 13:42, Gerd Hoffmann wrote:
Hi,
Only very recent distros fulfill the need of = 1.0.13, so you naturally
fall back to this code. I just realized that even the factory build of
OpenSUSE is still on libusb-1.0.9. Current Ubuntu versions are on 1.0.12
at best. Didn't check
On 2013-11-08 16:39, Gerd Hoffmann wrote:
Hi,
OK, then here is the first issue I ran into while trying libusbx (git
head, i.e. 1.0.17+: The new stack causes significant latency issues that
makes it almost unusable for pass-through of USB audio devices (some
headset in my case). Reverting
From: Jan Kiszka jan.kis...@siemens.com
As long as we have no persistent GTK configuration, this allows to
enable the useful grab-on-hover feature already when starting the VM.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/ui/console.h | 2 +-
qemu-options.hx | 5 +
ui
On 2013-11-11 13:41, Andreas Färber wrote:
Am 11.11.2013 08:44, schrieb Alexey Kardashevskiy:
This converts +foo/-foo to foo=on/foo=off respectively when
QEMU parser is used for the command line options.
-cpu parsers in x86 and other architectures should be unaffected
by this change.
On 2013-06-28 18:58, Paolo Bonzini wrote:
This series, split out of the previous attempt to set owners for memory
regions, adds reference counting operations to memory regions and uses
them. As requested by Peter, I'm adding an argument for the owner to
all memory region creation functions.
On 2013-07-01 10:43, Jan Kiszka wrote:
On 2013-06-28 18:58, Paolo Bonzini wrote:
This series, split out of the previous attempt to set owners for memory
regions, adds reference counting operations to memory regions and uses
them. As requested by Peter, I'm adding an argument for the owner
1 - 100 of 5319 matches
Mail list logo
