space) but the result
is cleaner as well.
Signed-off-by: Avi Kivity
---
exec.c | 13 -
kvm-all.c | 20 ++--
kvm-stub.c | 10 --
kvm.h | 2 --
memory.c | 17 +
memory.h | 4
6 files changed, 27 insertions(+), 39 deletions
Instead of checking manually, let the listener filter for us. This prepares
us for DMA address spaces.
Signed-off-by: Avi Kivity
---
hw/vhost.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/vhost.c b/hw/vhost.c
index d0ce5aa..100f765 100644
--- a/hw/vhost.c
+++ b
On 10/09/2012 06:57 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-----
>> From: Avi Kivity [mailto:a...@redhat.com]
>> Sent: Tuesday, October 09, 2012 10:24 PM
>> To: Bhushan Bharat-R65777
>> Cc: Andreas Färber; ag...@suse.de; qemu-...@nongnu.o
Instead of embedding knowledge of the memory and I/O address spaces in the
memory core, maintain a list of all address spaces. This list will later
be extended dynamically for other bus masters.
Reviewed-by: Anthony Liguori
Signed-off-by: Avi Kivity
---
memory.c | 75
er of anyone using them.
Reviewed-by: Anthony Liguori
Signed-off-by: Avi Kivity
---
cputlb.c | 3 +--
exec.c | 3 +--
exec-obsolete.h => memory-internal.h | 8 ++--
memory.c | 3 +--
4 files ch
With this change, memory.c no longer knows anything about special address
spaces, so it is prepared for AddressSpace based DMA.
Reviewed-by: Anthony Liguori
Signed-off-by: Avi Kivity
---
exec-memory.h | 6 --
exec.c| 9 +++--
memory.c | 16
3 files
Many listeners don't need to respond to all MemoryListener callbacks;
provide suitable no-op defaults instead.
Signed-off-by: Avi Kivity
---
memory.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/memory.c b/memory.c
index b58b97c..269af3f 1
ping was running on a NIC in slot 3. The kernel (Linux) detected
the stall and recovered after the command
setpci -s 03 COMMAND=7
was issued.
Signed-off-by: Avi Kivity
---
hw/pci.c | 13 +++--
hw/pci.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/pci.c
Removes quite a bit of useless code.
Signed-off-by: Avi Kivity
---
hw/xen_pt.c | 45 -
1 file changed, 45 deletions(-)
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 438ad54..6f16182 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -598,14 +598,6
We plan to make the core listener listen to all address spaces; this
will cause many more flushes than necessary. Prepare for that by
moving the flush into a tcg-specific listener.
Later we can avoid registering the listener if tcg is disabled.
Signed-off-by: Avi Kivity
---
exec.c | 8
thony Liguori
Signed-off-by: Avi Kivity
---
memory.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/memory.c b/memory.c
index 1aeca08..7e9e373 100644
--- a/memory.c
+++ b/memory.c
@@ -222,7 +222,7 @@ struct FlatView {
/* A system ad
Removes quite a bit of useless code.
Signed-off-by: Avi Kivity
---
exec.c | 96 --
1 file changed, 96 deletions(-)
diff --git a/exec.c b/exec.c
index 5c703b9..a16c6b4 100644
--- a/exec.c
+++ b/exec.c
@@ -3202,32 +3202,12 @@ static
Since address spaces can be created dynamically by device hotplug, they
can also be destroyed dynamically.
Signed-off-by: Avi Kivity
---
exec.c| 10 ++
memory-internal.h | 1 +
memory.c | 18 --
memory.h | 12
4 files changed
On 10/10/2012 12:24 PM, Alberto Garcia wrote:
> On Sun, Oct 07, 2012 at 12:13:53PM +0200, Avi Kivity wrote:
>
>> Luckily the low-order bits are used for offsets, and the high-order
>> bits are used for selecting the sub-device.
>>
>> So you could easily h
On 08/27/2012 06:01 PM, Jan Kiszka wrote:
> On 2012-08-27 22:53, Avi Kivity wrote:
> > On 08/27/2012 12:38 PM, Jan Kiszka wrote:
> >>>> Even worse, apply
> >>>> restrictions on how the dispatched objects, the regions, have to be
> >>>>
On 08/28/2012 02:42 AM, Jan Kiszka wrote:
>
> Let's not talk about devices or MMIO dispatching. I think the problem is
> way more generic, and we will face it multiple times in QEMU.
The problem exists outside qemu as well. It is one of the reasons for
the popularity of garbage collection IMO, a
On 08/29/2012 10:21 AM, Jan Kiszka wrote:
> On 2012-08-29 19:13, Avi Kivity wrote:
> > On 08/27/2012 06:01 PM, Jan Kiszka wrote:
> >> On 2012-08-27 22:53, Avi Kivity wrote:
> >>> On 08/27/2012 12:38 PM, Jan Kiszka wrote:
> >>>>>> Even worse
On 08/29/2012 10:30 AM, Jan Kiszka wrote:
> On 2012-08-29 19:23, Avi Kivity wrote:
> > On 08/28/2012 02:42 AM, Jan Kiszka wrote:
> >>
> >> Let's not talk about devices or MMIO dispatching. I think the problem is
> >> way more generic, and we will face
On 08/29/2012 10:49 AM, Jan Kiszka wrote:
> >
> > Let's experiment with refcounting MemoryRegion. We can move the entire
> > contents of MemoryRegion to MemoryRegionImpl, add a reference count (to
> > MemoryRegionImpl), and change MemoryRegion to contain a pointer to the
> > refcounted MemoryRegi
On 08/30/2012 12:08 AM, Jan Kiszka wrote:
> >>>
> >>> We are dispatching according to the memory region (parameters, op
> >>> handlers, opaques). If we end up in device object is not decided at this
> >>> level. A memory region describes a dispatchable area - not to confuse
> >>> with a device that
On 09/01/2012 01:57 AM, Jan Kiszka wrote:
> On 2012-09-01 10:31, Avi Kivity wrote:
> > On 08/29/2012 10:49 AM, Jan Kiszka wrote:
> >>>
> >>> Let's experiment with refcounting MemoryRegion. We can move the entire
> >>> contents of MemoryReg
On 09/03/2012 10:44 AM, liu ping fan wrote:
>>>
>>
>> If we make the refcount/lock internal to the region, we must remove the
>> opaque, since the region won't protect it.
>>
>> Replacing the opaque with container_of(mr) doesn't help, since we can't
>> refcount mr, only mr->impl.
>>
> I think you m
On 08/29/2012 08:41 PM, Jan Kiszka wrote:
>>>
>>> memory_region_transaction_commit (or calls that trigger this) will have
>>> to wait. That is required as the caller may start fiddling with the
>>> region right afterward.
>>
>> However, it may be running within an mmio dispatch, so it may wait for
On 09/03/2012 01:06 PM, liu ping fan wrote:
> On Mon, Sep 3, 2012 at 4:52 PM, Avi Kivity wrote:
>> On 09/03/2012 10:44 AM, liu ping fan wrote:
>>>>>
>>>>
>>>> If we make the refcount/lock internal to the region, we must remove th
On 08/29/2012 06:01 AM, Julien Grall wrote:
> This patch replaces all register_ioport* with the new memory API. It permits
> to use the new Memory stuff like listener.
>
> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> @@ -28,6 +28,7 @@
> #include "range.h"
> #include "ioport.h"
> #include "f
On 08/29/2012 06:01 AM, Julien Grall wrote:
> This patch replaces all register_ioport* with the new memory API. It permits
> to use the new Memory stuff like listener.
>
>
> @@ -55,7 +55,8 @@ struct pci_status {
>
> typedef struct PIIX4PMState {
> PCIDevice dev;
> -IORange ioport;
>
On 09/03/2012 11:40 AM, Andreas Färber wrote:
> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
>> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
>> index ab3d98b..dcde5f2 100644
>> --- a/hw/i8259_common.c
>> +++ b/hw/i8259_common.c
> [...]
>> @@ -111,6 +112,7 @@ static const VMStateDescription v
On 09/03/2012 06:42 PM, Juan Quintela wrote:
> Avi Kivity wrote:
>> On 09/03/2012 11:40 AM, Andreas Färber wrote:
>>> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
>>>> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
>>>> index ab3d98b..dcde5f2 100644
On 09/03/2012 06:54 PM, Jan Kiszka wrote:
> On 2012-09-03 17:52, Avi Kivity wrote:
>> On 09/03/2012 06:42 PM, Juan Quintela wrote:
>>> Avi Kivity wrote:
>>>> On 09/03/2012 11:40 AM, Andreas Färber wrote:
>>>>> Am 03.09.2012 04:56, schrieb Matthew Ogi
On 08/29/2012 11:49 AM, Peter Maydell wrote:
> On 29 August 2012 09:47, Jan Kiszka wrote:
>> On 2012-08-28 23:26, Peter Maydell wrote:
>>> Since this is arch-specific we should probably give the
>>> resulting device a more specific name than "pci-assign",
>>> which implies that it is (a) ok for an
On 08/28/2012 03:30 AM, Jan Kiszka wrote:
>>
>> Maybe add case 8: and default: with abort(), also below.
>
> PIO is never 8 bytes long, the generic layer protects us.
Note: eventually the pio space will be mapped directly to mmio (instead
of being bounced via cpu_inb() in the bridge's mmio handl
On 08/29/2012 11:27 AM, Markus Armbruster wrote:
>
> I don't see a point in making contributors avoid non-problems that might
> conceivably become trivial problems some day. Especially when there's
> no automated help with the avoiding.
-Wpointer-arith
--
error compiling committee.c: too man
On 09/03/2012 07:02 PM, Jan Kiszka wrote:
Looks like the optimal condition is ((s->icw3 & ~s->eclr) != 0) (i.e.
bit set in icw3 but clear in eclr).
>>>
>>> The standard PC values are optimal: 4 for master, 2 for slave.
>>
>> Can you explain why? I saw that icw3 is always ORed with eclr
On 09/03/2012 07:23 PM, Paolo Bonzini wrote:
> Il 03/09/2012 18:15, Avi Kivity ha scritto:
>>> > The values above are what every user of the PIC cascaded on our targets
>>> > must program to use them. So We will find them in the state once any
>>> > releva
On 09/03/2012 07:33 PM, Paolo Bonzini wrote:
> Il 03/09/2012 18:30, Avi Kivity ha scritto:
>>>>>> The values above are what every user of the PIC cascaded on our targets
>>>>>> >>> > must program to use them. So We will find them in the state once
On 09/03/2012 10:32 PM, Blue Swirl wrote:
> On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity wrote:
>> On 08/29/2012 11:27 AM, Markus Armbruster wrote:
>>>
>>> I don't see a point in making contributors avoid non-problems that might
>>> conceivably become tr
On 09/04/2012 12:15 PM, Paolo Bonzini wrote:
> Il 04/09/2012 10:16, Avi Kivity ha scritto:
>>> > But the point of subsections is to succeed migration in the common case,
>>> > assuming there is more than one case that doesn't affect guest operation.
>>
On 09/04/2012 12:29 PM, BALATON Zoltan wrote:
> On Tue, 4 Sep 2012, Avi Kivity wrote:
>> On 09/04/2012 12:15 PM, Paolo Bonzini wrote:
>>> Il 04/09/2012 10:16, Avi Kivity ha scritto:
>>>>>> But the point of subsections is to succeed migration in the common
>&g
On 09/04/2012 01:06 PM, Paolo Bonzini wrote:
> Il 04/09/2012 11:51, Jan Kiszka ha scritto:
>>> >
>>> > I don't mean to say we shouldn't care about them, but there are likely
>>> > to be a lot more users doing backwards migration than users running
>>> > those guests, let alone migrating them (forw
On 09/04/2012 06:13 PM, Cornelia Huck wrote:
> Add support for handling I/O interrupts (standard, subchannel-related
> ones and rudimentary adapter interrupts).
>
> The subchannel-identifying parameters are encoded into the interrupt
> type.
>
> I/O interrupts are floating, so they can't be injec
On 09/04/2012 06:13 PM, Cornelia Huck wrote:
> Hi,
>
> here's the second revision of the virtual channel subsystem support for
> s390.
>
> I changed the representation of the channel subsystem, introducing channel
> subsystem images, which brings it closer to the actual implementation. A
> new io
On 09/05/2012 11:19 AM, liu ping fan wrote:
> [...]
>>>
>> We could externalize the refcounting and push it into device code. This
>> means:
>>
>>memory_region_init_io(&s->mem, dev)
>>
>>...
>>
>>object_ref(dev)
>>memory_region_add_subregion(...,
On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>>
>> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a
>> corresponding unref), which has the following requirements:
>>
>> - if the refcount is nonzero, MemoryRegion::opaque is safe to use
>> - if the refcount is nonzero, the Memory
On 09/05/2012 02:11 PM, Jan Kiszka wrote:
> On 2012-09-05 12:53, Avi Kivity wrote:
>> On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>>>>
>>>> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a
>>>> corresponding unref), which has t
On 09/05/2012 03:02 PM, Jan Kiszka wrote:
> On 2012-09-05 13:25, Avi Kivity wrote:
>> On 09/05/2012 02:11 PM, Jan Kiszka wrote:
>>> On 2012-09-05 12:53, Avi Kivity wrote:
>>>> On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>>>>>>
>>>>>&
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
>>
>> Why? The way this is being submitted I don't see why we should treat
>> Jan's patch any different from a patch by IBM or Samsung where we've
>> asked folks to fix the license to comply with what I thought was our new
>> policy (it does not even c
On 09/05/2012 06:41 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> On 09/05/2012 12:00 AM, Anthony Liguori wrote:
>>>>
>>>> Why? The way this is being submitted I don't see why we should treat
>>>> Jan's patch any different from a p
On 08/14/2012 12:58 PM, Kevin Wolf wrote:
>
>> While we are at this, let me bring out another issue. Gluster supports 3
>> transport types:
>>
>> - socket in which case the server will be hostname, ipv4 or ipv4 address.
>> - rdma in which case server will be interpreted similar to socket.
>> - un
On 09/05/2012 10:04 PM, Blue Swirl wrote:
>
> Reinventing a disassembler for ever growing x86 assembly is
> no fun.
We can try linking to a disassembler library. I use udis86 to
disassemble instructions in kvm tracepoints
(http://udis86.git.sourceforge.net/git/gitweb.cgi?p=udis86/udis86;a=shortlo
On 08/22/2012 06:06 PM, Peter Lieven wrote:
> Hi,
>
> has anyone ever tested to run memtest with -cpu host flag passed to
> qemu-kvm?
> For me it resets when probing the chipset. With -cpu qemu64 it works
> just fine.
>
> Maybe this is specific to memtest, but it might be sth that can happen
> in
On 09/02/2012 01:51 PM, Blue Swirl wrote:
> I've used the following snippet to check what happens with the last 100
> commits:
> for i in '' 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do
> echo $i$j; git show HEAD~$i$j >/tmp/a; clear;head -20 /tmp/a;
> ./scripts/checkpatch.pl --root=. /tm
On 09/06/2012 06:47 PM, Daniel P. Berrange wrote:
>
> gluster:///volname/image?transport=unix&sockpath=/path/to/unix/sock
Like.
--
error compiling committee.c: too many arguments to function
On 08/20/2012 11:55 AM, Jan Kiszka wrote:
> No need to expose the fd-based interface, everyone will already be fine
> with the more handy EventNotifier variant. Rename the latter to clarify
> that we are still talking about irqfds here.
Thanks, applied.
>
> -int kvm_irqchip_add_irqfd(KVMState *
On 09/06/2012 11:44 AM, Jan Kiszka wrote:
> On 2012-08-30 20:30, Jan Kiszka wrote:
>> This adds PCI device assignment for i386 targets using the classic KVM
>> interfaces. This version is 100% identical to what is being maintained
>> in qemu-kvm for several years and is supported by libvirt as well
On 09/04/2012 06:13 PM, Julien Grall wrote:
> This patch replaces all register_ioport* with the new memory API. It permits
> to use the new Memory stuff like listener.
>
> @@ -200,8 +212,11 @@ static void pm_io_space_update(PIIX4PMState *s)
>
> /* XXX: need to improve memory and ioport
On 09/08/2012 01:53 PM, Jan Kiszka wrote:
> On 2012-09-07 18:09, Erik Lotspeich wrote:
>> Hi,
>>
>> I apologize if this isn't the right venue for this message, but this
>> mailing list seems a bit more active than qemu-discuss.
>>
>> Background:
>> I am running OpenSUSE 12.1. I fixed audio issues
On 09/07/2012 11:26 AM, Liu Sheng wrote:
> as readonly memory is support in kvm, this patch supports this feature
> in qemu, mainly pluging the memory region with KVM_MEM_READONLY flag
> to kvm.
>
> @@ -1607,10 +1623,19 @@ int kvm_cpu_exec(CPUArchState *env)
> break;
> case K
On 09/07/2012 11:50 AM, Jan Kiszka wrote:
>
>> +} else {
>> +cpu_physical_memory_rw(run->mmio.phys_addr,
>> + run->mmio.data,
>> + run->mmio.len,
>> + run->
On 09/10/2012 04:27 AM, Matthew Ogilvie wrote:
> Intel's definition of "edge triggered" means: "asserted with a
> low-to-high transition at the time an interrupt is registered and
> then kept high until the interrupt is served via one of the
> EOI mechanisms or goes away unhandled."
>
> So the onl
On 09/10/2012 12:06 PM, Jan Kiszka wrote:
>>> Known issue, likely unfixable in QEMU due to hard-coded constraints of
>>> the driver Windows uses (too small playback buffers).
>>
>> Would using real-time priority for the guest improve things?
>>
>> Of course that can be dangerous if the guest dec
On 09/10/2012 12:09 PM, Jan Kiszka wrote:
> On 2012-09-10 10:56, Avi Kivity wrote:
>> On 09/10/2012 04:27 AM, Matthew Ogilvie wrote:
>>> Intel's definition of "edge triggered" means: "asserted with a
>>> low-to-high transition at the time an interrupt
On 09/10/2012 01:37 PM, Julien Grall wrote:
> On 09/09/2012 03:22 PM, Avi Kivity wrote:
>> On 09/04/2012 06:13 PM, Julien Grall wrote:
>>
>>> This patch replaces all register_ioport* with the new memory API. It
>>> permits
>>>
On 09/10/2012 02:29 PM, Paolo Bonzini wrote:
> Il 10/09/2012 13:06, Peter Lieven ha scritto:
>>
>> qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_entry: vcpu 0
>> qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_exit: reason MSR_READ rip
>> 0x11478 info 0 0
>> qemu-kvm-1.0.1-5107 [007] 410771.148000: kv
On 09/10/2012 03:29 PM, Peter Lieven wrote:
> On 09/10/12 14:21, Gleb Natapov wrote:
>> On Mon, Sep 10, 2012 at 02:15:49PM +0200, Paolo Bonzini wrote:
>>> Il 10/09/2012 13:52, Peter Lieven ha scritto:
> dd if=/dev/cpu/0/msr skip=$((0x194)) bs=8 count=1 | xxd
> dd if=/dev/cpu/0/msr skip=$((0
On 09/10/2012 12:26 PM, Jan Kiszka wrote:
>>
>> Is patch 4 the only one that is at v3, and the rest are to be taken from
>> the original posting?
>
> That is correct.
Thanks, applied to uq/master, will push shortly.
--
error compiling committee.c: too many arguments to function
On 09/10/2012 01:44 PM, Liu, Jinsong wrote:
> Hi,
>
> I'm recently debugging a qemu-kvm issue. I add some print code like
> 'fprintf(stderr, ...)', however I fail to see any info at stdio. Anyone can
> tell me where is qemu-kvm logfile, or, what I need do to record my fprintf
> info?
If you'r
Please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
to merge some kvm updates, most notably a port of qemu-kvm's pre-vfio device
assignment. With this there are no significant changes left between qemu and
qemu-kvm (though some work remains).
---
On 09/10/2012 06:49 PM, Marcelo Tosatti wrote:
> On Mon, Sep 10, 2012 at 05:32:39PM +0200, Jan Kiszka wrote:
>> On 2012-09-10 17:25, Avi Kivity wrote:
>> > Please pull from:
>> >
>> > git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
>> >
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> If out of global lock, we will be challenged by SMP in low level,
> so need atomic ops.
>
> This file is a wrapper of GCC atomic builtin.
>
> Signed-off-by: Liu Ping Fan
> ---
> include/qemu/atomic.h | 63
> ++
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> This pair of interface help to decide when dispatching, whether
> we can pin mr without big lock or not.
>
> --- a/memory.h
> +++ b/memory.h
> @@ -25,6 +25,7 @@
> #include "iorange.h"
> #include "ioport.h"
> #include "int128
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Without biglock, we try to protect the mr by increase refcnt.
> If we can inc refcnt, go backward and resort to biglock.
>
> Another point is memory radix-tree can be flushed by another
> thread, so we should get the copy of te
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> DeviceState will be protected by refcnt from disappearing during
> dispatching. But when refcnt comes down to zero, DeviceState may
> be still in use by iohandler, timer etc in main loop, we just delay
> its free untill no reade
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> The func call chain can suffer from recursively hold
> qemu_mutex_lock_iothread. We introduce lockmap to record the
> lock depth.
What is the root cause? io handlers initiating I/O?
Perhaps we can have a solution that is loca
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> With this, e1000 show to memory core that it can be protected by
> refcnt.
>
> diff --git a/hw/e1000.c b/hw/e1000.c
> index ae8a6c5..df3a349 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -1037,9 +1037,26 @@ e1000_mmio_read(
On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Without biglock, we try to protect the mr by increase refcnt.
> If we can inc refcnt, go backward and resort to biglock.
>
> Another point is memory radix-tree can be flushed by another
> thread, so we should get the copy of te
On 09/11/2012 02:03 AM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> Please pull from:
>>
>> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
>>
>> to merge some kvm updates, most notably a port of qemu-kvm's pre-vfio device
>>
On 09/04/2012 06:13 PM, Julien Grall wrote:
> This is the nineth version of patch series about ioport registration.
>
> Some part of QEMU still use register_ioport* functions to register ioport.
> These functions doesn't allow to use Memory Listener on it.
Thanks, applied all (w/ updated patch 4)
On 09/11/2012 12:15 PM, Avi Kivity wrote:
> On 09/04/2012 06:13 PM, Julien Grall wrote:
>> This is the nineth version of patch series about ioport registration.
>>
>> Some part of QEMU still use register_ioport* functions to register ioport.
>> These functions doesn
On 09/11/2012 12:32 PM, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 4:32 PM, Avi Kivity wrote:
>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> DeviceState will be protected by refcnt from disappearing during
>>> di
On 09/11/2012 12:44 PM, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> The func call chain can suffer from recursively hold
>>> qemu_mutex_lock
On 09/11/2012 01:04 PM, Jan Kiszka wrote:
>> DMA is inherently asynchronous, so we already drop the lock between
>> initiation and completion; we need to find a way to make it easy to use
>> the API without taking the lock while the transfer takes place.
>
> We will have to review/rework device m
On 09/11/2012 02:08 PM, Jan Kiszka wrote:
> On 2012-09-11 13:03, Avi Kivity wrote:
>> On 09/11/2012 01:04 PM, Jan Kiszka wrote:
>>
>>>> DMA is inherently asynchronous, so we already drop the lock between
>>>> initiation and completion; we need to find a
On 09/11/2012 12:57 PM, Jan Kiszka wrote:
> On 2012-09-11 11:44, liu ping fan wrote:
>> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>>>> From: Liu Ping Fan
>>>>
>>>>
On 09/11/2012 03:25 PM, Jan Kiszka wrote:
Most DMA today happens without the big qemu lock. We only need to
convert the paths that actually access memory, these are the block and
network layers (for the respective devices).
>>>
>>> ...and the devices themselves, of course.
>>
On 09/11/2012 03:35 PM, Jan Kiszka wrote:
> On 2012-09-11 14:30, Avi Kivity wrote:
>>>>>>> The other option is to keep DMA requests issued by devices synchronous
>>>>>>> but let them fail if we are about to lock up. Still requires changes,
>>&
On 09/11/2012 03:24 PM, Avi Kivity wrote:
> On 09/11/2012 12:57 PM, Jan Kiszka wrote:
>> On 2012-09-11 11:44, liu ping fan wrote:
>>> On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote:
>>>> On 09/11/2012 10:51 AM, Liu Ping Fan wrote:
>>>>> From: Liu
On 09/11/2012 02:57 PM, Jan Kiszka wrote:
> Only listen on debug ports when we also handle them. They are better
> handled by debugcon these days which is runtime configurable.
>
> Signed-off-by: Jan Kiszka
> ---
> hw/pc.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> d
On 09/10/2012 04:09 PM, Maciej W. Rozycki wrote:
>
>> > No, this is about the PIC, not the CPU interrupt inputs.
>>
>> I see, the interrupt is still sent to the processor; but IRR reflects
>> that status of the input line, not a "pending interrupt" status.
>
> Not really, this is still a "pendi
On 09/11/2012 12:05 PM, Jan Kiszka wrote:
> I think this is convincing, maybe worth documenting in the related
> changelogs of QEMU and KVM. Avi, doubts remaining?
>
Nope, I think I've understood it finally.
--
error compiling committee.c: too many arguments to function
On 09/11/2012 05:11 PM, Jan Kiszka wrote:
> On 2012-09-11 14:53, Avi Kivity wrote:
>> On 09/11/2012 02:57 PM, Jan Kiszka wrote:
>>
>>> Only listen on debug ports when we also handle them. They are better
>>> handled by debugcon these days which is runtime configu
On 09/12/2012 08:57 AM, Michael Tokarev wrote:
>>
>> This unbreaks isapc for TCG, and keep it working for KVM once it starts
>> supporting read-only memslots.
>
> Can you clarify please, -- referring to the above? :)
kvm only works due to a bug. Once the kvm bug is fixed, isapc will
break, unle
On 09/10/2012 04:29 AM, Matthew Ogilvie wrote:
> Intel's definition of "edge triggered" means: "asserted with a
> low-to-high transition at the time an interrupt is registered
> and then kept high until the interrupt is served via one of the
> EOI mechanisms or goes away unhandled."
>
> So the onl
On 09/12/2012 11:48 AM, Jan Kiszka wrote:
> On 2012-09-12 10:01, Avi Kivity wrote:
>> On 09/10/2012 04:29 AM, Matthew Ogilvie wrote:
>>> Intel's definition of "edge triggered" means: "asserted with a
>>> low-to-high transition at the time an interrupt
On 09/12/2012 11:57 AM, Jan Kiszka wrote:
> On 2012-09-12 10:51, Avi Kivity wrote:
>> On 09/12/2012 11:48 AM, Jan Kiszka wrote:
>>> On 2012-09-12 10:01, Avi Kivity wrote:
>>>> On 09/10/2012 04:29 AM, Matthew Ogilvie wrote:
>>>>> Intel's defi
On 09/11/2012 08:00 PM, Don Slutz wrote:
> Add LSI53C1030, SAS1068, SAS1068e. Based on code from "VirtualBox Open
> Source Edition".
> Based on QEMU MegaRAID SAS 8708EM2.
>
> This is a common VMware disk controller.
>
> SEABIOS change for booting is in the works.
>
> Tested with Fedora 16, 17.
On 09/12/2012 02:57 PM, Lei Li wrote:
> This RFC series attempts to convert the MemCharDriver to use a circular
> buffer for input and output, expose it to users by introducing QMP commands
> memchar_write and memchar_read and via the command line like the other
> CharDriverStates.
>
> Serial port
On 09/13/2012 09:54 AM, liu ping fan wrote:
>>> +typedef struct Atomic {
>>> +int counter;
>>> +} Atomic;
>>
>> Best to mark counter 'volatile'.
>>
>>> +
>>> +static inline void atomic_set(Atomic *v, int i)
>>> +{
>>> +v->counter = i;
>>> +}
>>> +
>>> +static inline int atomic_read(Atomic
On 09/13/2012 09:55 AM, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 8:41 PM, Avi Kivity wrote:
>> On 09/11/2012 03:24 PM, Avi Kivity wrote:
>>> On 09/11/2012 12:57 PM, Jan Kiszka wrote:
>>>> On 2012-09-11 11:44, liu ping fan wrote:
>>>>> On Tu
On 09/13/2012 11:19 AM, Paolo Bonzini wrote:
> Il 13/09/2012 10:14, Avi Kivity ha scritto:
>>>>> >>> +static inline void atomic_set(Atomic *v, int i)
>>>>> >>> +{
>>>>> >>> +v->counter =
On 09/13/2012 09:54 AM, liu ping fan wrote:
> On Tue, Sep 11, 2012 at 5:37 PM, Avi Kivity wrote:
>> On 09/11/2012 12:32 PM, liu ping fan wrote:
>>> On Tue, Sep 11, 2012 at 4:32 PM, Avi Kivity wrote:
>>>> On 09/11/2012 10:51 AM, Liu Ping Fan w
501 - 600 of 4803 matches
Mail list logo
