On Sun, Oct 16, 2011 at 10:57 PM, Sasha Levin 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 int do_debug(cons
Hi Joerg,
On Fri, Oct 14, 2011 at 7:03 PM, Ohad Ben-Cohen wrote:
> On Fri, Oct 14, 2011 at 3:35 PM, Roedel, Joerg 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
>> (because it is the base page-
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 se
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 Specificat
---
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 "hw/pc.
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 R
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:
> "Hyperviso
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
---
hw/msi.c |3 ++-
hw/msix.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/msi.c b/hw/msi.c
index 5
Replace some open-coded msi/msix_present checks and drop redundant
msix_supported tests (present implies supported).
Signed-off-by: Jan Kiszka
---
hw/msi.c |2 +-
hw/msix.c | 20
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/hw/msi.c b/hw/msi.c
index
There are no routes to clear at this point, we are just creating the VM.
Signed-off-by: Jan Kiszka
---
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 b/qemu-kvm-x86.c
index
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
---
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 supp
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 p
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
CC: Gerd Hoffmann
CC: Isaku Yamahata
Signed-off-by: Jan Kiszka
---
hw/ide/ich.c|8
hw/intel-hda.c
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
CC: Gerd Hoffmann
CC:
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
---
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
--- a/hw/msix.c
+++ b/hw
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 MMIO
- 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
---
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
---
hw/msix.c | 72 +
Also remove the dead get_assigned_device at this chance. No functional
changes.
Signed-off-by: Jan Kiszka
---
hw/device-assignment.c | 199
hw/device-assignment.h | 14 ++--
2 files changed, 107 insertions(+), 106 deletions(-)
diff --git a/hw/
This helper will also be used by the upcoming config notifier.
Signed-off-by: Jan Kiszka
---
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
+++ b/hw/msix.c
@@ -33,6 +33,15 @
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 creates
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 cr
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 dire
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 i
Will be used for generating and distributing MSI messages, both in
emulation mode and under KVM.
Signed-off-by: Jan Kiszka
---
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 e5e821f..22e3932 100644
---
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
---
hw/virtio-pci.c | 10 ++
kvm.h |3 ++-
qemu-kvm.c | 17 +
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
---
hw/msix.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 57d0
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 se
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: Jan
Drop unused functions, privatize those which are only used internally now.
Signed-off-by: Jan Kiszka
---
kvm-stub.c | 10 --
kvm.h |1 -
qemu-kvm.c | 37 ++---
qemu-kvm.h | 39 ---
4 files changed, 6 inser
Don't pass kvm_assigned_irq struct, rather use the actually required
fields in the interface.
Signed-off-by: Jan Kiszka
---
hw/device-assignment.c | 42 --
qemu-kvm.c | 15 ++-
qemu-kvm.h | 11 +--
3 files
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
---
hw/device-assignment.c |
Allows to drop checking for out-of-memory.
Signed-off-by: Jan Kiszka
---
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 @@ int kvm_add_routing_entry
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 registrat
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
---
hw/device-assignment.c | 21 ++---
qemu-kvm.c | 17 +
qemu-kvm.h |2 ++
3 files
Will have more users soon.
Signed-off-by: Jan Kiszka
---
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
--- a/hw/device-assignment.c
+++ b
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
---
hw/device-assignment.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/device-assignment.c b/hw/devi
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 Kiszk
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
---
hw/msix.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-
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
---
hw/msix.c | 36
hw/msix.h |
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
---
hw/device-assignment.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/device-assignment.
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 acce
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
---
qemu-kvm.c | 16
qemu-kvm.h |8
2 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/qemu-kvm.c b/qemu
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
---
hw/apic.c | 24 +++-
hw/msi.c |5 -
hw/msix.c |5 -
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/hw/a
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
---
hw/msix.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
This helper will also be used by the upcoming config notifier.
Signed-off-by: Jan Kiszka
---
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
--- a/hw/msi.c
+++ b/hw/msi
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
---
hw/msi.c |8
hw/msi.h |2 ++
hw/msix.c |8 +++-
hw/msix.h |2 -
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
---
hw/hpet.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index d8e
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
---
hw/virtio-pci.c |6 +++---
kvm.h |2 ++
qe
Signed-off-by: Jan Kiszka
---
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;
bool msi64bit;
+if (
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
---
hw/msix.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 2c4de21..33cb716 100644
--- a/hw/
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 se
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));
c->fun
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).
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
On Mon, Oct 17, 2011 at 11:28 AM, Roedel, Joerg 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, yeah.
Though by dec
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
Am 26.09.2011 10:01, schrieb Zhi Yong Wu:
> On Fri, Sep 23, 2011 at 11:32 PM, Kevin Wolf wrote:
>> Am 08.09.2011 12:11, schrieb Zhi Yong Wu:
>>> Signed-off-by: Zhi Yong Wu
>>> ---
>>> 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 wrote:
>>> +}
>>> +
>>> +static void bdrv_block_timer(void *opaque)
>>> +{
>>> +BlockDriverState *bs = opaque;
>>> +BlockQueue *queue= bs->block_queue;
>>> +
>>> +qemu_block_queue_flush(queue);
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,
> > > +
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 properl
Am 26.09.2011 09:24, schrieb Zhi Yong Wu:
> On Sat, Sep 24, 2011 at 12:19 AM, Kevin Wolf 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 handle t
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 =&cpuid_data.en
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 messag
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 cur
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 chan
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
Why would msix_mmio_write be called on an access
outside the table?
> ---
> hw/msix.c | 16 +
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 cur
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
>> model
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 retu
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 centr
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 emula
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
>
> Why would msix_mmio_write be called on a
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 somet
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 ro
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
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 d
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
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 ev
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 forme
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 vect
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
I would add
uint64_t msix_get_address(dev, vector)
uint64_t msix_get_data(dev, vector)
and same for msi
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
>
> I would add
>
> uint64_t msix_get_address(dev, v
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.
> >>
> >>
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-of
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_handl
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
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 diffe
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
This is a bugfix
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
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'
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 stil
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:
> O
1 - 100 of 132 matches
Mail list logo