Re: [PATCH 8/9] VMX: work around lacking VNMI support

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

Re: [PATCH 8/9] VMX: work around lacking VNMI support

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

Re: [PATCH 8/9] VMX: work around lacking VNMI support

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

[PATCH 0/11] Fix&Enhance NMI support for KVM - v3

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

[PATCH 2/11] VMX: refactor/fix IRQ and NMI injectability determination

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 {

[PATCH 9/11] VMX: Provide support for user space injected NMIs

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

[PATCH 4/11] VMX: fix real-mode NMI support

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 =

[PATCH 8/11] kvm-x86: Support for user space injected NMIs

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 +++

[PATCH 5/11] kvm-x86: Enable NMI Watchdog via in-kernel PIT source

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

[PATCH 3/11] VMX: refactor IRQ and NMI window enabling

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

[PATCH 6/11] kvm-x86: VCPU with pending NMI is runnabled

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/

[PATCH 10/11] VMX: work around lacking VNMI support

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

[PATCH 7/11] kvm: kick NMI receiving VCPU

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 ==

[PATCH 1/11] VMX: include all IRQ window exits in statistics

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

[PATCH 11/11] kvm: Enable NMI support for userspace irqchip

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

writes to a virtio block device hungs

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

[ kvm-Bugs-2122614 ] Guests do not boot (W2k/Lilo) when using "boot=on" flag

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

Re: VMX: Host NMI triggering on NMI vmexit

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

Re: VMX: Host NMI triggering on NMI vmexit

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

[PATCH] don't enter guest after SIPI was received by a CPU

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.

Re: [PATCH 5/9] add debuging facilities to memory registration at libkvm

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

Re: [PATCH 8/9] coalesce mmio regions with an explicit call

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

Re: [PATCH 7/9] register mmio slots

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

Re: [PATCH 4/9] substitute is_allocated_mem with more general is_containing_region

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

Re: [PATCH 3/9] allow intersecting region to be on the boundary.

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

Re: [PATCH 10/11] VMX: work around lacking VNMI support

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

Re: [PATCH] don't enter guest after SIPI was received by a CPU

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

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

[Patch] Segfault with -vnc option

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

[PATCH 4/4] Add --with-kvm-trace arg to configure

./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 ++

[PATCH 1/4] Add kvm_trace.c to hack-files-x86

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

[PATCH 3/4] relay_open() compat

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

[PATCH 0/4] Allow enabling kvm_trace on external module

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

[PATCH 2/4] Hack DEFINE_SIMPLE_ATTRIBUTE for lost_records_get() also

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

Re: [Patch] Segfault with -vnc option

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]>

Re: mmotm 2008-09-22-01-36 uploaded (kvm)

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!

[PATCH 0/9][RFC] stackable dma_ops for x86

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

[PATCH 6/9] x86/iommu: change Calgary to use dma_ops register interface

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

[PATCH 2/9] x86/iommu: add stackable dma_ops registration interface

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

[PATCH 3/9] x86/iommu: change PCI-NOMMU to use dma_ops register interface

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/

[PATCH 7/9] x86/iommu: change AMD IOMMU to use dma_ops register interface

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

[PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops

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

[PATCH 4/9] x86/iommu: change SWIOTLB to use dma_ops register interface

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/

[PATCH 8/9] x86/iommu: change Intel IOMMU to use dma_ops register interface

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-

[PATCH 5/9] x86/iommu: change GART to use dma_ops register interface

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

[PATCH 1/9] x86/iommu: add necessary types for stackable dma_ops

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.

Re: [PATCH 0/9][RFC] stackable dma_ops for x86

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

Re: [PATCH 0/9][RFC] stackable dma_ops for x86

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

[patch 01/13] KVM: MMU: flush remote TLBs on large->normal entry overwrite

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

[patch 00/13] out of sync shadow v3

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

[patch 03/13] KVM: MMU: move local TLB flush to mmu_set_spte

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

[patch 04/13] KVM: MMU: do not write-protect large mappings

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

[patch 08/13] KVM: MMU: mmu_parent_walk

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

[patch 02/13] KVM: MMU: split mmu_set_spte

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 @@

[patch 07/13] KVM: x86: trap invlpg

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

[patch 05/13] KVM: MMU: mode specific sync_page

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

[patch 06/13] KVM: MMU: sync roots on mmu reload

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

[patch 09/13] KVM: MMU: awareness of new kvm_mmu_zap_page behaviour

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

[patch 13/13] KVM: MMU: add "oos_shadow" parameter to disable oos

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)

[patch 12/13] KVM: MMU: speed up mmu_unsync_walk

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

[patch 11/13] KVM: MMU: out of sync shadow core v2

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 {

[patch 10/13] KVM: MMU: mmu_convert_notrap helper

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

Re: KVM for Sparc?

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

Re: mmotm 2008-09-22-01-36 uploaded (kvm)

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

Re: KVM for Sparc?

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

Re: KVM for Sparc?

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

Re: KVM for Sparc?

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'

Re: [patch 02/10] KVM: MMU: move local TLB flush to mmu_set_spte

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

Re: [patch 02/10] KVM: MMU: move local TLB flush to mmu_set_spte

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

Re: [patch 07/10] KVM: MMU: mmu_parent_walk

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

Re: KVM for Sparc?

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

Re: [patch 09/10] KVM: MMU: out of sync shadow core v2

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; +

Re: [patch 10/10] KVM: MMU: speed up mmu_unsync_walk

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

Re: KVM for Sparc?

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

Re: [Qemu-devel] Re: [Patch] Segfault with -vnc option

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

Re: KVM for Sparc?

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

Re: KVM for Sparc?

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

Re: [patch 09/10] KVM: MMU: out of sync shadow core v2

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)) { >>>

Re: [patch 02/10] KVM: MMU: move local TLB flush to mmu_set_spte

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

Re: mmotm 2008-09-22-01-36 uploaded (kvm)

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:

Re: mmotm 2008-09-22-01-36 uploaded (kvm)

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

Re: [patch 07/10] KVM: MMU: mmu_parent_walk

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 >>

Re: mmotm 2008-09-22-01-36 uploaded (kvm)

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: > > > >

Re: KVM for Sparc?

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

Re: KVM for Sparc?

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

Re: [PATCH] Add USB sys file-system support (v5)

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

Re: [patch 09/10] KVM: MMU: out of sync shadow core v2

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) { > +

[PATCH 2/3] Move aio implementation out of raw block driver

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

[PATCH 1/3] Only call aio flush handler if set

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 +++

[PATCH 0/3] Refactor AIO to allow multiple AIO implementations

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

Re: Event channels in KVM?

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

RE: Event channels in KVM?

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

Re: Event channels in KVM?

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

Re: [PATCH 2/3] Move aio implementation out of raw block driver

* 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 >

[PATCH 3/3] Add linux aio implementation for raw block devices

* 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

Re: [Qemu-devel] Re: [PATCH] Add USB sys file-system support (v5)

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

[PATCH] Add USB sys file-system support (v6)

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

RE: Event channels in KVM?

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

Re: [PATCH 1/3] Only call aio flush handler if set

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

Re: [PATCH 0/9][RFC] stackable dma_ops for x86

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   2   >