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 Chris says it's the wrong
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
* 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
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 fine. Registers are
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
is
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.
Yeah, this
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
how MMIO
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 into
* 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 unsubscribe
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,
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 aarca...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
kvm_handle_hva relies on mmu_lock protection to safely access
the memslot structures.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm-pending/virt/kvm/kvm_main.c
===
--- kvm-pending.orig/virt/kvm/kvm_main.c
+++
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
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
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
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 mtosa...@redhat.com
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
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 mtosa...@redhat.com
Index: kvm-kmod/ia64/hack-module.awk
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
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
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 property (config
* 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
will be
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 for
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.
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 proposal is, thanks for
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 me
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, 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() asking
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
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
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
no...@sigbus.net:
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 typically use mmio).
I at least have a
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(pio_dev,
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 abstracts
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
---
101 - 135 of 135 matches
Mail list logo
