Hi Paolo,
On Tue, Aug 19, 2014 at 10:34:20AM +0200, Paolo Bonzini wrote:
>Il 19/08/2014 10:30, Wanpeng Li ha scritto:
>> +if (vmx->nested.virtual_apic_page)
>> +nested_release_page(vmx->nested.virtual_apic_page);
>> +vmx->nested.virtual_apic_page =
>> +
Il 20/08/2014 08:46, Valentine Sinitsyn ha scritto:
>
> You can see the problem here: the code tries to access APIC MMIO
> register, which is trapped by KVM's MMU code (at nested page table
> walk). During MMIO access emulation, KVM decides to inject 0x23c
> exception (which looks wrong, as there
Il 20/08/2014 05:17, Wanpeng Li ha scritto:
> + else if (spte & (1ULL << 7))
You have to check level == 1 specifically here, or add...
> + /*
> + * 1GB/2MB page, bits 29:12 or 20:12 reserved respectively,
> + * level == 1 if the hypervisor is using the ig
Hi all,
Please excuse me for bringing alive a two-month old thread, but I had
time to investigate the issue a bit only recently.
On 18.06.2014 18:47, Jan Kiszka wrote:
On 2014-06-18 13:36, Valentine Sinitsyn wrote:
If we want to provide useful nested SVM support, this must be feasible.
If the
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host or Guest. Patch also adds support for
software breakpo
Hi Paolo,
On Tue, Aug 19, 2014 at 11:09:49AM +0200, Paolo Bonzini wrote:
[...]
>I suggest that you write a testcase for kvm-unit-tests.
>
Just send out v3. The testcase will be written later since I'm not familiar
with kvm-unit-tests before and time is still needed.
Regards,
Wanpeng Li
>Paolo
-
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
paging-structure entry is configured with settings reserved for
future functionality. However, the handler can't identify if
paging-structure entry of reserved bits for
On Thu, Aug 14, 2014 at 03:03:07PM +1000, Alexey Kardashevskiy wrote:
> fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
> functional change but this is not true as it calls get_order() (which
> takes bytes) where it should have called ilog2() and the kernel stops
> on VM_BUG_ON().
On Tue, Aug 19, 2014 at 5:29 PM, Xiao Guangrong
wrote:
> On 08/19/2014 05:03 PM, Paolo Bonzini wrote:
>> Il 19/08/2014 10:50, Xiao Guangrong ha scritto:
>>> Okay, what confused me it that it seems that the single line patch
>>> is ok to you. :)
>>
>> No, it was late and I was confused. :)
>>
>>> N
On 08/19/2014 05:03 PM, Paolo Bonzini wrote:
> Il 19/08/2014 10:50, Xiao Guangrong ha scritto:
>> Okay, what confused me it that it seems that the single line patch
>> is ok to you. :)
>
> No, it was late and I was confused. :)
>
>> Now, do we really need to care the case 2? like David said:
>> "
By the way, at present, I use Qemu as user mode program, is there common
test with both Qemu and KVM/Xen? And is a PC enough for the common test?
Thanks.
On 08/20/2014 07:58 AM, Chen Gang wrote:
> On 08/19/2014 11:49 PM, Paolo Bonzini wrote:
>> Il 19/08/2014 17:44, Chen Gang ha scritto:
Hel
On 08/19/2014 11:49 PM, Paolo Bonzini wrote:
> Il 19/08/2014 17:44, Chen Gang ha scritto:
>> > Hello maintainers:
>> >
>> > Please help check this patch, when you have time.
> Hi, it's already on its way to 3.17-rc2, but I first have to run a bunch
> of tests.
OK, thanks. Also can let me try the
On Tue, Aug 19, 2014 at 04:04:03PM +0200, Christian Borntraeger wrote:
>On 18/08/14 07:02, Wanpeng Li wrote:
>> Hi Christian,
>> On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
>>> We currently track the pid of the task that runs the VCPU in
>>> vcpu_load. Since we call vcpu_
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #7 from Alex Williamson ---
I'm guessing this might be the motherboard here: MSI ZH77A-G43
Since you're apparently trying to use VT-d on this system for KVM and therefore
presumably device assignment, I'll note that you will never be
Hello,
ran into this error for a first time over veru large hardware
span/uptime (the server which experienced the error is identical to
others, and I had absolutely none of MSI-related problems with this
hardware ever).
Running 3.10 at host, I had one (of many) VM on it which produced
enormous c
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #6 from Alex Williamson ---
Ok, then it's probably not a result of the PCIe-to-PCI bridge since 05:00.0 is
the correct requester ID for all the devices behind the bridge. Unfortunately
that means that the problem may not be fixable.
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #5 from Ansa89 ---
Tested with 3.17-rc1: the errors still there, but the spam rate seems lower
than 3.16.1 (with 3.16.1 I get the errors repeated a lot of times and the count
grows fast; with 3.17-rc1 I get the same errors repeated les
sched_in preempt notifier is available for x86, allow its use in
specific virtualization technlogies as well.
Signed-off-by: Radim Krčmář
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/svm.c | 6 ++
arch/x86/kvm/vmx.c | 6 ++
arch/x86/kvm/x86.c
Change PLE window into per-vcpu variable, seeded from module parameter,
to allow greater flexibility.
Brings in a small overhead on every vmentry.
Signed-off-by: Radim Krčmář
---
I've been thinking about a general hierarchical per-vcpu variable model,
but it's hard to have current performance
PLE does not scale in its current form. When increasing VCPU count
above 150, one can hit soft lockups because of runqueue lock contention.
(Which says a lot about performance.)
The main reason is that kvm_ple_loop cycles through all VCPUs.
Replacing it with a scalable solution would be ideal, bu
Window is increased on every PLE exit and decreased on every sched_in.
The idea is that we don't want to PLE exit if there is no preemption
going on.
We do this with sched_in() because it does not hold rq lock.
There are two new kernel parameters for changing the window:
ple_window_grow and ple_
They were almost identical and thus merged with a loathable macro.
Signed-off-by: Radim Krčmář
---
This solution is hopefully more acceptable than function pointers.
arch/x86/kvm/vmx.c | 53 +++--
1 file changed, 19 insertions(+), 34 deletions(-)
Every increase of ple_window_grow creates potential overflows.
They are not serious, because we clamp ple_window and userspace is
expected to fix ple_window_max within a second.
---
arch/x86/kvm/vmx.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --
ple_window is updated on every vmentry, so there is no reason to have it
read-only anymore.
ple_window_* weren't writable to prevent runtime overflow races;
they are mitigated by clamping the value of ple_window.
Signed-off-by: Radim Krčmář
---
If we decide to ignore insane overflows, last two h
Tracepoint for dynamic PLE window, fired on every potential change.
Signed-off-by: Radim Krčmář
---
arch/x86/kvm/trace.h | 29 +
arch/x86/kvm/vmx.c | 4
arch/x86/kvm/x86.c | 1 +
3 files changed, 34 insertions(+)
diff --git a/arch/x86/kvm/trace.h b/arch/x8
Modifications could get unwanted values of PLE window. (low or negative)
Use ple_window and the maximal value that cannot overflow as bounds.
ple_window_max defaults to a very high value, but it would make sense to
set it to some fraction of the scheduler tick.
Signed-off-by: Radim Krčmář
---
a
Introduce preempt notifiers for architecture specific code.
Advantage over creating a new notifier in every arch is slightly simpler
code and guaranteed call order with respect to kvm_sched_in.
Signed-off-by: Radim Krčmář
---
arch/arm/kvm/arm.c | 4
arch/mips/kvm/mips.c | 4 ++
> This RFC's intention is to show what an interface to access device node
> properties for VFIO_PLATFORM can look like.
>
> If a device tree node corresponding to a platform device bound by
> VFIO_PLATFORM
> is available, this patch series will allow the user to query the properties
> associated
$ uname -r
3.16.1-1-ARCH
-
As a regular user, member of the libvirt group, I run this command to
create a basic VM:
virt-install --connect qemu:///system --name=test --ram 2048 --cpu
host-model-only --os-variant=win7 --disk /myVM/test --boot cdrom,hd
--virt-type kvm --graphics
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #4 from Ansa89 ---
I will try 3.17-rc1 (hoping it's enough stable for home-server).
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" i
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #3 from Alex Williamson ---
(In reply to Ansa89 from comment #2)
> 1) I would prefer stay on stable kernel if it's possible (which commits of
> 3.17-rc1 would be relevant for this bug?).
579305f iommu/vt-d: Update to use PCI DMA alias
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #2 from Ansa89 ---
1) I would prefer stay on stable kernel if it's possible (which commits of
3.17-rc1 would be relevant for this bug?).
2) Yes, all of the 8169 NICs are up and running.
3) lspci -vvs 04:00.0
04:00.0 PCI bridge: ASMed
Il 19/08/2014 17:44, Chen Gang ha scritto:
> Hello maintainers:
>
> Please help check this patch, when you have time.
Hi, it's already on its way to 3.17-rc2, but I first have to run a bunch
of tests.
Paolo
> Thanks.
>
> On 08/08/2014 11:37 PM, Chen Gang wrote:
>> As a generic function, deassi
Hello maintainers:
Please help check this patch, when you have time.
Thanks.
On 08/08/2014 11:37 PM, Chen Gang wrote:
> As a generic function, deassign_guest_irq() assumes it can be called
> even if assign_guest_irq() is not be called successfully (which can be
> triggered by ioctl from user mod
> hmmm, the point is that we need to ensure that we have a properly
> aligned allocated PGD, that's what this patch currently addresses, and as
> you pointed out, the BUG_ON() just before trying to run a VM is not the
> nicest solution - we should really be dealing with this properly at
> allocati
On Tue, Aug 19, 2014 at 09:53:51AM -0500, Joel Schopp wrote:
>
> On 08/19/2014 09:37 AM, Christoffer Dall wrote:
> > On Tue, Aug 19, 2014 at 09:05:09AM -0500, Joel Schopp wrote:
> >> On 08/19/2014 07:22 AM, Christoffer Dall wrote:
> >>> On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
On 08/19/2014 08:15 PM, Christian Borntraeger wrote:
We dont have to wait for a grace period if there is no oldpid that
we are going to free. putpid also checks for NULL, so this patch
only fences synchronize_rcu.
Signed-off-by: Christian Borntraeger
Feel free to add:
Reviewed-by: Raghavendra
On Tue, Aug 19, 2014 at 09:49:07AM -0500, Joel Schopp wrote:
>
> >> The return is a value,not just an error code. Because of this returning
> >> an error overloads that value. 0 just seemed like a convenient invalid
> >> value to check since a vttbr_x of 0 is invalid, but returning a negative
> >
On 08/19/2014 09:37 AM, Christoffer Dall wrote:
> On Tue, Aug 19, 2014 at 09:05:09AM -0500, Joel Schopp wrote:
>> On 08/19/2014 07:22 AM, Christoffer Dall wrote:
>>> On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
#endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/mmu
> >> Hmm. We want to not only reduce, we want them be zero.
> >> In addition to a reworked MP_STATE patch set, we might be able to change
> >> the code to call "KVM_S390_INITIAL_RESET" only from the cpu thread itself.
> >> If that simplifies things, we could avoid doing KVM_S390_INITIAL_RESET on
>> The return is a value,not just an error code. Because of this returning
>> an error overloads that value. 0 just seemed like a convenient invalid
>> value to check since a vttbr_x of 0 is invalid, but returning a negative
>> error code would be as equally invalid. If this is the only issue it
We dont have to wait for a grace period if there is no oldpid that
we are going to free. putpid also checks for NULL, so this patch
only fences synchronize_rcu.
Signed-off-by: Christian Borntraeger
---
virt/kvm/kvm_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/virt
On 19/08/14 16:23, David Hildenbrand wrote:
>> On 19/08/14 14:14, David Hildenbrand wrote:
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
> Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls
> in
> the vcpu thread (e.g. comming from cpu_synchronize_all_s
On Tue, Aug 19, 2014 at 09:23:57AM -0500, Joel Schopp wrote:
>
> On 08/19/2014 07:24 AM, Christoffer Dall wrote:
> > On Mon, Aug 18, 2014 at 03:36:04PM -0500, Joel Schopp wrote:
> >> The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
> >> systems. Rather than just add a b
On Tue, Aug 19, 2014 at 09:05:09AM -0500, Joel Schopp wrote:
>
> On 08/19/2014 07:22 AM, Christoffer Dall wrote:
> > On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
> >> #endif /* __ARM_KVM_MMU_H__ */
> >> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> >> index 16e7994..70f0f
On 08/19/2014 07:24 AM, Christoffer Dall wrote:
> On Mon, Aug 18, 2014 at 03:36:04PM -0500, Joel Schopp wrote:
>> The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
>> systems. Rather than just add a bit it seems like a good time to also set
>> things at run-time instead
> On 19/08/14 14:14, David Hildenbrand wrote:
> >> Il 19/08/2014 13:28, David Hildenbrand ha scritto:
> >>> Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls
> >>> in
> >>> the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
> >>> reasons
> >>> why kvm_cp
On 08/19/2014 07:22 AM, Christoffer Dall wrote:
> On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
>> #endif /* __ARM_KVM_MMU_H__ */
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 16e7994..70f0f02 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -
On 19/08/14 14:14, David Hildenbrand wrote:
>> Il 19/08/2014 13:28, David Hildenbrand ha scritto:
>>> Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
>>> the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
>>> reasons
>>> why kvm_cpu_synchronize_post_
On 18/08/14 07:02, Wanpeng Li wrote:
> Hi Christian,
> On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
>> We currently track the pid of the task that runs the VCPU in
>> vcpu_load. Since we call vcpu_load for all kind of ioctls on a
>> CPU, this causes hickups due to synchron
Il 19/08/2014 15:34, Nadav Amit ha scritto:
> I know, but all the other ‘call' tests did. If there is an error, at
> least it should be consistent. ;-)
Right, let's fix it up:
diff --git a/x86/taskswitch2.c b/x86/taskswitch2.c
index fd9a404..3cfb467 100644
--- a/x86/taskswitch2.c
+++ b/x86/tasksw
On Aug 19, 2014, at 4:28 PM, Paolo Bonzini wrote:
> Il 19/08/2014 15:04, Nadav Amit ha scritto:
>>
>> +void test_conforming_switch(void)
>> +{
>> +/* test lcall with conforming segment, cs.dpl != cs.rpl */
>> +test_count = 0;
>> +set_intr_task_gate(0, user_tss);
>
> No need to use
Il 19/08/2014 15:04, Nadav Amit ha scritto:
> Commit 5045b46803 added a check that cs.dpl equals cs.rpl during task-switch.
> This is a wrong check, and this patch introduces a test in which cs.dpl !=
> cs.rpl. To do so, it configures tss.cs to be conforming with rpl=3 and dpl=0.
> Since the cpl af
Il 19/08/2014 15:18, Eduardo Habkost ha scritto:
> On Tue, Aug 19, 2014 at 11:51:05AM +0200, Paolo Bonzini wrote:
>> Il 18/08/2014 21:43, Nadav Amit ha scritto:
>>> Currently, the TSC deadline test never runs, since TSC deadline is disabled
>>> unless the host cpu parameter is used. This patch chan
On Tue, Aug 19, 2014 at 11:51:05AM +0200, Paolo Bonzini wrote:
> Il 18/08/2014 21:43, Nadav Amit ha scritto:
> > Currently, the TSC deadline test never runs, since TSC deadline is disabled
> > unless the host cpu parameter is used. This patch changes the apic test to
> > use
> > the qemu host cpu
Commit 5045b46803 added a check that cs.dpl equals cs.rpl during task-switch.
This is a wrong check, and this patch introduces a test in which cs.dpl !=
cs.rpl. To do so, it configures tss.cs to be conforming with rpl=3 and dpl=0.
Since the cpl after calling is 3, it does not make any prints in the
Il 19/08/2014 13:14, zhanghailiang ha scritto:
> The third parameter of kvm_iommu_put_pages is wrong,
> It should be 'gfn-slot->base_gfn'
This fixes a crash, doesn't it? Please mention it in the commit
message, because we have to assign a CVE for this kind of issue. It
will be CVE-2014-3601.
I
https://bugzilla.kernel.org/show_bug.cgi?id=82761
Alex Williamson changed:
What|Removed |Added
CC||alex.william...@redhat.com
--- Comment
On Mon, Aug 18, 2014 at 03:36:04PM -0500, Joel Schopp wrote:
> The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
> systems. Rather than just add a bit it seems like a good time to also set
> things at run-time instead of compile time to accomodate more hardware.
>
> This
On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
>
> #endif /* __ARM_KVM_MMU_H__ */
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 16e7994..70f0f02 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -521,6 +521,7 @@ int create_hyp_io_mappings(void *from,
https://bugzilla.kernel.org/show_bug.cgi?id=82761
Bug ID: 82761
Summary: DMAR:[fault reason 06] PTE Read access is not set
Product: Virtualization
Version: unspecified
Kernel Version: 3.16.1
Hardware: All
OS: Linux
> Il 19/08/2014 13:28, David Hildenbrand ha scritto:
> > Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
> > the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
> > reasons
> > why kvm_cpu_synchronize_post_reset() doesn't do the same (e.g. called from
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
> Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
> the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any reasons
> why kvm_cpu_synchronize_post_reset() doesn't do the same (e.g. called from
> cpu_synchr
Il 19/08/2014 13:16, Wanpeng Li ha scritto:
> On Tue, Aug 19, 2014 at 11:09:49AM +0200, Paolo Bonzini wrote:
>> Il 19/08/2014 11:04, Wanpeng Li ha scritto:
>>> EPT misconfig handler in kvm will check which reason lead to EPT
>>> misconfiguration after vmexit. One of the reasons is that an EPT
>>>
To support read-only memory regions on arm and arm64, we have a need to
resolve a gfn to an hva given a pointer to a memslot to avoid looping
through the memslots twice and to reuse the hva error checking of
gfn_to_hva_prot(), add a new gfn_to_hva_memslot_prot() function and
refactor gfn_to_hva_pro
When userspace loads code and data in a read-only memory regions, KVM
needs to be able to handle this on arm and arm64. Specifically this is
used when running code directly from a read-only flash device; the
common scenario is a UEFI blob loaded with the -bios option in QEMU.
Note that the MMIO e
> Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
> >> > The patch may be okay, but I'm worried that it might be hiding a bug in
> >> > QEMU.
> > On s390 we call "KVM_S390_INITIAL_RESET" from several reset functions, e.g.
> > during
> > CPU creation. This is the first hickup and the pid no
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn-slot->base_gfn'
Signed-off-by: zhanghailiang
---
virt/kvm/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 0df7d4b..c02f9a3 100644
--- a/virt/kvm/iommu.c
++
On Tue, Aug 19, 2014 at 11:09:49AM +0200, Paolo Bonzini wrote:
>Il 19/08/2014 11:04, Wanpeng Li ha scritto:
>> EPT misconfig handler in kvm will check which reason lead to EPT
>> misconfiguration after vmexit. One of the reasons is that an EPT
>> paging-structure entry is configured with settings
Il 19/08/2014 12:48, Christian Borntraeger ha scritto:
> But I understand your concern of touching generic KVM code only if
> really necessary. Let me know if I should send a minimal pid==0
> version. (I would prefer the full version, of course).
Yes, please do.
Paolo
--
To unsubscribe from this
On 19/08/14 12:31, Paolo Bonzini wrote:
> Il 19/08/2014 12:09, Christian Borntraeger ha scritto:
>>> I'm not sure, this does seem like a workaround for another
>>> limitation after all... Gleb?
>>
>> Yes. We want to get rid of KVM_S390_INITIAL_RESET in QEMU. This comes
>> from a time, when we had
Il 18/08/2014 21:42, Nadav Amit ha scritto:
> Intel SDM 10.5.4.1 says "When the timer generates an interrupt, it disarms
> itself and clears the IA32_TSC_DEADLINE MSR".
>
> This patch clears the MSR upon timer interrupt delivery which delivered on
> deadline mode. Since the MSR may be reconfigure
Il 18/08/2014 23:03, Nadav Amit ha scritto:
> Currently, recalculate_apic_map ignores vcpus whose lapic is software disabled
> through the spurious interrupt vector. However, once it is re-enabled, the map
> is not recalculated. Therefore, if the guest OS configured DFR while lapic is
> software-di
Il 19/08/2014 12:09, Christian Borntraeger ha scritto:
>> I'm not sure, this does seem like a workaround for another
>> limitation after all... Gleb?
>
> Yes. We want to get rid of KVM_S390_INITIAL_RESET in QEMU. This comes
> from a time, when we had another userspace prototype for KVM on s390
> (
Il 17/08/2014 21:34, Nadav Amit ha scritto:
> Commit 5045b46803 added a check that cs.dpl equals cs.rpl during task-switch.
> This is a wrong check, and this test introduces a test in which cs.dpl !=
> cs.rpl. To do so, it configures tss.cs to be conforming with rpl=3 and dpl=0.
> Since the cpl aft
Juan Quintela wrote:
> Hi
>
> Please, send any topic that you are interested in covering.
>
> People have complained on the past that I don't cancel the call until
> the very last minute. So, what do you think that deadline for
> submitting topics is 23:00UTC on Monday?
As there are no topics, c
On 19/08/14 12:03, Paolo Bonzini wrote:
> Il 19/08/2014 11:59, Christian Borntraeger ha scritto:
>> Its only for the interrupts that are cpu local (like pending IPIs).
>> In addition, we would do that only for the reset case (with an
>> interface that can be used for migration). Right now
>> KVM_S3
Il 18/08/2014 21:43, Nadav Amit ha scritto:
> Once the local-apic timer is configured to use TSC deadline, the deadline
> should be cleared after the deadline passes. This patch adds a check of this
> behavior.
>
> Signed-off-by: Nadav Amit
> ---
> x86/apic.c | 1 +
> 1 file changed, 1 insertio
On Tue, Aug 19, 2014 at 10:53:16AM +0200, Eric Auger wrote:
> On 08/13/2014 04:55 PM, Christoffer Dall wrote:
> > On Mon, Aug 04, 2014 at 02:08:22PM +0200, Eric Auger wrote:
> >> This patch enables irqfd on ARM.
> >>
> >> irqfd framework enables to inject a virtual IRQ into a guest upon an
> >> eve
Il 19/08/2014 11:59, Christian Borntraeger ha scritto:
> Its only for the interrupts that are cpu local (like pending IPIs).
> In addition, we would do that only for the reset case (with an
> interface that can be used for migration). Right now
> KVM_S390_INITIAL_RESET takes the vcpu_mutex, so this
On 19/08/14 11:53, Paolo Bonzini wrote:
> Il 19/08/2014 11:47, Christian Borntraeger ha scritto:
>> On 19/08/14 11:27, Paolo Bonzini wrote:
>>> Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
>> The patch may be okay, but I'm worried that it might be
>> hiding a bug in QEMU.
On
Il 19/08/2014 11:47, Christian Borntraeger ha scritto:
> On 19/08/14 11:27, Paolo Bonzini wrote:
>> Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
> The patch may be okay, but I'm worried that it might be
> hiding a bug in QEMU.
>>> On s390 we call "KVM_S390_INITIAL_RESET" from seve
Il 18/08/2014 21:43, Nadav Amit ha scritto:
> Currently, the TSC deadline test never runs, since TSC deadline is disabled
> unless the host cpu parameter is used. This patch changes the apic test to use
> the qemu host cpu parameter.
Better use
> Signed-off-by: Nadav Amit
> ---
> x86/unittests.c
On 19/08/14 11:27, Paolo Bonzini wrote:
> Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be hiding a bug in
QEMU.
>> On s390 we call "KVM_S390_INITIAL_RESET" from several reset functions, e.g.
>> during
>> CPU creation. This i
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
>> > The patch may be okay, but I'm worried that it might be hiding a bug in
>> > QEMU.
> On s390 we call "KVM_S390_INITIAL_RESET" from several reset functions, e.g.
> during
> CPU creation. This is the first hickup and the pid now points to
Il 19/08/2014 11:04, Wanpeng Li ha scritto:
> Section 11.11.2.3 of the SDM mentions "All other bits in the
> IA32_MTRR_PHYSBASEn
> and IA32_MTRR_PHYSMASKn registers are reserved; the processor generates a
> general-protection exception(#GP) if software attempts to write to them".
> This
> patc
Section 11.11.2.3 of the SDM mentions "All other bits in the
IA32_MTRR_PHYSBASEn
and IA32_MTRR_PHYSMASKn registers are reserved; the processor generates a
general-protection exception(#GP) if software attempts to write to them". This
patch do it in kvm.
Signed-off-by: Wanpeng Li
---
arch/x86
The first entry in each pair(IA32_MTRR_PHYSBASEn) defines the base
address and memory type for the range; the second entry(IA32_MTRR_PHYSMASKn)
contains a mask used to determine the address range. The legal values
for the type field of IA32_MTRR_PHYSBASEn are 0,1,4,5, and 6. However,
IA32_MTRR_PH
Il 19/08/2014 10:50, Xiao Guangrong ha scritto:
> Okay, what confused me it that it seems that the single line patch
> is ok to you. :)
No, it was late and I was confused. :)
> Now, do we really need to care the case 2? like David said:
> "Sorry I didn't explain myself very well: Since we can get
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
paging-structure entry is configured with settings reserved for
future functionality. However, the handler can't identify if
paging-structure entry of reserved bits
Il 19/08/2014 11:04, Wanpeng Li ha scritto:
> EPT misconfig handler in kvm will check which reason lead to EPT
> misconfiguration after vmexit. One of the reasons is that an EPT
> paging-structure entry is configured with settings reserved for
> future functionality. However, the handler can't i
On 08/13/2014 04:55 PM, Christoffer Dall wrote:
> On Mon, Aug 04, 2014 at 02:08:22PM +0200, Eric Auger wrote:
>> This patch enables irqfd on ARM.
>>
>> irqfd framework enables to inject a virtual IRQ into a guest upon an
>> eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
>> a
On 08/13/2014 04:55 PM, Christoffer Dall wrote:
> On Mon, Aug 04, 2014 at 02:08:22PM +0200, Eric Auger wrote:
>> This patch enables irqfd on ARM.
>>
>> irqfd framework enables to inject a virtual IRQ into a guest upon an
>> eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
>> a
On 08/19/2014 04:28 PM, Paolo Bonzini wrote:
> Il 19/08/2014 05:50, Xiao Guangrong ha scritto:
>>
>> Note in the step *, my approach detects the invalid generation-number which
>> will invalidate the mmio spte properly .
>
> You are right, in fact my mail included another part: "Another
> alterna
On 07/08/14 15:39, Paolo Bonzini wrote:
> Il 05/08/2014 16:44, Christian Borntraeger ha scritto:
>> We currently track the pid of the task that runs the VCPU in
>> vcpu_load. Since we call vcpu_load for all kind of ioctls on a
>> CPU, this causes hickups due to synchronize_rcu if one CPU is
>> modi
On 07/08/14 15:40, Paolo Bonzini wrote:
> Il 07/08/2014 11:59, Christian Borntraeger ha scritto:
>> Paolo,
>>
>> are you willing to apply to kvm/queue?
>
> I asked a question, but anyway... not until the end of the merge window
> and my small vacation. :)
>
> Paolo
>
Absolutely, was on vacation
> That was just one example. There many other possibilities. Either
> actually make the systems load all host CPUs equally, or divide
> throughput by host CPU.
>
The polling patch adds this capability to vhost, reducing costly exit
overhead when the vm is loaded.
In order to load the vm I ran
Il 19/08/2014 10:30, Wanpeng Li ha scritto:
> + if (vmx->nested.virtual_apic_page)
> + nested_release_page(vmx->nested.virtual_apic_page);
> + vmx->nested.virtual_apic_page =
> +nested_get_page(vcpu, vmcs12->virtual_apic_page_addr);
> +
This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=61411
TPR shadow/threshold feature is important to speed up the Windows guest.
Besides, it is a must feature for certain VMM.
We map virtual APIC page address and TPR threshold from L1 VMCS. If
TPR_BELOW_THRESHOLD VM exit is triggered
Il 19/08/2014 05:50, Xiao Guangrong ha scritto:
>
> Note in the step *, my approach detects the invalid generation-number which
> will invalidate the mmio spte properly .
You are right, in fact my mail included another part: "Another
alternative could be to use the low bit to mark an in-progress
100 matches
Mail list logo
