[PATCH 1/6] pc: acpi: bump DSDT/SSDT compliance revision to v2

From: Igor Mammedov It turns on 64-bit integer handling in OSPM, which will be used for writing simpler/smaller AML code in following patch. Tested with Windows XP and Windows Server 2008, Linux: * XP doesn't care about revision and continues to use 32 integers and

[PATCH 0/6] NVDIMM ACPI: introduce the framework of QEMU emulated DSM

This patchset is against commit 5530427f0ca (acpi: extend aml_and() to accept target argument) on pci branch of Michael's git tree and can be found at: https://github.com/xiaogr/qemu.git nvdimm-acpi-v1 This is the second part of vNVDIMM implementation which implements the BIOS patched dsm

[PATCH 5/6] nvdimm acpi: let qemu handle _DSM method

If dsm memory is successfully patched, we let qemu fully emulate the dsm method This patch saves _DSM input parameters into dsm memory, tell dsm memory address to QEMU, then fetch the result from the dsm memory Signed-off-by: Xiao Guangrong ---

Re: [PATCH] KVM: PPC: fix ONE_REG AltiVec support

Happy new year ! On Wed, 16 Dec 2015 18:24:03 +0100 Greg Kurz wrote: > The get and set operations got exchanged by mistake when moving the > code from book3s.c to powerpc.c. > > Fixes: 3840edc8033ad5b86deee309c1c321ca54257452 > Signed-off-by: Greg Kurz

Re: [PATCH] KVM: PPC: fix ONE_REG AltiVec support

Happy new year ! On Wed, 16 Dec 2015 18:24:03 +0100 Greg Kurz wrote: > The get and set operations got exchanged by mistake when moving the > code from book3s.c to powerpc.c. > > Fixes: 3840edc8033ad5b86deee309c1c321ca54257452 > Signed-off-by: Greg Kurz

[PATCH] x86/vdso/pvclock: Protect STABLE check with the seqcount

If the clock becomes unstable while we're reading it, we need to bail. We can do this by simply moving the check into the seqcount loop. Reported-by: Marcelo Tosatti Signed-off-by: Andy Lutomirski --- Marcelo, how's this?

Re: [RFC PATCH v2 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Mon, 2016-01-04 at 14:07 -0700, Alex Williamson wrote: > On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote: > > Current vfio-pci implementation disallows to mmap MSI-X > > table in case that user get to touch this directly. > > > > However, EEH mechanism can ensure that a given pci device >

Re: [PATCH v2 1/4] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On Mon, Jan 04, 2016 at 02:33:12PM -0800, Andy Lutomirski wrote: > On Mon, Jan 4, 2016 at 12:26 PM, Marcelo Tosatti wrote: > > On Sun, Dec 20, 2015 at 03:05:41AM -0800, Andy Lutomirski wrote: > >> From: Andy Lutomirski > >> > >> The pvclock vdso code was

Re: [PATCH v2 1/4] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On Mon, Jan 4, 2016 at 12:26 PM, Marcelo Tosatti wrote: > On Sun, Dec 20, 2015 at 03:05:41AM -0800, Andy Lutomirski wrote: >> From: Andy Lutomirski >> >> The pvclock vdso code was too abstracted to understand easily and >> excessively paranoid. Simplify

Re: [PATCH] vfio/iommu_type1: make use of info.flags

On Wed, 2015-12-23 at 13:08 +0100, Pierre Morel wrote: > The flags entry is there to tell the user that some > optional information is available. > > Since we report the iova_pgsizes signal it to the user > by setting the flags to VFIO_IOMMU_INFO_PGSIZES. > > Signed-off-by: Pierre Morel

Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

On Mon, Jan 4, 2016 at 12:41 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Dec 13, 2015 at 01:28:09PM -0800, Alexander Duyck wrote: >> This patch set is meant to be the guest side code for a proof of concept >> involving leaving pass-through devices in the guest during the

Re: [PATCH RFC] vhost: basic device IOTLB support

On 2016/1/4 14:22, Jason Wang wrote: On 01/04/2016 09:39 AM, Yang Zhang wrote: On 2015/12/31 15:13, Jason Wang wrote: This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace(qemu) implementation of iommu for a secure DMA environment in

VIA Eden X4

Hello, According to WikiPedia VIA claims x86 hardware assisted virtualization for VIA Eden X4 CPU. Does anybody know if it is supported by Linux KVM? -- 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

Re: VIA Eden X4

"Matwey V. Kornilov" writes: > Hello, > > According to WikiPedia VIA claims x86 hardware assisted virtualization > for VIA Eden X4 CPU. > Does anybody know if it is supported by Linux KVM? > I can't say for sure but my guess is that it should work since VIA implements

[3.16.y-ckt stable] Patch "MIPS: KVM: Uninit VCPU in vcpu_create error path" has been added to staging queue

This is a note to let you know that I have just added a patch titled MIPS: KVM: Uninit VCPU in vcpu_create error path to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree which can be found at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y-queue

[3.16.y-ckt stable] Patch "MIPS: KVM: Fix CACHE immediate offset sign extension" has been added to staging queue

This is a note to let you know that I have just added a patch titled MIPS: KVM: Fix CACHE immediate offset sign extension to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree which can be found at:

[3.16.y-ckt stable] Patch "MIPS: KVM: Fix ASID restoration logic" has been added to staging queue

This is a note to let you know that I have just added a patch titled MIPS: KVM: Fix ASID restoration logic to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree which can be found at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y-queue This patch

Re: [PATCH RFC] vhost: basic device IOTLB support

On 2015/12/31 15:13, Jason Wang wrote: This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace(qemu) implementation of iommu for a secure DMA environment in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the

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

On 2015年12月30日 00:46, Michael S. Tsirkin wrote: > Interesting. So you sare saying merely ifdown/ifup is 100ms? > This does not sound reasonable. > Is there a chance you are e.g. getting IP from dhcp? > > If so that is wrong - clearly should reconfigure the old IP > back without playing with dhcp.

RE: [PATCH v2 2/2] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

> -Original Message- > From: Radim Krčmář [mailto:rkrc...@redhat.com] > Sent: Thursday, December 24, 2015 1:22 AM > To: Wu, Feng > Cc: pbonz...@redhat.com; kvm@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH v2 2/2] KVM: x86: Add lowest-priority

Re: [PATCH RFC] vhost: basic device IOTLB support

On 01/04/2016 09:39 AM, Yang Zhang wrote: > On 2015/12/31 15:13, Jason Wang wrote: >> This patch tries to implement an device IOTLB for vhost. This could be >> used with for co-operation with userspace(qemu) implementation of >> iommu for a secure DMA environment in guest. >> >> The idea is

Re: [PATCH RFC] vhost: basic device IOTLB support

On 12/31/2015 07:17 PM, Michael S. Tsirkin wrote: > On Thu, Dec 31, 2015 at 03:13:45PM +0800, Jason Wang wrote: >> This patch tries to implement an device IOTLB for vhost. This could be >> used with for co-operation with userspace(qemu) implementation of >> iommu for a secure DMA environment in

Re: [RFC v4 0/5] Add virtio transport for AF_VSOCK

On 12/22/2015 05:07 PM, Stefan Hajnoczi wrote: > This series is based on v4.4-rc2 and the "virtio: make find_vqs() > checkpatch.pl-friendly" patch I recently submitted. > > v4: > * Addressed code review comments from Alex Bennee > * MAINTAINERS file entries for new files > * Trace events

Charity Donation

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

[PATCH 2/4] KVM: x86: use list_for_each_entry*

Use list_for_each_entry*() instead of list_for_each*() to simplify the code. Signed-off-by: Geliang Tang --- arch/x86/kvm/assigned-dev.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/assigned-dev.c

[PATCH 1/4] KVM: use list_for_each_entry_safe

Use list_for_each_entry_safe() instead of list_for_each_safe() to simplify the code. Signed-off-by: Geliang Tang --- virt/kvm/kvm_main.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index

[PATCH 3/4] KVM: x86: use list_last_entry

To make the intention clearer, use list_last_entry instead of list_entry. Signed-off-by: Geliang Tang --- arch/x86/kvm/mmu.c | 4 ++-- arch/x86/kvm/vmx.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index

[PATCH 4/4] KVM: async_pf: use list_first_entry

To make the intention clearer, use list_first_entry instead of list_entry. Signed-off-by: Geliang Tang --- virt/kvm/async_pf.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c index 77d42be..62c4857 100644

[RFC PATCH v2 0/3] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table on PPC64 platform

Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because sub-page BARs' mmio page may be shared with other BARs and MSI-X table should not be accessed directly from the guest for security reasons. But these will easily cause some

[RFC PATCH v2 2/3] vfio-pci: Allow to mmap sub-page MMIO BARs if all MMIO BARs are page aligned

Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page may be shared with other BARs. But we should allow to mmap these sub-page MMIO BARs if PCI resource allocator enforces the alignment of all MMIO BARs to be at least PAGE_SIZE.

[RFC PATCH v2 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

Current vfio-pci implementation disallows to mmap MSI-X table in case that user get to touch this directly. However, EEH mechanism can ensure that a given pci device can only shoot the MSIs assigned for its PE. So we think it's safe to expose the MSI-X table to userspace because the exposed MSI-X

[RFC PATCH v2 1/3] PCI: Add support for enforcing all MMIO BARs to be page aligned

When vfio passthrough a PCI device of which MMIO BARs are smaller than PAGE_SIZE, guest will not handle the mmio accesses to the BARs which leads to mmio emulations in host. This is because vfio will not allow to passthrough one BAR's mmio page which may be shared with other BARs. To solve this

Re: [PATCH RFC] vhost: basic device IOTLB support

On Thu, Dec 31, 2015 at 03:13:45PM +0800, Jason Wang wrote: > This patch tries to implement an device IOTLB for vhost. This could be > used with for co-operation with userspace(qemu) implementation of > iommu for a secure DMA environment in guest. > > The idea is simple. When vhost meets an IOTLB

[PATCH RFC] vhost: basic device IOTLB support

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace(qemu) implementation of iommu for a secure DMA environment in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the

[PATCH] kvm: x86: fix comment about {mmu,nested_mmu}.gva_to_gpa

The comment had the meaning of mmu.gva_to_gpa and nested_mmu.gva_to_gpa swapped. Fix that, and also add some details describing how each translation works. Signed-off-by: David Matlack --- arch/x86/kvm/mmu.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)

Re: How to reserve guest physical region for ACPI

On Wed, Dec 30, 2015 at 04:55:54PM +0100, Igor Mammedov wrote: > On Mon, 28 Dec 2015 14:50:15 +0200 > "Michael S. Tsirkin" wrote: > > > On Mon, Dec 28, 2015 at 10:39:04AM +0800, Xiao Guangrong wrote: > > > > > > Hi Michael, Paolo, > > > > > > Now it is the time to return to

Re: How to reserve guest physical region for ACPI

On Mon, 28 Dec 2015 14:50:15 +0200 "Michael S. Tsirkin" wrote: > 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

Re: QUESTION: mmu.gva_to_gpa versus nested_mmu.gva_to_gpa

On 29/12/2015 17:37, David Matlack wrote: >> > Yes, it's correct. s/it's/you're/ :) Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] virtio/s390: use dev_to_virtio

Use dev_to_virtio() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/s390/virtio/virtio_ccw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 1b83159..97231e1

Re: QUESTION: mmu.gva_to_gpa versus nested_mmu.gva_to_gpa

On Wed, Dec 30, 2015 at 3:36 AM, Paolo Bonzini wrote: > > > On 29/12/2015 17:37, David Matlack wrote: >>> > Yes, it's correct. > > s/it's/you're/ :) Ah ok. Thanks for your help! I will send a patch to fix the comment then. > > Paolo -- To unsubscribe from this list: send

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

On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin wrote: > On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote: >> >> >> 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

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

On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote: > > > 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

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

On Tue, Dec 29, 2015 at 9:15 AM, Michael S. Tsirkin wrote: > On Tue, Dec 29, 2015 at 09:04:51AM -0800, Alexander Duyck wrote: >> On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin wrote: >> > On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote: >> >> >>

Re: QUESTION: mmu.gva_to_gpa versus nested_mmu.gva_to_gpa

On Mon, Dec 28, 2015 at 6:25 PM, Paolo Bonzini wrote: > > > 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

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

On Tue, Dec 29, 2015 at 09:04:51AM -0800, Alexander Duyck wrote: > On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin wrote: > > On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote: > >> > >> > >> On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote: > >> >As long as you keep

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

On 12/28/2015 11:45 PM, Andy Lutomirski wrote: > 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

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

On Tue, Dec 29, 2015 at 4:50 AM, Joao Martins wrote: > On 12/28/2015 11:45 PM, Andy Lutomirski wrote: >> 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 >>>

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

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

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 > implement a "pause" mechanism which is meant to be used for high > availability type environments. What I am proposing is basically > extending the standard

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

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 >> implement a "pause" mechanism which is meant to be used for high >> availability

How to reserve guest physical region for ACPI

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 memory. | For pc we have "reserved-memory-end" which currently makes sure |

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

On Sun, Dec 27, 2015 at 7:20 PM, 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)

> > > > 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 hot-plug if we are expecting to > support migration. You would simply have to

[PATCH v6 2/6] arm: KVM: Introduce host fp/simd context switch function

Add fp/simd context switch function callable from host kernel mode. Signed-off-by: Mario Smarduch --- arch/arm/kvm/Makefile| 2 +- arch/arm/kvm/fpsimd_switch.S | 47 2 files changed, 48 insertions(+), 1 deletion(-)

[PATCH v6 0/6] arm/arm64: KVM: Enhance armv7/8 fp/simd lazy switch

Current lazy fp/simd implementation switches hardware context on guest access and again on exit to host, otherwise context switch is skipped. This patch set builds on that functionality and executes a hardware context switch on first time access and when vCPU is scheduled out or returns to user

[PATCH v6 1/6] arm/arm64: KVM: Introduce armv7 fp/simd vcpu fields and helpers

Add helper functions to enable access to fp/smid on guest entry and save host fpexc on vcpu put, check if fp/simd registers are dirty and add new vcpu fields. Signed-off-by: Mario Smarduch --- arch/arm/include/asm/kvm_emulate.h | 42

[PATCH v6 3/6] arm/arm64: KVM: Enable armv7 fp/simd enhanced context switch

Enable armv7 enhanced fp/simd context switch. Guest and host registers are only context switched on first access and vcpu put. Signed-off-by: Mario Smarduch --- arch/arm/include/asm/kvm_host.h | 2 ++ arch/arm/kernel/asm-offsets.c | 1 + arch/arm/kvm/arm.c

[PATCH v6 4/6] arm: KVM: Delete unused macros

set_hcptr is no longer used so delete it. Signed-off-by: Mario Smarduch --- arch/arm/kvm/interrupts_head.S | 29 - 1 file changed, 29 deletions(-) diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S index

[PATCH v6 5/6] arm/arm64: KVM: Introduce armv8 fp/simd vcpu fields and helpers

Similar to armv7 add helper functions to enable access to fp/smid registers on guest entry. Save guest fpexc32_el2 on vcpu_put, check if guest is 32 bit. Save guest and restore host registers from host kernel, and check if fp/simd registers are dirty, lastly add cptr_el2 vcpu field.

[PATCH v6 6/6] arm/arm64: KVM: Enable armv8 fp/simd enhanced context switch

Enable armv8 enhanced fp/simd context switch. Guest and host registers are only context switched on first access and vcpu put. Signed-off-by: Mario Smarduch --- arch/arm/kvm/arm.c | 13 +++-- arch/arm64/kernel/asm-offsets.c | 1 +

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

On Fri, Dec 25, 2015 at 03:03:47PM +0800, Lan Tianyu wrote: > Merry Christmas. > Sorry for later response due to personal affair. > > On 2015年12月14日 03:30, Alexander Duyck wrote: > >> > These sounds we need to add a faked bridge for migration and adding a > >> > driver in the guest for it. It

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

On Thu, Dec 24, 2015 at 11:03 PM, Lan Tianyu wrote: > Merry Christmas. > Sorry for later response due to personal affair. > > On 2015年12月14日 03:30, Alexander Duyck wrote: >>> > These sounds we need to add a faked bridge for migration and adding a >>> > driver in the guest

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

Merry Christmas. Sorry for later response due to personal affair. On 2015年12月14日 03:30, Alexander Duyck wrote: >> > These sounds we need to add a faked bridge for migration and adding a >> > driver in the guest for it. It also needs to extend PCI bus/hotplug >> > driver to do pause/resume other

nvdimm: fix header pointer in nvdimm_build_nfit()

In the current nvdimm_build_nfit(), the pointer 'header' initially equals to table_data->data + table_data->len. However, the following g_array_append_vals(table_data, structures->data, structures->len) may resize and relocate table_data->data[]. Therefore, the usage of 'header' afterwards may be

Re: [PATCH v2 09/11] KVM: MMU: simplify mmu_need_write_protect

On 12/23/2015 07:25 PM, Xiao Guangrong wrote: Now, all non-leaf shadow page are page tracked, if gfn is not tracked there is no non-leaf shadow page of gfn is existed, we can directly make the shadow page of gfn to unsync Signed-off-by: Xiao Guangrong ---

Re: [PATCH v2 09/11] KVM: MMU: simplify mmu_need_write_protect

On 12/24/2015 04:36 PM, Kai Huang wrote: On 12/23/2015 07:25 PM, Xiao Guangrong wrote: Now, all non-leaf shadow page are page tracked, if gfn is not tracked there is no non-leaf shadow page of gfn is existed, we can directly make the shadow page of gfn to unsync Signed-off-by: Xiao

Re: [PATCH v2 09/11] KVM: MMU: simplify mmu_need_write_protect

On 12/24/2015 05:11 PM, Xiao Guangrong wrote: On 12/24/2015 04:36 PM, Kai Huang wrote: On 12/23/2015 07:25 PM, Xiao Guangrong wrote: Now, all non-leaf shadow page are page tracked, if gfn is not tracked there is no non-leaf shadow page of gfn is existed, we can directly make the shadow

[PATCH v1] kvm: Make vcpu->requests as 64 bit bitmap

Currently on x86 arch we has already 32 requests defined so the newer request bits can't be placed inside vcpu->requests(unsigned long) inside x86 32 bit system. But we are going to add a new request in x86 arch for Hyper-V tsc page support. To solve the problem the patch replaces vcpu->requests

[PATCH v1] kvm: Make vcpu->requests as 64 bit bitmap

Currently on x86 arch we has already 32 requests defined so the newer request bits can't be placed inside vcpu->requests(unsigned long) inside x86 32 bit system. But we are going to add a new request in x86 arch for Hyper-V tsc page support. To solve the problem the patch replaces vcpu->requests

[PATCH v1] kvm/x86: Hyper-V tsc page setup

Lately tsc page was implemented but filled with empty values. This patch setup tsc page scale and offset based on vcpu tsc, tsc_khz and HV_X64_MSR_TIME_REF_COUNT value. The valid tsc page drops HV_X64_MSR_TIME_REF_COUNT msr reads count to zero which potentially improves performance. The patch

Re: [PATCH v1] kvm: Make vcpu->requests as 64 bit bitmap

Hi Andrey, On Thu, Dec 24, 2015 at 12:30:26PM +0300, Andrey Smetanin wrote: > Currently on x86 arch we has already 32 requests defined > so the newer request bits can't be placed inside > vcpu->requests(unsigned long) inside x86 32 bit system. > But we are going to add a new request in x86 arch >

Re: [PATCH v1] kvm: Make vcpu->requests as 64 bit bitmap

Hi Andrey, On Thu, Dec 24, 2015 at 12:30:26PM +0300, Andrey Smetanin wrote: > Currently on x86 arch we has already 32 requests defined > so the newer request bits can't be placed inside > vcpu->requests(unsigned long) inside x86 32 bit system. > But we are going to add a new request in x86 arch >

[PATCH 18/31] arm64: KVM: Add panic handling

Add the panic handler, together with the small bits of assembly code to call the kernel's panic implementation. Signed-off-by: Marc Zyngier Reviewed-by: Christoffer Dall --- arch/arm64/kvm/hyp/hyp-entry.S | 11 ++-

[PATCH 17/31] arm64: KVM: HYP mode entry points

Add the entry points for HYP mode (both for hypercalls and exception handling). Signed-off-by: Marc Zyngier Reviewed-by: Christoffer Dall --- arch/arm64/kvm/hyp/Makefile| 1 + arch/arm64/kvm/hyp/hyp-entry.S | 203

[PATCH 25/31] ARM: KVM: Cleanup exception injection

David Binderman reported that the exception injection code had a couple of unused variables lingering around. Upon examination, it looked like this code could do with an anticipated spring cleaning, which amounts to deduplicating the CPSR/SPSR update, and making it look a bit more like the

[PATCH 22/31] arm64: KVM: Turn system register numbers to an enum

Having the system register numbers as #defines has been a pain since day one, as the ordering is pretty fragile, and moving things around leads to renumbering and epic conflict resolutions. Now that we're mostly acessing the sysreg file in C, an enum is a much better type to use, and we can clean

[PATCH 21/31] arm64: KVM: Move away from the assembly version of the world switch

This is it. We remove all of the code that has now been rewritten. Signed-off-by: Marc Zyngier Acked-by: Christoffer Dall --- arch/arm64/kvm/Makefile |2 - arch/arm64/kvm/hyp.S| 1081

[PATCH 09/31] arm64: KVM: Implement system register save/restore

Implement the system register save/restore as a direct translation of the assembly code version. Signed-off-by: Marc Zyngier Reviewed-by: Christoffer Dall --- arch/arm64/kvm/hyp/Makefile| 1 + arch/arm64/kvm/hyp/hyp.h | 3 ++

<    1   2   3   4   5   6   7   8   9   10   >