[ CCed Zhang Yang ]
On 06/04/2015 04:36 PM, Paolo Bonzini wrote:
On 04/06/2015 10:23, Xiao Guangrong wrote:
So, why do you need to always use IPAT=0? Can patch 15 keep the current
logic for RAM, like this:
if (is_mmio || kvm_arch_has_noncoherent_dma(vcpu-kvm))
ret =
From: Marc Zyngier marc.zyng...@arm.com
In order to reduce the memory usage of large guests (as well
as improve performance), tell KVM about the number of interrupts
we require.
To avoid synchronization with the various device creation,
use a late_init callback to compute the GIC configuration.
Since Linux 3.19-rc1 there is a new API to explicitly initialise
the in-kernel GIC emulation by a userland KVM device call.
Use that to tell the kernel we are finished with the GIC
initialisation, since the automatic GIC init will only be provided
as a legacy functionality in the future.
From: Marc Zyngier marc.zyng...@arm.com
The ARM GIC emulation needs to be told the number of interrupts
it has to support. As commit 1c262fa1dc7bc (kvm tools: irq: make
irq__alloc_line generic) made the interrupt counter private,
add a new accessor returning the number of interrupt lines we've
From: Marc Zyngier marc.zyng...@arm.com
As of 3.14, KVM/arm supports the creation/configuration of the GIC through
a more generic device API, which is now the preferred way to do so.
Plumb the new API in, and allow the old code to be used as a fallback.
[Andre: Rename some functions on the way
The code currently is assuming fixed sized memory regions for the
distributor and CPU interface. GICv3 needs a dynamic allocation of
its redistributor region, since its size depends on the number of
vCPUs.
Also add the necessary code to create a GICv3 IRQ chip instance.
This contains some defines
Hi,
a rework of the GICv3 support series for kvmtool.
I addressed Will's comments on the broken fallback in VGIC creation,
also changed the command line parameter to --irqchip=[gicv2,gicv3].
The default is still GICv2 emulation for the sake of reproducibility,
not sure we want to have an
Currently we unconditionally create a virtual GICv2 in the guest.
Add a --irqchip= parameter to let the user specify a different GIC
type for the guest.
For now we the only other supported type is GICv3.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
arm/aarch64/arm-cpu.c
Extend the vGIC handling code to potentially deal with different IRQ
chip devices instead of hard-coding the GICv2 in.
We extend most vGIC functions to take a type parameter, but still put
GICv2 in at the top for the time being.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
From: Marc Zyngier marc.zyng...@arm.com
On AArch64 system with a GICv2, the GICC range can be aligned
to the last 4k block of a 64k page, ending up straddling two
64k pages. In order not to conflict with the distributor mapping,
allocate two 64k pages to the CPU interface.
Signed-off-by: Marc
From the perspective of avoiding impacting other architectures, this is a
good idea, but the naming seems strange in the x86 case. Having
irqchip_in_kernel be true when the ioapic/pic are in userspace seems
strange. Admittedly, the irqchip isn't a real concept on x86, so
inventing a new
On 05/27/2015 08:05 PM, Paolo Bonzini wrote:
This brings together the remaining parts of SMM. For now I've left the
weird interaction between SMM and NMI blocking, and I'm using the same
format for the state save area (which is also the one used by QEMU) as
the RFC.
It builds on the previous
On 05/06/2015 12:50, Joerg Roedel wrote:
Great, I'll apply the patch.
Gentle ping. I don't see the patch in the queue or next branches of the
KVM tree yet. Do you plan to apply it for v4.2?
Fell through the cracks, sorry. I will apply it today.
Paolo
--
To unsubscribe from this list:
On 29/05/2015 21:23, Radim Krčmář wrote:
+int kvm_vcpu_write_guest(struct kvm_vcpu *vcpu, gpa_t gpa, const void
*data,
+ unsigned long len)
+{
+ gfn_t gfn = gpa PAGE_SHIFT;
+ int seg;
+ int offset = offset_in_page(gpa);
+ int ret;
+
+ while ((seg =
Hi Paolo,
On Mon, May 11, 2015 at 03:27:26PM +0200, Paolo Bonzini wrote:
Great, I'll apply the patch.
Gentle ping. I don't see the patch in the queue or next branches of the
KVM tree yet. Do you plan to apply it for v4.2?
Joerg
--
To unsubscribe from this list: send the line
2015-06-05 12:26+0200, Paolo Bonzini:
On 29/05/2015 21:23, Radim Krčmář wrote:
+int kvm_vcpu_write_guest(struct kvm_vcpu *vcpu, gpa_t gpa, const void
*data,
+ unsigned long len)
+{
| [...]
+}
(There is no need to pass vcpu, and kvm, in this API.
How so? A single
On 06/02/2015 02:27 AM, Christoffer Dall wrote:
On Mon, Jun 01, 2015 at 08:48:22AM -0700, Mario Smarduch wrote:
On 05/30/2015 11:59 PM, Christoffer Dall wrote:
Hi Mario,
On Fri, May 29, 2015 at 03:34:47PM -0700, Mario Smarduch wrote:
On 05/28/2015 11:49 AM, Christoffer Dall wrote:
Until now
On 05/06/2015 14:10, Radim Krčmář wrote:
+ ret = __kvm_write_guest_page(__gfn_to_memslot(slots, gfn), gfn,
+ data, offset, seg);
Even better, let's pass memslots to all the __ functions.
Paolo
--
To unsubscribe from this list: send the line unsubscribe
On 05/06/2015 14:10, Radim Krčmář wrote:
2015-06-05 12:26+0200, Paolo Bonzini:
On 29/05/2015 21:23, Radim Krčmář wrote:
+int kvm_vcpu_write_guest(struct kvm_vcpu *vcpu, gpa_t gpa, const void
*data,
+ unsigned long len)
+{
| [...]
+}
(There is no need to pass vcpu, and
On 05/06/2015 20:57, Radim Krčmář wrote:
lapic.timer_mode was not properly initialized after migration, which
broke few useful things, like login, by making every sleep eternal.
Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore.
There are other slowpaths that update
lapic.timer_mode was not properly initialized after migration, which
broke few useful things, like login, by making every sleep eternal.
Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore.
There are other slowpaths that update lvtt, so this patch makes sure
something similar
On Thu, Jun 04, 2015 at 04:20:45PM +0100, Andre Przywara wrote:
In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
firmware to the OS. _Hardware_ should never use this information,
as the OS is free to write any
On Tue, May 26, 2015 at 9:47 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, May 22, 2015 at 10:53:54AM +0800, Yong Wang wrote:
On Thu, May 21, 2015 at 03:51:43PM +0200, Paolo Bonzini wrote:
On the QEMU side, there is no support yet for persistent memory and the
NFIT tables from ACPI
2015-06-05 14:46+0200, Paolo Bonzini:
On 05/06/2015 14:10, Radim Krčmář wrote:
+ ret = __kvm_write_guest_page(__gfn_to_memslot(slots, gfn), gfn,
+ data, offset, seg);
Even better, let's pass memslots to all the __ functions.
Yeah, while scoping it, I
From: Kim Phillips kim.phill...@linaro.org
The KVM-VFIO device is used by the QEMU VFIO device. It is used to
record the list of in-use VFIO groups so that KVM can manipulate
them.
Signed-off-by: Kim Phillips kim.phill...@linaro.org
Signed-off-by: Eric Auger eric.au...@linaro.org
---
-
On 05/06/2015 17:13, Radim Krčmář wrote:
2015-06-05 14:46+0200, Paolo Bonzini:
On 05/06/2015 14:10, Radim Krčmář wrote:
+ ret = __kvm_write_guest_page(__gfn_to_memslot(slots, gfn), gfn,
+ data, offset, seg);
Even better, let's pass memslots to all the __
On Tue, Apr 14, 2015 at 07:37:44AM +, Wu, Feng wrote:
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Tuesday, March 31, 2015 7:56 AM
To: Wu, Feng
Cc: h...@zytor.com; t...@linutronix.de; mi...@redhat.com; x...@kernel.org;
g...@kernel.org;
tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
head: 6aa5e7eb06cff8d317328a0c4696b5f635ba6be3
commit: 6aa5e7eb06cff8d317328a0c4696b5f635ba6be3 [76/76] kvm: irqchip: Break up
high order allocations of kvm_irq_routing_table
reproduce:
# apt-get install sparse
git checkout
28 matches
Mail list logo
