Re: [PATCH 09/10] KVM: x86: MMU: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page()

On 20/11/2015 09:57, Xiao Guangrong wrote: > > > You can move this patch to the front of > [PATCH 08/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of > pte_list_walk() > > By moving kvm_mmu_mark_parents_unsync() to the behind of mmu_spte_set() > (then the parent > spte is present

Re: [PATCH 3/3] target-i386: kvm: Print warning when clearing mcg_cap bits

On Wed, Nov 25, 2015 at 01:49:49PM -0200, Eduardo Habkost wrote: > Instead of silently clearing mcg_cap bits when the host doesn't > support them, print a warning when doing that. Why the host? Why would we want there to be any relation between the MCA capabilities of the host and what qemu is

Re: [PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

Haozhong Zhang writes: > On 11/25/15 10:45, Bandan Das wrote: >> Haozhong Zhang writes: >> >> > This patch removes the vpid check when emulating nested invvpid >> > instruction of type all-contexts invalidation. The existing code is >> >

Re: [PATCH 3/3] target-i386: kvm: Print warning when clearing mcg_cap bits

On Wed, Nov 25, 2015 at 05:45:20PM +0100, Paolo Bonzini wrote: > On 25/11/2015 16:49, Eduardo Habkost wrote: > > Instead of silently clearing mcg_cap bits when the host doesn't > > support them, print a warning when doing that. > > > > Signed-off-by: Eduardo Habkost > > ---

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote: > On 2015年11月25日 13:30, Alexander Duyck wrote: >> No, what I am getting at is that you can't go around and modify the >> configuration space for every possible device out there. This >> solution won't scale. > > > PCI

Re: [PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

On 11/25/15 10:45, Bandan Das wrote: > Haozhong Zhang writes: > > > This patch removes the vpid check when emulating nested invvpid > > instruction of type all-contexts invalidation. The existing code is > > incorrect because: > > (1) According to Intel SDM Vol 3,

[PATCH v1 7/7] kvm/x86: Hyper-V SynIC timers

Per Hyper-V specification (and as required by Hyper-V-aware guests), SynIC provides 4 per-vCPU timers. Each timer is programmed via a pair of MSRs, and signals expiration by delivering a special format message to the configured SynIC message slot and triggering the corresponding synthetic

[PATCH v1 0/7] KVM: Hyper-V SynIC timers

Per Hyper-V specification (and as required by Hyper-V-aware guests), SynIC provides 4 per-vCPU timers. Each timer is programmed via a pair of MSRs, and signals expiration by delivering a special format message to the configured SynIC message slot and triggering the corresponding synthetic

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: Frankly, I don't really see what this short term hack buys us, and if it goes in, we'll have to maintain it forever. The framework of how to notify VF about migration status won't be changed regardless of stopping VF or not before doing

[GIT PULL] KVM fixes for 4.4-rc3

Linus, The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4: Linux 4.4-rc2 (2015-11-22 16:45:59 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

Re: [PATCH 1/3] target-i386: kvm: Abort if MCE bank count is not supported by host

On 25/11/2015 18:26, Eduardo Habkost wrote: >> > Yoda conditions? >> > >> > if (banks < MCE_BANKS_DEF) { >> > error_report("kvm: Unsupported MCE bank count (QEMU = %d, KVM >> > = %d)", >> > MCE_BANKS_DEF, banks); > This was on purpose, because

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

2015-11-25 15:38+0100, Paolo Bonzini: > On 25/11/2015 15:12, Radim Krcmár wrote: >> I think it's ok to pick any algorithm we like. It's unlikely that >> software would recognize and take advantage of the hardware algorithm >> without adding a special treatment for KVM. >> (I'd vote for the simple

Re: [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support

On Wed, Nov 25, 2015 at 11:32:23PM +0800, Lan, Tianyu wrote: > > On 11/25/2015 5:03 AM, Michael S. Tsirkin wrote: > >>>+void vfio_migration_cap_handle(PCIDevice *pdev, uint32_t addr, > >>>+ uint32_t val, int len) > >>>+{ > >>>+VFIOPCIDevice *vdev =

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Thu, Nov 26, 2015 at 12:02:33AM +0800, Lan, Tianyu wrote: > On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: > >Frankly, I don't really see what this short term hack buys us, > >and if it goes in, we'll have to maintain it forever. > > > > The framework of how to notify VF about migration

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Wed, Nov 25, 2015 at 08:24:38AM -0800, Alexander Duyck wrote: > >> Also, assuming you just want to do ifdown/ifup for some reason, it's > >> easy enough to do using a guest agent, in a completely generic way. > >> > > > > Just ifdown/ifup is not enough for migration. It needs to restore some

Re: [PATCH 3/3] target-i386: kvm: Print warning when clearing mcg_cap bits

On 25/11/2015 18:29, Eduardo Habkost wrote: >>> > > >>> > > +unsupported_caps = env->mcg_cap & ~(mcg_cap | >>> > > MCG_CAP_BANKS_MASK); >>> > > +if (unsupported_caps) { >>> > > +error_report("warning: Unsupported MCG_CAP bits: 0x%" >>> > > PRIx64 "\n", >> > >> >

[PATCH v1 2/2] target-i386/kvm: Hyper-V SynIC timers MSR's support

Hyper-V SynIC timers are host timers that are configurable by guest through corresponding MSR's (HV_X64_MSR_STIMER*). Guest setup and use fired by host events(SynIC interrupt and appropriate timer expiration message) as guest clock events. The state of Hyper-V SynIC timers are stored in

[PATCH v1 6/7] kvm/x86: Hyper-V SynIC message slot pending clearing at SINT ack

The SynIC message protocol mandates that the message slot is claimed by atomically setting message type to something other than HVMSG_NONE. If another message is to be delivered while the slot is still busy, message pending flag is asserted to indicate to the guest that the hypervisor wants to be

[PATCH v1 4/7] kvm/x86: Added Hyper-V vcpu_to_hv_vcpu()/hv_vcpu_to_vcpu() helpers

Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov CC: Paolo Bonzini CC: "K. Y. Srinivasan" CC: Haiyang Zhang CC: Vitaly Kuznetsov

[PATCH v1 0/2] QEMU: Hyper-V SynIC timers MSR's support

Hyper-V SynIC timers are host timers that are configurable by guest through corresponding MSR's (HV_X64_MSR_STIMER*). Guest setup and use fired by host events(SynIC interrupt and appropriate timer expiration message) as guest clock events. The state of Hyper-V SynIC timers are stored in

[PATCH v1 1/7] drivers/hv: Move HV_SYNIC_STIMER_COUNT into Hyper-V UAPI x86 header

This constant is required for Hyper-V SynIC timers MSR's support by userspace(QEMU). Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov CC: Paolo Bonzini CC: "K. Y. Srinivasan"

[PATCH v1 1/2] include: update Hyper-V header to include SynIC timers defines

This patch brings in the necessary changes from the corresponding kernel patchset. It's included only for completeness; ideally these changes should arrive via the standard kernel header pull. Signed-off-by: Andrey Smetanin CC: Paolo Bonzini CC:

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Wed, Nov 25, 2015 at 8:02 AM, Lan, Tianyu wrote: > On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: >> >> Frankly, I don't really see what this short term hack buys us, >> and if it goes in, we'll have to maintain it forever. >> > > The framework of how to notify VF about

Re: [PATCH 3/3] target-i386: kvm: Print warning when clearing mcg_cap bits

On 25/11/2015 16:49, Eduardo Habkost wrote: > Instead of silently clearing mcg_cap bits when the host doesn't > support them, print a warning when doing that. > > Signed-off-by: Eduardo Habkost > --- > target-i386/kvm.c | 8 +++- > 1 file changed, 7 insertions(+), 1

Re: [PATCH v1 6/7] kvm/x86: Hyper-V SynIC message slot pending clearing at SINT ack

On 25/11/2015 16:20, Andrey Smetanin wrote: > +static void synic_clear_sint_msg_pending(struct kvm_vcpu_hv_synic *synic, > + u32 sint) > +{ > + struct kvm_vcpu *vcpu = synic_to_vcpu(synic); > + struct page *page; > + gpa_t gpa; > + struct

Re: [PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

Haozhong Zhang writes: > This patch removes the vpid check when emulating nested invvpid > instruction of type all-contexts invalidation. The existing code is > incorrect because: > (1) According to Intel SDM Vol 3, Section "INVVPID - Invalidate > Translations

Re: [PATCH 08/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk()

On 20/11/2015 09:47, Takuya Yoshikawa wrote: > kvm_mmu_mark_parents_unsync() alone uses pte_list_walk(), witch does > nearly the same as the for_each_rmap_spte macro. The only difference > is that is_shadow_present_pte() checks cannot be placed there because > kvm_mmu_mark_parents_unsync() can

Re: [PATCH v1 6/7] kvm/x86: Hyper-V SynIC message slot pending clearing at SINT ack

On 11/25/2015 07:52 PM, Paolo Bonzini wrote: On 25/11/2015 16:20, Andrey Smetanin wrote: +static void synic_clear_sint_msg_pending(struct kvm_vcpu_hv_synic *synic, + u32 sint) +{ + struct kvm_vcpu *vcpu = synic_to_vcpu(synic); + struct page

Re: [PATCH 3/3] target-i386: kvm: Print warning when clearing mcg_cap bits

On 25/11/2015 18:21, Borislav Petkov wrote: >> Instead of silently clearing mcg_cap bits when the host doesn't >> > support them, print a warning when doing that. > Why the host? Why would we want there to be any relation between the MCA > capabilities of the host and what qemu is emulating? He

[PATCH 3/3] target-i386: kvm: Print warning when clearing mcg_cap bits

Instead of silently clearing mcg_cap bits when the host doesn't support them, print a warning when doing that. Signed-off-by: Eduardo Habkost --- target-i386/kvm.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/target-i386/kvm.c

[PATCH 2/3] target-i386: kvm: Use env->mcg_cap when setting up MCE

When setting up MCE, instead of using the MCE_*_DEF macros directly, just filter the existing env->mcg_cap value. As env->mcg_cap is already initialized as MCE_CAP_DEF|MCE_BANKS_DEF at target-i386/cpu.c:mce_init(), this doesn't change any behavior. But it will allow us to change mce_init() in the

[PATCH 1/3] target-i386: kvm: Abort if MCE bank count is not supported by host

Instead of silently changing the number of banks in mcg_cap based on kvm_get_mce_cap_supported(), abort initialization if the host doesn't support MCE_BANKS_DEF banks. Note that MCE_BANKS_DEF was always 10 since it was introduced in QEMU, and Linux always returned 32 at KVM_CAP_MCE since

Re: [PATCH 1/3] target-i386: kvm: Abort if MCE bank count is not supported by host

On 25/11/2015 16:49, Eduardo Habkost wrote: > Instead of silently changing the number of banks in mcg_cap based > on kvm_get_mce_cap_supported(), abort initialization if the host > doesn't support MCE_BANKS_DEF banks. > > Note that MCE_BANKS_DEF was always 10 since it was introduced in > QEMU,

Re: [PATCH v1 6/7] kvm/x86: Hyper-V SynIC message slot pending clearing at SINT ack

On 25/11/2015 17:55, Andrey Smetanin wrote: >> >> +gpa = synic->msg_page & PAGE_MASK; >> +page = kvm_vcpu_gfn_to_page(vcpu, gpa >> PAGE_SHIFT); >> +if (is_error_page(page)) { >> +vcpu_err(vcpu, "Hyper-V SynIC can't get msg page, gpa 0x%llx\n", >> + gpa); >> +

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Wed, Nov 25, 2015 at 8:39 AM, Michael S. Tsirkin wrote: > On Wed, Nov 25, 2015 at 08:24:38AM -0800, Alexander Duyck wrote: >> >> Also, assuming you just want to do ifdown/ifup for some reason, it's >> >> easy enough to do using a guest agent, in a completely generic way. >> >>

[PATCH v1 5/7] kvm/x86: Hyper-V internal helper to read MSR HV_X64_MSR_TIME_REF_COUNT

This helper will be used also in Hyper-V SynIC timers implementation. Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov CC: Paolo Bonzini CC: "K. Y. Srinivasan" CC:

[PATCH v1 2/7] drivers/hv: Move struct hv_message into UAPI Hyper-V x86 header

This struct is required for Hyper-V SynIC timers implementation inside KVM and for upcoming Hyper-V VMBus support by userspace(QEMU). So place it into Hyper-V UAPI header. Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov

[PATCH v1 3/7] kvm/x86: Rearrange func's declarations inside Hyper-V header

This rearrangement places functions declarations together according to their functionality, so future additions will be simplier. Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan CC: Gleb Natapov CC: Paolo Bonzini

Re: [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support

On 11/25/2015 5:03 AM, Michael S. Tsirkin wrote: >+void vfio_migration_cap_handle(PCIDevice *pdev, uint32_t addr, >+ uint32_t val, int len) >+{ >+VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev); >+ >+if (addr == vdev->migration_cap +

[PATCH 0/3] target-i386: kvm: Use env->mcg_cap when setting up MCE

Instead of overwriting env->mcg_cap, make kvm_arch_init_vcpu(), use the value already set at the CPU object when initializing MCE. Except for the new "unsupported MCG_CAPS bits" warning, this patch doesn't change any of the existing QEMU behavior. The previous code set env->mcg_cap to:

Re: [PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

On 25/11/2015 16:45, Bandan Das wrote: > Haozhong Zhang writes: > >> This patch removes the vpid check when emulating nested invvpid >> instruction of type all-contexts invalidation. The existing code is >> incorrect because: >> (1) According to Intel SDM Vol 3,

Re: [PATCH 1/3] target-i386: kvm: Abort if MCE bank count is not supported by host

On Wed, Nov 25, 2015 at 05:46:38PM +0100, Paolo Bonzini wrote: > > > On 25/11/2015 16:49, Eduardo Habkost wrote: > > Instead of silently changing the number of banks in mcg_cap based > > on kvm_get_mce_cap_supported(), abort initialization if the host > > doesn't support MCE_BANKS_DEF banks. > >

Re: [PATCH 3/3] target-i386: kvm: Print warning when clearing mcg_cap bits

On Wed, Nov 25, 2015 at 06:29:25PM +0100, Paolo Bonzini wrote: > On 25/11/2015 18:21, Borislav Petkov wrote: > >> Instead of silently clearing mcg_cap bits when the host doesn't > >> > support them, print a warning when doing that. > > Why the host? Why would we want there to be any relation

[PATCH v2 7/9] KVM: PPC: Book3S HV: Host side kick VCPU when poked by real-mode KVM

This patch adds the support for the kick VCPU operation for kvmppc_host_rm_ops. The kvmppc_xics_ipi_action() function provides the function to be invoked for a host side operation when poked by the real mode KVM. This is initiated by KVM by sending an IPI to any free host core. KVM real mode must

[PATCH v2 2/9] powerpc/smp: Add smp_muxed_ipi_set_message

smp_muxed_ipi_message_pass() invokes smp_ops->cause_ipi, which updates the MFFR through an ioremapped address, to cause the IPI. Because of this real mode callers cannot call smp_muxed_ipi_message_pass() for IPI messaging. This patch creates a separate function smp_muxed_ipi_set_message just to

[PATCH v2 4/9] KVM: PPC: Book3S HV: Host-side RM data structures

This patch defines the data structures to support the setting up of host side operations while running in real mode in the guest, and also the functions to allocate and free it. The operations are for now limited to virtual XICS operations. Currently, we have only defined one operation in the

[PATCH v2 8/9] KVM: PPC: Book3S HV: Send IPI to host core to wake VCPU

This patch adds support to real-mode KVM to search for a core running in the host partition and send it an IPI message with VCPU to be woken. This avoids having to switch to the host partition to complete an H_IPI hypercall when the VCPU which is the target of the the H_IPI is not loaded (is not

[PATCH v2 6/9] KVM: PPC: Book3S HV: kvmppc_host_rm_ops - handle offlining CPUs

The kvmppc_host_rm_ops structure keeps track of which cores are are in the host by maintaining a bitmask of active/runnable online CPUs that have not entered the guest. This patch adds support to manage the bitmask when a CPU is offlined or onlined in the host. Signed-off-by: Suresh Warrier

[PATCH v2 1/9] powerpc/smp: Support more IPI messages

This patch increases the number of demuxed messages for a controller with a single ipi to 8 for 64-bit systems This is required because we want to use the IPI mechanism to send messages from a CPU running in KVM real mode in a guest to a CPU in the host to take some action. Currently, we only

[PATCH v2 5/9] KVM: PPC: Book3S HV: Manage core host state

Update the core host state in kvmppc_host_rm_ops whenever the primary thread of the core enters the guest or returns back. Signed-off-by: Suresh Warrier --- arch/powerpc/kvm/book3s_hv.c | 44 1 file changed, 44

[PATCH v2 3/9] powerpc/powernv: Add icp_native_cause_ipi_rm

Function to cause an IPI. Requires kvm_hstate.xics_phys to be initialized with physical address of XICS. Signed-off-by: Suresh Warrier --- arch/powerpc/include/asm/xics.h | 1 + arch/powerpc/sysdev/xics/icp-native.c | 19 +++ 2 files changed,

[PATCH v2 9/9] KVM: PPC: Book3S HV: Add tunable to control H_IPI redirection

Redirecting the wakeup of a VCPU from the H_IPI hypercall to a core running in the host is usually a good idea, most workloads seemed to benefit. However, in one heavily interrupt-driven SMT1 workload, some regression was observed. This patch adds a kvm_hv module parameter called h_ipi_redirect to

[PATCH v2 0/9] KVM: PPC: Book3S HV: Optimize wakeup VCPU from H_IPI

When the VCPU target of an H_IPI hypercall is not running in the guest, we need to do a kick VCPU (wake the VCPU thread) to make it runnable. The real-mode version of the H_IPI hypercall cannot do this because it involves waking a sleeping thread. Thus the hcall returns H_TOO_HARD which forces a

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Wed, Nov 25, 2015 at 7:15 PM, Dong, Eddie wrote: >> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote: >> > On 2015年11月25日 13:30, Alexander Duyck wrote: >> >> No, what I am getting at is that you can't go around and modify the >> >> configuration

Re: [PATCH 09/10] KVM: x86: MMU: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page()

On 2015/11/26 1:32, Paolo Bonzini wrote: On 20/11/2015 09:57, Xiao Guangrong wrote: You can move this patch to the front of [PATCH 08/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk() By moving kvm_mmu_mark_parents_unsync() to the behind of mmu_spte_set() (then the

RE: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote: > > On 2015年11月25日 13:30, Alexander Duyck wrote: > >> No, what I am getting at is that you can't go around and modify the > >> configuration space for every possible device out there. This > >> solution won't scale. > >

Re: [PATCH v6 1/3] target-i386: fallback vcpu's TSC rate to value returned by KVM

On Tue, Nov 24, 2015 at 11:33:55AM +0800, Haozhong Zhang wrote: > If no user-specified TSC rate is present, we will try to set > env->tsc_khz to the value returned by KVM_GET_TSC_KHZ. This patch does > not change the current functionality of QEMU and just prepares for later > patches to enable

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

> -Original Message- > From: Radim Krčmář [mailto:rkrc...@redhat.com] > Sent: Wednesday, November 25, 2015 11:43 PM > To: Paolo Bonzini > Cc: Wu, Feng ; kvm@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add

Is KVM support single step execution

Hi Paolo, Do you know whether KVM supports single step execution? If it is, could you please give me some information about it. Really appreciate it! Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v1 0/7] KVM: Hyper-V SynIC timers

2015-11-25 23:20 GMT+08:00 Andrey Smetanin : > Per Hyper-V specification (and as required by Hyper-V-aware guests), > SynIC provides 4 per-vCPU timers. Each timer is programmed via a pair > of MSRs, and signals expiration by delivering a special format message > to the

[PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

This patch removes the vpid check when emulating nested invvpid instruction of type all-contexts invalidation. The existing code is incorrect because: (1) According to Intel SDM Vol 3, Section "INVVPID - Invalidate Translations Based on VPID", invvpid instruction does not check vpid in

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 2015年11月25日 13:30, Alexander Duyck wrote: > No, what I am getting at is that you can't go around and modify the > configuration space for every possible device out there. This > solution won't scale. PCI config space regs are emulation by Qemu and so We can find the free PCI config space

Re: [PATCH 05/21] arm64: KVM: Implement timer save/restore

On Mon, 23 Nov 2015 10:47:10 + Steve Capper wrote: Hi Steve, > On Mon, Nov 16, 2015 at 01:11:43PM +, Marc Zyngier wrote: > > Implement the timer save restore as a direct translation of > > the assembly code version. > > Hi Marc, some comments below. > Cheers,

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

On 25/11/2015 02:58, Wu, Feng wrote: > Okay, let me try to understand this clearly: > - We will have a new KVM command line parameter to indicate whether > vector hashing is enabled. > - If it is not enabled, for PI, we can only support single destination lowest > priority interrupts, for

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Wed, Nov 25, 2015 at 01:39:32PM +0800, Lan Tianyu wrote: > On 2015年11月25日 05:20, Michael S. Tsirkin wrote: > > I have to say, I was much more interested in the idea > > of tracking dirty memory. I have some thoughts about > > that one - did you give up on it then? > > No, our finial target is

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

2015-11-19 19:05 GMT+08:00 Paolo Bonzini : > > 1) Clear F(SYSCALL) in kvm_update_cpuid, like you are doing here but > only if F(LM) is already clear (in addition to the vendor being Intel). It seems that F(LM) is always set in the case of qemu-system-x86_64 w/ 32-bit guest,

[PATCH 5/7] vfio: fix a problematic usage of WARN()

WARN() takes a condition and a format string. The condition was omitted. So I added it. Signed-off-by: Geliang Tang --- drivers/vfio/vfio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c index de632da..9da0703

RE: [PATCH v3 15/16] KVM: arm64: implement MSI injection in ITS emulation

Hello! I have discovered one more issue, and it is major one. It gets triggered by VFIO. See inline. P.S. What is the overall current status? Long time has passed since the last email... > -Original Message- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On

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

On 25/11/2015 13:45, Wanpeng Li wrote: > 2015-11-19 19:05 GMT+08:00 Paolo Bonzini : >> >> 1) Clear F(SYSCALL) in kvm_update_cpuid, like you are doing here but >> only if F(LM) is already clear (in addition to the vendor being Intel). > > It seems that F(LM) is always set in

Re: [PATCH 5/7] vfio: fix a problematic usage of WARN()

On Wed, 2015-11-25 at 21:12 +0800, Geliang Tang wrote: > WARN() takes a condition and a format string. The condition was > omitted. So I added it. > > Signed-off-by: Geliang Tang > --- > drivers/vfio/vfio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

2015-11-25 03:21+, Wu, Feng: > From: Radim Krčmář [mailto:rkrc...@redhat.com] >> The hash function just interprets a subset of vector's bits as a number >> and uses that as a starting offset in a search for an enabled APIC >> within the destination set? >> >> For example: >> The x2APIC

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

On 25/11/2015 15:12, Radim Krcmár wrote: > I think it's ok to pick any algorithm we like. It's unlikely that > software would recognize and take advantage of the hardware algorithm > without adding a special treatment for KVM. > (I'd vote for the simple pick-first-APIC lowest priority algorithm