To support domain-isolation usages, the platform hardware must be
capable of uniquely identifying the requestor (source-id) for each
interrupt message. Without source-id checking for interrupt remapping
, a rouge guest/VM with assigned devices can launch interrupt attacks
to bring down anothe
Interrupt remapping table entry is 128bits. Currently, it only sets low
64bits of irte in modify_irte and free_irte. This ignores high 64bits
setting of irte, that means source-id setting will be ignored. This patch
sets the whole 128bits of irte when modify/free it. Following source-id
checking
Yuji virtualized more capabilities to guest in Xen Qemu. I think your tg3
driver can work in Xen guest with VT-d passthrough. If anyone interests, he/she
can port the code from Xen Qemu to KVM Qemu.
Regards,
Weidong
Alex Williamson wrote:
On Wed, May 6, 2009 at 11:31 AM, Nadolski, Ed
Sebastian Herbszt wrote:
Jan Kiszka wrote:
Sebastian Herbszt wrote:
Simon Bienlein wrote:
Is a support for BIOS worked on right now?
The vgabios (vgabios.c) has a FIXME should beep. Volker, do you plan
to fix this?
Which frequency should be used for the beep? Which delay?
I would try 1
Zhang, Xiantao wrote:
--- qemu-kvm.orig/vl.c
+++ qemu-kvm/vl.c
@@ -4417,13 +4417,11 @@
}
if (cpu_can_run(env))
ret = qemu_cpu_exec(env);
-#ifndef CONFIG_GDBSTUB
^^^
Don't know why change #ifdef to #ifndef in upstream, and I remember it should be ifdef
pci_enable_msix currently returns -EINVAL if you ask
for more vectors than supported by the device, which would
typically cause fallback to regular interrupts.
It's better to return the table size, making the driver retry
MSI-X with less vectors.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Bugs item #2506814, was opened at 2009-01-14 11:38
Message generated for change (Comment added) made by mellen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2506814group_id=180599
Please note that this message will contain a full copy of the comment
On Thursday 07 May 2009 16:28:41 Michael S. Tsirkin wrote:
pci_enable_msix currently returns -EINVAL if you ask
for more vectors than supported by the device, which would
typically cause fallback to regular interrupts.
It's better to return the table size, making the driver retry
MSI-X with
Bugs item #2506814, was opened at 2009-01-14 11:38
Message generated for change (Comment added) made by cova
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2506814group_id=180599
Please note that this message will contain a full copy of the comment
Hi,
Don't like ugly assembler errors because QEMU tries to build some x86
assembly code which isn't needed on non-x86.
Jes
Do not try to build extboot when INSTALL_BLOBS is not set.
Signed-off-by: Jes Sorensen j...@sgi.com
---
Makefile |2 ++
configure |1 +
2 files changed, 3
On Thursday 07 May 2009 17:05:06 Michael S. Tsirkin wrote:
On Thu, May 07, 2009 at 04:51:24PM +0800, Sheng Yang wrote:
On Thursday 07 May 2009 16:28:41 Michael S. Tsirkin wrote:
pci_enable_msix currently returns -EINVAL if you ask
for more vectors than supported by the device, which would
Jes Sorensen wrote:
Hi,
Don't like ugly assembler errors because QEMU tries to build some x86
assembly code which isn't needed on non-x86.
.PHONY: kvm/extboot
+ifdef INSTALL_BLOBS
all: kvm/extboot
kvm/extboot:
@@ -427,3 +428,4 @@
|| ! cmp -s pc-bios/extboot.bin $@/extboot.bin;
On Thu, May 07, 2009 at 04:51:24PM +0800, Sheng Yang wrote:
On Thursday 07 May 2009 16:28:41 Michael S. Tsirkin wrote:
pci_enable_msix currently returns -EINVAL if you ask
for more vectors than supported by the device, which would
typically cause fallback to regular interrupts.
It's
Zhang, Xiantao wrote:
Jes Sorensen wrote:
Hi,
The latest changes to qemu-kvm breaks miserably if one tries to build
without CONFIG_GDBSTUB.
Jes
--- qemu-kvm.orig/vl.c
+++ qemu-kvm/vl.c
@@ -4417,13 +4417,11 @@
}
if (cpu_can_run(env))
ret =
On Thu, May 07, 2009 at 05:10:46PM +0800, Sheng Yang wrote:
I think driver should read from capability list to know how many vector
supported by this device before enable MSI-X for device, as
pci_msix_table_size() did...
Drivers can do this, but it's more code. Since pci_enable_msix
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.
--
error compiling
Avi Kivity wrote:
Seems a bit heavy handed. blobs != extboot.
How about instead:
build-targets-x86 = kvm/extboot
all: $(build-targets-$(ARCH))
(or something similar that builds)
There's no problem that cannot be fixed by applying an appropriately
large hammer :-)
This one
On Thursday 07 May 2009 17:27:31 Matthew Wilcox wrote:
On Thu, May 07, 2009 at 04:51:24PM +0800, Sheng Yang wrote:
On Thursday 07 May 2009 16:28:41 Michael S. Tsirkin wrote:
pci_enable_msix currently returns -EINVAL if you ask
for more vectors than supported by the device, which would
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
have eventfd with 2 references. If userspace closes the eventfd, it
will drop 1 of
Jes Sorensen wrote:
There's no problem that cannot be fixed by applying an appropriately
large hammer :-)
This one works for me.
applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
Avi Kivity wrote:
Zhang, Xiantao wrote:
Jes Sorensen wrote:
Hi,
The latest changes to qemu-kvm breaks miserably if one tries to
build without CONFIG_GDBSTUB.
Jes
--- qemu-kvm.orig/vl.c
+++ qemu-kvm/vl.c
@@ -4417,13 +4417,11 @@
}
if (cpu_can_run(env))
On Thu, May 07, 2009 at 05:40:15PM +0800, Sheng Yang wrote:
It's indeed weird. Why the semantic of pci_enable_msix can be changed to
enable msix, or tell me how many vector do you have? You can simply call
pci_msix_table_size() to get what you want, also without any more work, no? I
can't
Zhang, Xiantao wrote:
Avi Kivity wrote:
Zhang, Xiantao wrote:
Jes Sorensen wrote:
Hi,
The latest changes to qemu-kvm breaks miserably if one tries to
build without CONFIG_GDBSTUB.
Jes
--- qemu-kvm.orig/vl.c
+++ qemu-kvm/vl.c
@@ -4417,13 +4417,11 @@
}
Jes Sorensen wrote:
Hi,
This one is needed to build on ia64.
Applied, thanks.
--
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
More majordomo info at
Alex Williamson wrote:
Thanks Avi, I think you got the important bits. I might recommend the
following change to keep this contained to a version_id 7 load and bail
if vnet header support is required, but not available. Thanks,
Alex
kvm: virtio-net: Cleanup load from vnet header saved image
On Thursday 07 May 2009 17:53:02 Matthew Wilcox wrote:
On Thu, May 07, 2009 at 05:40:15PM +0800, Sheng Yang wrote:
It's indeed weird. Why the semantic of pci_enable_msix can be changed to
enable msix, or tell me how many vector do you have? You can simply
call pci_msix_table_size() to get
Christian Borntraeger wrote:
Why can't this be done from the timer context (after adjusting the locks)?
It can be done, in fact I did that in my first version. The thing is, we would
need to change all local_int.locks to spinlock_irqs, since standard timers are
softirqs and hrtimers and
On Thu, 2009-05-07 at 03:53 -0600, Matthew Wilcox wrote:
On Thu, May 07, 2009 at 05:40:15PM +0800, Sheng Yang wrote:
It's indeed weird. Why the semantic of pci_enable_msix can be changed to
enable msix, or tell me how many vector do you have? You can simply call
pci_msix_table_size() to
On Thursday 07 May 2009 18:23:50 Michael Ellerman wrote:
On Thu, 2009-05-07 at 03:53 -0600, Matthew Wilcox wrote:
On Thu, May 07, 2009 at 05:40:15PM +0800, Sheng Yang wrote:
It's indeed weird. Why the semantic of pci_enable_msix can be changed
to enable msix, or tell me how many vector do
Am Thursday 07 May 2009 12:19:32 schrieb Avi Kivity:
Makes sense.
Back when irqsave/irqrestore were expensive on x86 (P4 days, I think it
was ~100 cycles) there was talk of using a software irq disable flag
instead of using the hardware support. So
- local_irq_disable() sets a flag
On Thu, May 07, 2009 at 06:19:53PM +0800, Sheng Yang wrote:
On Thursday 07 May 2009 17:53:02 Matthew Wilcox wrote:
On Thu, May 07, 2009 at 05:40:15PM +0800, Sheng Yang wrote:
It's indeed weird. Why the semantic of pci_enable_msix can be changed to
enable msix, or tell me how many vector
Michael Ellerman wrote:
Not to mention that there's no guarantee that you'll get as many
interrupts as the device supports, so you should really be coding to
cope with that anyway. Like the example in MSI-HOWTO.txt:
197 static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
Avi Kivity wrote:
Zhang, Xiantao wrote:
Jes Sorensen wrote:
Hi,
The latest changes to qemu-kvm breaks miserably if one tries to build
without CONFIG_GDBSTUB.
Jes
--- qemu-kvm.orig/vl.c
+++ qemu-kvm/vl.c
@@ -4417,13 +4417,11 @@
}
if (cpu_can_run(env))
Jan Kiszka wrote:
In upstream. Please fix it in upstream and qemu-kvm.git will get the
fix from there.
Given that CONFIG_GDBSTUB is always true upstream, I tend to say:
Finally drop it upstream and keep this (or a more arch-local) workaround
for missing ia64 gdbstub support downstream.
Avi Kivity wrote:
Jan Kiszka wrote:
In upstream. Please fix it in upstream and qemu-kvm.git will get the
fix from there.
Given that CONFIG_GDBSTUB is always true upstream, I tend to say:
Finally drop it upstream and keep this (or a more arch-local) workaround
for missing ia64 gdbstub
Jan Kiszka 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 any
Bugs item #2506814, was opened at 2009-01-14 11:38
Message generated for change (Comment added) made by mellen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2506814group_id=180599
Please note that this message will contain a full copy of the comment
Avi Kivity wrote:
Jan Kiszka 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
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,
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
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 alex.william...@hp.com
---
kvm/bios/rombios32.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
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
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 still needed or
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 are ready).
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
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 properly
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 :-(
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 gdbstubs for
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
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
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
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
have eventfd with
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 holds eventfd. In a
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 m...@redhat.com
---
Here's a draft set of patches for MSI-X support in the guest. It still
needs to be tested
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 m...@redhat.com
---
drivers/block/virtio_blk.c | 11 +++---
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 m...@redhat.com
---
drivers/virtio/virtio_pci.c | 45 +-
1 files changed, 35 insertions(+), 10 deletions(-)
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 m...@redhat.com
---
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
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
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
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 when
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,
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
Signed-off-by: Beth Kon e...@us.ibm.com
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
commit 01813db8627e74018c8cec90df7e345839351f23
Author: root r...@xendinar01.amd.com
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
Signed-off-by: Beth Kon e...@us.ibm.com
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);
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
(copying Ingo)
Mark Langsdorf wrote:
commit 01813db8627e74018c8cec90df7e345839351f23
Author: root r...@xendinar01.amd.com
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
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
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
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
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 alex.william...@hp.com
---
bios/rombios32.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git
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
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
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 each
other.
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 benefit with it yet
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 alex.william...@hp.com
---
hw/device-assignment.c |2 +-
kvm/libkvm/libkvm.c|2 +-
2 files
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
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
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
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
reinvent the
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
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
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 making mmio a pv_op
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 =
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
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 set the
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
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 understand
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
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 ioread()/iowrite() call
* 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 case.
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 any reason why
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
* 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-mmio hit that 2.07us
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
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
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
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 of a
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 we
1 - 100 of 135 matches
Mail list logo
