Is kvm-kmod still supported?

I've been maintaining a fork for research and tinkering. Is the kvm-kmod standalone module still supported or should I be using the full Linux tree? I find kvm-kmod convenient to keep the source independent of the kernel tree, but I also want to be using the latest and greatest. The

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Mon, Dec 28, 2015 at 03:20:10AM +, Dong, Eddie wrote: > > > > > > Even if the device driver doesn't support migration, you still want to > > > migrate VM? That maybe risk and we should add the "bad path" for the > > > driver at least. > > > > At a minimum we should have support for

RE: [Qemu-devel] live migration vs device assignment (motivation)

Hello! > A dedicated IRQ per device for something that is a system wide event > sounds like a waste. I don't understand why a spec change is strictly > required, we only need to support this with the specific virtual bridge > used by QEMU, so I think that a vendor specific capability will do. >

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Sun, Dec 27, 2015 at 01:45:15PM -0800, Alexander Duyck wrote: > On Sun, Dec 27, 2015 at 1:21 AM, Michael S. Tsirkin wrote: > > On Fri, Dec 25, 2015 at 02:31:14PM -0800, Alexander Duyck wrote: > >> The PCI hot-plug specification calls out that the OS can optionally > >>

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Mon, Dec 28, 2015 at 11:52:43AM +0300, Pavel Fedin wrote: > Hello! > > > A dedicated IRQ per device for something that is a system wide event > > sounds like a waste. I don't understand why a spec change is strictly > > required, we only need to support this with the specific virtual bridge

Re: How to reserve guest physical region for ACPI

On Mon, Dec 28, 2015 at 10:39:04AM +0800, Xiao Guangrong wrote: > > Hi Michael, Paolo, > > Now it is the time to return to the challenge that how to reserve guest > physical region internally used by ACPI. > > Igor suggested that: > | An alternative place to allocate reserve from could be high

[PATCH v2 0/7] KVM: Hyper-V SynIC timers migration fixes

During testing of Windows 2012R2 guest migration with Hyper-V SynIC timers enabled we found several bugs which lead to restoring guest in a hung state. This patch series provides several fixes to make the migration of guest with Hyper-V SynIC timers enabled succeed. The series applies on top of

[PATCH v2 5/7] kvm/x86: Hyper-V fix SynIC timer disabling condition

Hypervisor Function Specification(HFS) doesn't require to disable SynIC timer at timer config write if timer->count = 0. So drop this check, this allow to load timers MSR's during migration restore, because config are set before count in QEMU side. Also fix condition according to HFS

[PATCH v2 7/7] kvm/x86: Update SynIC timers on guest entry only

Consolidate updating the Hyper-V SynIC timers in a single place: on guest entry in processing KVM_REQ_HV_STIMER request. This simplifies the overall logic, and makes sure the most current state of msrs and guest clock is used for arming the timers (to achieve that, KVM_REQ_HV_STIMER has to be

[PATCH v2 2/7] kvm/x86: Drop stimer_stop() function

The function stimer_stop() is called in one place so remove the function and replace it's call by function content. Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov CC: Paolo Bonzini

[PATCH v2 3/7] kvm/x86: Hyper-V unify stimer_start() and stimer_restart()

This will be used in future to start Hyper-V SynIC timer in several places by one logic in one function. Changes v2: * drop stimer->count == 0 check inside stimer_start() * comment stimer_start() assumptions Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan

[PATCH v2 4/7] kvm/x86: Reorg stimer_expiration() to better control timer restart

Split stimer_expiration() into two parts - timer expiration message sending and timer restart/cleanup based on timer state(config). This also fixes a bug where a one-shot timer message whose delivery failed once would get lost for good. Signed-off-by: Andrey Smetanin

[PATCH v2 6/7] kvm/x86: Skip SynIC vector check for QEMU side

QEMU zero-inits Hyper-V SynIC vectors. We should allow that, and don't reject zero values if set by the host. Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov CC: Paolo Bonzini CC:

[PATCH v2 1/7] kvm/x86: Hyper-V timers fix incorrect logical operation

Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov CC: Paolo Bonzini CC: Roman Kagan CC: Denis V. Lunev CC: qemu-de...@nongnu.org ---

Re: [Qemu-devel] live migration vs device assignment (motivation)

On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote: As long as you keep up this vague talk about performance during migration, without even bothering with any measurements, this patchset will keep going nowhere. I measured network service downtime for "keep device alive"(RFC patch V1

[PATCH RFC 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

Right now there is only a pvclock_pvti_cpu0_va() which is defined on kvmclock since: commit dac16fba6fc5 ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap") The only user of this interface so far is kvm. This commit adds a setter function for the pvti page and moves

QUESTION: mmu.gva_to_gpa versus nested_mmu.gva_to_gpa

I'm wondering if this comment in mmu.c:init_kvm_nested_mmu is correct (at least in the context of Nested EPT): 4055 /* 4056 * Note that arch.mmu.gva_to_gpa translates l2_gva to l1_gpa. The 4057 * translation of l2_gpa to l1_gpa addresses is done using the 4058 *

Re: Is kvm-kmod still supported?

On 28/12/2015 23:09, Estrada, Zachary J wrote: > I've been maintaining a fork for research and tinkering. Is the kvm-kmod > standalone module still supported or should I be using the full Linux > tree? I find kvm-kmod convenient to keep the source independent of the > kernel tree, but I also

Donation/Charity

Hi, My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give

Re: [PATCH v3 0/4] scsi: cleanup ioctl headers and provide UAPI versions

On 25/09/2015 11:27, Paolo Bonzini wrote: > This is v3 of the series to provide an "official" sg.h header (and > scsi_ioctl.h too, though it's basically obsolete) together with the other > userspace API definitions. The change from v2 to v3 is that defaults > for sg.c are not exported in

Re: [PATCH RFC 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

On Mon, Dec 28, 2015 at 1:52 PM, Joao Martins wrote: > Right now there is only a pvclock_pvti_cpu0_va() which is defined on > kvmclock since: > > commit dac16fba6fc5 > ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap") > > The only user of this

Re: QUESTION: mmu.gva_to_gpa versus nested_mmu.gva_to_gpa

On 28/12/2015 23:23, David Matlack wrote: > I'm wondering if this comment in mmu.c:init_kvm_nested_mmu is correct (at > least in the context of Nested EPT): > > 4055 /* > 4056 * Note that arch.mmu.gva_to_gpa translates l2_gva to l1_gpa. The > 4057 * translation of

Re: Is kvm-kmod still supported?

On Tue, Dec 29, 2015 at 12:16:13AM +0100, Paolo Bonzini wrote: > > > On 28/12/2015 23:09, Estrada, Zachary J wrote: > > I've been maintaining a fork for research and tinkering. Is the kvm-kmod > > standalone module still supported or should I be using the full Linux > > tree? I find kvm-kmod