-Original Message-
From: David Woodhouse [mailto:dw...@infradead.org]
Sent: Wednesday, January 28, 2015 11:23 PM
To: Wu, Feng
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
g...@kernel.org; pbonz...@redhat.com; j...@8bytes.org;
Hey guys,
That might be a dumb question, but currently I find myself unable to
clearly explain that to others. As we all know how CPU and memory is
virtualised, and how memory address space is translated using the
shadow page table or EPT, that creates each VM an individual running
space.
On Thu, 01/29 16:51, Kun Cheng wrote:
Hey guys,
Hi!
That might be a dumb question, but currently I find myself unable to
clearly explain that to others. As we all know how CPU and memory is
virtualised, and how memory address space is translated using the
shadow page table or EPT, that
Hi, Fam
Thanks for your reply. So a VM process cannot use IPC because it's not
provided with certain abilities as the concerned resources or
functions are hide (not virtualised or not provided) from it. But in
another case, we do know VMs can interact with the host via hypercalls
. This, however,
-Original Message-
From: David Woodhouse [mailto:dw...@infradead.org]
Sent: Wednesday, January 28, 2015 11:38 PM
To: Wu, Feng
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
g...@kernel.org; pbonz...@redhat.com; j...@8bytes.org;
On 29.01.15 at 04:54, wangyij...@huawei.com wrote:
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev
*dev, unsigned nr_entries)
{
resource_size_t phys_addr;
u32 table_offset;
+ unsigned long flags;
Hi Antonios,
On Thu, 27 Nov 2014 18:22:53 Antonios Motakis wrote:
VFIO_IOMMU_TYPE1 keeps track for each domain it knows a list of protection
flags it always applies to all mappings in the domain. This is used for
domains that support IOMMU_CAP_CACHE_COHERENCY.
Refactor this slightly, by keeping
On Tue, Jan 27, 2015 at 01:44:05PM +, Marc Zyngier wrote:
On 27/01/15 13:17, Christoffer Dall wrote:
On Tue, Jan 27, 2015 at 11:21:38AM +, Marc Zyngier wrote:
On 26/01/15 22:58, Christoffer Dall wrote:
On Wed, Jan 21, 2015 at 06:39:46PM +, Marc Zyngier wrote:
Trying to emulate
On 29/01/15 17:40, Christoffer Dall wrote:
On Thu, Jan 29, 2015 at 5:01 PM, Marc Zyngier marc.zyng...@arm.com
mailto:marc.zyng...@arm.com wrote:
Hi Arnd,
On 29/01/15 15:53, Arnd Bergmann wrote:
On Thursday 29 January 2015 16:23:42 Christoffer Dall wrote:
the changes
Hi Alex,
starting to play with Intel IGD pass-through in KVM, I managed to
trigger this with linux git head:
[ 232.317043] BUG: unable to handle kernel NULL pointer dereference at
0037
[ 232.325249] IP: [8142ed36] dmar_insert_dev_info+0x86/0x220
[ 232.331905] PGD 0
[
https://bugzilla.kernel.org/show_bug.cgi?id=92291
--- Comment #1 from Mark kernelbugzilla.org.mark...@dfgh.net ---
Created attachment 165181
-- https://bugzilla.kernel.org/attachment.cgi?id=165181action=edit
serial log during bug; when smp 1
--
You are receiving this mail because:
You are
On Wed, Jan 21, 2015 at 06:39:47PM +, Marc Zyngier wrote:
Let's assume a guest has created an uncached mapping, and written
to that page. Let's also assume that the host uses a cache-coherent
IO subsystem. Let's finally assume that the host is under memory
pressure and starts to swap
On Thu, Jan 29, 2015 at 7:15 AM, Jan Beulich jbeul...@suse.com wrote:
On 29.01.15 at 04:54, wangyij...@huawei.com wrote:
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev
*dev, unsigned nr_entries)
{
On Wed, Jan 21, 2015 at 06:39:48PM +, Marc Zyngier wrote:
When handling a fault in stage-2, we need to resync I$ and D$, just
to be sure we don't leave any old cache line behind.
That's very good, except that we do so using the *user* address.
Under heavy load (swapping like crazy), we
https://bugzilla.kernel.org/show_bug.cgi?id=92291
Bug ID: 92291
Summary: kvm/guest crashes when smp 1 with AMD FX8300; with
host kernel oops from abrt as well
Product: Virtualization
Version: unspecified
Kernel Version:
https://bugzilla.kernel.org/show_bug.cgi?id=92291
--- Comment #3 from Mark kernelbugzilla.org.mark...@dfgh.net ---
Created attachment 165201
-- https://bugzilla.kernel.org/attachment.cgi?id=165201action=edit
host cpuinfo
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=92291
--- Comment #2 from Mark kernelbugzilla.org.mark...@dfgh.net ---
Created attachment 165191
-- https://bugzilla.kernel.org/attachment.cgi?id=165191action=edit
serial log when no smp
--
You are receiving this mail because:
You are watching the
Hi Arnd,
On 29/01/15 15:53, Arnd Bergmann wrote:
On Thursday 29 January 2015 16:23:42 Christoffer Dall wrote:
On Wed, Jan 28, 2015 at 8:57 PM, Arnd Bergmann a...@arndb.de wrote:
8
Subject: [PATCH] ARM: KVM: avoid HYP init code too big error
When building large kernels, the linker will
On Thursday 29 January 2015 16:23:42 Christoffer Dall wrote:
On Wed, Jan 28, 2015 at 8:57 PM, Arnd Bergmann a...@arndb.de wrote:
8
Subject: [PATCH] ARM: KVM: avoid HYP init code too big error
When building large kernels, the linker will emit lots of veneers
into the .hyp.idmap.text
On Tue, Jan 27, 2015 at 05:44:26PM +, Andre Przywara wrote:
Hi,
On 27/01/15 17:26, Eric Auger wrote:
On 01/27/2015 05:51 PM, Nikolay Nikolaev wrote:
Hi Andre,
On Tue, Jan 27, 2015 at 3:31 PM, Andre Przywara andre.przyw...@arm.com
wrote:
Hi Nikolay,
On 24/01/15 11:59,
On Thu, 2015-01-29 at 12:24 +, GAUGUEY Rémy 228890 wrote:
Hi Antonios,
On Thu, 27 Nov 2014 18:22:53 Antonios Motakis wrote:
VFIO_IOMMU_TYPE1 keeps track for each domain it knows a list of protection
flags it always applies to all mappings in the domain. This is used for
domains that
On Thu, 2015-01-29 at 19:21 +0100, Jan Kiszka wrote:
Hi Alex,
starting to play with Intel IGD pass-through in KVM, I managed to
trigger this with linux git head:
[ 232.317043] BUG: unable to handle kernel NULL pointer dereference at
0037
[ 232.325249] IP:
In mixed modes, we musn't deliver xAPIC IPIs like x2APIC and vice versa.
Instead of preserving the information in apic_send_ipi(), we regain it
by converting all destinations into correct APIC MDA in the slow path.
This allows easier reasoning about subsequent matching.
kvm_apic_broadcast() had
To make the code self-documenting.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/lapic.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 271e7d076879..0ee743c6b4f1 100644
--- a/arch/x86/kvm/lapic.c
+++
recalculate_apic_map() uses two passes over all VCPUs. This is a relic
from time when we selected a global mode in the first pass and set up
the optimized table in the second pass (to have a consistent mode).
Recent changes made mixed mode unoptimized and we can do it in one pass.
Format of
We want to support mixed modes and the easiest solution is to avoid
optimizing those weird and unlikely scenarios.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/lapic.c| 16
arch/x86/kvm/lapic.h|
Broadcast allowed only one global APIC mode, but mixed modes are
theoretically possible. x2APIC IPI doesn't mean 0xff as broadcast,
the rest does.
(We also save one rcu dereference with broadcasts.)
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/include/asm/kvm_host.h | 2 +-
The majority of this patch turns
result = 0; if (CODE) result = 1; return result;
into
return CODE;
because we return bool now.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/lapic.c | 44 +++-
1 file changed, 15 insertions(+), 29
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez
On Thu, 2015-01-29 at 22:48 +0100, Radim Krčmář wrote:
And don't export the internal ones while at it.
[]
-int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u32 mda)
+static bool kvm_apic_match_logical_addr(struct kvm_lapic *apic, u32 mda)
{
int result = 0;
u32 logical_id;
[Added Michal. Removed Yann.]
On Thu, 2015-01-29 at 12:38 -0800, Luis R. Rodriguez wrote:
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
On Wed,
We forgot to re-check LAPIC after splitting the loop in
173beedc1601 KVM: x86: Software disabled APIC should still deliver NMIs
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/lapic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kvm/lapic.c
On Tue, Jan 27, 2015 at 10:06:44AM +, David Vrabel wrote:
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this
This patch series is made our of three logical parts,
[1-3/8] are just a cleanup and could be omitted
[4-6/8] improve broadcast detection and unoptimized delivery
[7-8/8] handle mixed mode (by falling back to improvements from [5-6/9])
Radim Krčmář (8):
KVM: x86: return bool from
And don't export the internal ones while at it.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/ioapic.h | 2 +-
arch/x86/kvm/lapic.c | 8
arch/x86/kvm/lapic.h | 2 --
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/ioapic.h
We cannot hit the bug now, but future patches will expose this path.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/lapic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0ee743c6b4f1..aae043f38548 100644
From: Marc Zyngier marc.zyng...@arm.com
Trying to emulate the behaviour of set/way cache ops is fairly
pointless, as there are too many ways we can end-up missing stuff.
Also, there is some system caches out there that simply ignore
set/way operations.
So instead of trying to implement them,
From: Marc Zyngier marc.zyng...@arm.com
Let's assume a guest has created an uncached mapping, and written
to that page. Let's also assume that the host uses a cache-coherent
IO subsystem. Let's finally assume that the host is under memory
pressure and starts to swap things out.
Before this
From: Marc Zyngier marc.zyng...@arm.com
When handling a fault in stage-2, we need to resync I$ and D$, just
to be sure we don't leave any old cache line behind.
That's very good, except that we do so using the *user* address.
Under heavy load (swapping like crazy), we may end up in a situation
Hi Jidong,
Thanks for the reply. I think I've gathered adequate explanation now.
Many thanks to you guys!
Best regards,
Kun Cheng
2015-01-30 9:53 GMT+08:00 Jidong Xiao jidong.x...@gmail.com:
On Thu, Jan 29, 2015 at 3:00 AM, Kun Cheng chengku...@gmail.com wrote:
Hi, Fam
Thanks for your
Hi Paolo,
Please pull this second round of fixes for KVM/ARM for 3.19. Hopefully there
is time to get this upstream before the final release of 3.19.
The series fixes the notorious memory corruption issues on APM platforms and
swapping issues on DMA-coherent systems.
The following changes
On 2015/1/29 22:12, Bjorn Helgaas wrote:
On Thu, Jan 29, 2015 at 7:15 AM, Jan Beulich jbeul...@suse.com wrote:
On 29.01.15 at 04:54, wangyij...@huawei.com wrote:
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev
*dev,
On Thu, Jan 29, 2015 at 3:00 AM, Kun Cheng chengku...@gmail.com wrote:
Hi, Fam
Thanks for your reply. So a VM process cannot use IPC because it's not
provided with certain abilities as the concerned resources or
functions are hide (not virtualised or not provided) from it. But in
another
Fix trace_kvm_pml_full build error on i386, introduced by below commit:
commit 19cf3eb32410 (KVM: VMX: Add PML support in VMX)
In above commit trace_kvm_pml_full was only defined in CONFIG_X86_64, which
breaks build on i386. Fix it by moving trace_kvm_pml_full definition out of
On Tue, Jan 27, 2015 at 7:44 PM, Andre Przywara andre.przyw...@arm.com wrote:
Hi,
On 27/01/15 17:26, Eric Auger wrote:
On 01/27/2015 05:51 PM, Nikolay Nikolaev wrote:
Hi Andre,
On Tue, Jan 27, 2015 at 3:31 PM, Andre Przywara andre.przyw...@arm.com
wrote:
Hi Nikolay,
On 24/01/15 11:59,
45 matches
Mail list logo
