KVM memory slots limit on powerpc

Hi all, now that we get memory hotplugging for the spapr machine on qemu-ppc, too, it seems like we easily can hit the amount of KVM-internal memory slots now ("#define KVM_USER_MEM_SLOTS 32" in arch/powerpc/include/asm/kvm_host.h). For example, start qemu-system-ppc64 with a couple of "-device

Re: KVM memory slots limit on powerpc

Am 04.09.2015 um 11:35 schrieb Thomas Huth: > > Hi all, > > now that we get memory hotplugging for the spapr machine on qemu-ppc, > too, it seems like we easily can hit the amount of KVM-internal memory > slots now ("#define KVM_USER_MEM_SLOTS 32" in > arch/powerpc/include/asm/kvm_host.h). For

Re: [PATCH] kvmtool Makefile: relax arm test

On 4 September 2015 at 13:10, Andre Przywara wrote: > Hi Riku, > > On 03/09/15 12:20, riku.voi...@linaro.org wrote: >> From: Riku Voipio >> >> Currently Makefile accepts only armv7l.* When building kvmtool under 32bit >> personality on Aarch64

Re: [PATCH] kvmtool Makefile: relax arm test

Hi Riku, On 04/09/15 11:52, Riku Voipio wrote: > On 4 September 2015 at 13:10, Andre Przywara wrote: >> Hi Riku, >> >> On 03/09/15 12:20, riku.voi...@linaro.org wrote: >>> From: Riku Voipio >>> >>> Currently Makefile accepts only armv7l.* When

Re: [Qemu-devel] [PATCH v2 07/18] nvdimm: reserve address range for NVDIMM

On Fri, 14 Aug 2015 22:52:00 +0800 Xiao Guangrong wrote: > NVDIMM reserves all the free range above 4G to do: > - Persistent Memory (PMEM) mapping > - implement NVDIMM ACPI device _DSM method > > Signed-off-by: Xiao Guangrong >

[PATCH kvmtool] Make static libc and guest-init functionality optional.

If one typically only boots full disk-images, one wouldn't necessaraly want to statically link glibc, for the guest-init feature of the kvmtool. As statically linked glibc triggers haevy security maintainance. Signed-off-by: Dimitri John Ledkov --- Makefile|

[PATCH v3 3/5] KVM: arm64: Refactor system register handlers

Replace Rt with data pointer in struct sys_reg_params. This will allow to reuse system register handling code in implementation of vGICv3 CPU interface access API. Additionally, got rid of "massive hack" in kvm_handle_cp_64(). Signed-off-by: Pavel Fedin ---

[PATCH v3 5/5] KVM: arm64: Implement vGICv3 CPU interface access

The access is done similar to GICv2, using KVM_DEV_ARM_VGIC_GRP_CPU_REGS group, however attribute ID encodes corresponding system register. Access size is always 64 bits. Since CPU interface state actually affects only a single vCPU, no vGIC locking is done. Just made sure that the vCPU is not

[PATCH v3 4/5] KVM: arm64: Introduce find_reg_by_id()

In order to implement vGICv3 CPU interface access, we will need to perform table lookup of system registers. We would need both index_to_params() and find_reg() exported for that purpose, but instead we export a single function which combines them both. Signed-off-by: Pavel Fedin

[PATCH v3 1/5] KVM: arm/arm64: Refactor vGIC attributes handling code

Separate all implementation-independent code in vgic_attr_regs_access() and move it to vgic.c. This will allow to reuse this code for vGICv3 implementation. Signed-off-by: Pavel Fedin --- virt/kvm/arm/vgic-v2-emul.c | 126 +---

[PATCH v3 0/5] KVM: arm64: Implement API for vGICv3 live migration

This patchset adds necessary userspace API in order to support vGICv3 live migration. GICv3 registers are accessed using device attribute ioctls, similar to GICv2. V2 => V3: - KVM_DEV_ARM_VGIC_CPUID_MASK enlarged to 20 bits, allowing more than 256 CPUs. - Bug fix: Correctly set mmio->private,

[PATCH v3 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

The access is done similar to vGICv2, using KVM_DEV_ARM_VGIC_GRP_DIST_REGS and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS with KVM_SET_DEVICE_ATTR and KVM_GET_DEVICE_ATTR ioctls. Since GICv3 can handle large number of CPUs, KVM_DEV_ARM_VGIC_CPUID_MASK has been extended to 20 bits. This is enough for 1048576

Re: [PATCH] kvmtool Makefile: relax arm test

Hi Riku, On 03/09/15 12:20, riku.voi...@linaro.org wrote: > From: Riku Voipio > > Currently Makefile accepts only armv7l.* When building kvmtool under 32bit > personality on Aarch64 machines, uname -m reports "armv8l", so build fails. > We expect doing 32bit arm builds

Re: [Qemu-ppc] KVM memory slots limit on powerpc

Am 04.09.2015 um 12:04 schrieb Alexander Graf: > > > On 04.09.15 11:59, Christian Borntraeger wrote: >> Am 04.09.2015 um 11:35 schrieb Thomas Huth: >>> >>> Hi all, >>> >>> now that we get memory hotplugging for the spapr machine on qemu-ppc, >>> too, it seems like we easily can hit the amount

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On 04.09.15 11:59, Christian Borntraeger wrote: > Am 04.09.2015 um 11:35 schrieb Thomas Huth: >> >> Hi all, >> >> now that we get memory hotplugging for the spapr machine on qemu-ppc, >> too, it seems like we easily can hit the amount of KVM-internal memory >> slots now ("#define

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On 04/09/15 12:07, Christian Borntraeger wrote: > Am 04.09.2015 um 12:04 schrieb Alexander Graf: >> >> >> On 04.09.15 11:59, Christian Borntraeger wrote: >>> Am 04.09.2015 um 11:35 schrieb Thomas Huth: Hi all, now that we get memory hotplugging for the spapr machine on

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On Fri, 2015-09-04 at 12:28 +0200, Thomas Huth wrote: > > Maybe some rcu protected scheme that doubles the amount of memslots > > for > > each overrun? Yes, that would be good and even reduce the footprint > > for > > systems with only a small number of memslots. > > Seems like Alex Williamson

Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] arm/arm64 config: Fix arch_clean rule

On Wed, Sep 02, 2015 at 11:25:26AM +0200, Alexander Spyridakis wrote: > Properly clean any generated object and binary files after a 'make clean', > this fixes an issue when trying to reconfigure between arm and arm64. Are you also running configure (with the opposite arch selected) after 'make

Re: [PATCH 1/9] KVM: Add kvm_arch_vcpu_{un}blocking callbacks

On Fri, Sep 04, 2015 at 03:50:08PM +0200, Eric Auger wrote: > Hi Christoffer, > On 08/30/2015 03:54 PM, Christoffer Dall wrote: > > Some times it is useful for architecture implementations of KVM to know > > when the VCPU thread is about to block or when it comes back from > > blocking (arm/arm64

Re: [PATCH v2 1/5] KVM: arm/arm64: Refactor vGIC attributes handling code

Hi Pavel, On 02/09/15 09:09, Pavel Fedin wrote: > Separate all implementation-independent code in vgic_attr_regs_access() > and move it to vgic.c. This will allow to reuse this code for vGICv3 > implementation. > > Signed-off-by: Pavel Fedin > --- >

Re: [PATCH 1/9] KVM: Add kvm_arch_vcpu_{un}blocking callbacks

Hi Christoffer, On 08/30/2015 03:54 PM, Christoffer Dall wrote: > Some times it is useful for architecture implementations of KVM to know > when the VCPU thread is about to block or when it comes back from > blocking (arm/arm64 needs to know this to properly implement timers, for > example). what

[PATCH 1/2] arm/arm64: KVM: vgic: Move active state handling to flush_hwstate

We currently set the physical active state only when we *inject* a new pending virtual interrupt, but this is actually not correct, because we could have been preempted and run something else on the system that resets the active state to clear. This causes us to run the VM with the timer set to

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On Fri, 2015-09-04 at 12:28 +0200, Thomas Huth wrote: > On 04/09/15 12:07, Christian Borntraeger wrote: > > Am 04.09.2015 um 12:04 schrieb Alexander Graf: > >> > >> > >> On 04.09.15 11:59, Christian Borntraeger wrote: > >>> Am 04.09.2015 um 11:35 schrieb Thomas Huth: > > Hi all, >

[PATCH 2/2] arm/arm64: KVM: arch timer: Reset CNTV_CTL to 0

Provide a better quality of implementation and be architecture compliant on ARMv7 for the architected timer by resetting the CNTV_CTL to 0 on reset of the timer, and call kvm_timer_update_state(vcpu) at the same time, ensuring the timer output is not asserted after, for example, a PSCI system

[PATCH 0/2] arm/arm64: KVM: Fix arthictected timer issues

These two patches fix two separate issues with the architected timer and the corresponding interrupt injection to VMs on KVM/ARM. The first patch fixes an issue introduced with the active timer state switching series recently merged for v4.3, which could cause a guest to loop without progress if

Re: [PATCH 2/2] arm/arm64: KVM: arch timer: Reset CNTV_CTL to 0

On Fri, Sep 04, 2015 at 04:24:39PM +0200, Christoffer Dall wrote: > Provide a better quality of implementation and be architecture compliant > on ARMv7 for the architected timer by resetting the CNTV_CTL to 0 on > reset of the timer, and call kvm_timer_update_state(vcpu) at the same > time,

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On 04/09/15 12:04, Alexander Graf wrote: > > > On 04.09.15 11:59, Christian Borntraeger wrote: >> Am 04.09.2015 um 11:35 schrieb Thomas Huth: >>> >>> Hi all, >>> >>> now that we get memory hotplugging for the spapr machine on qemu-ppc, >>> too, it seems like we easily can hit the amount of

Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] arm/arm64 config: Fix arch_clean rule

On Fri, Sep 04, 2015 at 03:48:35PM +0200, Alexander Spyridakis wrote: > On 4 September 2015 at 12:48, Andrew Jones wrote: > > Are you also running configure (with the opposite arch selected) after > > 'make clean'? If not, then that could be the source of your problems. > >

Re: [PATCH 2/2] arm/arm64: KVM: arch timer: Reset CNTV_CTL to 0

On 04/09/15 15:47, Christoffer Dall wrote: > On Fri, Sep 04, 2015 at 04:24:39PM +0200, Christoffer Dall wrote: >> Provide a better quality of implementation and be architecture compliant >> on ARMv7 for the architected timer by resetting the CNTV_CTL to 0 on >> reset of the timer, and call

Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] arm/arm64 config: Fix arch_clean rule

On 4 September 2015 at 12:48, Andrew Jones wrote: > The lines this > patch adds are already there. See the arm_clean target in > config/config-arm-common.mak. I see your point now. Maybe then "arm_clean" should be changed in "arch_clean" in config-arm-common.mak? Regards. --

Re: [PATCH v3 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

Hi Pavel, On 04/09/15 13:40, Pavel Fedin wrote: > The access is done similar to vGICv2, using KVM_DEV_ARM_VGIC_GRP_DIST_REGS > and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS with KVM_SET_DEVICE_ATTR and > KVM_GET_DEVICE_ATTR ioctls. Since GICv3 can handle large number of CPUs, > KVM_DEV_ARM_VGIC_CPUID_MASK

Re: [PATCH 12/14] arm64: Check for selected granule support

On Wed, Sep 02, 2015 at 12:19:07PM +0200, Ard Biesheuvel wrote: > On 2 September 2015 at 11:48, Ard Biesheuvel > wrote: > > Couldn't we allocate some flag bits in the Image header to communicate > > the page size to the bootloader? > > Something like this perhaps? >

Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] arm/arm64 config: Fix arch_clean rule

On 4 September 2015 at 16:05, Andrew Jones wrote: > This doesn't reproduce for me. I did the following, and it worked > fine. > > make distclean > ./configure --arch=arm --cross-prefix=arm-linux-gnu- > make > ./configure --arch=arm64 --cross-prefix=aarch64-linux-gnu- > make

Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] arm/arm64 config: Fix arch_clean rule

On 4 September 2015 at 12:48, Andrew Jones wrote: > Are you also running configure (with the opposite arch selected) after > 'make clean'? If not, then that could be the source of your problems. > Anyway, please describe the issues you're seeing because I don't see > what this

Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] arm/arm64 config: Fix arch_clean rule

On 4 September 2015 at 15:05, Andrew Jones wrote: > But anyway I would suggest you do your 'make clean' or even a > 'make distclean' *before* running configure the second time. > Otherwise you'll leave old object files around from the previously > configured arch. I.e. you

Re: [Qemu-devel] [kvm-unit-tests PATCH 2/2] arm/arm64 config: Fix arch_clean rule

On Fri, Sep 04, 2015 at 03:53:46PM +0200, Alexander Spyridakis wrote: > On 4 September 2015 at 12:48, Andrew Jones wrote: > > The lines this > > patch adds are already there. See the arm_clean target in > > config/config-arm-common.mak. > > I see your point now. Maybe then

Re: [PATCH v3 3/5] KVM: arm64: Refactor system register handlers

Hi Pavel, On 04/09/15 13:40, Pavel Fedin wrote: > Replace Rt with data pointer in struct sys_reg_params. This will allow to > reuse system register handling code in implementation of vGICv3 CPU > interface access API. Additionally, got rid of "massive hack" > in kvm_handle_cp_64(). > >

RE: [PATCH v2 1/5] KVM: arm/arm64: Refactor vGIC attributes handling code

Hello! > Isn't the len parameter redundant here? I see that you don't initialize > mmio.len (which is a bit scary, btw), so can't you just use that field? This was because of split below. I did not know about call_range_handler(), and now i will redo this. > That (and other parts of this

Re: [PATCH v3 4/5] KVM: arm64: Introduce find_reg_by_id()

On 04/09/15 13:40, Pavel Fedin wrote: > In order to implement vGICv3 CPU interface access, we will need to perform > table lookup of system registers. We would need both index_to_params() and > find_reg() exported for that purpose, but instead we export a single > function which combines them

RE: [PATCH v3 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

Hello! > > The access is done similar to vGICv2, using KVM_DEV_ARM_VGIC_GRP_DIST_REGS > > and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS with KVM_SET_DEVICE_ATTR and > > KVM_GET_DEVICE_ATTR ioctls. Since GICv3 can handle large number of CPUs, > > KVM_DEV_ARM_VGIC_CPUID_MASK has been extended to 20 bits.

Re: [PATCH 0/2] arm/arm64: KVM: Fix arthictected timer issues

Hi Christoffer, On 04/09/15 15:24, Christoffer Dall wrote: > These two patches fix two separate issues with the architected timer and > the corresponding interrupt injection to VMs on KVM/ARM. > > The first patch fixes an issue introduced with the active timer state > switching series recently

Re: [PATCH 0/2] arm/arm64: KVM: Fix arthictected timer issues

On Fri, Sep 04, 2015 at 04:35:20PM +0100, Marc Zyngier wrote: > Hi Christoffer, > > On 04/09/15 15:24, Christoffer Dall wrote: > > These two patches fix two separate issues with the architected timer and > > the corresponding interrupt injection to VMs on KVM/ARM. > > > > The first patch fixes

Re: [PATCH] KVM: arm/arm64: Fix PSCI affinity info return value for non valid cores

On Fri, Sep 04, 2015 at 04:06:24PM +0100, Alexander Spyridakis wrote: > If a guest requests the affinity info for a non-existing vCPU we need to > properly return an error, instead of erroneously reporting an off state. > > Signed-off-by: Alexander Spyridakis

[PATCH] KVM: arm/arm64: Fix PSCI affinity info return value for non valid cores

If a guest requests the affinity info for a non-existing vCPU we need to properly return an error, instead of erroneously reporting an off state. Signed-off-by: Alexander Spyridakis Signed-off-by: Alvise Rigo ---

Re: [PATCH v3 5/5] KVM: arm64: Implement vGICv3 CPU interface access

Hi Pavel, On 04/09/15 13:40, Pavel Fedin wrote: > The access is done similar to GICv2, using KVM_DEV_ARM_VGIC_GRP_CPU_REGS > group, however attribute ID encodes corresponding system register. Access > size is always 64 bits. Why is this? Actually all registers in the CPU interface (except the

Re: [PATCH 6/9] arm/arm64: KVM: Add mapped interrupts documentation

On Thu, Sep 03, 2015 at 05:56:26PM +0200, Eric Auger wrote: > Hi Christoffer, > On 09/03/2015 05:23 PM, Marc Zyngier wrote: > > On 30/08/15 14:54, Christoffer Dall wrote: > >> Mapped interrupts on arm/arm64 is a tricky concept and the way we deal > >> with them is not apparently easy to understand

Re: [PATCH 6/9] arm/arm64: KVM: Add mapped interrupts documentation

On Thu, Sep 03, 2015 at 04:23:04PM +0100, Marc Zyngier wrote: > On 30/08/15 14:54, Christoffer Dall wrote: > > Mapped interrupts on arm/arm64 is a tricky concept and the way we deal > > with them is not apparently easy to understand by reading various specs. > > > > Therefore, add a proper

Re: [PATCH 5/9] arm/arm64: KVM: Use appropriate define in VGIC reset code

On 08/30/2015 03:54 PM, Christoffer Dall wrote: > We currently initialize the SGIs to be enabled in the VGIC code, but we > use the VGIC_NR_PPIS define for this purpose, instead of the the more s/the// Eric > natural VGIC_NR_SGIS. Change this slightly confusing use of the > defines. > > Note:

Re: [PATCH] KVM: arm/arm64: Fix PSCI affinity info return value for non valid cores

On 4 September 2015 at 17:54, Marc Zyngier wrote: > Seems sound to me. Out of curiosity, how was this found? Hello Mark, This issue came up when testing some basic bare metal tests with KVM, which originally were meant for the multi-threading TCG effort

RE: [PATCH v3 3/5] KVM: arm64: Refactor system register handlers

Hello! > Mmmh, not sure about this, but I guess u64 would be more precise here? > With the Rt2 handling below we rely on this being 64 bits anyway. But I > guess that breaks with assigning vcpu_reg later and since this is arm64 > only, long is always 64 bits? It is because ' params.val = '.

RE: [PATCH v3 5/5] KVM: arm64: Implement vGICv3 CPU interface access

Hello! > So can you model the register size according to the spec and allow > 32-bit accesses from userland? I can. But i'll have to invent my own macro for encoding register IDs into the attribute, as well as drop reusing index_to_params(). Will it be OK? Upside: i can further extend "cpu

Re: [PATCH v2 1/5] KVM: arm/arm64: Refactor vGIC attributes handling code

Hi, On 04/09/15 16:11, Pavel Fedin wrote: > Hello! > >> Isn't the len parameter redundant here? I see that you don't initialize >> mmio.len (which is a bit scary, btw), so can't you just use that field? > > This was because of split below. I did not know about call_range_handler(), > and now

Re: [PATCH 6/9] arm/arm64: KVM: Add mapped interrupts documentation

On 04/09/15 16:57, Christoffer Dall wrote: > On Thu, Sep 03, 2015 at 04:23:04PM +0100, Marc Zyngier wrote: >> On 30/08/15 14:54, Christoffer Dall wrote: >>> + >>> + >>> +Life Cycle for Forwarded Physical Interrupts >>> + >>> + >>> +By forwarded physical

Re: [PATCH 6/9] arm/arm64: KVM: Add mapped interrupts documentation

On Thu, Sep 03, 2015 at 04:23:04PM +0100, Marc Zyngier wrote: > On 30/08/15 14:54, Christoffer Dall wrote: > > Mapped interrupts on arm/arm64 is a tricky concept and the way we deal > > with them is not apparently easy to understand by reading various specs. > > > > Therefore, add a proper

[PATCH v2 5/8] arm/arm64: KVM: Use appropriate define in VGIC reset code

We currently initialize the SGIs to be enabled in the VGIC code, but we use the VGIC_NR_PPIS define for this purpose, instead of the the more natural VGIC_NR_SGIS. Change this slightly confusing use of the defines. Note: This should have no functional change, as both names are defined to the

[PATCH v2 3/8] arm/arm64: KVM: vgic: Factor out level irq processing on guest exit

Currently vgic_process_maintenance() processes dealing with a completed level-triggered interrupt directly, but we are soon going to reuse this logic for level-triggered mapped interrupts with the HW bit set, so move this logic into a separate static function. Probably the most scary part of this

[PATCH v2 8/8] arm/arm64: KVM: Support edge-triggered forwarded interrupts

We mark edge-triggered interrupts with the HW bit set as queued to prevent the VGIC code from injecting LRs with both the Active and Pending bits set at the same time while also setting the HW bit, because the hardware does not support this. However, this means that we must also clear the queued

[PATCH v2 2/8] arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block

We currently schedule a soft timer every time we exit the guest if the timer did not expire while running the guest. This is really not necessary, because the only work we do in the timer work function is to kick the vcpu. Kicking the vcpu does two things: (1) If the vpcu thread is on a

[PATCH v2 0/8] Rework architected timer and forwarded IRQs handling

The architected timer integration with the VGIC had some shortcomings in that certain guest operations weren't fully supported. This series tries to address these problems in providing level-triggered semantics for the arch timer and VGIC integration and seeks to clarify the behavior when

[PATCH v2 1/8] KVM: Add kvm_arch_vcpu_{un}blocking callbacks

Some times it is useful for architecture implementations of KVM to know when the VCPU thread is about to block or when it comes back from blocking (arm/arm64 needs to know this to properly implement timers, for example). Therefore provide a generic architecture callback function in line with what

[PATCH v2 4/8] arm/arm64: KVM: Implement GICD_ICFGR as RO for PPIs

The GICD_ICFGR allows the bits for the SGIs and PPIs to be read only. We currently simulate this behavior by writing a hardcoded value to the register for the SGIs and PPIs on every write of these bits to the register (ignoring what the guest actually wrote), and by writing the same value as the

[PATCH] kvm: fix maybe-uninitialized compiler warning

Fixes the following compiler warning, occuring with GCC 5.2.0: arch/x86/kvm/mmu.c: In function ‘handle_mmio_page_fault_common’: arch/x86/kvm/mmu.c:3332:9: warning: ‘leaf’ may be used uninitialized in this function [-Wmaybe-uninitialized] while (root >= leaf) { ^

[PATCH v2 7/8] arm/arm64: KVM: Rework the arch timer to use level-triggered semantics

The arch timer currently uses edge-triggered semantics in the sense that the line is never sampled by the vgic and lowering the line from the timer to the vgic doesn't have any affect on the pending state of virtual interrupts in the vgic. This means that we do not support a guest with the

[PATCH v2 6/8] arm/arm64: KVM: Add forwarded physical interrupts documentation

Forwarded physical interrupts on arm/arm64 is a tricky concept and the way we deal with them is not apparently easy to understand by reading various specs. Therefore, add a proper documentation file explaining the flow and rationale of the behavior of the vgic. Some of this text was contributed

Re: [PATCH] KVM: arm/arm64: Fix PSCI affinity info return value for non valid cores

On 04/09/15 16:06, Alexander Spyridakis wrote: > If a guest requests the affinity info for a non-existing vCPU we need to > properly return an error, instead of erroneously reporting an off state. > > Signed-off-by: Alexander Spyridakis > Signed-off-by:

Re: [PATCH v7 2/3] KVM: dynamic halt-polling

Hi Paolo, On 9/3/15 10:07 PM, Wanpeng Li wrote: [...] static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu) { if (kvm_arch_vcpu_runnable(vcpu)) { @@ -1928,7 +1962,8 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) { ktime_t start, cur; DEFINE_WAIT(wait); - bool

RE: [PATCH v2 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

Hello! > > + KVM_DEV_ARM_VGIC_GRP_REDIST_REGS > > + Attributes: > > +The attr field of kvm_device_attr encodes two values: > > +bits: | 63 | 62 .. 40 | 39 .. 32 | 31 0 | > > +values: | size | reserved | cpu id | offset | > > We should avoid

KVM memory slots limit on powerpc

Hi all, now that we get memory hotplugging for the spapr machine on qemu-ppc, too, it seems like we easily can hit the amount of KVM-internal memory slots now ("#define KVM_USER_MEM_SLOTS 32" in arch/powerpc/include/asm/kvm_host.h). For example, start qemu-system-ppc64 with a couple of "-device

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On 04/09/15 12:07, Christian Borntraeger wrote: > Am 04.09.2015 um 12:04 schrieb Alexander Graf: >> >> >> On 04.09.15 11:59, Christian Borntraeger wrote: >>> Am 04.09.2015 um 11:35 schrieb Thomas Huth: Hi all, now that we get memory hotplugging for the spapr machine on

Re: KVM memory slots limit on powerpc

Am 04.09.2015 um 11:35 schrieb Thomas Huth: > > Hi all, > > now that we get memory hotplugging for the spapr machine on qemu-ppc, > too, it seems like we easily can hit the amount of KVM-internal memory > slots now ("#define KVM_USER_MEM_SLOTS 32" in > arch/powerpc/include/asm/kvm_host.h). For

Re: [Qemu-ppc] KVM memory slots limit on powerpc

Am 04.09.2015 um 12:04 schrieb Alexander Graf: > > > On 04.09.15 11:59, Christian Borntraeger wrote: >> Am 04.09.2015 um 11:35 schrieb Thomas Huth: >>> >>> Hi all, >>> >>> now that we get memory hotplugging for the spapr machine on qemu-ppc, >>> too, it seems like we easily can hit the amount

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On Fri, 2015-09-04 at 12:28 +0200, Thomas Huth wrote: > > Maybe some rcu protected scheme that doubles the amount of memslots > > for > > each overrun? Yes, that would be good and even reduce the footprint > > for > > systems with only a small number of memslots. > > Seems like Alex Williamson

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On 04/09/15 12:04, Alexander Graf wrote: > > > On 04.09.15 11:59, Christian Borntraeger wrote: >> Am 04.09.2015 um 11:35 schrieb Thomas Huth: >>> >>> Hi all, >>> >>> now that we get memory hotplugging for the spapr machine on qemu-ppc, >>> too, it seems like we easily can hit the amount of

[PATCH] powerpc/e500: move qemu machine spec together with the rest

This way we get rid of an entire file with mostly duplicated code plus a Kconfig option that you always had to take care to check it in order for kvm to work. Signed-off-by: Laurentiu Tudor --- arch/powerpc/platforms/85xx/Kconfig | 15 -

Re: [Qemu-ppc] KVM memory slots limit on powerpc

On Fri, 2015-09-04 at 12:28 +0200, Thomas Huth wrote: > On 04/09/15 12:07, Christian Borntraeger wrote: > > Am 04.09.2015 um 12:04 schrieb Alexander Graf: > >> > >> > >> On 04.09.15 11:59, Christian Borntraeger wrote: > >>> Am 04.09.2015 um 11:35 schrieb Thomas Huth: > > Hi all, >