Gleb Natapov wrote:
> On Sun, Sep 21, 2008 at 06:57:32PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> Hi Jan,
>>>
>>> On Fri, Sep 19, 2008 at 02:04:37PM +0200, Jan Kiszka wrote:
static void vmx_inject_irq(struct kvm_vcpu *vcpu, int irq)
{
struct vcpu_vmx *vmx = to_vmx(vcp
On Mon, Sep 22, 2008 at 09:19:27AM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Sun, Sep 21, 2008 at 06:57:32PM +0200, Jan Kiszka wrote:
> >> Gleb Natapov wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, Sep 19, 2008 at 02:04:37PM +0200, Jan Kiszka wrote:
> static void vmx_inject_irq(struct
Gleb Natapov wrote:
> On Mon, Sep 22, 2008 at 09:19:27AM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Sun, Sep 21, 2008 at 06:57:32PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
> Hi Jan,
>
> On Fri, Sep 19, 2008 at 02:04:37PM +0200, Jan Kiszka wrote:
>> static void
The third revision of this series comes with several bug fixes, both
regarding the series itself and existing KVM code. In details:
- break out of in-kernel halt if NMI is pending (patch 6)
- kick NMI receiving VCPU from LAPIC and IOAPIC (patch 7)
- take user space requested NMI window into acc
There are currently two ways in VMX to check if an IRQ or NMI can be
injected:
- vmx_{nmi|irq}_enabled and
- vcpu.arch.{nmi|interrupt}_window_open.
Even worse, one test (at the end of vmx_vcpu_run) uses an inconsistent,
likely incorrect logic.
This patch consolidates and unifies the tests over
{
This patch adds the required bits to the VMX side for user space
injected NMIs. As with the preexisting in-kernel irqchip support, the
CPU must provide the "virtual NMI" feature for proper tracking of the
NMI blocking state.
Based on the original patch by Sheng Yang.
Signed-off-by: Jan Kiszka <[E
Fix NMI injection in real-mode with the same pattern we perform IRQ
injection.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c | 13 +
1 file changed, 13 insertions(+)
Index: b/arch/x86/kvm/vmx.c
=
Introduces the KVM_NMI IOCTL to the generic x86 part of KVM for
injecting NMIs from user space and also extends the statistic report
accordingly.
Based on the original patch by Sheng Yang.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 46 +++
LINT0 of the LAPIC can be used to route PIT events as NMI watchdog ticks
into the guest. This patch aligns the in-kernel irqchip emulation with
the user space irqchip with already supports this feature. The trick is
to route PIT interrupts to all LAPIC's LVT0 lines.
Rebased and slightly polished p
do_interrupt_requests and vmx_intr_assist go different way for
achieving the same: enabling the nmi/irq window start notification.
Unify their code over enable_{irq|nmi}_window, get rid of a redundant
call to enable_intr_window instead of direct enable_nmi_window
invocation and unroll enable_intr_w
Ensure that a VCPU with pending NMIs is considered runnable.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/
Older VMX supporting CPUs do not provide the "Virtual NMI" feature for
tracking the NMI-blocked state after injecting such events. For now
KVM is unable to inject NMIs on those CPUs.
Derived from Sheng Yang's suggestion to use the IRQ window notification
for detecting the end of NMI handlers, this
Kick the NMI-receiving VCPU in case the triggering caller runs in a
different context.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
arch/x86/kvm/lapic.c |1 +
virt/kvm/ioapic.c|1 +
2 files changed, 2 insertions(+)
Index: b/arch/x86/kvm/lapic.c
==
irq_window_exits only tracks IRQ window exits due to user space
requests, nmi_window_exits include all exits. The latter makes more
sense, so let's adjust irq_window_exits accounting.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c |2 +-
1 file changed, 1 insertion(+), 1
Make use of the new KVM_NMI IOCTL to push NMIs into the KVM guest if the
user space APIC emulation or some other source raised them.
In order to use the 'nmi' monitor command which asynchroniously injects
NMIs for the given CPU, a new service called kvm_inject_interrupt is
required. This will invo
Hello! It's my first email to this list.. ;)
After experimenting for some time with KVM on linux
(both host and guests are linux machines), I placed
one virtual machine into production use, and almost
immediately come... issues. Here's how it looks like
from the guest:
Sep 21 10:35:52 hobbit ke
Bugs item #2122614, was opened at 2008-09-22 11:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2122614&group_id=180599
Please note that this message will contain a full copy
Avi Kivity wrote:
> Jan Kiszka wrote:
>> Sheng,
>>
>> out of curiosity: vmx_vcpu_run invokes 'int $2' to trigger a host NMI if
>> the VM exited due to an external NMI event. According to Intel specs I
>> have, software-triggered NMIs do not block hardware NMIs. So are we
>> facing the risk to recei
Jan Kiszka wrote:
Maybe the answer is to generate the local nmi via an IPI-to-self command
to the local apic.
Going this way leaves me with a few questions: Will it be OK for the
related mainainers to export the required service?
If we can make a case for it (I think we can), then I don
Don't enter guest after SIPI was issued.
CPU should process SIPI message before entering a guest mode again.
kvm_arch_vcpu_runnable() return true if CPU is in SIPI state, so
we can't call it here.
Signed-off-by: Gleb Natapov <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.
On Sat, Sep 20, 2008 at 11:34:55AM -0700, Avi Kivity wrote:
> Glauber Costa wrote:
>> +#ifdef DEBUG_MEMREG
>> +fprintf(stderr, "%s, memory: gpa: %llx, size: %llx, uaddr: %llx, slot:
>> %x, flags: %lx\n",
>> +__func__, memory.guest_phys_addr, memory.memory_size,
>> +memo
On Sat, Sep 20, 2008 at 11:39:44AM -0700, Avi Kivity wrote:
> Glauber Costa wrote:
>> Remove explicit calls to mmio coalescing. Rather,
>> include it in the registration functions.
>>
>> index 5ae3960..2d97b34 100644
>> --- a/qemu/hw/e1000.c
>> +++ b/qemu/hw/e1000.c
>> @@ -942,18 +942,6 @@ e1000_mm
On Sat, Sep 20, 2008 at 11:38:22AM -0700, Avi Kivity wrote:
> Glauber Costa wrote:
>> By analysing phys_offset, we know whether a region is an mmio region
>> or not. If it is, register it as so. We don't reuse the same slot
>> infrastructure already existant, because there is a relationship between
On Sat, Sep 20, 2008 at 11:33:56AM -0700, Avi Kivity wrote:
> Glauber Costa wrote:
>> is_allocated_mem is a function that checks if every relevant aspect of the
>> memory slot
>> match (start and size). Replace it with a more generic function that checks
>> if a memory
>> region is totally contai
On Sat, Sep 20, 2008 at 11:32:48AM -0700, Avi Kivity wrote:
> Glauber Costa wrote:
>> Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
>> ---
>> libkvm/libkvm.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
>> index e768e44..f
On Mon, Sep 22, 2008 at 09:59:07AM +0200, Jan Kiszka wrote:
> @@ -2356,6 +2384,19 @@ static void vmx_inject_nmi(struct kvm_vc
> {
> struct vcpu_vmx *vmx = to_vmx(vcpu);
>
> + if (!cpu_has_virtual_nmis()) {
> + /*
> + * Tracking the NMI-blocked state in software
Looks good. Thanks Gleb.
On Mon, Sep 22, 2008 at 02:28:53PM +0300, Gleb Natapov wrote:
> Don't enter guest after SIPI was issued.
>
> CPU should process SIPI message before entering a guest mode again.
> kvm_arch_vcpu_runnable() return true if CPU is in SIPI state, so
> we can't call it here.
>
KVM: PIC: enhance IPI avoidance
The PIC code makes little effort to avoid kvm_vcpu_kick(), resulting in
unnecessary guest exits in some conditions.
For example, if the timer interrupt is routed through the IOAPIC, IRR
for IRQ 0 will get set but not cleared, since the APIC is handling the
acks.
T
Hi!
I observed a reproducible segmentation fault of kvm under the following
conditions:
- start kvm with -vnc option, using cirrus vga (default)
- connect to the vnc console
- boot windows xp
- login
- screen resolutions 1024x768
- change to qemu monitor (ctrl-alt-2)
- wait for the windows
./configure --with-kvm-trace will set a CONFIG_KVM_TRACE option on a
kernel/config.kbuild file. This file can be included from the Kbuild
files to get kvm-specific CONFIG_* definitions.
Signed-off-by: Eduardo Habkost <[EMAIL PROTECTED]>
---
.gitignore|1 +
configure | 11 ++
We will add some hacks for kvm_trace.c on hack-module.awk
Signed-off-by: Eduardo Habkost <[EMAIL PROTECTED]>
---
kernel/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/Makefile b/kernel/Makefile
index 3f5f6da..151183a 100644
--- a/kernel/Makefile
+++ b/ke
On 2.6.21 a new parameter was added to relay_open(). Handle this parameter
on kvm_relay_open() if needed.
Signed-off-by: Eduardo Habkost <[EMAIL PROTECTED]>
---
kernel/external-module-compat-comm.h | 19 +++
kernel/external-module-compat.c | 22 ++
ker
This series adds compat code to allow enabling kvm_trace when building
KVM as an external module on older kernels.
The most hackish part is the last patch, that adds --with-kvm-trace to
configure and adds an include to a generated file on kernel/x86/Kbuild. It
doesn't look pretty, so suggestions o
Change the DEFINE_SIMPLE_ATTRIBUTE pattern to match the lost_records_get()
definition also, so kvm_trace can compile on older kernels.
Signed-off-by: Eduardo Habkost <[EMAIL PROTECTED]>
---
kernel/x86/hack-module.awk |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kern
Jan Niehusmann wrote:
Hi!
Hi Jan,
Very good catch. My only suggestion would be to move this check into
cirrus_vga.c and vmware_vga.c. Even better would be to introduce a
wrapper around callers of dpy_copy.
Regards,
Anthony Liguori
Signed-off-by: Jan Niehusmann <[EMAIL PROTECTED]>
On Mon, 22 Sep 2008 01:38:58 -0700 [EMAIL PROTECTED] wrote:
> The mm-of-the-moment snapshot 2008-09-22-01-36 has been uploaded to
>
>http://userweb.kernel.org/~akpm/mmotm/
>
> It contains the following patches against 2.6.27-rc7:
ERROR: "intel_iommu_found" [arch/x86/kvm/kvm.ko] undefined!
Hi,
this patch series implements stackable dma_ops on x86. This is useful to
be able to fall back to a different dma_ops implementation if one can
not handle a particular device (as necessary for example with
paravirtualized device passthrough or if a hardware IOMMU only handles a
subset of availa
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-calgary_64.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index fe7695e..e2f2f60 100644
--- a/arch/x86/kerne
This patch adds the function x86_register_dma_ops which drivers can use
to register their specific dma_ops implementations. The patch also adds
the data structures necessary for registration and the initializtion of
them.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-dma
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-nommu.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index 1c1c98a..0cbecb9 100644
--- a/arch/x86/kernel/pci-nommu.c
+++ b/arch/
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kernel/amd_iommu.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/amd_iommu.c b/arch/x86/kernel/amd_iommu.c
index 6f7b974..7aa9824 100644
--- a/arch/x86/kernel/amd_iommu.c
+++ b/arch/x86/kern
This patch enables stackable dma_ops on x86. To do this, it also enables
the per-device dma_ops on i386.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-dma.c | 26 ++
include/asm-x86/device.h |6 +++---
include/asm-x86/dma-mapping.h
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-dma.c|6 +-
arch/x86/kernel/pci-swiotlb_64.c | 16 +++-
include/asm-x86/swiotlb.h|1 +
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
drivers/pci/intel-iommu.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 6c4c1c3..283e65f 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-gart_64.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index 508ef47..c5891c9 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/a
This patch extends the x86 dma_ops structure so that we can queue it
into a list. It also adds a device_supported callback. It can be used to
find out if a registered dma_ops implementation can handle a given
device. Further it adds an enum with dma_ops implementation types
possible in the future.
On Mon, 22 Sep 2008 20:21:12 +0200
Joerg Roedel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> this patch series implements stackable dma_ops on x86. This is useful
> to be able to fall back to a different dma_ops implementation if one
> can not handle a particular device (as necessary for example with
> p
On Mon, Sep 22, 2008 at 11:36:19AM -0700, Arjan van de Ven wrote:
> On Mon, 22 Sep 2008 20:21:12 +0200
> Joerg Roedel <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > this patch series implements stackable dma_ops on x86. This is useful
> > to be able to fall back to a different dma_ops implementatio
It is necessary to flush all TLB's when a large spte entry is
overwritten with a normal page directory pointer.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/paging_tmpl.h
===
--- kvm.orig/arch/x86/kvm/pa
Adressing v2 comments, and with an option to disable oos.
Windows 2003 DDK build (4-way guest) results:
mainline oos
04:37 03:42( ~= -20% )
kernel builds on 4-way guest improve by 10%.
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EM
Since the sync page path can collapse flushes.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -1189,10 +1189,8 @@ static int set_spte
There is not much point in write protecting large mappings. This
can only happen when a page is shadowed during the window between
is_largepage_backed and mmu_lock acquision. Zap the entry instead, so
the next pagefault will find a shadowed page via is_largepage_backed and
fallback to 4k translatio
Introduce a function to walk all parents of a given page, invoking a handler.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -147,6
Split the spte entry creation code into a new set_spte function.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -1148,44 +1148,13 @@
With pages out of sync invlpg needs to be trapped. For now simply nuke
the entry.
Untested on AMD.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86
Examine guest pagetable and bring the shadow back in sync. Caller is responsible
for local TLB flush before re-entering guest mode.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arc
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -1471,6 +1471,41 @@ static void mmu_alloc_roots(struct kvm_v
vcpu->arch.mmu.roo
kvm_mmu_zap_page will soon zap the unsynced children of a page. Restart
list walk in such case.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm
Subject says it all.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -70,6 +70,9 @@ static int dbg = 0;
module_param(dbg, bool, 0644)
Cache the unsynced children information in a per-page bitmap.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -927,6 +927,52 @@ static
Allow guest pagetables to go out of sync.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -147,6 +147,10 @@ struct kvm_shadow_walk {
Need to convert shadow_notrap_nonpresent -> shadow_trap_nonpresent when
unsyncing pages.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
Blue Swirl wrote:
Hi,
Sorry for cross-posting (and because I used the wrong address in the
first time for KVM, sorry for the duplicate on Sparclinux).
Sparc host support for Qemu is getting close
to ready, I can already run a Sparc32 system emulator on
OpenBSD/Sparc64 and there is some limi
On Mon, 22 Sep 2008 11:19:47 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Sep 2008 01:38:58 -0700 [EMAIL PROTECTED] wrote:
>
> > The mm-of-the-moment snapshot 2008-09-22-01-36 has been uploaded to
> >
> >http://userweb.kernel.org/~akpm/mmotm/
> >
> > It contains the following
On Mon, 2008-09-22 at 14:34 -0500, Anthony Liguori wrote:
> Blue Swirl wrote:
> > Hi,
> >
> > Sorry for cross-posting (and because I used the wrong address in the
> > first time for KVM, sorry for the duplicate on Sparclinux).
> >
> > Sparc host support for Qemu is getting close
> > to ready, I
From: Anthony Liguori <[EMAIL PROTECTED]>
Date: Mon, 22 Sep 2008 14:34:21 -0500
> Blue Swirl wrote:
> > But I think we could already start early drafting of what KVM support
> > for Sparc32 and Sparc64 would mean. Because of certain problems in the
> > V9 instruction set design (V8 rett reuse f
From: Hollis Blanchard <[EMAIL PROTECTED]>
Date: Mon, 22 Sep 2008 15:18:39 -0500
> It would be even more interesting to implement host support on the Sparc
> processors with hardware virtualization support.
That's just a lot of protocol and userland work, rather than much
kernel stuff.
To me it'
Marcelo Tosatti wrote:
I think we had cases where the spte.pfn contents changed, for example
when a large page was replaced by a normal page,
True. And the TLB is not flushed now for large->normal replace, in case
the pte thats faulting is read-only. The local (and remote) TLB's must
Marcelo Tosatti wrote:
I think we had cases where the spte.pfn contents changed, for example
when a large page was replaced by a normal page,
True. And the TLB is not flushed now for large->normal replace, in case
the pte thats faulting is read-only. The local (and remote) TLB's must
Marcelo Tosatti wrote:
On Fri, Sep 19, 2008 at 05:56:46PM -0700, Avi Kivity wrote:
+ } while (level > start_level-1);
+}
+
Could be much simplified with recursion, no? As the depth is limited to
4, there's no stack overflow problem.
The early version was recursive, but
On Mon, Sep 22, 2008 at 3:18 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> It would be even more interesting to implement host support on the Sparc
> processors with hardware virtualization support.
Does Sparc processors also have 'virtualization support' as an extra
feature? i thought that 'n
Marcelo Tosatti wrote:
+ while (parent->unsync_children) {
+ for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
+ u64 ent = sp->spt[i];
+
+ if (is_shadow_present_pte(ent)) {
+ struct kvm_mmu_page *child;
+
Marcelo Tosatti wrote:
Also, it may make sense to replace it with an array of u16s.
Why?
They'll be usually empty or near-empty, no? In which case the array is
faster and smaller.
But I don't think the difference is measurable. So scratch that remark.
--
I have a truly marvellous
From: "Javier Guerra" <[EMAIL PROTECTED]>
Date: Mon, 22 Sep 2008 15:31:07 -0500
> On Mon, Sep 22, 2008 at 3:18 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > It would be even more interesting to implement host support on the Sparc
> > processors with hardware virtualization support.
>
> Does
2008/9/22 Anthony Liguori <[EMAIL PROTECTED]>:
> Jan Niehusmann wrote:
>>
>> Hi!
>>
>
> Hi Jan,
>
> Very good catch. My only suggestion would be to move this check into
> cirrus_vga.c and vmware_vga.c. Even better would be to introduce a wrapper
> around callers of dpy_copy.
Yes, I don't think h
On Mon, 2008-09-22 at 13:26 -0700, David Miller wrote:
> From: Hollis Blanchard <[EMAIL PROTECTED]>
> Date: Mon, 22 Sep 2008 15:18:39 -0500
>
> > It would be even more interesting to implement host support on the Sparc
> > processors with hardware virtualization support.
>
> That's just a lot of
On Mon, 2008-09-22 at 15:31 -0500, Javier Guerra wrote:
> On Mon, Sep 22, 2008 at 3:18 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > It would be even more interesting to implement host support on the Sparc
> > processors with hardware virtualization support.
>
> Does Sparc processors also ha
On Mon, Sep 22, 2008 at 11:41:14PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
+ while (parent->unsync_children) {
+ for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
+ u64 ent = sp->spt[i];
+
+ if (is_shadow_present_pte(ent)) {
>>>
On Mon, Sep 22, 2008 at 11:26:36PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>
>
>
>>> I think we had cases where the spte.pfn contents changed, for example
>>> when a large page was replaced by a normal page,
>>>
>>
>> True. And the TLB is not flushed now for large->normal replac
On Monday, September 22, 2008 12:52 pm Andrew Morton wrote:
> On Mon, 22 Sep 2008 11:19:47 -0700
>
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > On Mon, 22 Sep 2008 01:38:58 -0700 [EMAIL PROTECTED] wrote:
> > > The mm-of-the-moment snapshot 2008-09-22-01-36 has been uploaded to
> > >
> > >http:
On Monday, September 22, 2008 2:58 pm Jesse Barnes wrote:
> On Monday, September 22, 2008 12:52 pm Andrew Morton wrote:
> > On Mon, 22 Sep 2008 11:19:47 -0700
> >
> > Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > On Mon, 22 Sep 2008 01:38:58 -0700 [EMAIL PROTECTED] wrote:
> > > > The mm-of-the-mome
On Mon, Sep 22, 2008 at 11:30:51PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> On Fri, Sep 19, 2008 at 05:56:46PM -0700, Avi Kivity wrote:
>>
+ } while (level > start_level-1);
+}
+
>>> Could be much simplified with recursion, no? As the depth is limited
>>
On Mon, 22 Sep 2008 14:58:52 -0700
Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Monday, September 22, 2008 12:52 pm Andrew Morton wrote:
> > On Mon, 22 Sep 2008 11:19:47 -0700
> >
> > Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > On Mon, 22 Sep 2008 01:38:58 -0700 [EMAIL PROTECTED] wrote:
> > > >
From: Hollis Blanchard <[EMAIL PROTECTED]>
Date: Mon, 22 Sep 2008 16:25:51 -0500
> On Mon, 2008-09-22 at 13:26 -0700, David Miller wrote:
> > From: Hollis Blanchard <[EMAIL PROTECTED]>
> > Date: Mon, 22 Sep 2008 15:18:39 -0500
> >
> > > It would be even more interesting to implement host support
From: Hollis Blanchard <[EMAIL PROTECTED]>
Date: Mon, 22 Sep 2008 16:27:40 -0500
> On Mon, 2008-09-22 at 15:31 -0500, Javier Guerra wrote:
> > On Mon, Sep 22, 2008 at 3:18 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > > It would be even more interesting to implement host support on the Sparc
TJ wrote:
Demoted to dprintf().
--
This patch adds support for host USB devices discovered via:
/sys/bus/usb/devices/* and opened from /dev/bus/usb/*/*
/dev/bus/usb/devices and opened from /dev/bus/usb/*/*
in addition to the existing discovery via:
/proc/bu
On Mon, Sep 22, 2008 at 06:55:03PM -0300, Marcelo Tosatti wrote:
> On Mon, Sep 22, 2008 at 11:41:14PM +0300, Avi Kivity wrote:
> > Marcelo Tosatti wrote:
> +while (parent->unsync_children) {
> +for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
> +
This patch moves the existing posix aio implementation out of block-raw-posix.c
into aio-posix.c. Added in a per-block device aio driver abstraction.
Block-raw-posix invokes the aio driver methods, .submit, .flush, and .cancel as
needed. aio-posix.c contains the posix aio implementation.
The ch
If the aio handler doesn't register an io_flush handler, we'd SEGV; fix that by
only calling the flush handler if set. BTW, aio handlers *should* register an
io_flush routine.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff --git a/aio.c b/aio.c
index 687e4be..2bb3ed4 100644
--- a/aio.c
+++
The patchset adds additional AIO driver abstraction to the block raw driver to
support multiple aio implementations for each device. The first patch pulls
the posix aio implementation out of the block-raw device using a generic call
to the newly created AIO Driver structure. The posix aio impleme
Thanks for the info, I've been looking into it by trying to look
around kvm source code.
Apparently I have to write a kernel driver for the guest os and then
also write backend driver and modify qemu to use it? Is that correct?
That seems ugly, especially since now my io goes guest->guest kernel
dr
Matt Anger wrote:
> Thanks for the info, I've been looking into it by trying
> to look
> around kvm source code.
> Apparently I have to write a kernel driver for the guest
> os and then
> also write backend driver and modify qemu to use it? Is
> that correct?
> That seems ugly, especially since
I was referring to the bounce from host kernel to qemu and then back
to the host kernel for my BE driver.
Xen:
guest -> guest kernel driver-> host kernel driver
For both situations I need a FE and BE driver, but for KVM I need to
modify QEMU and teach it how to pass the virtio calls to my Host
dri
* Ryan Harper <[EMAIL PROTECTED]> [2008-09-22 18:18]:
> This patch moves the existing posix aio implementation out of
> block-raw-posix.c
> into aio-posix.c. Added in a per-block device aio driver abstraction.
> Block-raw-posix invokes the aio driver methods, .submit, .flush, and .cancel
> as
>
* Ryan Harper <[EMAIL PROTECTED]> [2008-09-22 18:18]:
> This patch adds a linux aio raw block driver implementation. If a raw block
> device is opened with cached=off (O_DIRECT) then we can utilize linux aio to
> submit io to/from the block device. Utilizing linux aio allows for multiple
> outsta
On Mon, 2008-09-22 at 17:37 -0500, Anthony Liguori wrote:
> This patch is still white spaced damaged.
> Is identical to this chunk with the exception of whitespace. But
> curiously, not enough white space to warrant such a large diff. I broke
> out ediff-buffers to verify this. Did you refor
This patch adds support for host USB devices discovered via:
/sys/bus/usb/devices/* and opened from /dev/bus/usb/*/*
/dev/bus/usb/devices and opened from /dev/bus/usb/*/*
in addition to the existing discovery via:
/proc/bus/usb/devices and opened from /proc/bus/usb/*/*
Signed-off-by: TJ <[EMAIL
Matt Anger wrote:
> I was referring to the bounce from host kernel to qemu
> and then back
> to the host kernel for my BE driver.
> Xen:
> guest -> guest kernel driver-> host kernel driver
>
> For both situations I need a FE and BE driver, but for
> KVM I need to modify QEMU and teach it how to p
Ryan Harper wrote:
If the aio handler doesn't register an io_flush handler, we'd SEGV; fix that by
only calling the flush handler if set. BTW, aio handlers *should* register an
io_flush routine.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff --git a/aio.c b/aio.c
index 687e4be..2bb3ed4 10
Joerg Roedel wrote:
> Its implemented using the per-device dma-ops already there. With this
> patches there is a list of available dma_ops implementations which are
> asked in a particular order if they can handle the device. The first
> implementation which returns true is assigned to the device a
1 - 100 of 107 matches
Mail list logo