On 18.11.2013, at 19:36, Scott Wood wrote:
> On Fri, 2013-11-15 at 11:01 +0530, Bharat Bhushan wrote:
>> From: Bharat Bhushan
>>
>> v2->v3
>> - Returning pte pointer rather than pte as suggested by Scott
>> - Also removed PAGE_SPLITTING as this need to be handled by caller
>>
>> v1->v2
>>
Il 17/12/2013 19:57, Jan Kiszka ha scritto:
> When userspace sets MSR_IA32_FEATURE_CONTROL to 0, make sure we leave
> root and non-root mode, fully disabling VMX. The register state of the
> VCPU is undefined after this step, so userspace has to set it to a
> proper state afterward.
>
> This enabl
Il 17/12/2013 20:05, Jan Kiszka ha scritto:
> If the guest is running in nested mode on system reset, clearing the
> feature MSR signals the kernel to leave this mode. Recent kernels
> processes this properly, but leave the VCPU state undefined behind. It
> is the job of userspace to bring it to a
Il 16/12/2013 12:55, Jan Kiszka ha scritto:
> It's a pathological case, but still a valid one: If L1 disables APIC
> virtualization and also allows L2 to directly write to the APIC page, we
> have to forcibly enable APIC virtualization while in L2 if the in-kernel
> APIC is in use.
>
> This allows
Il 16/12/2013 10:57, Jan Kiszka ha scritto:
> This series contains various smaller fixes and cleanups for the VMX unit
> tests and also a few unrelated corners of the test suite. It ends with a
> rework of the VMX capability test and the addition of a bunch of new
> test cases for interrupt injecti
On 18.12.2013, at 08:35, Aneesh Kumar K.V
wrote:
>
> Hi Alex,
>
> Any update on this ? We need this to got into 3.13.
Thanks, applied to for-3.13.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On 16.12.2013, at 03:31, Paul Mackerras wrote:
> Commit caaa4c804fae ("KVM: PPC: Book3S HV: Fix physical address
> calculations") unfortunately resulted in some low-order address bits
> getting dropped in the case where the guest is creating a 4k HPTE
> and the host page size is 64k. By getting
On Tue, Dec 17, 2013 at 12:04:42PM +0200, Razya Ladelsky wrote:
> Hi,
>
> Thank you all for your comments.
> I'm sorry for taking this long to reply, I was away on vacation..
>
> It was a good, long discussion, many issues were raised, which we'd like
> to address with the following proposed roa
On 17/12/13 20:39, Alexander Graf wrote:
On 17.12.2013, at 19:31, Robin Murphy wrote:
Some platforms have secure firmware which does not correctly set the
CNTFRQ register on boot, preventing the use of the Generic Timer.
This patch allows mirroring the necessary host workaround by specifying
On 18.12.2013, at 14:44, Robin Murphy wrote:
> On 17/12/13 20:39, Alexander Graf wrote:
>>
>> On 17.12.2013, at 19:31, Robin Murphy wrote:
>>
>>> Some platforms have secure firmware which does not correctly set the
>>> CNTFRQ register on boot, preventing the use of the Generic Timer.
>>> This
https://bugzilla.kernel.org/show_bug.cgi?id=67061
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Summary|[Neste
As soon as we get back to our "highmem" handler in virtual address
space we may get preempted. Today the reason we can get preempted is
that we replay interrupts and all the lazy logic thinks we have
interrupts enabled.
However, it's not hard to make the code interruptible and that way
we can enab
We call a C helper to save all svcpu fields into our vcpu. The C
ABI states that r12 is considered volatile. However, we keep our
exit handler id in r12 currently.
So we need to save it away into a non-volatile register instead
that definitely does get preserved across the C call.
This bug usuall
From: Paul Mackerras
This fixes a bug in kvmppc_do_h_enter() where the physical address
for a page can be calculated incorrectly if transparent huge pages
(THP) are active. Until THP came along, it was true that if we
encountered a large (16M) page in kvmppc_do_h_enter(), then the
associated mem
From: Scott Wood
Commit ce11e48b7fdd256ec68b932a89b397a790566031 ("KVM: PPC: E500: Add
userspace debug stub support") added "struct thread_struct" to the
stack of kvmppc_vcpu_run(). thread_struct is 1152 bytes on my build,
compared to 48 bytes for the recently-introduced "struct debug_reg".
Use
The kvmppc_copy_{to,from}_svcpu functions are publically visible,
so we should also export them in a header for others C files to
consume.
So far we didn't need this because we only called it from asm code.
The next patch will introduce a C caller.
Signed-off-by: Alexander Graf
---
arch/powerpc
Now that the svcpu sync is interrupt aware we can enable interrupts
earlier in the exit code path again, moving 32bit and 64bit closer
together.
While at it, document the fact that we're always executing the exit
path with interrupts enabled so that the next person doesn't trap
over this.
Signed-
Hi Paolo / Gleb,
This is my current patch queue for 3.13.
It fixes some grave issues we've only found after 3.13-rc1:
- Make the modularized HV/PR book3s kvm work well as modules
- Fix some race conditions
- Fix compilation with certain compilers (booke)
- Fix THP for book3s_hv
- Fix p
From: "Aneesh Kumar K.V"
We don't use PACATOC for PR. Avoid updating HOST_R2 with PR
KVM mode when both HV and PR are enabled in the kernel. Without this we
get the below crash
(qemu)
Unable to handle kernel paging request for data at address 0x8310
Faulting instruction address: 0xc0
From: Paul Mackerras
Commit caaa4c804fae ("KVM: PPC: Book3S HV: Fix physical address
calculations") unfortunately resulted in some low-order address bits
getting dropped in the case where the guest is creating a 4k HPTE
and the host page size is 64k. By getting the low-order bits from
hva rather
From: pingfan liu
Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
realmode, so it can trigger the deadlock.
Suppose the following scene:
Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of
vcpus.
If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is
From: Paul Mackerras
Some users have reported instances of the host hanging with secondary
threads of a core waiting for the primary thread to exit the guest,
and the primary thread stuck in nap mode. This prompted a review of
the memory barriers in the guest entry/exit code, and this is the
res
From: Paul Mackerras
Lockdep reported that there is a potential for deadlock because
vcpu->arch.tbacct_lock is not irq-safe, and is sometimes taken inside
the rq_lock (run-queue lock) in the scheduler, which is taken within
interrupts. The lockdep splat looks like:
=
From: Paul Mackerras
Running a kernel with CONFIG_PROVE_RCU=y yields the following diagnostic:
===
[ INFO: suspicious RCU usage. ]
3.12.0-rc5-kvm+ #9 Not tainted
---
include/linux/kvm_host.h:473 suspicious rcu_dereference_check() usage!
o
On 18/12/13 14:07, Alexander Graf wrote:
[...]
How does it encourage a vendor to properly implement their firmware if there's
a workaround?
Alex
Hi Alex,
In short, by enabling the users to create the demand. Yes, like any workaround there's potential
for abuse, but having *something* th
On Mon, Dec 16, 2013 at 12:38:17PM +0100, Paolo Bonzini wrote:
> The KVM patch "fix vapic memory corruption" applies to most kernels that
> have KVM, but the fix does not apply on many older branches. The APIs it
> uses are available in 3.1, but until 3.9 kvm_gfn_to_hva_cache_init had
> one fewer
If kvm_get_dr or kvm_set_dr reports that it raised a fault, we must not
advance the instruction pointer. Otherwise the exception will hit the
wrong instruction.
Signed-off-by: Jan Kiszka
---
arch/x86/kvm/vmx.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x8
Fix off-by-one error (noticed by Andrea Arcangeli).
Signed-off-by: Marcelo Tosatti
diff --git a/exec.c b/exec.c
index f4b9ef2..1be5252 100644
--- a/exec.c
+++ b/exec.c
@@ -1000,7 +1000,7 @@ static void *file_ram_alloc(RAMBlock *block,
}
/* MAP_POPULATE silently ignores failu
On 11.11.2013, at 15:02, Aneesh Kumar K.V
wrote:
> From: "Aneesh Kumar K.V"
>
> Don't try to compute these values.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
>
> NOTE: I am not sure why we were originally computing dsisr and dar. So may be
> we need a variant of this patch. But with this an
On 29.11.2013, at 03:01, “tiejun.chen” wrote:
> Alex,
>
> I suppose Scott already elaborate anything you want to know.
Thanks, applied with this minor patch on top:
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
b/arch/powerpc/kvm/bookehv_interrupts.S
index 191c32b..be3de1d 100644
--- a/
On Wed, Dec 18, 2013 at 10:44:08PM +0100, Alexander Graf wrote:
>
> On 11.11.2013, at 15:02, Aneesh Kumar K.V
> wrote:
>
> > From: "Aneesh Kumar K.V"
> >
> > Don't try to compute these values.
> >
> > Signed-off-by: Aneesh Kumar K.V
> > ---
> >
> > NOTE: I am not sure why we were originall
On Tue, Dec 03, 2013 at 12:34:54PM +, Kim Phillips wrote:
> Platform drivers such as the vfio-platform "meta-" driver [1]
> should be allowed to specify that they can bind to any device,
> much like PCI drivers can with PCI_ANY_ID.
>
> Currently, binding platform drivers to devices depends on:
On Tue, Dec 03, 2013 at 12:34:46PM +, Kim Phillips wrote:
> VFIO supports pass-through of devices to user space - for sake
> of illustration, say a PCI e1000 device:
>
> - the e1000 is first unbound from the PCI e1000 driver via sysfs
> - the vfio-pci driver is told via new_id that it now hand
On Tue, Dec 03, 2013 at 04:34:33PM +0100, Jan Kiszka wrote:
> On 2013-12-03 13:34, Kim Phillips wrote:
> > VFIO supports pass-through of devices to user space - for sake
> > of illustration, say a PCI e1000 device:
> >
> > - the e1000 is first unbound from the PCI e1000 driver via sysfs
> > - the
On Wed, Dec 18, 2013 at 12:43 PM, Michael S. Tsirkin wrote:
> On Tue, Dec 17, 2013 at 12:04:42PM +0200, Razya Ladelsky wrote:
>> Hi,
>>
>> Thank you all for your comments.
>> I'm sorry for taking this long to reply, I was away on vacation..
>>
>> It was a good, long discussion, many issues were ra
Alexander Graf writes:
> On 11.11.2013, at 15:02, Aneesh Kumar K.V
> wrote:
>
>> From: "Aneesh Kumar K.V"
>>
>> Don't try to compute these values.
>>
>> Signed-off-by: Aneesh Kumar K.V
>> ---
>>
>> NOTE: I am not sure why we were originally computing dsisr and dar. So may be
>> we need a v
36 matches
Mail list logo
