On Wed, May 06, 2009 at 01:51:04PM +0300, Avi Kivity wrote:
> Gleb Natapov wrote:
>> On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
>>
>>> diff --git a/arch/x86/include/asm/kvm_host.h
>>> b/arch/x86/include/asm/kvm_host.h
>>> index 8e680c3..a49d07b 100644
>>> --- a/arch/x86/incl
On Thu, 7 May 2009, Avi Kivity wrote:
> What's your take on adding irq context safe callbacks to irqfd?
>
> To give some background here, we would like to use eventfd as a generic
> connector between components, so the components do not know about each other.
> So far eventfd successfully abstrac
Marcelo Tosatti wrote:
> On Thu, May 07, 2009 at 08:35:03PM -0300, Marcelo Tosatti wrote:
>
>> Also for PIO/MMIO you're adding this unoptimized lookup to the
>> measurement:
>>
>> pio_dev = vcpu_find_pio_dev(vcpu, port, size, !in);
>> if (pio_dev) {
>> kernel_pio
Marcelo Tosatti wrote:
> On Thu, May 07, 2009 at 01:03:45PM -0400, Gregory Haskins wrote:
>
>> Chris Wright wrote:
>>
>>> * Gregory Haskins (ghask...@novell.com) wrote:
>>>
>>>
Chris Wright wrote:
> VF drivers can also have this issue (and typicall
Marcelo Tosatti wrote:
There's no savevm handler at all:
Ahh! Thank you for the explanation.
There was an incomplete patch posted to qemu-devel a while ago, which I
can't find.
I'm guessing that would be "[PATCH] save/restore for LSI SCSI", by Nolan
:
http://permalink.gmane.org/gmane.comp
Charles,
There's no savevm handler at all:
$ grep register_savevm hw/lsi53c895a.c
There was an incomplete patch posted to qemu-devel a while ago, which I
can't find.
On Tue, Apr 28, 2009 at 04:24:02PM -0500, Charles Duffy wrote:
> Per subject. Observed on kvm-83 through kvm-85; haven't traced b
On Fri, 2009-05-08 at 09:25 +0930, Rusty Russell wrote:
> On Thu, 7 May 2009 07:49:53 pm Sheng Yang wrote:
> > On Thursday 07 May 2009 17:53:02 Matthew Wilcox wrote:
> > > Here's a good example. Let's suppose you have a driver which supports
> > > two different models of cards, one has 16 MSI-X in
On Fri, May 08, 2009 at 09:25:00AM +0930, Rusty Russell wrote:
> Sheng is absolutely right, that's a horrid API.
But the API already exists, and is in use by 27 drivers. If this were a
change to the API, I'd be against it, but it is the existing API.
--
To unsubscribe from this list: send the li
On Thu, 7 May 2009 07:49:53 pm Sheng Yang wrote:
> On Thursday 07 May 2009 17:53:02 Matthew Wilcox wrote:
> > Here's a good example. Let's suppose you have a driver which supports
> > two different models of cards, one has 16 MSI-X interrupts, the other
> > has 10. You can call pci_enable_msix()
On Thu, May 07, 2009 at 08:35:03PM -0300, Marcelo Tosatti wrote:
> Also for PIO/MMIO you're adding this unoptimized lookup to the
> measurement:
>
> pio_dev = vcpu_find_pio_dev(vcpu, port, size, !in);
> if (pio_dev) {
> kernel_pio(pio_dev, vcpu, vcpu->arch.pio_data
On Thu, May 07, 2009 at 08:57:03AM -0700, Ross Boylan wrote:
> I'm trying to understand bridging with KVM, but am still puzzled.
> I think that the recommended bridging with TAP means that packets from
> the VM will end up going out the host card attached to the default
> gateway. But it looks to
On Thu, May 07, 2009 at 01:03:45PM -0400, Gregory Haskins wrote:
> Chris Wright wrote:
> > * Gregory Haskins (ghask...@novell.com) wrote:
> >
> >> Chris Wright wrote:
> >>
> >>> VF drivers can also have this issue (and typically use mmio).
> >>> I at least have a better idea what your propo
We're currently using a counter to track the most recent GSI we've
handed out. This quickly hits KVM_MAX_IRQ_ROUTES when using device
assignment with a driver that regularly toggles the MSI enable bit.
This can mean only a few minutes of usable run time. Instead, track
used GSIs in a bitmap.
Sig
On Thursday 07 May 2009, Chris Wright wrote:
>
> > Chris, is that issue with the non ioread/iowrite access of a mangled
> > pointer still an issue here? I would think so, but I am a bit fuzzy on
> > whether there is still an issue of non-wrapped MMIO ever occuring.
>
> Arnd was saying it's a bug
* Gregory Haskins (gregory.hask...@gmail.com) wrote:
> Arnd Bergmann wrote:
> > pci_iomap could look at the bus device that the PCI function sits on.
> > If it detects a PCI bridge that has a certain property (config space
> > setting, vendor/device ID, ...), it assumes that the device itself
> > w
Arnd Bergmann wrote:
> On Thursday 07 May 2009, Gregory Haskins wrote:
>
>> What I am not clear on is how you would know to flag the address to
>> begin with.
>>
>
> pci_iomap could look at the bus device that the PCI function sits on.
> If it detects a PCI bridge that has a certain propert
Disallow the deletion of memory slots (and aliases, for x86 case), if a
vcpu contains a cr3 that points to such slot/alias.
This complements commit 6c20e1442bb1c62914bb85b7f4a38973d2a423ba.
v2:
- set KVM_REQ_TRIPLE_FAULT
- use __KVM_HAVE_ARCH_CAN_FREE_MEMSLOT to avoid duplication of stub
Signed-
KVM uses a function call IPI to cause the exit of a guest running on a
physical cpu. For virtual interrupt notification there is no need to
wait on IPI receival, or to execute any function.
This is exactly what the reschedule IPI does, without the overhead
of function IPI. So use it instead of smp
Addressing comments.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
smp_send_reschedule was exported (via smp_ops) in v2.6.24.
Create a compat function which schedules the IPI to keventd context,
in case interrupts are disabled, for kernels < 2.6.24.
Signed-off-by: Marcelo Tosatti
Index: kvm-kmod/ia64/hack-module.awk
=
Support to shrinking aliases complicates kernel code unnecessarily,
while userspace can do the same with two operations, delete an alias,
and create a new alias.
Signed-off-by: Marcelo Tosatti
Index: kvm-pending/arch/x86/kvm/x86.c
=
Addressing comments.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm_assigned_dev_ack_irq is vulnerable to a race condition with the
interrupt handler function. It does:
if (dev->host_irq_disabled) {
enable_irq(dev->host_irq);
dev->host_irq_disabled = false;
}
If an interrupt triggers before the host->dev_irq_dis
Signed-off-by: Marcelo Tosatti
Index: kvm-kmod/external-module-compat-comm.h
===
--- kvm-kmod.orig/external-module-compat-comm.h
+++ kvm-kmod/external-module-compat-comm.h
@@ -116,6 +116,10 @@ int kvm_smp_call_function_single(int cpu
kvm_handle_hva, called by MMU notifiers, manipulates mmu data only with
the protection of mmu_lock.
Update kvm_mmu_change_mmu_pages callers to take mmu_lock, thus protecting
against kvm_handle_hva.
CC: Andrea Arcangeli
Signed-off-by: Marcelo Tosatti
Index: kvm-pending/arch/x86/kvm/mmu.c
==
kvm_handle_hva relies on mmu_lock protection to safely access
the memslot structures.
Signed-off-by: Marcelo Tosatti
Index: kvm-pending/virt/kvm/kvm_main.c
===
--- kvm-pending.orig/virt/kvm/kvm_main.c
+++ kvm-pending/virt/kvm/kvm_m
On Thursday 07 May 2009, Gregory Haskins wrote:
> What I am not clear on is how you would know to flag the address to
> begin with.
pci_iomap could look at the bus device that the PCI function sits on.
If it detects a PCI bridge that has a certain property (config space
setting, vendor/device ID,
* Gregory Haskins (gregory.hask...@gmail.com) wrote:
> After posting my numbers today, what I *can* tell you definitively that
> its significantly slower to VMEXIT via MMIO. I guess I do not really
> know the reason for sure. :)
there's certainly more work, including insn decoding
--
To unsubscri
On Thursday 07 May 2009, Arnd Bergmann wrote:
> An easy way to deal with the pass-through case might be to actually use
> __raw_writel there. In guest-to-guest communication, the two sides are
> known to have the same endianess (I assume) and you can still add the
> appropriate smp_mb() and such in
On Thursday 07 May 2009, Gregory Haskins wrote:
> Arnd Bergmann wrote:
> > An mmio that goes through a PF is a bug, it's certainly broken on
> > a number of platforms, so performance should not be an issue there.
> >
>
> This may be my own ignorance, but I thought a VMEXIT of type "PF" was
> ho
Chris Wright wrote:
> * Gregory Haskins (gregory.hask...@gmail.com) wrote:
>
>> What I am not clear on is how you would know to flag the address to
>> begin with.
>>
>
> That's why I mentioned pv_io_ops->iomap() earlier. Something I'd expect
> would get called on IORESOURCE_PVIO type.
Yea
Arnd Bergmann wrote:
> On Thursday 07 May 2009, Gregory Haskins wrote:
>
>> I guess technically mmio can just be a simple access of the page which
>> would be problematic to trap locally without a PF. However it seems
>> that most mmio always passes through a ioread()/iowrite() call so this
>>
Avi Kivity wrote:
> Gregory Haskins wrote:
>>> Oh yes. But don't call it dynhc - like Chris says it's the wrong
>>> semantic.
>>>
>>> Since we want to connect it to an eventfd, call it HC_NOTIFY or
>>> HC_EVENT or something along these lines. You won't be able to pass
>>> any data, but that's fin
* Gregory Haskins (gregory.hask...@gmail.com) wrote:
> What I am not clear on is how you would know to flag the address to
> begin with.
That's why I mentioned pv_io_ops->iomap() earlier. Something I'd expect
would get called on IORESOURCE_PVIO type. This isn't really transparent
though (only vi
Gregory Haskins wrote:
Oh yes. But don't call it dynhc - like Chris says it's the wrong
semantic.
Since we want to connect it to an eventfd, call it HC_NOTIFY or
HC_EVENT or something along these lines. You won't be able to pass
any data, but that's fine. Registers are saved to memory anyway.
Avi Kivity wrote:
> Gregory Haskins wrote:
>>> Don't - it's broken. It will also catch device assignment mmio and
>>> hypercall them.
>>>
>>>
>> Ah. Crap.
>>
>> Would you be conducive if I continue along with the dynhc() approach
>> then?
>>
>
> Oh yes. But don't call it dynhc - like Chr
On Thursday 07 May 2009, Gregory Haskins wrote:
> I guess technically mmio can just be a simple access of the page which
> would be problematic to trap locally without a PF. However it seems
> that most mmio always passes through a ioread()/iowrite() call so this
> is perhaps the hook point. If w
Avi Kivity wrote:
I think we just past the "too complicated" threshold.
And the "can't spel" threshold in the same sentence.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body o
Gregory Haskins wrote:
Don't - it's broken. It will also catch device assignment mmio and
hypercall them.
Ah. Crap.
Would you be conducive if I continue along with the dynhc() approach then?
Oh yes. But don't call it dynhc - like Chris says it's the wrong semantic.
Since we want
Chris Wright wrote:
> * Gregory Haskins (ghask...@novell.com) wrote:
>
>> Chris Wright wrote:
>>
>>> * Avi Kivity (a...@redhat.com) wrote:
>>>
Gregory Haskins wrote:
> Cool, I will code this up and submit it. While Im at it, Ill run it
> through the "null
Chris Wright wrote:
* Gregory Haskins (ghask...@novell.com) wrote:
Chris Wright wrote:
* Avi Kivity (a...@redhat.com) wrote:
Gregory Haskins wrote:
Cool, I will code this up and submit it. While Im at it, Ill run it
through the "nullio" ringer, too. ;) It would be c
* Gregory Haskins (ghask...@novell.com) wrote:
> Chris Wright wrote:
> > * Avi Kivity (a...@redhat.com) wrote:
> >> Gregory Haskins wrote:
> >>> Cool, I will code this up and submit it. While Im at it, Ill run it
> >>> through the "nullio" ringer, too. ;) It would be cool to see the
> >>> pv-mmi
Ross Boylan wrote:
On Thu, 2009-05-07 at 11:13 -0600, Cam Macdonell wrote:
Ross Boylan wrote:
I'm trying to understand bridging with KVM, but am still puzzled.
I think that the recommended bridging with TAP means that packets
from
the VM will end up going out the host card attached to the def
Chris Wright wrote:
> * Avi Kivity (a...@redhat.com) wrote:
>
>> Gregory Haskins wrote:
>>
>>> Cool, I will code this up and submit it. While Im at it, Ill run it
>>> through the "nullio" ringer, too. ;) It would be cool to see the
>>> pv-mmio hit that 2.07us number. I can't think of an
* Avi Kivity (a...@redhat.com) wrote:
> Gregory Haskins wrote:
>> Cool, I will code this up and submit it. While Im at it, Ill run it
>> through the "nullio" ringer, too. ;) It would be cool to see the
>> pv-mmio hit that 2.07us number. I can't think of any reason why this
>> will not be the ca
Avi Kivity wrote:
> Gregory Haskins wrote:
>> Avi Kivity wrote:
>>
>>> Gregory Haskins wrote:
>>>
I guess technically mmio can just be a simple access of the page which
would be problematic to trap locally without a PF. However it seems
that most mmio always passes through a i
Gregory Haskins wrote:
Avi Kivity wrote:
Gregory Haskins wrote:
I guess technically mmio can just be a simple access of the page which
would be problematic to trap locally without a PF. However it seems
that most mmio always passes through a ioread()/iowrite() call so this
is perhaps t
On Thu, May 07, 2009 at 05:16:35PM +0300, Avi Kivity wrote:
> mtosa...@redhat.com wrote:
>> Disallow the deletion of memory slots (and aliases, for x86 case), if a
>> vcpu contains a cr3 that points to such slot/alias.
>>
>
> That allows the guest to induce failures in the host.
I don't under
Olders kernel which don't contain kvm.git commit
61a6bd672bda3b9468bf5895c1be085c4e481138 display the following message:
kvm: 32301: cpu0 unhandled wrmsr: 0xc0010117 data 0
When kvm_arch_load_regs is called. This is confusing in bug reports.
Avoid it by checking whether the host advertises the
Avi Kivity wrote:
> Gregory Haskins wrote:
>> I guess technically mmio can just be a simple access of the page which
>> would be problematic to trap locally without a PF. However it seems
>> that most mmio always passes through a ioread()/iowrite() call so this
>> is perhaps the hook point. If we
Gregory Haskins wrote:
I guess technically mmio can just be a simple access of the page which
would be problematic to trap locally without a PF. However it seems
that most mmio always passes through a ioread()/iowrite() call so this
is perhaps the hook point. If we set the stake in the ground t
On Wed, 2009-05-06 at 23:16 -0700, Han, Weidong wrote:
> @@ -634,6 +694,44 @@ static int ir_parse_ioapic_scope(struct acpi_dmar_header
> *header,
> " 0x%Lx\n", scope->enumeration_id,
> drhd->address);
>
> + bus = pci_f
Avi Kivity wrote:
> Gregory Haskins wrote:
>>> What do you think of my mmio hypercall? That will speed up all mmio
>>> to be as fast as a hypercall, and then we can use ordinary mmio/pio
>>> writes to trigger things.
>>>
>>>
>> I like it!
>>
>> Bigger question is what kind of work goes into m
Davide Libenzi wrote:
On Thu, 7 May 2009, Avi Kivity wrote:
Davide Libenzi wrote:
What's your take on adding irq context safe callbacks to irqfd?
To give some background here, we would like to use eventfd as a generic
connector between components, so the components do not kn
Gregory Haskins wrote:
What do you think of my mmio hypercall? That will speed up all mmio
to be as fast as a hypercall, and then we can use ordinary mmio/pio
writes to trigger things.
I like it!
Bigger question is what kind of work goes into making mmio a pv_op (or
is this already done)
Avi Kivity wrote:
> Gregory Haskins wrote:
>> I completed the resurrection of the test and wrote up a little wiki on
>> the subject, which you can find here:
>>
>> http://developer.novell.com/wiki/index.php/WhyHypercalls
>>
>> Hopefully this answers Chris' "show me the numbers" and Anthony's "Why
>
Gregory Haskins wrote:
I completed the resurrection of the test and wrote up a little wiki on
the subject, which you can find here:
http://developer.novell.com/wiki/index.php/WhyHypercalls
Hopefully this answers Chris' "show me the numbers" and Anthony's "Why
reinvent the wheel?" questions.
I
On Thu, 2009-05-07 at 11:13 -0600, Cam Macdonell wrote:
>
> Ross Boylan wrote:
> > I'm trying to understand bridging with KVM, but am still puzzled.
> > I think that the recommended bridging with TAP means that packets
> from
> > the VM will end up going out the host card attached to the default
>
On Thu, 2009-05-07 at 11:09 -0600, Alex Williamson wrote:
> Fix the index at which we return -ENOSPC since the kernel side will
> reject a GSI >= KVM_MAX_IRQ_ROUTES. Also, mask as a signed int before
> testing for error.
Even with this, there still seems to be a fundamental problem with our
consu
Fix the index at which we return -ENOSPC since the kernel side will
reject a GSI >= KVM_MAX_IRQ_ROUTES. Also, mask as a signed int before
testing for error.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c |2 +-
kvm/libkvm/libkvm.c|2 +-
2 files changed, 2 insertions(+),
Chris Wright wrote:
> * Gregory Haskins (ghask...@novell.com) wrote:
>
>> Chris Wright wrote:
>>
>>> VF drivers can also have this issue (and typically use mmio).
>>> I at least have a better idea what your proposal is, thanks for
>>> explanation. Are you able to demonstrate concrete benef
On Thu, 7 May 2009, Avi Kivity wrote:
> Davide Libenzi wrote:
> >
> > > What's your take on adding irq context safe callbacks to irqfd?
> > >
> > > To give some background here, we would like to use eventfd as a generic
> > > connector between components, so the components do not know about ea
Avi Kivity wrote:
Beth Kon wrote:
These patches resolve the irq0->inti2 override issue, and get the
hpet working
on kvm.
They are dependent on Jes Sorensen's recent
0006-qemu-kvm-irq-routing.patch.
Override and HPET changes are sent as a series because HPET depends
on the override. Win2k8 e
Driver for inter-VM shared memory device that now supports interrupts between
two guests. The driver defines a counting semaphore and wait_event queue for
different synchronization needs of users. Initializing the semaphore count,
sending interrupts and waiting are implemented via ioctl calls.
I'm trying to understand bridging with KVM, but am still puzzled.
I think that the recommended bridging with TAP means that packets from
the VM will end up going out the host card attached to the default
gateway. But it looks to me as if their IP address is unchanged, which
means replies will neve
Bit 0 is the enable bit, which we not only don't want to set, but
it will stick and make us think it's an I/O port resource.
Signed-off-by: Alex Williamson
---
bios/rombios32.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/bios/rombios32.c b/bios/rombios32.c
in
Support an inter-vm shared memory device that maps a shared-memory object
as a PCI device in the guest. This patch also supports interrupts between
guest by communicating over a unix domain socket. This patch applies to the
qemu-kvm repository.
This device now creates a qemu character de
Beth Kon wrote:
These patches resolve the irq0->inti2 override issue, and get the hpet working
on kvm.
They are dependent on Jes Sorensen's recent 0006-qemu-kvm-irq-routing.patch.
Override and HPET changes are sent as a series because HPET depends on the
override. Win2k8 expects the HPET int
Davide Libenzi wrote:
What's your take on adding irq context safe callbacks to irqfd?
To give some background here, we would like to use eventfd as a generic
connector between components, so the components do not know about each other.
So far eventfd successfully abstracts among components in
(copying Ingo)
Mark Langsdorf wrote:
commit 01813db8627e74018c8cec90df7e345839351f23
Author: root
Date: Thu May 7 09:44:10 2009 -0500
New AMD processors will support the Pause Filter Feature.
This feature creates a new field in the VMCB called Pause
Filter Count. If Pause Filter
Gregory Haskins wrote:
This is my preferred option. For a virtio-net-server in the kernel,
we'd service its eventfd in qemu, raising and lowering the pci
interrupt in the traditional way.
But we'd still need to know when to lower the interrupt. How?
IIUC, isn't that usually device/
commit 01813db8627e74018c8cec90df7e345839351f23
Author: root
Date: Thu May 7 09:44:10 2009 -0500
New AMD processors will support the Pause Filter Feature.
This feature creates a new field in the VMCB called Pause
Filter Count. If Pause Filter Count is greater than 0 and
interce
Just a note here...
The number of table_offset_entry entries for the non BX_QEMU case doesn't make
sense here. There are only 2 entries. I left it as is, since it does not
impact HPET's interraction with it. Actually it seems like dead code since
this is in kvm code but with BX_QEMU undefined
Signed-off-by: Beth Kon
diff --git a/hw/hpet.c b/hw/hpet.c
index c7945ec..47c9f89 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -30,6 +30,7 @@
#include "console.h"
#include "qemu-timer.h"
#include "hpet_emul.h"
+#include "qemu-kvm.h"
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -48,6 +49,43 @@
Signed-off-by: Beth Kon
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index e1b19d7..bb74f38 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -279,6 +279,7 @@ void *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
fw_cfg_add_bytes(s, FW_CFG_UUID, qemu_uuid, 16);
fw_cfg_add_i16(s, FW_CFG_NOGRAPH
These patches resolve the irq0->inti2 override issue, and get the hpet working
on kvm.
They are dependent on Jes Sorensen's recent 0006-qemu-kvm-irq-routing.patch.
Override and HPET changes are sent as a series because HPET depends on the
override. Win2k8 expects the HPET interrupt on inti2, re
Avi Kivity wrote:
> Gregory Haskins wrote:
>> One thing I was thinking here was that I could create a flag for the
>> kvm_irqfd() function for something like "KVM_IRQFD_MODE_CLEAR". This
>> flag when specified at creation time will cause the event to execute a
>> clear operation instead of a set w
On Thu, 7 May 2009, Avi Kivity wrote:
> What's your take on adding irq context safe callbacks to irqfd?
>
> To give some background here, we would like to use eventfd as a generic
> connector between components, so the components do not know about each other.
> So far eventfd successfully abstrac
Gregory Haskins wrote:
One thing I was thinking here was that I could create a flag for the
kvm_irqfd() function for something like "KVM_IRQFD_MODE_CLEAR". This
flag when specified at creation time will cause the event to execute a
clear operation instead of a set when triggered. That way, the
mtosa...@redhat.com wrote:
Disallow the deletion of memory slots (and aliases, for x86 case), if a
vcpu contains a cr3 that points to such slot/alias.
That allows the guest to induce failures in the host. Better to
triple-fault the guest instead.
+int kvm_arch_can_free_memslot(struct k
This implements optional MSI-X support in virtio_pci.
MSI-X is used whenever the host supports at least 2 MSI-X
vectors: 1 for configuration changes and 1 for virtqueues.
Per-virtqueue vectors are allocated if enough vectors
available.
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_
This reorganizes virtio-pci code in vp_interrupt slightly, so that
it's easier to add per-vq MSI support on top.
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_pci.c | 45 +-
1 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/d
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations,
and updates all drivers. This is needed for MSI support, because MSI
needs to know the total number of vectors upfront.
Signed-off-by: Michael S. Tsirkin
---
drivers/block/virtio_blk.c | 11 +++---
drivers/char/hw_r
Add optional MSI-X support: use a vector per virtqueue with
fallback to a common vector and finally to regular interrupt.
Teach all drivers to use it.
Signed-off-by: Michael S. Tsirkin
---
Here's a draft set of patches for MSI-X support in the guest. It still
needs to be tested properly, and p
Marcelo Tosatti wrote:
> On Thu, May 07, 2009 at 12:48:21PM +0300, Avi Kivity wrote:
>
>> Davide Libenzi wrote:
>>
>>> On Wed, 6 May 2009, Gregory Haskins wrote:
>>>
>>>
>>>
I think we are ok in this regard (at least in v5) without the
callback. kvm holds irqfd, which h
On Thu, May 07, 2009 at 12:48:21PM +0300, Avi Kivity wrote:
> Davide Libenzi wrote:
>> On Wed, 6 May 2009, Gregory Haskins wrote:
>>
>>
>>> I think we are ok in this regard (at least in v5) without the
>>> callback. kvm holds irqfd, which holds eventfd. In a normal
>>> situation, we will
>>>
Jan Kiszka wrote:
I'm not asking for full gdbstub support at this point, just for a build
workaround at arch-level (or in arch-specific blocks, in gdbstub.c e.g.)
instead of patching generic code with global risk of regressions.
Oh, I see.
I already submitted that to Avi, making gdb_set_stop_c
mtosa...@redhat.com wrote:
smp_send_reschedule was exported (via smp_ops) in v2.6.24.
Create a compat function which schedules the IPI to keventd context,
in case interrupts are disabled, for kernels < 2.6.24.
#endif
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
+#define nr_cpu_ids NR
Sheng Yang wrote:
Is there any issue blocked this patchset?
Yes, a slow maintainer. I'll go review it now.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
Jes Sorensen wrote:
> Jan Kiszka wrote:
>> As the original change this patch (correctly) fixes broke gdbstub
>> support in qemu-kvm for all archs + it is still a deviation from
>> upstream, please take the chance and go for ia64 stubs.
>
> Jan,
>
> There's far more to do in upstream than just gdb
Jan Kiszka wrote:
As the original change this patch (correctly) fixes broke gdbstub
support in qemu-kvm for all archs + it is still a deviation from
upstream, please take the chance and go for ia64 stubs.
Jan,
There's far more to do in upstream than just gdbstubs for ia64 to be
usable :-(
We'
Jes Sorensen wrote:
> Avi Kivity wrote:
>> I agree, unless
>>
>> - we want to make gdbstub support configurable (don't see any
>> overwhelming reason for this, but maybe others do)
>> - we want to merge ia64 kvm support upstream, and don't want to impose
>> gdbstub support (though I'd recommend pro
Avi Kivity wrote:
I agree, unless
- we want to make gdbstub support configurable (don't see any
overwhelming reason for this, but maybe others do)
- we want to merge ia64 kvm support upstream, and don't want to impose
gdbstub support (though I'd recommend properly implementing gdbstub)
In an
On Thursday 07 May 2009 20:28:12 Marcelo Tosatti wrote:
> On Thu, May 07, 2009 at 03:24:15PM +0300, Avi Kivity wrote:
> > Sheng Yang wrote:
> >> Some device like VF of SRIOV only support MSI-X.
> >>
> >> With this patch, SRIOV can be enabled with KVM assigned device(all
> >> kernel space patches ar
Gregory Haskins wrote:
Chris Wright wrote:
* Gregory Haskins (ghask...@novell.com) wrote:
Chris Wright wrote:
But a free-form hypercall(unsigned long nr, unsigned long *args, size_t count)
means hypercall number and arg list must be the same in order for code
to call hyp
On Thu, May 07, 2009 at 03:24:15PM +0300, Avi Kivity wrote:
> Sheng Yang wrote:
>> Some device like VF of SRIOV only support MSI-X.
>>
>> With this patch, SRIOV can be enabled with KVM assigned device(all kernel
>> space
>> patches are ready).
>>
>>
>
> Just noticed I missed this patch. Is it
Sheng Yang wrote:
Some device like VF of SRIOV only support MSI-X.
With this patch, SRIOV can be enabled with KVM assigned device(all kernel space
patches are ready).
Just noticed I missed this patch. Is it still needed or is it obsolete?
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm
Alex Williamson wrote:
Bit 0 is the enable bit, which we not only don't want to set, but
it will stick and make us think it's an I/O port resource.
Signed-off-by: Alex Williamson
---
kvm/bios/rombios32.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/kvm/bios/
On Thu, May 07, 2009 at 01:44:38PM +0300, Avi Kivity wrote:
> I imagine this loop is present in many drivers. So why not add a helper
Let's look!
arch/x86/kernel/amd_iommu_init.c : Needs an exact number of vectors.
drivers/block/cciss.c : If it doesn't get all 4 vectors, falls back to pin mode
Avi Kivity wrote:
Jes Sorensen wrote:
Hi,
Some freak :-) put x86 specific irq routing into the generic code path,
which obviously won't work on non-x86 systems.
This patch creates kvm_arch_init_irq_routing() and moves the x86
gibberish to it's correct location :-)
Applied, thanks.
Argh,
1 - 100 of 136 matches
Mail list logo
