On 06/05/2014 05:11 AM, Mario Smarduch wrote:
> + spin_lock(&kvm->mmu_lock);
> +
> + for (i = 0; i < n / sizeof(long); i++) {
> + unsigned long mask;
> + gfn_t offset;
> +
> + if (!dirty_bitmap[i])
> + continue;
> +
> + is
On Mon, Jun 02, 2014 at 10:57:05AM -0600, Bjorn Helgaas wrote:
>On Sat, May 31, 2014 at 5:42 AM, Gavin Shan wrote:
>> On Fri, May 30, 2014 at 04:12:32PM -0600, Bjorn Helgaas wrote:
>>>On Mon, May 19, 2014 at 01:01:10PM +1000, Gavin Shan wrote:
.../...
[ Remove the confusing description ]
>It so
Hello
Just a bump to see if anyone can help:)
MW
On Tue, Jun 3, 2014 at 6:08 PM, Marcus White wrote:
> Cant the pages be locked down by the host when it gets the call down
> for an operation with a buffer(like if a usual user mode process
> case), and once locked down in the host kernel, the phy
On 04.06.14 13:17, Aneesh Kumar K.V wrote:
We use time base for PURR and SPURR emulation with PR KVM since we
are emulating a single threaded core. When using time base
we need to make sure that we don't accumulate time spent in the host
in PURR and SPURR value.
Also we don't need to emulate mt
Jidong Xiao writes:
..
>>
> Hi, Bandan,
>
> Thanks for the advice. I think Paolo has incorporated this patch into
> his patch sets, and he sent the revised version in a separate email
> earlier today with the subject "[PULL 11/11] kvm: Fix eax for cpuid
> leaf 0x4000".
Oops! Sorry, must have
A couple more updates to test_vmxon, test_vmptrld
and test_vmclear based on kvm commits -
3573e22cfecaac83f82ef4f6847d90e466fc8e10
KVM: nVMX: additional checks on vmxon region
96ec146330d18a938b4773be8d6dd1f93399507c
KVM: nVMX: fail on invalid vmclear/vmptrld pointer
Bandan Das (2):
VMX: Add m
Check if the vmcs pointer is not aligned to page size,
and if bits beyond physical address width are set. Also,
vmclear and vmptrld should fail if the vmxon region is
supplied instead of the vmcs
Signed-off-by: Bandan Das
---
x86/vmx.c | 63 +++
Verify that vmon fails with unaligned vmxon region or
any bits set beyong the physical address width. Also verify
failure with an invalid revision identifier.
Signed-off-by: Bandan Das
---
x86/vmx.c | 46 +++---
1 file changed, 43 insertions(+), 3 deletion
Resending patch, noticed I forgot to adjust start_ipa properly in
stage2_wp_mask_range() and then noticed that pte's can be indexed directly.
The patch applies cleanly after 2/4 and 4/4 applies cleanly after this patch.
This patch adds support for keeping track of VM dirty pages. As dirty page l
On Jun 4, 2014, at 11:11 PM, Gabriel L. Somlo wrote:
> On Wed, Jun 04, 2014 at 11:01:50PM +0300, Nadav Amit wrote:
>> On Jun 4, 2014, at 10:43 PM, Gabriel L. Somlo wrote:
>>
>> My implementation still emulates the instruction as a NOP, but first checks
>> for an exception.
>
> [...]
>
>> A
On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote:
> That should be the purpose of KVM_GET_EMULATED_CPUID, so MWAIT could be
> added in __do_cpuid_ent_emulated. However, the corresponding QEMU patches
> were never included. Borislav, can you refresh them?
/me goes and swaps in all th
On Wed, Jun 04, 2014 at 11:01:50PM +0300, Nadav Amit wrote:
> On Jun 4, 2014, at 10:43 PM, Gabriel L. Somlo wrote:
>
> My implementation still emulates the instruction as a NOP, but first checks
> for an exception.
[...]
> Anyhow, if you want a real mwait emulation, you can write-protect the
On Jun 4, 2014, at 10:43 PM, Gabriel L. Somlo wrote:
My implementation still emulates the instruction as a NOP, but first checks for
an exception.
> On Wed, Jun 04, 2014 at 10:12:39PM +0300, Nadav Amit wrote:
>
> I'd be curious how you're dealing with the "hidden" CPU state which
> tells MWAIT
On Wed, Jun 4, 2014 at 3:08 PM, Bandan Das wrote:
> Jidong Xiao writes:
>
>> On Wed, Jun 4, 2014 at 3:09 AM, Paolo Bonzini wrote:
>>> Il 04/06/2014 03:10, Jidong Xiao ha scritto:
>>>
diff --git a/qemu-2.0.0/target-i386/kvm.c.orig
b/qemu-2.0.0/target-i386/kvm.c
index 4389959..b8b28
On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote:
> On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote:
> > Il 02/06/2014 23:58, Eric Dumazet ha scritto:
> > > This looks dubious
> > >
> > > What about using kfree_rcu() instead ?
> >
> > It would lead to unbound allocation from use
On Wed, Jun 04, 2014 at 10:12:39PM +0300, Nadav Amit wrote:
> Regardless to the whole discussion of what the guest is informed about, I
> think it might be better to implement mwait and monitor correctly according
> to the spec and let the instructions to be fully emulated.
> Both mwait and monit
On Wed, Jun 04, 2014 at 03:33:38PM -0400, Gabriel L. Somlo wrote:
> On Wed, Jun 04, 2014 at 10:08:12PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote:
> > > Il 04/06/2014 16:44, Alexander Graf ha scritto:
> > > >
> > > >
> > > >>Obviously, if you
On Wed, Jun 04, 2014 at 03:24:06PM -0400, Gabriel L. Somlo wrote:
> On Wed, Jun 04, 2014 at 10:06:18PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 04, 2014 at 01:07:21PM -0400, Gabriel L. Somlo wrote:
> > > Ah, so kvm_vcpu_ioctl_set_cpuid() and friends, morally similar to
> > > kvm_vcpu_ioctl_
On Wed, Jun 04, 2014 at 10:08:12PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote:
> > Il 04/06/2014 16:44, Alexander Graf ha scritto:
> > >
> > >
> > >>Obviously, if you really like the current behavior better you can
> > >>always reject whatever p
On Wed, Jun 04, 2014 at 10:06:18PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 04, 2014 at 01:07:21PM -0400, Gabriel L. Somlo wrote:
> > Ah, so kvm_vcpu_ioctl_set_cpuid() and friends, morally similar to
> > kvm_vcpu_ioctl_enable_cap() on ppc, except it turns on cpuid flags
> > instead of entire
On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote:
> Il 04/06/2014 16:44, Alexander Graf ha scritto:
> >
> >
> >>Obviously, if you really like the current behavior better you can
> >>always reject whatever patch I'll come up with, but I'd like to at
> >>least try and see what it would l
On Jun 4, 2014, at 7:34 PM, Paolo Bonzini wrote:
> Il 04/06/2014 16:44, Alexander Graf ha scritto:
>>
>>
>>> Obviously, if you really like the current behavior better you can
>>> always reject whatever patch I'll come up with, but I'd like to at
>>> least try and see what it would look like :)
Jidong Xiao writes:
> On Wed, Jun 4, 2014 at 3:09 AM, Paolo Bonzini wrote:
>> Il 04/06/2014 03:10, Jidong Xiao ha scritto:
>>
>>> diff --git a/qemu-2.0.0/target-i386/kvm.c.orig
>>> b/qemu-2.0.0/target-i386/kvm.c
>>> index 4389959..b8b282d 100644
>>> --- a/qemu-2.0.0/target-i386/kvm.c.orig
>>> ++
On Wed, Jun 04, 2014 at 01:07:21PM -0400, Gabriel L. Somlo wrote:
> On Wed, Jun 04, 2014 at 05:09:49PM +0200, Alexander Graf wrote:
> > >>>
> > >>>I grep-ed through the kvm sources for KVM_CAP for some inspiration,
> > >>>and it looks more like KVM_CAP_* is a way to tell userspace what the
> > >>>k
On Wed, Jun 04, 2014 at 01:22:49PM +0930, Rusty Russell wrote:
> Vlad Zolotarov writes:
> > Rusty, hi!
> > I'd like to ask for a small clarification about the virtio spec.
> > The virtio specification is put the way that it allows the out-of-order
> > completions in general. Although it states th
On Mon, Jun 02, 2014 at 02:58:00PM -0700, Eric Dumazet wrote:
> On Tue, 2014-06-03 at 00:30 +0300, Michael S. Tsirkin wrote:
> > All memory accesses are done under some VQ mutex.
> > So lock/unlock all VQs is a faster equivalent of synchronize_rcu()
> > for memory access changes.
> > Some guests ca
On Wed, Jun 04, 2014 at 05:09:49PM +0200, Alexander Graf wrote:
> >>>
> >>>I grep-ed through the kvm sources for KVM_CAP for some inspiration,
> >>>and it looks more like KVM_CAP_* is a way to tell userspace what the
> >>>kernel supports, but nothing I saw showed me an example of a "tunable"
> >>>f
Il 04/06/2014 16:44, Alexander Graf ha scritto:
Obviously, if you really like the current behavior better you can
always reject whatever patch I'll come up with, but I'd like to at
least try and see what it would look like :)
I think it's perfectly fine to leave mwait always implemented as N
On 04.06.14 17:05, Gabriel L. Somlo wrote:
On Wed, Jun 04, 2014 at 04:44:13PM +0200, Alexander Graf wrote:
On 04.06.14 16:39, Gabriel L. Somlo wrote:
Paolo,
I noticed the monitor=mwait=nop patch is making its way upstream, so
thanks !
I'm still interested in following up with something that
On Wed, Jun 04, 2014 at 04:44:13PM +0200, Alexander Graf wrote:
>
> On 04.06.14 16:39, Gabriel L. Somlo wrote:
> >Paolo,
> >
> >I noticed the monitor=mwait=nop patch is making its way upstream, so
> >thanks !
> >
> >I'm still interested in following up with something that would enable
> >this beha
On 04.06.14 16:39, Gabriel L. Somlo wrote:
Paolo,
I noticed the monitor=mwait=nop patch is making its way upstream, so
thanks !
I'm still interested in following up with something that would enable
this behavior only conditionally (e.g. following an ioctl call from
userspace to enable it only
Paolo,
I noticed the monitor=mwait=nop patch is making its way upstream, so
thanks !
I'm still interested in following up with something that would enable
this behavior only conditionally (e.g. following an ioctl call from
userspace to enable it only for the (set of) vcpu(s) belonging to one
gues
Currently when a KVM region is deleted or moved after
KVM_SET_USER_MEMORY_REGION ioctl, the corresponding
intermediate physical memory is not unmapped.
This patch corrects this and unmaps the region's IPA range
in kvm_arch_commit_memory_region using unmap_stage2_range.
The patch was tested with Q
"Aneesh Kumar K.V" writes:
> Paul Mackerras writes:
>
>> On Tue, Jun 03, 2014 at 05:46:11PM +0530, Aneesh Kumar K.V wrote:
>>> We use time base for PURR and SPURR emulation with PR KVM since we
>>> are emulating a single threaded core. When using time base
>>> we need to make sure that we don't
We use time base for PURR and SPURR emulation with PR KVM since we
are emulating a single threaded core. When using time base
we need to make sure that we don't accumulate time spent in the host
in PURR and SPURR value.
Also we don't need to emulate mtspr because both the registers are
hypervisor
Linus,
The following changes since commit 0f689a33ad17845363acdc6d52783befd6ad116c:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2014-04-16 11:28:25
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/
Paul Mackerras writes:
> On Tue, Jun 03, 2014 at 05:46:11PM +0530, Aneesh Kumar K.V wrote:
>> We use time base for PURR and SPURR emulation with PR KVM since we
>> are emulating a single threaded core. When using time base
>> we need to make sure that we don't accumulate time spent in the host
>>
Il 03/06/2014 22:27, Bandan Das ha scritto:
Adds a simple test for interrupt acknowledgement and change
invept behavior to check for supported invalidation contexts
Bandan Das (2):
VMX: check for supported contexts before calling invept
VMX: Add test for interrupt acknowledgement
lib/x86/i
On Wed, Jun 04 2014 at 7:19:42 am BST, Lei Wen wrote:
> On Tue, Jun 3, 2014 at 5:11 PM, Marc Zyngier wrote:
>> On Tue, Jun 03 2014 at 3:14:33 am BST, Lei Wen
>> wrote:
>>> Hi Marc,
>>>
>>> On Mon, Jun 2, 2014 at 5:27 PM, Marc Zyngier wrote:
kvmtool tells you where the console lives (it
On 2014-06-03 22:11, Bandan Das wrote:
> Paolo Bonzini writes:
>
>> Il 06/05/2014 08:19, Bandan Das ha scritto:
>>> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=54521
>>>
>>> The vmxon region is unused by nvmx, but adding these checks
>>> are probably harmless and may detect buggy L1 hy
On Wed, Jun 4, 2014 at 3:09 AM, Paolo Bonzini wrote:
> Il 04/06/2014 03:10, Jidong Xiao ha scritto:
>
>> diff --git a/qemu-2.0.0/target-i386/kvm.c.orig
>> b/qemu-2.0.0/target-i386/kvm.c
>> index 4389959..b8b282d 100644
>> --- a/qemu-2.0.0/target-i386/kvm.c.orig
>> +++ b/qemu-2.0.0/target-i386/kvm.
Il 04/06/2014 03:10, Jidong Xiao ha scritto:
diff --git a/qemu-2.0.0/target-i386/kvm.c.orig b/qemu-2.0.0/target-i386/kvm.c
index 4389959..b8b282d 100644
--- a/qemu-2.0.0/target-i386/kvm.c.orig
+++ b/qemu-2.0.0/target-i386/kvm.c
@@ -530,7 +530,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
memcpy(
42 matches
Mail list logo
