Re: KVM call for November 24th

Juan Quintela wrote: > Hi > Hi again Changing $date in subject. Thanks to Felipe Franciosi for noticing. It is the 24th, not the 22th. Later, Juan. > Please, send any topic that you are interested in covering. > > At the end of Monday I will send an email with the

[PATCH 4/4] KVM: Use common function for VCPU lookup by id

From: David Hildenbrand Let's reuse the new common function for VPCU lookup by id. Reviewed-by: Christian Borntraeger Reviewed-by: Dominik Dingel Signed-off-by: David Hildenbrand

Re: [PATCH v8 0/5] implement vNVDIMM

On Thu, Nov 19, 2015 at 10:39:05AM +0800, Xiao Guangrong wrote: > > > On 11/19/2015 04:44 AM, Michael S. Tsirkin wrote: > >On Wed, Nov 18, 2015 at 05:18:17PM -0200, Eduardo Habkost wrote: > >>On Wed, Nov 18, 2015 at 09:59:34AM +0800, Xiao Guangrong wrote: > >>> > >>>Ping... > >>> > >>>Do you

[PATCH 2/4] KVM: s390: fix wrong lookup of VCPUs by array index

From: David Hildenbrand For now, VCPUs were always created sequentially with incrementing VCPU ids. Therefore, the index in the VCPUs array matched the id. As sequential creation might change with cpu hotplug, let's use the correct lookup function to find a VCPU by id,

[PATCH 3/4] KVM: use heuristic for fast VCPU lookup by id

From: David Hildenbrand Usually, VCPU ids match the array index. So let's try a fast lookup first before falling back to the slow iteration. Suggested-by: Christian Borntraeger Reviewed-by: Dominik Dingel Reviewed-by:

[PATCH 1/4] KVM: Provide function for VCPU lookup by id

From: David Hildenbrand Let's provide a function to lookup a VCPU by id. Reviewed-by: Christian Borntraeger Reviewed-by: Dominik Dingel Signed-off-by: David Hildenbrand Signed-off-by:

[PATCH 2/4] KVM: s390: fix wrong lookup of VCPUs by array index

From: David Hildenbrand For now, VCPUs were always created sequentially with incrementing VCPU ids. Therefore, the index in the VCPUs array matched the id. As sequential creation might change with cpu hotplug, let's use the correct lookup function to find a VCPU by id,

[PATCH 1/4] KVM: Provide function for VCPU lookup by id

From: David Hildenbrand Let's provide a function to lookup a VCPU by id. Reviewed-by: Christian Borntraeger Reviewed-by: Dominik Dingel Signed-off-by: David Hildenbrand Signed-off-by:

[PATCH 0/4] Preview: vcpu lookup by id changes

Paolo, some more patches for review before I add them in my next pull request. Can you review the common code changes and Ack/Nack? Alex, Paul, can you review the power changes and Ack/Nack? As I want to have patch 2 in 4.4, I splitted up Davids patch into smaller chunks. David, can you double

[PATCH 3/4] KVM: use heuristic for fast VCPU lookup by id

From: David Hildenbrand Usually, VCPU ids match the array index. So let's try a fast lookup first before falling back to the slow iteration. Suggested-by: Christian Borntraeger Reviewed-by: Dominik Dingel Reviewed-by:

[PATCH 0/4] Preview: vcpu lookup by id changes

Paolo, some more patches for review before I add them in my next pull request. Can you review the common code changes and Ack/Nack? Alex, Paul, can you review the power changes and Ack/Nack? As I want to have patch 2 in 4.4, I splitted up Davids patch into smaller chunks. David, can you double

[PATCH 4/4] KVM: Use common function for VCPU lookup by id

From: David Hildenbrand Let's reuse the new common function for VPCU lookup by id. Reviewed-by: Christian Borntraeger Reviewed-by: Dominik Dingel Signed-off-by: David Hildenbrand

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 19/11/2015 09:37, Christian Borntraeger wrote: > > some more patches for review before I add them in my next pull request. > Can you review the common code changes and Ack/Nack? > > Alex, Paul, > can you review the power changes and Ack/Nack? > > As I want to have patch 2 in 4.4, I

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 19/11/2015 09:37, Christian Borntraeger wrote: > > some more patches for review before I add them in my next pull request. > Can you review the common code changes and Ack/Nack? > > Alex, Paul, > can you review the power changes and Ack/Nack? > > As I want to have patch 2 in 4.4, I

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 11/19/2015 10:38 AM, Paolo Bonzini wrote: > > > On 19/11/2015 09:37, Christian Borntraeger wrote: >> >> some more patches for review before I add them in my next pull request. >> Can you review the common code changes and Ack/Nack? >> >> Alex, Paul, >> can you review the power changes and

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 11/19/2015 10:38 AM, Paolo Bonzini wrote: > > > On 19/11/2015 09:37, Christian Borntraeger wrote: >> >> some more patches for review before I add them in my next pull request. >> Can you review the common code changes and Ack/Nack? >> >> Alex, Paul, >> can you review the power changes and

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 19/11/2015 10:51, Christian Borntraeger wrote: > > I can apply patch 1 and 2 now to kvm/master. By the time kvm/next forks > > from Linus's tree (sometime next week, since kvm/queue is already > > largish) they will be in. > > I have 2or 3 more patches for 4.4 and I will prepare a pull

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 19/11/2015 10:51, Christian Borntraeger wrote: > > I can apply patch 1 and 2 now to kvm/master. By the time kvm/next forks > > from Linus's tree (sometime next week, since kvm/queue is already > > largish) they will be in. > > I have 2or 3 more patches for 4.4 and I will prepare a pull

Re: [PATCH 2/4] KVM: s390: fix wrong lookup of VCPUs by array index

Sigh. Seems that my mail script got confused by the # after stable. So please strip down the cc list. On 11/19/2015 09:37 AM, Christian Borntraeger wrote: > From: David Hildenbrand > > For now, VCPUs were always created sequentially with incrementing > VCPU ids.

Re: [RFC PATCH 1/3] x86/cpu: Unify CPU family, model, stepping calculation

On Thu, Nov 19, 2015 at 10:34:07AM +0100, Paolo Bonzini wrote: > Let me know if I should include this patch via the KVM tree. Do you > want it in 4.4? Nah, no need. I'll send the whole pile with your Reviewed-by's to Ingo so that they all go together. I'll run them some more on my boxes first

Re: [PATCH 2/4] KVM: s390: fix wrong lookup of VCPUs by array index

Sigh. Seems that my mail script got confused by the # after stable. So please strip down the cc list. On 11/19/2015 09:37 AM, Christian Borntraeger wrote: > From: David Hildenbrand > > For now, VCPUs were always created sequentially with incrementing > VCPU ids.

Re: [RFC PATCH 1/3] x86/cpu: Unify CPU family, model, stepping calculation

On 18/11/2015 19:50, Borislav Petkov wrote: > On Wed, Nov 18, 2015 at 12:35:24PM +0100, Paolo Bonzini wrote: >> Yes, exactly. I'm suggesting that the same applies to x86_vendor(). I >> also prefer x86_cpuid_* to x86_*_cpuid because, once you add two >> functions in the same family it's nice

Re: [patch 1/2] KVM: fix error handling in kvm_create_vm_debugfs()

No problem. Fold away. regards, dan carpenter -- 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

Re: [PATCH 9/9] vfio-pci: constify pci_error_handlers structures

On Sat, 2015-11-14 at 11:07 +0100, Julia Lawall wrote: > This pci_error_handlers structure is never modified, like all the other > pci_error_handlers structures, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > There

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, 2015-11-19 at 13:59 -0800, Andy Lutomirski wrote: > > > > > So thinking hard about it, I don't see any real drawbacks to making this > > conditional on a new feature bit, that Xen can then set.. > > Can you elaborate?  If I run QEMU, hosting Xen, hosting Linux, and the > virtio device is

[PATCH] vfio: platform: remove needless stack usage

request_module already takes format strings, so no need to duplicate the effort. Signed-off-by: Kees Cook --- drivers/vfio/platform/vfio_platform_common.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/vfio/platform/vfio_platform_common.c

linux-next: manual merge of the kvms390 tree with the kvm tree

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: include/linux/kvm_host.h arch/s390/kvm/interrupt.c arch/s390/kvm/sigp.c between commits: db27a7a37aa0 ("KVM: Provide function for VCPU lookup by id") b85de33a1a34 ("KVM: s390: avoid memory overwrites on emergency

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin" wrote: > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > > This switches virtio to use the DMA API unconditionally. I'm sure > > it breaks things, but it seems to work on x86 using virtio-pci, with > > and

Re: [RESEND PATCH] vfio: Drop owner assignment from platform_driver

On Thu, 2015-11-19 at 13:00 +0900, Krzysztof Kozlowski wrote: > platform_driver does not need to set an owner because > platform_driver_register() will set it. > > Signed-off-by: Krzysztof Kozlowski > Acked-by: Baptiste Reynal > > ---

[patch 2/2] KVM: fix vm_stat_get()

The indenting suggests missing curly braces. Fixes: 7805f53a85ec ('KVM: Create debugfs dir and stat files for each VM') Signed-off-by: Dan Carpenter diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index f62621f..4740e54 100644 --- a/virt/kvm/kvm_main.c +++

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 19/11/15 09:37, Christian Borntraeger wrote: > From: David Hildenbrand > > Let's provide a function to lookup a VCPU by id. > > Reviewed-by: Christian Borntraeger > Reviewed-by: Dominik Dingel > Signed-off-by:

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 19/11/15 09:37, Christian Borntraeger wrote: > From: David Hildenbrand > > Let's provide a function to lookup a VCPU by id. > > Reviewed-by: Christian Borntraeger > Reviewed-by: Dominik Dingel > Signed-off-by:

[patch 1/2] KVM: fix error handling in kvm_create_vm_debugfs()

The "goto out_err" is buggy because we forgot to set the return code. The other issue is that if the kmalloc() fails, we should remove the debugfs directory before returning. Fixes: 7805f53a85ec ('KVM: Create debugfs dir and stat files for each VM') Signed-off-by: Dan Carpenter

Re: [Qemu-devel] [PATCH v3 1/3] target-i386: add pkeys support for cpuid handling

On 19/11/2015 07:36, Han, Huaitong wrote: > I understand it has always been that QEMU considers the feature of > cpuid_7_0_ecx_feature_name as migratable. If the feature is > unmigratable, it will been added to unmigratable_flags. > > A series of patches do complete a full function, moving >

Re: [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest

2015-11-19 19:05 GMT+08:00 Paolo Bonzini : > > > On 19/11/2015 11:45, Wanpeng li wrote: >> Intel cpu doesn't support syscall/sysret in non 64-bit mode which >> is different from AMD. Expose syscall/sysret to intel 32-bit guest >> just makes no sense and leads to #UD which will

Re: [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest

On 19/11/2015 13:01, Wanpeng Li wrote: > > This is not correct. As far as I know, the SYSCALL bit is always > > present in CPUID, even if the machine is running in 32-bit mode; CPUID > > documentation (SDM Volume 2) explicitly documents bit 11 as "Bit 11: > > SYSCALL/SYSRET available in 64-bit

Re: [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest

On 19/11/2015 11:45, Wanpeng li wrote: > Intel cpu doesn't support syscall/sysret in non 64-bit mode which > is different from AMD. Expose syscall/sysret to intel 32-bit guest > just makes no sense and leads to #UD which will confuse the users. > > This patch disable expose syscall/sysret to

[PATCH v4 05/13] VFIO: platform: add vfio_platform_set_forwarded

This function allows to change the forwarded mode and selects the IRQ handler accordingly. Signed-off-by: Eric Auger --- v3 -> v3: - renamed vfio_platform_set_automasked into vfio_platform_set_forwarded - do not change VFIO_IRQ_INFO_AUTOMASKED setting when turning

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, 2015-11-19 at 23:38 +, David Woodhouse wrote: > > I understand that POWER and other platforms don't currently have a > clean way to indicate that certain device don't have translation. And I > understand that we may end up with a *quirk* which ensures that the DMA > API does the right

Re: [PATCH] KVM: x86: emulate: correct page fault error code for NoWrite instructions

2015-11-20 10:52 GMT+08:00 Wanpeng Li : > Hi Paolo, > 2015-02-09 17:03 GMT+08:00 Paolo Bonzini : >> NoWrite instructions (e.g. cmp or test) never set the "write access" >> bit in the error code, even if one of the operands is treated as a >> destination. >

Re: [PATCH] KVM: x86: emulate: correct page fault error code for NoWrite instructions

Hi Paolo, 2015-02-09 17:03 GMT+08:00 Paolo Bonzini : > NoWrite instructions (e.g. cmp or test) never set the "write access" > bit in the error code, even if one of the operands is treated as a > destination. Sorry to reply to an old commit, btw, could you point out where in

Re: [PATCH] virtio_ring: Shadow available ring flags & index

On 11/18/2015 12:28 PM, Venkatesh Srinivas wrote: > On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote: >> On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei wrote: >> >>> On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote: On Wed, Nov 11, 2015 at 02:34:33PM

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Fri, Nov 20, 2015 at 08:56:46AM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 19, 2015 at 01:59:05PM -0800, Andy Lutomirski wrote: > > On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin" wrote: > > > > > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > > > >

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, Nov 19, 2015 at 01:59:05PM -0800, Andy Lutomirski wrote: > On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin" wrote: > > > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > > > This switches virtio to use the DMA API unconditionally. I'm sure > > > it

Re: [PATCH] KVM: x86: emulate: correct page fault error code for NoWrite instructions

Wanpeng Li wrote: > 2015-11-20 10:52 GMT+08:00 Wanpeng Li : >> Hi Paolo, >> 2015-02-09 17:03 GMT+08:00 Paolo Bonzini : >>> NoWrite instructions (e.g. cmp or test) never set the "write access" >>> bit in the error code, even if one of

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > This switches virtio to use the DMA API unconditionally. I'm sure > it breaks things, but it seems to work on x86 using virtio-pci, with > and without Xen, and using both the modern 1.0 variant and the > legacy variant. So

[PATCH v4 09/13] KVM: arm/arm64: vgic: support irqfd injection of a mapped IRQ

Up to now irqfd injection was only possible for unmapped IRQ. This patch adds support for injecting mapped interrupts. Signed-off-by: Eric Auger --- virt/kvm/arm/vgic.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/virt/kvm/arm/vgic.c

Re: [patch 1/2] KVM: fix error handling in kvm_create_vm_debugfs()

On 11/19/2015 01:40 PM, Dan Carpenter wrote: > The "goto out_err" is buggy because we forgot to set the return code. > > The other issue is that if the kmalloc() fails, we should remove the > debugfs directory before returning. > > Fixes: 7805f53a85ec ('KVM: Create debugfs dir and stat files for

[PATCH] KVM: arm/arm64: vgic: leave the LR active state on GICD_ICENABLERn access

Currently on clear-enable MMIO we retire the corresponding LR whatever its state. More precisely we do not sync ACTIVE state but we erase the LR state. In case of a forwarded IRQ, the physical IRQ source is also erased meaning the physical IRQ will never be deactivated. In case of a non forwarded

[PATCH v4 07/13] VFIO: platform: add irq bypass producer management

This patch populates the IRQ bypass callacks: - stop/start producer simply consist in disabling/enabling the host irq - add/del consumer: basically set the automasked flag to false/true Signed-off-by: Eric Auger --- v3 -> v4: - use vfio_platform_set_forwarded in place of

Re: [RFC] kvmtool: add support for modern virtio-pci

Hi, > That was indeed the ISR field. Fixing that makes seabios reach the same point > as > legacy virtio before failing. > > I don't see the original correspondence about seabios failures you've > reported, if > you want to forward them over we can look at it further. It was a few months

[PATCH v4 12/13] KVM: arm/arm64: vgic: implement clear pending for non shared mapped IRQ

This patch implements the clear of a pending non shared mapped IRQ. In case of an edge IRQ, we deactivate the physical IRQ that will never be deactivated by the guest. In case of a level sensitive IRQ we check the level of the input signal. If it is asserted we leave the virtual IRQ pending. In

[PATCH v4 13/13] KVM: arm/arm64: implement IRQ bypass consumer functions

Implement IRQ bypass callbacks for arm/arm64 IRQ forwarding: - kvm_arch_irq_bypass_add_producer: perform VGIC/irqchip settings for forwarding - kvm_arch_irq_bypass_del_producer: same for inverse operation - kvm_arch_irq_bypass_stop: halt guest execution - kvm_arch_irq_bypass_start: resume guest

Re: [Qemu-devel] [PATCH v3 1/3] target-i386: add pkeys support for cpuid handling

On Thu, Nov 19, 2015 at 12:10:49PM +0100, Paolo Bonzini wrote: > > > On 19/11/2015 07:36, Han, Huaitong wrote: > > I understand it has always been that QEMU considers the feature of > > cpuid_7_0_ecx_feature_name as migratable. If the feature is > > unmigratable, it will been added to

[PATCH v4 11/13] KVM: arm/arm64: vgic: implement clear active for non shared mapped IRQ

When disabling a non shared mapped IRQs, we must manually deactivate the corresponding physical IRQ on top of removing the active state from the distributor. Signed-off-by: Eric Auger --- virt/kvm/arm/vgic.c | 22 +- 1 file changed, 21 insertions(+), 1

[PATCH v4 04/13] VFIO: platform: single handler using function pointer

A single handler now is registered whatever the use case: automasked or not. A function pointer is set according to the wished behavior and the handler calls this function. The irq lock is taken/released in the root handler. eventfd_signal can be called in regions not allowed to sleep.

[PATCH v4 10/13] KVM: arm/arm64: vgic: forwarding control

Implements kvm_vgic_[set|unset]_forward. Handle low-level VGIC programming: physical IRQ/guest IRQ mapping, list register cleanup, VGIC state machine. Also interacts with the irqchip. Signed-off-by: Eric Auger --- v3 -> v4: - use the target vCPU in set/unset_forward -

[PATCH v4 08/13] KVM: arm/arm64: vgic: adapt state machine for non shared mapped interrupts

From: Marc Zyngier So far, the only user of the mapped interrupt facility was the timer: the physical distributor active state needed to be context-switched for each vcpu, as the device is shared across all vcpus. This patch allows to indicate whether a mapped IRQ

[PATCH v4 06/13] VFIO: platform: add vfio_platform_irq_is_active

This function returns whether the IRQ is active at irqchip level or VFIO masked. If either is true, the IRQ is considered active. Currently there is no way to differentiate userspace masked IRQ from automasked IRQ. There might be false detection of activity. However it is currently acceptable to

[PATCH v4 01/13] KVM: arm/arm64: select IRQ_BYPASS_MANAGER

Select IRQ_BYPASS_MANAGER when CONFIG_KVM is set Signed-off-by: Eric Auger --- arch/arm/kvm/Kconfig | 2 ++ arch/arm64/kvm/Kconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 95a0005..73d7201 100644 ---

[PATCH v4 02/13] VFIO: platform: registration of a dummy IRQ bypass producer

Register a dummy producer with void callbacks Signed-off-by: Eric Auger --- v3 -> v3: - replace WARN_ON by pr_info() in case irq_bypass_register_producer fails v2 -> v3: - rename vfio_platform_irq_bypass_resume into *_start ---

[PATCH v4 03/13] VFIO: platform: test forwarded state when selecting the IRQ handler

Add a new forwarded flag in vfio_platform_irq. In case the IRQ is forwarded, the VFIO platform IRQ handler does not need to disable the IRQ anymore. When setting the IRQ handler we now also test the forwarded state. In case the IRQ is forwarded we select the vfio_irq_handler. Signed-off-by:

[PATCH v4 00/13] ARM IRQ forward control based on IRQ bypass manager

This series allows to optimize the deactivation of virtual interrupts associated to a vfio platform device IRQ. Let's call this optimization: ARM IRQ forwarding. Without that optimization the deactivation of the physical IRQ is done by the host and the deactivation of the virtual IRQ, by the

Re: [GIT PULL 0/5] KVM: s390: Fixes for 4.4

On 19/11/2015 15:09, Christian Borntraeger wrote: > Paolo, > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > >

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

> > Any chance that you name this function differently? Otherwise we've got > two functions that sound very similar and also have similar prototypes: > > - kvm_get_vcpu(struct kvm *kvm, int i) > - kvm_lookup_vcpu(struct kvm *kvm, int id) > > I'm pretty sure this will cause confusion in the

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

> > Any chance that you name this function differently? Otherwise we've got > two functions that sound very similar and also have similar prototypes: > > - kvm_get_vcpu(struct kvm *kvm, int i) > - kvm_lookup_vcpu(struct kvm *kvm, int id) > > I'm pretty sure this will cause confusion in the

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 19/11/2015 13:55, David Hildenbrand wrote: >> > >> > I'm pretty sure this will cause confusion in the future! >> > ==> Could you maybe name the new function something like >> > "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id" instead? > Had that in a previous version but decided to name it

Re: [RFC] kvmtool: add support for modern virtio-pci

On 11/19/2015 02:21 AM, Gerd Hoffmann wrote: > On Mi, 2015-11-18 at 23:01 -0500, Sasha Levin wrote: >> On 11/18/2015 11:00 PM, Sasha Levin wrote: >>> Anyways, I debugged it for a bit a found that seabios attempts to write to >>> the notification BAR, I look further tomorrow to narrow it down and

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 19/11/2015 13:55, David Hildenbrand wrote: >> > >> > I'm pretty sure this will cause confusion in the future! >> > ==> Could you maybe name the new function something like >> > "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id" instead? > Had that in a previous version but decided to name it

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 11/19/2015 02:13 PM, Paolo Bonzini wrote: > > > On 19/11/2015 13:55, David Hildenbrand wrote: I'm pretty sure this will cause confusion in the future! ==> Could you maybe name the new function something like "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id" instead? >> Had

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 11/19/2015 02:13 PM, Paolo Bonzini wrote: > > > On 19/11/2015 13:55, David Hildenbrand wrote: I'm pretty sure this will cause confusion in the future! ==> Could you maybe name the new function something like "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id" instead? >> Had

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

> On 11/19/2015 02:13 PM, Paolo Bonzini wrote: > > > > > > On 19/11/2015 13:55, David Hildenbrand wrote: > > I'm pretty sure this will cause confusion in the future! > ==> Could you maybe name the new function something like > "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id"

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

> On 11/19/2015 02:13 PM, Paolo Bonzini wrote: > > > > > > On 19/11/2015 13:55, David Hildenbrand wrote: > > I'm pretty sure this will cause confusion in the future! > ==> Could you maybe name the new function something like > "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id"

[GIT PULL 3/5] KVM: Provide function for VCPU lookup by id

From: David Hildenbrand Let's provide a function to lookup a VCPU by id. Reviewed-by: Christian Borntraeger Reviewed-by: Dominik Dingel Signed-off-by: David Hildenbrand Signed-off-by:

[GIT PULL 5/5] KVM: s390: fix wrong lookup of VCPUs by array index

From: David Hildenbrand For now, VCPUs were always created sequentially with incrementing VCPU ids. Therefore, the index in the VCPUs array matched the id. As sequential creation might change with cpu hotplug, let's use the correct lookup function to find a VCPU by id,

[GIT PULL 4/5] KVM: s390: avoid memory overwrites on emergency signal injection

From: David Hildenbrand Commit 383d0b050106 ("KVM: s390: handle pending local interrupts via bitmap") introduced a possible memory overwrite from user space. User space could pass an invalid emergency signal code (sending VCPU) and therefore exceed the bitmap. Let's

[GIT PULL 1/5] KVM: s390: enable SIMD only when no VCPUs were created

From: David Hildenbrand We should never allow to enable/disable any facilities for the guest when other VCPUs were already created. kvm_arch_vcpu_(load|put) relies on SIMD not changing during runtime. If somebody would create and run VCPUs and then decides to enable

[GIT PULL 2/5] KVM: s390: fix pfmf intercept handler

From: Heiko Carstens The pfmf intercept handler should check if the EDAT 1 facility is installed in the guest, not if it is installed in the host. Signed-off-by: Heiko Carstens Signed-off-by: Christian Borntraeger

[GIT PULL 0/5] KVM: s390: Fixes for 4.4

Paolo, The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git tags/kvm-s390-master-4.4-1 for you to fetch changes up to