> -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 lowest-priority support for vt-d posted-
> in
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 majordom
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 configured SynIC message slo
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 space for every possible device out there. Th
> 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 config spac
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 pa
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
---
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 supp
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 se
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 data
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 ru
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 insertions(+)
diff --git a/arch/powerpc
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, 20 insertions(+)
diff --git a
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
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
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 sw
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 migr
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 MCE_BA
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
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",
>> >
>> > \
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
> > ---
> > target-i386/kvm.c
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 betwee
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.
> >
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.
>> >>
>> >
>> > Just if
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 emu
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);
>> +
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 *
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 hv_mes
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, a
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 deletion(-)
>
> diff -
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 PCI
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
>> > incorrect because:
>> > (1) According to Intel SDM Vol 3
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 now
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 b
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 migration status won't
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 b2467e744f89fcb2e723143c2b78bcba
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 statu
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, Section "INVVPID - Invalidate
>
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, Section "INVVPID - Invalidate
>
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 migratio
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
KVM_CAP_M
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
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 b/target-i386/kvm.c
index d63a85b..446b
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:
(MCE_CAP_
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 config space regs are emula
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 Based on VPID", invvpid instru
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 = DO_UPCAST(VF
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
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 + PCI_VF_MIG
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
CC: "K. Y. Srinivasan"
CC: Haiyang Zhang
CC: Vitaly Kuznetsov
CC: Roma
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
CC: Paolo Bonzini
CC: "K. Y. Srinivasan"
CC: Hai
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 interrup
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 correspond
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 n
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
CC: Roman Kagan
CC: Denis V. Lunev
CC: qemu-de...@nongnu.org
---
arch/x86/kvm/hyperv.h | 20 ++--
1 file changed, 14 ins
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 interrup
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: Haiyang Zhang
CC: Vitaly Kuznetsov
CC: Roman Kagan
CC: Denis V. Lunev
CC: qemu-de...@nongnu.org
---
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"
CC: Haiyang Zhang
CC: Vitaly Kuznetsov
CC: Roman Kagan
CC: Denis V. Lunev
CC: qemu-de...@n
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: Richard Henderson
CC: Eduardo Habkost
CC: "Andr
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 correspond
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
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 destina
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 --git a/drivers/vfio/vf
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 Beh
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 the case of qemu-syst
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 100644
--- a/drivers/vf
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, vmware also exposes LM
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 t
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 non
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 t
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 regs
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,
> --
> Steve
>
> >
> >
72 matches
Mail list logo
