This imports and builds the original VAPIC option ROM of qemu-kvm.
Its interaction with QEMU is described in the commit that introduces the
corresponding device model.
Signed-off-by: Jan Kiszka
---
.gitignore |1 +
Makefile |2 +-
pc-bios/optionrom
-by: Jan Kiszka
---
Makefile.target|3 +-
hw/apic.c | 126 -
hw/apic_common.c | 64 -
hw/apic_internal.h | 27 ++
hw/kvm/apic.c | 32 ++
hw/kvmvapic.c | 805
6 files changed, 1043 insertions
CPUState::next_cpu is already CPUState *.
Signed-off-by: Jan Kiszka
---
cpus.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpus.c b/cpus.c
index d0c8340..4e65894 100644
--- a/cpus.c
+++ b/cpus.c
@@ -853,7 +853,7 @@ static int all_vcpus_paused(void
Use OPTION_ROM_START/END from the common header file, add comment to
init code.
Signed-off-by: Jan Kiszka
---
pc-bios/optionrom/kvmvapic.S | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/pc-bios/optionrom/kvmvapic.S b/pc-bios/optionrom/kvmvapic.S
index
expired timer to
achieve the same effect (suggested by Paolo Bonzini). This requires to
perform the alarm timer initialization earlier as otherwise timer
subsystem can be used before being ready.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- Move init_alarm_timer call to fix e.g. -monitor stdio
On 2012-10-08 20:52, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> On 2012-09-11 17:53, Jan Kiszka wrote:
>>> Our one and only BIOS depends on a writable shadowed BIOS in the ISA
>>> range. As we have no interface to control the write property, make that
On 2012-10-12 15:41, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> On 2012-10-08 20:52, Anthony Liguori wrote:
>>> Jan Kiszka writes:
>>>
>>>> On 2012-09-11 17:53, Jan Kiszka wrote:
>>>>> Our one and only BIOS depends on a wri
On 2012-10-16 18:02, Andreas Färber wrote:
> Am 12.10.2012 03:26, schrieb Andreas Färber:
>> This prepares for changing the variable type from void*.
>>
>> Signed-off-by: Andreas Färber
>> Cc: Igor Mammedov
>
> Paolo, are you happy with getting rid of the pointer property this way?
>
> Jan, are
We need to evaluate $libexecdir in configure, otherwise we literally end
up with "${prefix}/libexec" instead of the absolute path as
CONFIG_QEMU_HELPERDIR.
Signed-off-by: Jan Kiszka
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b
On 2012-10-17 20:25, Alex Williamson wrote:
> Rather than assert, simply return PCI_INTX_DISABLED when we don't
> have a pci_route_irq_fn. PIIX already returns DISABLED for an
> invalid pin, so users already deal with this state. Users of this
> interface should only be acting on an ENABLED or IN
On 2012-10-17 18:44, Paolo Bonzini wrote:
> Il 17/10/2012 18:37, Clemens Kolbitsch ha scritto:
>> Guys,
>>
>> I know this is question might seem a bit odd, but I'm curious:
>>
>> Has anyone ever tried to write code to disable KVM on the fly / is it
>> at all possible? I have a situation where I nee
ing (%s)\n",
> + object_get_typename(OBJECT(bus->qbus.parent)));
> +return (PCIINTxRoute) { PCI_INTX_DISABLED, -1 };
> +}
> +
> return bus->route_intx_to_irq(bus->irq_opaque, pin);
> }
>
>
I'm fine with this. I also see this as de
On 2012-10-17 22:14, Eduardo Habkost wrote:
> On Wed, Jul 15, 2009 at 01:43:31PM +0200, Gerd Hoffmann wrote:
> [...]
>> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
>> new file mode 100644
>> index 000..8b0d0ff
>> --- /dev/null
>> +++ b/hw/qdev-properties.c
>> @@ -0,0 +1,246 @@
>
>
On 2012-10-18 08:29, Paolo Bonzini wrote:
> Il 17/10/2012 20:37, Jan Kiszka ha scritto:
>> On 2012-10-17 18:44, Paolo Bonzini wrote:
>>> Il 17/10/2012 18:37, Clemens Kolbitsch ha scritto:
>>>> Guys,
>>>>
>>>> I know this is question might seem
On 2012-10-10 17:07, Peter Maydell wrote:
> From: Christoffer Dall
>
> Add basic support for KVM on ARM architecture.
>
> Signed-off-by: Christoffer Dall
> [PMM: Minor tweaks and code cleanup, switch to ONE_REG]
> Signed-off-by: Peter Maydell
> ---
> hw/arm_pic.c | 28
> ta
On 2012-10-22 11:23, Liu Ping Fan wrote:
> If mmio dispatch out of big lock, some function's calling context (ie,
> holding big lock or not) are different. We need to trace these info in
> runtime, and use tls to store them.
> By this method, we can avoid to require big lock recursive.
>
> Signed-
On 2012-10-22 12:31, Avi Kivity wrote:
> On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
>> Signed-off-by: Liu Ping Fan
>> ---
>> kvm-all.c |3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index b3fa597..3d7ae18 100644
>> --- a/kvm-all.c
>> +
On 2012-10-23 07:53, liu ping fan wrote:
> On Mon, Oct 22, 2012 at 6:30 PM, Avi Kivity wrote:
>> On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
>>> This can help memory core to use mr's fine lock to mmio dispatch.
>>>
>>> diff --git a/memory.c b/memory.c
>>> index d528d1f..86d5623 100644
>>> --- a/me
On 2012-10-22 11:23, Liu Ping Fan wrote:
> Use local lock to protect e1000. When calling the system function,
> dropping the fine lock before acquiring the big lock. This will
> introduce broken device state, which need extra effort to fix.
>
> Signed-off-by: Liu Ping Fan
> ---
> hw/e1000.c |
On 2012-10-23 07:52, liu ping fan wrote:
> On Mon, Oct 22, 2012 at 6:40 PM, Avi Kivity wrote:
>> On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
>>> The broken device state is caused by releasing local lock before acquiring
>>> big lock. To fix this issue, we have two choice:
>>> 1.use busy flag to
On 2012-10-23 13:50, Peter Maydell wrote:
> On 23 October 2012 12:48, Paolo Bonzini wrote:
>> Il 22/10/2012 19:13, Peter Maydell ha scritto:
> Can't we enhance qemu-tls.h to work via pthread_setspecific in case
> __thread is not working and use that abstraction (DECLARE/DEFINE_TLS)
> d
On 2012-10-23 13:55, Avi Kivity wrote:
> On 10/23/2012 01:51 PM, Paolo Bonzini wrote:
>> Il 22/10/2012 11:38, Avi Kivity ha scritto:
>
> typedef struct MemoryRegionOps MemoryRegionOps;
> typedef struct MemoryRegion MemoryRegion;
> @@ -66,6 +67,8 @@ struct MemoryRegionOps {
>
On 2012-10-22 11:23, Liu Ping Fan wrote:
> 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 terminal mr to survive
> from
On 2012-10-23 14:12, Paolo Bonzini wrote:
> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>>>>>
>>>>>> So the stop_machine idea is thrown away?
>>>>
>>>> IIRC I convinced myself that it's just as bad.
>> One tricky part wit
On 2012-10-23 14:28, Avi Kivity wrote:
> On 10/23/2012 02:16 PM, Jan Kiszka wrote:
>> On 2012-10-23 14:12, Paolo Bonzini wrote:
>>> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>>>>>>>
>>>>>>>> So the stop_machine idea is thrown a
On 2012-10-24 08:31, liu ping fan wrote:
> On Tue, Oct 23, 2012 at 5:04 PM, Jan Kiszka wrote:
>> On 2012-10-22 11:23, Liu Ping Fan wrote:
>>> Use local lock to protect e1000. When calling the system function,
>>> dropping the fine lock before acquiring the big lock. Thi
On 2012-10-25 11:01, Avi Kivity wrote:
> On 10/24/2012 09:17 AM, Jan Kiszka wrote:
>>>>
>>>> This is ugly for many reasons. First of all, it is racy as the register
>>>> content may change while dropping the device lock, no? Then you would
>>>>
On 2012-10-25 11:21, Xiao Guangrong wrote:
> let it not depend on __KVM_HAVE_READONLY_MEM to make it friendly
> to userspace
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/x86.c |2 ++
> include/linux/kvm.h |2 --
> virt/kvm/kvm_main.c |2 +-
> 3 files changed, 3 insertions(
On 2012-10-24 09:29, liu ping fan wrote:
> On Tue, Oct 23, 2012 at 5:04 PM, Jan Kiszka wrote:
>> On 2012-10-22 11:23, Liu Ping Fan wrote:
>>> Use local lock to protect e1000. When calling the system function,
>>> dropping the fine lock before acquiring the big lock. Thi
On 2012-10-25 18:21, Avi Kivity wrote:
> On 10/25/2012 11:31 AM, Jan Kiszka wrote:
>> On 2012-10-25 11:01, Avi Kivity wrote:
>>> On 10/24/2012 09:17 AM, Jan Kiszka wrote:
>>>>>>
>>>>>> This is ugly for many reasons. First of all, it is racy as
On 2012-10-25 18:23, Avi Kivity wrote:
> On 10/25/2012 03:34 PM, Jan Kiszka wrote:
>
>>>> Second, it clearly shows that we need to address lock-less IRQ delivery.
>>>> Almost nothing is won if we have to take the global lock again to push
>>>> an IRQ eve
On 2012-10-25 16:04, Peter Maydell wrote:
> On 22 October 2012 10:23, Liu Ping Fan wrote:
>> v1:
>> https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg03312.html
>>
>> v2:
>> http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01275.html
>>
>> v3:
>> http://lists.nongnu.org/archive/html/
On 2012-10-25 19:02, Avi Kivity wrote:
> On 10/25/2012 06:39 PM, Jan Kiszka wrote:
>>>
>>> That doesn't work cross-thread.
>>>
>>> vcpu A: write to device X, dma-ing to device Y
>>> vcpu B: write to device Y, dma-ing to device X
>>
>&g
On 2012-10-25 20:13, Marcelo Tosatti wrote:
> On Thu, Oct 25, 2012 at 06:13:51PM +0100, Peter Maydell wrote:
>> On 25 October 2012 18:07, Avi Kivity wrote:
>>> On 10/25/2012 04:04 PM, Peter Maydell wrote:
Is there a clear up to date description somewhere of the design and
locking strateg
>> On 10/23/2012 11:32 AM, liu ping fan wrote:
>>>>>> On Tue, Oct 23, 2012 at 5:07 PM, Jan Kiszka
>>>>>> wrote:
>>>>>>> On 2012-10-23 07:52, liu ping fan wrote:
>>>>>>>> On Mon, Oct 22, 2012 at 6:40 PM, Avi Kivity
On 2012-10-25 11:22, Xiao Guangrong wrote:
> In isapc, no i440x device exists in guest that means seabios can not
> make 0xc to 0x100 writable
>
> It works fine in current code since the guest can happily write readonly
> memory. In order to support readonly slot in Qemu, we do not make th
On 2012-10-29 08:09, Xiao Guangrong wrote:
> Jan,
>
> On 10/26/2012 06:35 PM, Jan Kiszka wrote:
>
>> This has two problems: We know it breaks at least Win 95 that overwrites
>> its F-segment during boot. And it applies changes to the shadowed area
>> (below 1 MB)
On 2012-10-28 13:26, Blue Swirl wrote:
> Signed-off-by: Blue Swirl
> ---
> slirp/misc.c | 14 --
> slirp/misc.h |1 -
> 2 files changed, 0 insertions(+), 15 deletions(-)
>
> diff --git a/slirp/misc.c b/slirp/misc.c
> index 0bee864..664532a 100644
> --- a/slirp/misc.c
> +++ b/sl
ch;
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 3aa62b2..092d4f1 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -1384,16 +1384,9 @@ static int kvm_get_mp_state(CPUX86State *env)
> static int kvm_get_apic(CPUX86State *env)
> {
> DeviceStat
On 2012-10-30 13:16, Paolo Bonzini wrote:
> Change the hard-coded references to kvm_get_apic_state and
> kvm_put_apic_state to methods in APICCommonClass. This makes it possible
> to reuse the methods in common code that cannot assume the presence
> of KVM.
The effect of patch 3 can be achieved u
On 2012-10-30 13:16, Paolo Bonzini wrote:
> The LAPIC is loaded separately from the rest of the VCPU state. Thus,
> when restoring the CPU the dummy post-reset state is passed to the
> in-kernel APIC.
>
> This can cause MSI injection to fail if attempted during the restore of
> another device, be
On 2012-10-30 13:16, Paolo Bonzini wrote:
> Similar to the APIC, add get/put methods that can be called from common
> IOAPIC code. Use them already for pre_save/post_load, since they are
> exact replacements.
Also here: I don't see a benefit and prefer the current style.
Jan
>
> Signed-off-by:
On 2012-10-30 15:16, Paolo Bonzini wrote:
> Il 30/10/2012 13:38, Avi Kivity ha scritto:
>> On 10/30/2012 02:16 PM, Paolo Bonzini wrote:
>>> The LAPIC is loaded separately from the rest of the VCPU state. Thus,
>>> when restoring the CPU the dummy post-reset state is passed to the
>>> in-kernel API
On 2012-10-30 17:47, Paolo Bonzini wrote:
> Il 30/10/2012 13:16, Paolo Bonzini ha scritto:
>> A simplified reproducer (that doesn't hang Linux,
>> but shows the message) is to start the VM without a backend for the
>> virtserialport, and to resume it with a backend, for example
>>
>> $ qemu-system-
On 2012-10-30 10:48, Peter Maydell wrote:
> Ping?
>
> (patchwork url http://patchwork.ozlabs.org/patch/193125/)
Should obviously go in soon.
Jan
>
> thanks
> -- PMM
>
> On 22 October 2012 13:54, Peter Maydell wrote:
>> Recent kernels have moved to keeping the userspace headers
>> in uapi/ su
On 2012-06-17 16:28, Anthony Liguori wrote:
> On 06/17/2012 03:34 AM, Michael S. Tsirkin wrote:
>> On Sun, Jun 17, 2012 at 06:26:33AM +, Ma, Stephen B. wrote:
>>>
>>> Michael,
>>>
>>> Thanks for the review. I added the unparent to the qdev_free.
>>>
>>>
>>> ---
>>> hw/qdev.c |1 +
>>> 1
On 2012-06-14 23:31, Michael S. Tsirkin wrote:
> On Thu, Jun 14, 2012 at 12:15:42PM -0600, Alex Williamson wrote:
>> v3:
>> - more patches, smaller diff, must be headed in the right direction
>> - macros for all hardcoded values in msix_init_exclusive_bar
>> - fold msix_add_config into msix_init
On 2012-06-18 02:32, Andreas Färber wrote:
> Am 18.06.2012 02:01, schrieb Anthony Liguori:
>> I think I understand enough of what's going on in these rules to ensure this
>> is
>> right. But I could certainly use a second or third opinion...
>>
>> Signed-off-by: Anthony Liguori
>> ---
>> v1 -> v
On 2012-06-18 09:19, Michael S. Tsirkin wrote:
> On Mon, Jun 18, 2012 at 09:06:01AM +0200, Jan Kiszka wrote:
>> On 2012-06-14 23:31, Michael S. Tsirkin wrote:
>>> On Thu, Jun 14, 2012 at 12:15:42PM -0600, Alex Williamson wrote:
>>>> v3:
>>>> - more pa
On 2012-06-18 11:57, Michael S. Tsirkin wrote:
> On Mon, Jun 18, 2012 at 11:23:41AM +0200, Jan Kiszka wrote:
>> On 2012-06-18 09:19, Michael S. Tsirkin wrote:
>>> On Mon, Jun 18, 2012 at 09:06:01AM +0200, Jan Kiszka wrote:
>>>> On 2012-06-14 23:31, Michael S. Tsirk
On 2012-06-18 14:47, Anthony Liguori wrote:
> On 06/18/2012 04:13 AM, Jan Kiszka wrote:
>> On 2012-06-18 02:32, Andreas Färber wrote:
>>> Am 18.06.2012 02:01, schrieb Anthony Liguori:
>>> This will work technically but I still feel this is wrong semantically.
>>&
On 2012-06-18 12:36, Jan Kiszka wrote:
>>>>> Could you publish your queue? I'd like to rebase my missing bits.
>>>>>
>>>>> Thanks,
>>>>> Ja
>>>>>
>>>>
>>>> Will do. FYI Anthony said on irc he
On 2012-06-20 14:59, Igor Mammedov wrote:
> Chain of exception handlers are currently unused feature, drop it
> for now to avoid moving prev_debug_excp_handler variable at global
> scope when moving tcg initialization into target-i386/cpu.c
>
> Later we probably could re-invent better interface fo
On 2012-06-21 08:46, Alexey Kardashevskiy wrote:
>
> Ok, another try. Is it any better now? :)
No - posted the old version accidentally?
Jan
>
>
> Normally QEMU expects the guest to initialize MSI/MSIX vectors.
> However on POWER the guest uses RTAS subsystem to configure MSI/MSIX and
> does
On 2012-06-21 09:18, Alexey Kardashevskiy wrote:
>
> agrhhh. sha1 of the patch changed after rebasing :)
>
>
>
> Added (msi|msix)_(set|get)_message() function for whoever might
> want to use them.
>
> Currently msi_notify()/msix_notify() write to these vectors to
> signal the guest about an in
On 2012-06-21 12:28, Alexey Kardashevskiy wrote:
> On 21/06/12 17:39, Jan Kiszka wrote:
>> On 2012-06-21 09:18, Alexey Kardashevskiy wrote:
>>>
>>> agrhhh. sha1 of the patch changed after rebasing :)
>>>
>>>
>>>
>>> Added (msi|msix)
On 2012-06-21 12:50, Alexey Kardashevskiy wrote:
> On 21/06/12 20:38, Jan Kiszka wrote:
>> On 2012-06-21 12:28, Alexey Kardashevskiy wrote:
>>> On 21/06/12 17:39, Jan Kiszka wrote:
>>>> On 2012-06-21 09:18, Alexey Kardashevskiy wrote:
>>>>>
>>&
On 2012-06-21 13:39, Alexey Kardashevskiy wrote:
> Added (msi|msix)_set_message() functions.
>
> Currently msi_notify()/msix_notify() write to these vectors to
> signal the guest about an interrupt so the correct values have to
> written there by the guest or QEMU.
>
> For example, POWER guest ne
On 2012-06-21 16:49, Liu Ping Fan wrote:
> In order to break the big lock, using per-cpu_lock in kvm_cpu_exec()
> to protect the race from other cpu's access to env->apic_state & related
> field in env.
> Also, we need to protect agaist run_on_cpu().
>
> Race condition can be like this:
> 1. vcpu
On 2012-06-21 16:49, Liu Ping Fan wrote:
> Nowadays, we use qemu_mutex_lock_iothread()/qemu_mutex_unlock_iothread() to
> protect the race to access the emulated dev launched by vcpu threads &
> iothread.
>
> But this lock is too big. We can break it down.
> These patches separate the CPUArchState
On 2012-06-22 08:44, Peter A. G. Crosthwaite wrote:
> The block layer assumes that it is the only user of coroutines -
> The qemu_in_coroutine() is used to determine if a function is in one of the
> block layers coroutines, which is flawed. I.E. If a client (e.g. a device or
> a machine model) of t
On 2012-06-22 12:24, liu ping fan wrote:
> On Thu, Jun 21, 2012 at 11:23 PM, Jan Kiszka wrote:
>> On 2012-06-21 16:49, Liu Ping Fan wrote:
>>> Nowadays, we use qemu_mutex_lock_iothread()/qemu_mutex_unlock_iothread() to
>>> protect the race to access the emulated d
Hi Gerd,
I'm getting
qemu/hw/usb/core.c:410: usb_packet_complete: Assertion
`((&ep->queue)->tqh_first) == p' failed.
with a passed-through USB headset (UHCI controller). This was with
current QEMU git head. Known issues? Anything I can do to debug it?
Jan
--
Siemens AG, Corporate Technology,
On 2012-06-22 22:11, Anthony Liguori wrote:
> On 06/22/2012 05:37 AM, Jan Kiszka wrote:
>> On 2012-06-22 12:24, liu ping fan wrote:
>>> On Thu, Jun 21, 2012 at 11:23 PM, Jan Kiszka
>>> wrote:
>>>> On 2012-06-21 16:49, Liu Ping Fan wrote:
>>>&g
On 2012-06-22 23:44, Anthony Liguori wrote:
> On 06/22/2012 04:14 PM, Jan Kiszka wrote:
>> On 2012-06-22 22:11, Anthony Liguori wrote:
>>> On 06/22/2012 05:37 AM, Jan Kiszka wrote:
>>>> On 2012-06-22 12:24, liu ping fan wrote:
>>>>> On Thu, Jun
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode. On x86, the the in-kernel irqchips has to be used because
we otherwise need to synchronize APIC and other per-cpu state accesses
that could be changed concurrently. Not yet fully analyzed is the NMI
injection path
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
> This sketches a possible path to get rid of the iothread lock on vmexits
> in KVM mode. On x86, the the in-kernel irqchips has to be used because
> we otherwise need to synchr
On 2012-06-23 00:56, Anthony Liguori wrote:
> On 06/22/2012 05:27 PM, Jan Kiszka wrote:
>> On 2012-06-22 23:44, Anthony Liguori wrote:
>>> 1) unlock iothread before entering the do {} look in kvm_cpu_exec()
>>> a) reacquire the lock after the loop
>>> b)
On 2012-06-23 00:59, Anthony Liguori wrote:
> On 06/22/2012 05:45 PM, Jan Kiszka wrote:
>> This sketches a possible path to get rid of the iothread lock on vmexits
>> in KVM mode. On x86, the the in-kernel irqchips has to be used because
>> we otherwise need to synchronize A
On 2012-06-23 02:22, Marcelo Tosatti wrote:
> On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
>> Should have declared this [RFC] in the subject and CC'ed kvm...
>>
>> On 2012-06-23 00:45, Jan Kiszka wrote:
>>> This sketches a possible path to get
Hi all,
just stumbled over the memory_region_set_coalescing in pci_i82378_init:
What ISA devices are affected by this? It looks a bit strange to me as
the MMIO requests are apparently mapped on PIO requests, and we don't
have PIO coalescing on x86. Depending on the target device on PREP, this
may
On 2012-06-23 11:29, Erik Rull wrote:
> Jan Kiszka wrote:
>> Hi Gerd,
>>
>> I'm getting
>>
>> qemu/hw/usb/core.c:410: usb_packet_complete: Assertion
>> `((&ep->queue)->tqh_first) == p' failed.
>>
>> with a passed-through USB h
On 2012-06-23 11:06, Marcelo Tosatti wrote:
> On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
>> On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
>>> Should have declared this [RFC] in the subject and CC'ed kvm...
>>>
>>> On 2012
On 2012-06-23 14:46, Andreas Färber wrote:
> Hi Jan,
>
> Am 23.06.2012 11:28, schrieb Jan Kiszka:
>> just stumbled over the memory_region_set_coalescing in pci_i82378_init:
>> What ISA devices are affected by this? It looks a bit strange to me as
>> the MMIO requests a
On 2012-06-24 10:49, Avi Kivity wrote:
> On 06/23/2012 02:45 PM, Jan Kiszka wrote:
>>
>> Hmm, we may need the iothread lock around cpu_set_apic_tpr for
>> !kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
>> can be but there as well.
>>
>&
On 2012-06-24 15:34, liu ping fan wrote:
> On Sat, Jun 23, 2012 at 7:45 PM, Jan Kiszka wrote:
>> On 2012-06-23 11:06, Marcelo Tosatti wrote:
>>> On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
>>>> On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan K
On 2012-06-24 16:35, Avi Kivity wrote:
> On 06/24/2012 05:08 PM, Jan Kiszka wrote:
>> As a first step, I will post a series later that gets rid of
>> kvm_flush_coalesced_mmio_buffer in the common vmexit path.
>
> If you defer this, I can think of two places that need to flu
On 2012-06-24 16:46, Avi Kivity wrote:
> On 06/24/2012 05:40 PM, Jan Kiszka wrote:
>> On 2012-06-24 16:35, Avi Kivity wrote:
>>> On 06/24/2012 05:08 PM, Jan Kiszka wrote:
>>>> As a first step, I will post a series later that gets rid of
>>>> kvm_flush_
On 2012-06-24 16:56, Avi Kivity wrote:
> On 06/24/2012 05:51 PM, Jan Kiszka wrote:
>> On 2012-06-24 16:46, Avi Kivity wrote:
>>> On 06/24/2012 05:40 PM, Jan Kiszka wrote:
>>>> On 2012-06-24 16:35, Avi Kivity wrote:
>>>>> On 06/24/2012 05:08 PM, Jan Kisz
are not yet fully converted.
Another reason to flush are remappings or other relevant region state
changes.
Please review carefully.
CC: Andreas Färber
CC: Hervé Poussineau
Jan Kiszka (5):
i82378: Remove bogus MMIO coalescing
memory: Flush coalesced MMIO on selected region access
memory
In preparation of stopping to flush coalesced MMIO unconditionally on
vmexits, mark VGA MMIO and PIO regions as synchronous /wrt coalesced
MMIO and flush the buffer explicitly on PIO accesses that do not use
generic memory regions yet.
Signed-off-by: Jan Kiszka
---
hw/cirrus_vga.c |7
, by calling memory_region_set_flush_coalesced.
Signed-off-by: Jan Kiszka
---
memory.c | 13 +
memory.h | 13 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
index aab4a31..ba55b3e 100644
--- a/memory.c
+++ b/memory.c
@@ -311,6
The memory subsystem will now take care of flushing whenever affected
regions are accessed or the memory mapping changes.
Signed-off-by: Jan Kiszka
---
kvm-all.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index f8e4328..a1d32f6 100644
--- a
: Hervé Poussineau
Signed-off-by: Jan Kiszka
---
hw/i82378.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/i82378.c b/hw/i82378.c
index 9b11d90..2123c14 100644
--- a/hw/i82378.c
+++ b/hw/i82378.c
@@ -225,7 +225,6 @@ static int pci_i82378_init(PCIDevice *dev
Flush pending coalesced MMIO before performing mapping or state changes
that could affect the event orderings or route the buffered requests to
a wrong region.
Signed-off-by: Jan Kiszka
In addition, we also have to
---
memory.c | 23 +++
1 files changed, 23 insertions
On 2012-06-25 10:57, Avi Kivity wrote:
> On 06/25/2012 10:01 AM, Jan Kiszka wrote:
>> Flush pending coalesced MMIO before performing mapping or state changes
>> that could affect the event orderings or route the buffered requests to
>> a wrong region.
>>
>> Si
On 2012-06-25 12:15, Jan Kiszka wrote:
> On 2012-06-25 10:57, Avi Kivity wrote:
>> The repetitiveness of this code suggests a different way of doing this:
>> make every API call be its own subtransaction and perform the flush in
>> memory_region_begin_transaction() (maybe th
On 2012-06-25 13:01, Avi Kivity wrote:
> On 06/25/2012 01:26 PM, Jan Kiszka wrote:
>> On 2012-06-25 12:15, Jan Kiszka wrote:
>>> On 2012-06-25 10:57, Avi Kivity wrote:
>>>> The repetitiveness of this code suggests a different way of doing this:
>>>> mak
On 2012-06-25 15:38, Alex Williamson wrote:
> On Mon, 2012-05-14 at 18:07 -0300, Jan Kiszka wrote:
>> Add a service that establishes a static route from a virtual IRQ line to
>> an MSI message. Will be used for IRQFD and device assignment. As we will
>> use this service
On 2012-06-25 18:55, Luiz Capitulino wrote:
> Allow for disabling memory merge support (KSM on Linux), which is
> enabled by default otherwise.
-machine mem_merge=on|off?
Jan
>
> Signed-off-by: Luiz Capitulino
> ---
> cpu-all.h | 1 +
> exec-obsolete.h | 1 +
> exec.c | 25 ++
m_irqchip_add_msi_route(KVMState *s, MSIMessage msg)
> {
> -abort();
> +return -ENOSYS;
> }
>
> static int kvm_irqchip_assign_irqfd(KVMState *s, int fd, int virq, bool
> assign)
>
Acked-by: Jan Kiszka
signature.asc
Description: OpenPGP digital signature
On 2012-06-26 00:02, Anthony Liguori wrote:
> On 06/25/2012 03:26 PM, Jan Kiszka wrote:
>> On 2012-06-25 18:55, Luiz Capitulino wrote:
>>> Allow for disabling memory merge support (KSM on Linux), which is
>>> enabled by default otherwise.
>>
>> -machine m
On 2012-06-26 09:47, Avi Kivity wrote:
> On 06/25/2012 11:26 PM, Jan Kiszka wrote:
>> On 2012-06-25 18:55, Luiz Capitulino wrote:
>>> Allow for disabling memory merge support (KSM on Linux), which is
>>> enabled by default otherwise.
>>
>> -machine mem_merge
On 2012-06-26 21:34, Marcelo Tosatti wrote:
> The following plan would allow progressive convertion to parallel
> operation.
>
> Jan mentioned the MMIO handler->MMIO handler deadlock in a private message.
>
> Jan: if there is recursive MMIO accesses, you can detect that and skip
> such MMIO handl
On 2012-06-27 09:02, Wen Congyang wrote:
> When the guest is panicked, it will write 0x1 to the port KVM_PV_PORT.
> So if qemu reads 0x1 from this port, we can do the folloing three
> things according to the parameter -onpanic:
> 1. emit QEVENT_GUEST_PANICKED only
> 2. emit QEVENT_GUEST_PANICKED an
VGA PIO accesses that are not yet fully converted.
Another reason to flush are remappings or other relevant region state
changes.
Jan Kiszka (7):
i82378: Remove bogus MMIO coalescing
memory: Flush coalesced MMIO on selected region access
memory: Use transaction_begin/commit also for single-step
Signed-off-by: Jan Kiszka
---
hw/i82378.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/i82378.c b/hw/i82378.c
index 9b11d90..2123c14 100644
--- a/hw/i82378.c
+++ b/hw/i82378.c
@@ -225,7 +225,6 @@ static int pci_i82378_init(PCIDevice *dev)
pci_register_bar(dev
, by calling memory_region_set_flush_coalesced.
Signed-off-by: Jan Kiszka
---
memory.c | 21 +
memory.h | 24
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
index aab4a31..c29a8a3 100644
--- a/memory.c
+++ b
In preparation of stopping to flush coalesced MMIO unconditionally on
vmexits, mark VGA MMIO and PIO regions as synchronous /wrt coalesced
MMIO and flush the buffer explicitly on PIO accesses that do not use
generic memory regions yet.
Signed-off-by: Jan Kiszka
---
hw/cirrus_vga.c |7
Flush pending coalesced MMIO before performing mapping or state changes
that could affect the event orderings or route the buffered requests to
a wrong region.
Signed-off-by: Jan Kiszka
---
memory.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
401 - 500 of 5428 matches
Mail list logo
