On Sun, Oct 16, 2011 at 10:57 PM, Sasha Levin levinsasha...@gmail.com wrote:
@@ -47,6 +47,7 @@ void kvm_debug_help(void)
static int do_debug(const char *name, int sock)
{
+ char buff[100];
struct debug_cmd cmd = {KVM_IPC_DEBUG, 0};
int r;
@@ -54,6 +55,14 @@ static
Hi Joerg,
On Fri, Oct 14, 2011 at 7:03 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Fri, Oct 14, 2011 at 3:35 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Hmm, I'd like to constify the iommu_ops structures in the future. This
wouldn't work then anymore. How about renaming it to io_page_size
On 10/16/2011 05:39 PM, Avi Kivity wrote:
On 10/14/2011 11:03 AM, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
With the following series of patches we are starting to implement
some basic Microsoft Hyper-V Enlightenment functionality. This series
is mostly about adding support for relaxed timing, spinlock,
and virtual apic.
For more Hyper-V related information please see:
Hypervisor Functional
---
target-i386/kvm.c | 64 +++-
1 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 3840255..30b3e85 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -29,6 +29,7 @@
#include
with the following series of patches we are starting to implement
some basic Microsoft Hyper-V Enlightenment functionality, like relaxed
timing, spinlock, and virtual apic support.
For more Hyper-V related information please see:
Hypervisor Functional Specification v2.0: For Windows Server 2008
Am 17.10.2011 11:17, schrieb Vadim Rozenfeld:
with the following series of patches we are starting to implement
some basic Microsoft Hyper-V Enlightenment functionality, like relaxed
timing, spinlock, and virtual apic support.
For more Hyper-V related information please see:
Hypervisor
Terminate msi/msix_write_config early if support is not enabled. This
allows to remove checks at the caller site if MSI is optional.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msi.c |3 ++-
hw/msix.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Replace some open-coded msi/msix_present checks and drop redundant
msix_supported tests (present implies supported).
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msi.c |2 +-
hw/msix.c | 20
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git
There are no routes to clear at this point, we are just creating the VM.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-kvm-x86.c |1 -
qemu-kvm.c | 10 --
qemu-kvm.h |9 -
3 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/qemu-kvm-x86.c
Start benefiting from the new abstractions and drop the KVM-specific
vector tracking to generic MSIMessage and MSIRoutingCache data
structures and helpers, also reducing the diff to upstream.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msi.c| 49
Implement MSI support of a assigned devices via the generic MSI layer of
QEMU. Use config notifiers to update the vector route or switch back to
INTx when MSI gets disabled again.
Using the generic layer not only saves a bit code, it also fixes reset
while legacy MSI is in use and adds 64 bit
Realize support for MSI config notifiers analogously to MSI-X. The logic
is slightly more complex for legacy MSI as per-vector masking is option
here. Device assignment will be the first user.
Note that this change does not introduce per-vector masking support.
This can to be added at some later
Also this functions is better invoked by the core than by each and every
device. This allows to drop the config_write callbacks from ich and
intel-hda.
CC: Alexander Graf ag...@suse.de
CC: Gerd Hoffmann kra...@redhat.com
CC: Isaku Yamahata yamah...@valinux.co.jp
Signed-off-by: Jan Kiszka
There is no point in pushing this burden to the devices, they may rather
forget to call them (like intel-hda and ahci ATM). Instead, reset
functions are now called from pci_device_reset and pci_bridge_reset.
They do nothing if the MSI/MSI-X is not in use.
CC: Alexander Graf ag...@suse.de
CC: Gerd
As previously indicated, I was working for quite a while on a major
refactoring of the MSI additions we have in qemu-kvm to support
in-kernel irqchip, vhost and device assignment. This is now the outcome.
I'm quite happy with it, things are still working (apparently), and the
invasiveness of KVM
No use for it, even more after the upcoming API changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c |8
hw/msix.h |2 --
hw/pci.h |2 --
3 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 5f0fa6a..bccd8b1 100644
Switch MSI-X support of the device assignment core to the generic layer
QEMU offers. As for legacy MSI, we use config notifiers to update IRQ
assignment and routes on guest changes. Quite a bit code becomes
obsolete in the device assigment core, e.g. the maintenance of the MSI-X
vector masking
- rename to assigned_dev_set_msix_vectors
- drop unused msg_ctrl
- use pci_get_* accessors
- rename variable va to msix_page
- clarify comment on msg_data == 0 optimization
- fix coding style
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c | 53
msix_add_config is called from msix_init which only supports init-once.
Moreover, msix_add_config performed no check if the provided parameters
were compatible with the existing capability entry, so was inconsistent
anyway.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c | 72
Also remove the dead get_assigned_device at this chance. No functional
changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c | 199
hw/device-assignment.h | 14 ++--
2 files changed, 107 insertions(+), 106
This helper will also be used by the upcoming config notifier.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 04e08e5..50fa504 100644
--- a/hw/msix.c
+++
This enables fully configurable MSI-X initialization by taking config
space offset, independent table and PBA BARs and the offset inside them
on msix_init. Table and PBA are now realized as two memory subregions,
either of the passed BAR regions or the single page container
msix_init_simple
Create kvm_device_msix_{supported,init_vectors,set_vector,assign},
replacing the old kvm_assign_set_msix_{nr,entry} services. The new API
no longer requires direct fiddling with the KVM API data structures and
just takes the required parameters. kvm_device_msix_set_vector also
combines MSI route
This cache will help us implementing KVM in-kernel irqchip support
without spreading hooks all over the place.
KVM requires us to register it first and then deliver it by raising a
pseudo IRQ line returned on registration. While this could be changed
for QEMU-originated MSI messages by adding
Hi Ohad,
On Mon, Oct 17, 2011 at 04:05:02AM -0400, Ohad Ben-Cohen wrote:
This whole thing is quite marginal though and also very easy to change
later, so we can start with the driver-provided io_page_size
approach for now.
Sorry, I just couldn't get myself to sign-off this as it really
Will be used for generating and distributing MSI messages, both in
emulation mode and under KVM.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msi.h |5 +
qemu-common.h |1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/msi.h b/hw/msi.h
index
Updating the MSI message registration on kvm_msi_irqfd_set will allow us
to switch to a lazy mode and remove the need to track message changes in
the device config space.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/virtio-pci.c | 10 ++
kvm.h |3 ++-
If MSI-X is disabled or the global mask is set, don't fire the notifier
during registration or removal, reporting a wrong state.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/msix.c
Devices models are usually not interested in specifying MSI-X
configuration details beyond the number of vectors to provide and the
BAR number to use. Layout of an exclusively used BAR and its
registration can also be handled centrally.
This is the purpose of msix_init_simple. It provides handy
This optimization was only required to keep KVM route usage low. Now
that we solve that problem via lazy updates, we can drop the field. We
still need interfaces to clear pending vectors, though (and we have to
make use of them more broadly - but that's unrelated to this patch).
Signed-off-by:
Drop unused functions, privatize those which are only used internally now.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-stub.c | 10 --
kvm.h |1 -
qemu-kvm.c | 37 ++---
qemu-kvm.h | 39 ---
4
Don't pass kvm_assigned_irq struct, rather use the actually required
fields in the interface.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c | 42 --
qemu-kvm.c | 15 ++-
qemu-kvm.h |
This reuses the MSI routing infrastructure of the KVM core by folding
both the routing setup and the IRQ assignment into a new function called
kvm_device_msi_assign. It's also a good chance to clean up the IRQ
deassignment before updates.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Allows to drop checking for out-of-memory.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-kvm.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 6bdd7b5..eb8f176 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -258,7 +258,6 @@
Instead of registering every possible MSI message that is prepared in
some device's config space, this commit only registers those messages
that are actually sent.
Every message that runs through the delivery hook is first checked
against its cached data. If there is a mismatch, then the
Avoid passing kvm_assigned_irq on INTx assignment and separate this
function from (to-be-refactored) MSI/MSI-X assignment.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c | 21 ++---
qemu-kvm.c | 17 +
qemu-kvm.h
Will have more users soon.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c | 30 ++
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index e0b9cfe..e5ac54c 100644
---
real_device.irq is never set explicitly, thus remains 0. So we can
simply drop this line as assigned_irq_data is zero-initialized anyway.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
Keep a link from the internal KVM routing table to potential MSI routing
cache entries. The link is used so far whenever the entry is dropped to
invalidate the cache content. It will allow us to build MSI routing
entries on demand and flush existing ones on table overflow.
Signed-off-by: Jan
Also invoke the mask notifier if the global MSI-X mask is modified. For
this purpose, we push the notifier call from the per-vector mask update
to the central msix_handle_mask_update.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c | 16 +---
1 files changed, 9
Reorganize msix_mmio_writel so that msix_handle_mask_update is only
called on mask changes. Pass previous config space value to
msix_write_config so that is can check if a mask change took place.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c | 36
The previous name may incorrectly suggest that this function assigns all
types of IRQs though it's only dealing with legacy interrupts.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git
MSI config notifiers are supposed to be triggered on every relevant
configuration change of MSI vectors or if MSI is enabled/disabled.
Two notifiers are established, one for vector changes and one for general
enabling. The former notifier additionally passes the currently active
MSI message. This
So far we deliver MSI messages by writing them into the target MMIO
area. This reflects what happens on hardware, but imposes some
limitations on the emulation when introducing KVM in-kernel irqchip
models. For those we will need to track the message origin. Moreover,
different architecture or
kvm_add_irq_route only exists to create platform specific static routes.
So there is no need for a corresponding delete.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-kvm.c | 16
qemu-kvm.h |8
2 files changed, 0 insertions(+), 24 deletions(-)
diff
Move the two hooks for MSI delivery to in-kernel irqchips from the MSI
layer to a single place: the APIC.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c | 24 +++-
hw/msi.c |5 -
hw/msix.c |5 -
3 files changed, 15 insertions(+), 19
As long as MSI-X is disabled, it's incorrect to invoke
msix_handle_mask_update on per-vector mask changes. That may misguide
the config notifier callback or spuriously trigger an MSI event.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c |2 +-
1 files changed, 1
This helper will also be used by the upcoming config notifier.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msi.c | 43 +--
1 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/hw/msi.c b/hw/msi.c
index 2b7b6e3..3c7ebc3 100644
---
Rename msix_supported to msi_supported and control MSI and MSI-X
activation this way. That was likely to original intention for this
flag, but MSI support came after MSI-X.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msi.c |8
hw/msi.h |2 ++
hw/msix.c |8
Avoid the slow-path MSI delivery via stl_phys by switching to
msi_deliver. This also allows to prepare these rarely changing messages
in advance.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git
This makes the KVM core layer aware of the irqfd associated with some
MSI cache. kvm_msi_irqfd_set is defined for this purpose, which avoids
that virtio needs to peek into the cache for extracting the GSI.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/virtio-pci.c |6 +++---
kvm.h
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/msi.c b/hw/msi.c
index bbc9cd7..5db 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -288,6 +288,9 @@ void msi_reset(PCIDevice *dev)
uint16_t flags;
Only accesses to the MSI-X table must trigger a call to
msix_handle_mask_update or a notifier invocation.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/msix.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index
On 2011-10-17 11:17, Vadim Rozenfeld wrote:
with the following series of patches we are starting to implement
some basic Microsoft Hyper-V Enlightenment functionality, like relaxed
timing, spinlock, and virtual apic support.
For more Hyper-V related information please see:
Hypervisor
On 10/16/2011 05:39 PM, Avi Kivity wrote:
On 10/14/2011 11:03 AM, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
On 10/17/2011 11:17 AM, Vadim Rozenfeld wrote:
@@ -379,11 +380,16 @@ int kvm_arch_init_vcpu(CPUState *env)
cpuid_i = 0;
/* Paravirtualization CPUIDs */
-memcpy(signature, KVMKVMKVM\0\0\0, 12);
c =cpuid_data.entries[cpuid_i++];
memset(c, 0, sizeof(*c));
On 10/17/2011 11:40 AM, Lai Jiangshan wrote:
LINT1 may have been programmed as a level -triggered interrupt instead
of edge triggered (NMI or interrupt). We can use the ioctl argument for
the level (and pressing the NMI button needs to pulse the level to 1 and
back to 0).
Hi,
On 10/17/2011 11:17 AM, Lai Jiangshan wrote:
On 10/16/2011 05:39 PM, Avi Kivity wrote:
On 10/14/2011 11:03 AM, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button
On Mon, Oct 17, 2011 at 11:28 AM, Roedel, Joerg joerg.roe...@amd.com wrote:
The patch looks good now. Please implement option a) and it should be
fine.
Ok, will send in a few moments.
I will test it on an AMD IOMMU platform. We still need someone to
test it on VT-d.
That could be great,
On 10/17/2011 08:10 AM, Jorge Lucangeli Obes wrote:
What do top/vmstat/kvm_stat say?
I'm attaching the output of the three commands during a test run
launched form inside the chroot, which was slow as usual. I didn't see
anything too weird on top/vmstat, though I found it odd that once the
Am 26.09.2011 10:01, schrieb Zhi Yong Wu:
On Fri, Sep 23, 2011 at 11:32 PM, Kevin Wolf kw...@redhat.com wrote:
Am 08.09.2011 12:11, schrieb Zhi Yong Wu:
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
Makefile.objs |2 +-
block/blk-queue.c | 201
Am 26.09.2011 08:15, schrieb Zhi Yong Wu:
On Fri, Sep 23, 2011 at 11:54 PM, Kevin Wolf kw...@redhat.com wrote:
+}
+
+static void bdrv_block_timer(void *opaque)
+{
+BlockDriverState *bs = opaque;
+BlockQueue *queue= bs-block_queue;
+
+qemu_block_queue_flush(queue);
Hm,
On 10/17/2011 12:17 PM, Kevin Wolf wrote:
+
+static int qemu_block_queue_handler(BlockQueueAIOCB *request)
+{
+int ret;
+BlockDriverAIOCB *res;
+
+res = request-handler(request-common.bs, request-sector_num,
+ request-qiov,
On 2011-10-17 11:54, Avi Kivity wrote:
On 10/17/2011 11:17 AM, Lai Jiangshan wrote:
On 10/16/2011 05:39 PM, Avi Kivity wrote:
On 10/14/2011 11:03 AM, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate
Am 26.09.2011 09:24, schrieb Zhi Yong Wu:
On Sat, Sep 24, 2011 at 12:19 AM, Kevin Wolf kw...@redhat.com wrote:
Am 08.09.2011 12:11, schrieb Zhi Yong Wu:
Note:
1.) When bps/iops limits are specified to a small value such as 511
bytes/s, this VM will hang up. We are considering how to
On 10/17/2011 11:40 AM, Paolo Bonzini wrote:
On 10/17/2011 11:17 AM, Vadim Rozenfeld wrote:
@@ -379,11 +380,16 @@ int kvm_arch_init_vcpu(CPUState *env)
cpuid_i = 0;
/* Paravirtualization CPUIDs */
-memcpy(signature, KVMKVMKVM\0\0\0, 12);
c
On 10/17/2011 12:41 PM, Avi Kivity wrote:
Even not counting that hyper-v support should IMHO not be in
KVM-specific code, I still think this shouldn't remove KVM leaves
completely but rather move them to 0x4100. The KVM
paravirtualization code then can similarly probe with 0x100
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
So far we deliver MSI messages by writing them into the target MMIO
area. This reflects what happens on hardware, but imposes some
limitations on the emulation when introducing KVM in-kernel irqchip
models. For those we will need to track the message
On Sun, Oct 16, 2011 at 03:12:23PM +0200, Michael S. Tsirkin wrote:
On Thu, Oct 13, 2011 at 11:54:50AM -0300, Marcelo Tosatti wrote:
On Tue, Oct 11, 2011 at 08:38:28PM +0200, Michael S. Tsirkin wrote:
To forward an interrupt to a vcpu that runs on
a host cpu different from the current
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
This cache will help us implementing KVM in-kernel irqchip support
without spreading hooks all over the place.
KVM requires us to register it first and then deliver it by raising a
pseudo IRQ line returned on registration. While this could be changed
On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote:
Only accesses to the MSI-X table must trigger a call to
msix_handle_mask_update or a notifier invocation.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Why would msix_mmio_write be called on an access
outside the table?
---
On Sun, Oct 16, 2011 at 03:12:23PM +0200, Michael S. Tsirkin wrote:
On Thu, Oct 13, 2011 at 11:54:50AM -0300, Marcelo Tosatti wrote:
On Tue, Oct 11, 2011 at 08:38:28PM +0200, Michael S. Tsirkin wrote:
To forward an interrupt to a vcpu that runs on
a host cpu different from the current
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
Keep a link from the internal KVM routing table to potential MSI routing
cache entries. The link is used so far whenever the entry is dropped to
invalidate the cache content. It will allow us to build MSI routing
entries on demand and flush existing
On 2011-10-17 12:56, Avi Kivity wrote:
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
So far we deliver MSI messages by writing them into the target MMIO
area. This reflects what happens on hardware, but imposes some
limitations on the emulation when introducing KVM in-kernel irqchip
models. For
On 2011-10-17 13:06, Avi Kivity wrote:
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
This cache will help us implementing KVM in-kernel irqchip support
without spreading hooks all over the place.
KVM requires us to register it first and then deliver it by raising a
pseudo IRQ line returned on
On Mon, Oct 17, 2011 at 11:28:16AM +0200, Jan Kiszka wrote:
Devices models are usually not interested in specifying MSI-X
configuration details beyond the number of vectors to provide and the
BAR number to use. Layout of an exclusively used BAR and its
registration can also be handled
On 10/17/2011 01:15 PM, Jan Kiszka wrote:
On 2011-10-17 12:56, Avi Kivity wrote:
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
So far we deliver MSI messages by writing them into the target MMIO
area. This reflects what happens on hardware, but imposes some
limitations on the emulation when
On 2011-10-17 13:10, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote:
Only accesses to the MSI-X table must trigger a call to
msix_handle_mask_update or a notifier invocation.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Why would msix_mmio_write be
On 10/17/2011 01:19 PM, Jan Kiszka wrote:
IMO this needlessly leaks kvm information into core qemu. The cache
should be completely hidden in kvm code.
I think msi_deliver() can hide the use of the cache completely. For
pre-registered events like kvm's irqfd, you can use something like
On 2011-10-17 13:13, Avi Kivity wrote:
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
Keep a link from the internal KVM routing table to potential MSI routing
cache entries. The link is used so far whenever the entry is dropped to
invalidate the cache content. It will allow us to build MSI routing
On 2011-10-17 13:22, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:28:16AM +0200, Jan Kiszka wrote:
Devices models are usually not interested in specifying MSI-X
configuration details beyond the number of vectors to provide and the
BAR number to use. Layout of an exclusively used BAR
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to
On 2011-10-17 13:22, Avi Kivity wrote:
On 10/17/2011 01:15 PM, Jan Kiszka wrote:
On 2011-10-17 12:56, Avi Kivity wrote:
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
So far we deliver MSI messages by writing them into the target MMIO
area. This reflects what happens on hardware, but imposes some
On 2011-10-17 13:25, Avi Kivity wrote:
On 10/17/2011 01:19 PM, Jan Kiszka wrote:
IMO this needlessly leaks kvm information into core qemu. The cache
should be completely hidden in kvm code.
I think msi_deliver() can hide the use of the cache completely. For
pre-registered events like kvm's
On Mon, Oct 17, 2011 at 11:27:57AM +0200, Jan Kiszka wrote:
MSI config notifiers are supposed to be triggered on every relevant
configuration change of MSI vectors or if MSI is enabled/disabled.
Two notifiers are established, one for vector changes and one for general
enabling. The former
On 2011-10-17 13:40, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:57AM +0200, Jan Kiszka wrote:
MSI config notifiers are supposed to be triggered on every relevant
configuration change of MSI vectors or if MSI is enabled/disabled.
Two notifiers are established, one for vector
On Mon, Oct 17, 2011 at 11:27:42AM +0200, Jan Kiszka wrote:
Will be used for generating and distributing MSI messages, both in
emulation mode and under KVM.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
I would add
uint64_t msix_get_address(dev, vector)
uint64_t msix_get_data(dev,
On 2011-10-17 13:46, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:42AM +0200, Jan Kiszka wrote:
Will be used for generating and distributing MSI messages, both in
emulation mode and under KVM.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
I would add
uint64_t
On Mon, Oct 17, 2011 at 01:23:46PM +0200, Jan Kiszka wrote:
On 2011-10-17 13:10, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote:
Only accesses to the MSI-X table must trigger a call to
msix_handle_mask_update or a notifier invocation.
Signed-off-by:
On Mon, Oct 17, 2011 at 01:51:00PM +0200, Jan Kiszka wrote:
On 2011-10-17 13:46, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:42AM +0200, Jan Kiszka wrote:
Will be used for generating and distributing MSI messages, both in
emulation mode and under KVM.
Signed-off-by: Jan
On 2011-10-17 13:57, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 01:23:46PM +0200, Jan Kiszka wrote:
On 2011-10-17 13:10, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote:
Only accesses to the MSI-X table must trigger a call to
msix_handle_mask_update
On 2011-10-17 14:04, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 01:51:00PM +0200, Jan Kiszka wrote:
On 2011-10-17 13:46, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:42AM +0200, Jan Kiszka wrote:
Will be used for generating and distributing MSI messages, both in
emulation
On 10/17/2011 01:29 PM, Jan Kiszka wrote:
APIC is x86-specific, MSI is not. I think Xen will also want to make use
of this hook. I originally though of using it for the KVM in-kernel
models as well, but I will now establish a callback at APIC-level
(upstream will look differently from
On Mon, Oct 17, 2011 at 11:27:56AM +0200, Jan Kiszka wrote:
Also invoke the mask notifier if the global MSI-X mask is modified. For
this purpose, we push the notifier call from the per-vector mask update
to the central msix_handle_mask_update.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
On 10/17/2011 01:25 PM, Jan Kiszka wrote:
On 2011-10-17 13:13, Avi Kivity wrote:
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
Keep a link from the internal KVM routing table to potential MSI routing
cache entries. The link is used so far whenever the entry is dropped to
invalidate the cache
On 10/17/2011 01:31 PM, Jan Kiszka wrote:
Just to make sure I understand this completely: a hash table indexed by
MSIMessage in kvm code would avoid this? You'd just allocate on demand
when seeing a new MSIMessage and free on an LRU basis, avoiding pinned
entries.
I'm not
On 10/17/2011 11:27 AM, Jan Kiszka wrote:
As previously indicated, I was working for quite a while on a major
refactoring of the MSI additions we have in qemu-kvm to support
in-kernel irqchip, vhost and device assignment. This is now the outcome.
I'm quite happy with it, things are still
On Mon, Oct 17, 2011 at 01:45:04PM +0200, Jan Kiszka wrote:
On 2011-10-17 13:40, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:57AM +0200, Jan Kiszka wrote:
MSI config notifiers are supposed to be triggered on every relevant
configuration change of MSI vectors or if MSI is
On Mon, Oct 17, 2011 at 02:07:10PM +0200, Jan Kiszka wrote:
On 2011-10-17 13:57, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 01:23:46PM +0200, Jan Kiszka wrote:
On 2011-10-17 13:10, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote:
Only accesses
1 - 100 of 135 matches
Mail list logo
