This patch emulated MSI-X per vector mask bit on assigned device.
Signed-off-by: Sheng Yang
---
hw/device-assignment.c | 161 ++--
1 files changed, 155 insertions(+), 6 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 8
Signed-off-by: Sheng Yang
---
hw/device-assignment.c | 77 ---
1 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2605bd1..8a98876 100644
--- a/hw/device-assignment.c
+++ b/hw/device
Signed-off-by: Sheng Yang
---
qemu-kvm.c | 15 +++
qemu-kvm.h |6 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 733d0a9..ba6db51 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -1092,6 +1092,21 @@ int kvm_assign_set_msix_entry(
Sheng Yang (3):
qemu-kvm: Ioctl for in-kernel mask support
qemu-kvm: device assignment: Some clean up about MSI-X code
qemu-kvm: device assignment: emulate MSI-X mask bits
hw/device-assignment.c | 236 ++--
qemu-kvm.c | 15 +++
qemu
Then it can be used by others.
Reviewed-by: Matthew Wilcox
Cc: Jesse Barnes
Cc: linux-...@vger.kernel.org
Signed-off-by: Sheng Yang
---
drivers/pci/msi.h|6 --
include/linux/pci_regs.h |7 +++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/ms
Then we can use it instead of magic number 1.
Cc: Matthew Wilcox
Cc: Jesse Barnes
Cc: linux-...@vger.kernel.org
Signed-off-by: Sheng Yang
---
drivers/pci/msi.c|4 ++--
include/linux/pci_regs.h |1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/msi.
Then it can be used in struct kvm_assigned_dev_kernel later.
Signed-off-by: Sheng Yang
---
include/linux/kvm_host.h | 23 +++
virt/kvm/iodev.h | 25 +
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/include/linux/kvm_host.h
This patch enable per-vector mask for assigned devices using MSI-X.
This patch provided two new APIs: one is for guest to specific device's MSI-X
table address in MMIO, the other is for userspace to get information about mask
bit.
All the mask bit operation are kept in kernel, in order to acceler
Here is the latest series of MSI-X mask supporting patches.
The bigest change from last version is, in order to reduce the complexity, I
moved all mask bit operation to kernel, including disabled entries. This
addressed two concerns:
1. KVM and QEmu each own a part of mask bit operation.
2. QEmu n
We need to query the entry later.
Signed-off-by: Sheng Yang
---
include/linux/kvm_host.h |2 ++
virt/kvm/irq_comm.c | 20
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 7f9e4b7..e2ecbac 100
On Wed, 2010-11-03 at 12:48 +0200, Michael S. Tsirkin wrote:
> I mean in practice, you see a benefit from this patch?
Yes, I tested it. It does benefit the performance.
> > My concern here is whether checking only in set up would be
> sufficient
> > for security?
>
> It better be sufficient beca
Am 03.11.2010 23:13, Marcelo Tosatti wrote:
> On Wed, Nov 03, 2010 at 09:11:13AM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> This improves the IRQ forwarding for assigned devices: By using the
>> kernel's threaded IRQ scheme, we can get rid of the latency-prone work
>> queue and simplify th
On Tue, Nov 02, 2010 at 03:55:33PM +0100, Jan Kiszka wrote:
> Mostly usability fixes, but also a patch to allow using devices that
> have problems with MSIs.
>
> Jan Kiszka (4):
> pci-assign: Convert iommu property to booleam
> pci-assign: Allow to disable MSI perference for host IRQ
> pci-a
On Wed, Nov 03, 2010 at 09:11:13AM +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> This improves the IRQ forwarding for assigned devices: By using the
> kernel's threaded IRQ scheme, we can get rid of the latency-prone work
> queue and simplify the code in the same run.
>
> Moreover, we no longe
03.11.2010 22:44, Khaled El Mously wrote:
> The host kernel is on Ubuntu: 2.6.32-25-generic
>
> The guest kernel is 2.6.34-something.
>
> I have figured out what the problem is. When I first attempted to run kvm, it
> said access to /dev/kvm was denied. So I did "chmod o+rw /dev/kvm" and
> relo
Applied.
On Wednesday, November 03, 2010 01:17:33 pm Alex Williamson wrote:
> Trying to be too clever with setting the irq_disabled flag. PCI 2.3
> disabled devices can still share IRQs, which can lead to clearing
> the irq_disabled flag, preventing the EOI from registering, and leaving
> the dev
Trying to be too clever with setting the irq_disabled flag. PCI 2.3
disabled devices can still share IRQs, which can lead to clearing
the irq_disabled flag, preventing the EOI from registering, and leaving
the device without interrupts. Interrupt handler should only ever
set irq_disabled and we c
The host kernel is on Ubuntu: 2.6.32-25-generic
The guest kernel is 2.6.34-something.
I have figured out what the problem is. When I first attempted to run kvm, it
said access to /dev/kvm was denied. So I did "chmod o+rw /dev/kvm" and
reloaded. It stopped complaining about permissions, but appa
On Wed, 3 Nov 2010, Balbir Singh wrote:
> > > +#define UNMAPPED_PAGE_RATIO 16
> >
> > Maybe come up with a scheme that allows better configuration of the
> > mininum? I think in some setting we may want an absolute limit and in
> > other a fraction of something (total zone size or working set?)
>
Am 03.11.2010 18:37, Michael S. Tsirkin wrote:
> On Wed, Nov 03, 2010 at 06:27:50PM +0100, Jan Kiszka wrote:
>> Am 03.11.2010 16:57, Alex Williamson wrote:
>>> On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
> From: J
On Wed, Nov 03, 2010 at 06:35:48PM +0100, Jan Kiszka wrote:
> Am 03.11.2010 18:27, Jan Kiszka wrote:
> > Am 03.11.2010 16:57, Alex Williamson wrote:
> >> On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote:
> >>> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
> From: Jan K
On Wed, Nov 03, 2010 at 06:27:50PM +0100, Jan Kiszka wrote:
> Am 03.11.2010 16:57, Alex Williamson wrote:
> > On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote:
> >> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
> >>> From: Jan Kiszka
> >>>
> >>> PCI 2.3 allows to generical
Am 03.11.2010 18:27, Jan Kiszka wrote:
> Am 03.11.2010 16:57, Alex Williamson wrote:
>> On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote:
>>> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
From: Jan Kiszka
PCI 2.3 allows to generically disable IRQ sources at
Am 03.11.2010 16:57, Alex Williamson wrote:
> On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote:
>> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> PCI 2.3 allows to generically disable IRQ sources at device level. This
>>> enables us to share IRQ
Gleb Natapov writes:
> On Wed, Nov 03, 2010 at 04:18:18PM +0100, Markus Armbruster wrote:
>> Gleb Natapov writes:
>>
>> > On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
>> >> Here's a generic answer to the question "which of the device's buses is
>> >> this?"
>> >>
>> >> in
* Christoph Lameter [2010-11-03 09:35:33]:
> On Fri, 29 Oct 2010, Balbir Singh wrote:
>
> > A lot of the code is borrowed from zone_reclaim_mode logic for
> > __zone_reclaim(). One might argue that the with ballooning and
> > KSM this feature is not very useful, but even with ballooning,
>
> In
On Wed, Nov 03, 2010 at 04:18:18PM +0100, Markus Armbruster wrote:
> Gleb Natapov writes:
>
> > On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
> >> Here's a generic answer to the question "which of the device's buses is
> >> this?"
> >>
> >> int qbus_index(BusState *bus)
> >>
On Mon, Nov 01, 2010 at 12:13:33PM -0700, Ross Boylan wrote:
> I built from qemu-kvm-0.13.0.tar.gz on a Debian system with kernel
> linux-image-2.6.32-5-amd642.6.32-26
> (but otherwise basically the stable/lenny version) and now see
> Oct 26 16:57:38 markov kernel: [ 5757.672426] kv
On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > PCI 2.3 allows to generically disable IRQ sources at device level. This
> > enables us to share IRQs of such devices between on the host side whe
Jan Kiszka writes:
> Am 03.11.2010 14:02, Markus Armbruster wrote:
>> Jan Kiszka writes:
>>
>>> These qemu-kvm-only interfaces were broken by b560a9ab9b, but no one
>>> complained loud enough to get them fixed again. As we have properly
>>> working "-device pci-assign"/"device_add" and we won't
Gleb Natapov writes:
> On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
>> Here's a generic answer to the question "which of the device's buses is
>> this?"
>>
>> int qbus_index(BusState *bus)
>> {
>> BusState *b;
>> int i, index;
>>
>> index = -1;
>> i = 0;
>>
On Fri, 29 Oct 2010, Balbir Singh wrote:
> A lot of the code is borrowed from zone_reclaim_mode logic for
> __zone_reclaim(). One might argue that the with ballooning and
> KSM this feature is not very useful, but even with ballooning,
Interesting use of zone reclaim. I am having a difficult time
Hello All,
I was reading code of launching and resuming the VM code. While
reading code I came across a small typo. I am not sure if it is
important/necessary to make this change. Anyways here is the patch
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 200533e..990a67a 100644
--- a/ar
On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
> Here's a generic answer to the question "which of the device's buses is
> this?"
>
> int qbus_index(BusState *bus)
> {
> BusState *b;
> int i, index;
>
> index = -1;
> i = 0;
> QLIST_FOREACH(b, &bus->parent->
On Wed, Nov 03, 2010 at 11:45:08AM +0200, Gleb Natapov wrote:
> On Wed, Nov 03, 2010 at 05:47:53PM +0800, Xiao Guangrong wrote:
> > On 11/01/2010 08:55 PM, Gleb Natapov wrote:
> >
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index 2cfdf2d..f7aed95 100644
> > > --- a/arch/x86/kv
On Tue, Nov 02, 2010 at 05:11:19AM +0100, Jesper Juhl wrote:
> On Tue, 2 Nov 2010, Takuya Yoshikawa wrote:
>
> > Hi Jesper, (dropped some addresses from Cc)
> >
> > > > Jesper Juhl wrote:
> > > There's definately a positive size impact for the generated object code
> > > and we save having to do
On Tue, Oct 26, 2010 at 10:52:00AM -0700, Tim Pepper wrote:
> While doing some source review I noticed what appears to be
> an extraneous call to pc_allocate_cpu_irq() in qemu-kvm and
> which does not appear in qemu. From the git history it almost
> looks like b725a661eb38c93086e0b98f626a3864ae865
Here's a generic answer to the question "which of the device's buses is
this?"
int qbus_index(BusState *bus)
{
BusState *b;
int i, index;
index = -1;
i = 0;
QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
if (b == bus) {
index = i;
}
i+
On Wed, 2010-10-27 at 13:59 -0700, H. Peter Anvin wrote:
> I'll check it this evening when I'm at a working network again :(
Did this get applied? It seems to affect 2.6.32.x too
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602273) so can we tag
it for stable as well?
Thanks,
Ian.
>
> "Jer
Am 03.11.2010 14:02, Markus Armbruster wrote:
> Jan Kiszka writes:
>
>> These qemu-kvm-only interfaces were broken by b560a9ab9b, but no one
>> complained loud enough to get them fixed again. As we have properly
>> working "-device pci-assign"/"device_add" and we won't push this
>> upstream anywa
Jan Kiszka writes:
> These qemu-kvm-only interfaces were broken by b560a9ab9b, but no one
> complained loud enough to get them fixed again. As we have properly
> working "-device pci-assign"/"device_add" and we won't push this
> upstream anyway, there is likely no point in restoring the interface
Jan Kiszka writes:
> Some devices (e.g. the ath9k) claim to support MSI but actually do not
> work when this is enabled. We must not blindly switch such devices to
> MSI but rather provide the user a way to pass control back to the
> guest driver. This can be done by turning the new property "pre
On Tue, Nov 02, 2010 at 11:11:03AM -0400, Christoph Hellwig wrote:
> On Sun, Oct 31, 2010 at 09:06:29AM -0400, Christoph Hellwig wrote:
> > With Linus' git tree from today I can't boot qemu when using kvm. It
> > seems to do fine, just glacially slow without -enable-kvm. The command
> > simplest
On Mon, Nov 01, 2010 at 01:17:53PM -0700, Shirley Ma wrote:
> On Sat, 2010-10-30 at 22:06 +0200, Michael S. Tsirkin wrote:
> > On Fri, Oct 29, 2010 at 08:43:08AM -0700, Shirley Ma wrote:
> > > On Fri, 2010-10-29 at 10:10 +0200, Michael S. Tsirkin wrote:
> > > > Hmm. I don't yet understand. We are s
Teck Choon Giam gmail.com> writes:
> # grep kvm_handle_internal_error ./*
> ./kvm-all.c:static void kvm_handle_internal_error(CPUState *env,
> struct kvm_run *run)
> ./kvm-all.c:kvm_handle_internal_error(env, run);
> ./qemu-kvm.c:kvm_handle_internal_error(env, run);
I h
On Wed, Nov 03, 2010 at 05:47:53PM +0800, Xiao Guangrong wrote:
> On 11/01/2010 08:55 PM, Gleb Natapov wrote:
>
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 2cfdf2d..f7aed95 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -5295,8 +5295,9 @@ static int
On 11/01/2010 08:55 PM, Gleb Natapov wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 2cfdf2d..f7aed95 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5295,8 +5295,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
> {
>
Khaled El Mously wrote:
There seems to be a problem kvm-booting a 32-bit (Fedora) machine on a 32-bit
Intel Q9450 (Ubuntu) machine.
The error displayed is:
kvm: unhandled exit 4400
kvm_run returned -22
I've checked google, the kvm website, forums, FAQs and IRC channel.
Anyone know what cause
On Wed, Nov 03, 2010 at 10:15:59AM +0100, Jan Kiszka wrote:
> Am 03.11.2010 10:05, Michael S. Tsirkin wrote:
> > On Wed, Nov 03, 2010 at 09:51:10AM +0100, Jan Kiszka wrote:
> >> Am 03.11.2010 09:43, Michael S. Tsirkin wrote:
> >>> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
> F
Am 03.11.2010 10:10, Michael S. Tsirkin wrote:
> On Wed, Nov 03, 2010 at 09:56:24AM +0100, Jan Kiszka wrote:
>>> Hmm, this does an extra config read on each interrupt (another one is in
>>> pci_2_3_irq_unmask). These reads are pretty expensive... I do realize
>>> locking becomes ugly, though. Mayb
Am 03.11.2010 10:05, Michael S. Tsirkin wrote:
> On Wed, Nov 03, 2010 at 09:51:10AM +0100, Jan Kiszka wrote:
>> Am 03.11.2010 09:43, Michael S. Tsirkin wrote:
>>> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
From: Jan Kiszka
PCI 2.3 allows to generically disable IRQ s
On Wed, Nov 03, 2010 at 09:44:25AM +0100, Jan Kiszka wrote:
> Am 03.11.2010 09:33, Michael S. Tsirkin wrote:
> > On Wed, Nov 03, 2010 at 09:14:14AM +0100, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> Make use of the new KVM feature that allows legacy interrupt sharing
> >> for PCI-2.3-complia
On Wed, Nov 03, 2010 at 09:56:24AM +0100, Jan Kiszka wrote:
> > Hmm, this does an extra config read on each interrupt (another one is in
> > pci_2_3_irq_unmask). These reads are pretty expensive... I do realize
> > locking becomes ugly, though. Maybe my idea to avoid set level to 0
> > was silly?
Khaled El Mously wrote:
There seems to be a problem kvm-booting a 32-bit (Fedora) machine on a 32-bit
Intel Q9450 (Ubuntu) machine.
The error displayed is:
kvm: unhandled exit 4400
kvm_run returned -22
I've checked google, the kvm website, forums, FAQs and IRC channel.
Anyone know what cause
On 11/03/2010 04:53 AM, Jason Wang wrote:
> Michael Goldish writes:
> > On 11/02/2010 07:34 AM, Jason Wang wrote:
> > > Michael Goldish writes:
> > > > On 09/25/2010 11:36 AM, Jason Wang wrote:
> > > > > We could give a further test of migration by launch test during
> migartion. So
> > >
On Wed, Nov 03, 2010 at 09:51:10AM +0100, Jan Kiszka wrote:
> Am 03.11.2010 09:43, Michael S. Tsirkin wrote:
> > On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> PCI 2.3 allows to generically disable IRQ sources at device level. This
> >> enables us to sh
On Wed, Nov 03, 2010 at 03:08:17PM +0800, Jason Wang wrote:
> We need call netif_carrier_off() and do not assume VIRTIO_NET_S_LINKUP
> before querying device state during probing, otherwise we may get
> wrong operstate after driver was loaded because the link watch event
> was not fired as expected
We need call netif_carrier_off() and do not assume VIRTIO_NET_S_LINKUP
before querying device state during probing, otherwise we may get
wrong operstate after driver was loaded because the link watch event
was not fired as expected.
Since the device state changed could be caught through interrupt,
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
> > Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
> >
> > > > > > Results for UDP BW tests (unidirectional, sum across
> > > > > > 3 iterations, each iteration of 45 seconds, default
> > > > > > netperf, vhosts bound to cpu
59 matches
Mail list logo
