Re: [PATCH v4 3/7] KVM: arm/arm64: Fix the documentation

On Mon, Sep 28, 2015 at 06:27:30PM +0300, Pavel Fedin wrote: > During refactoring we noticed some mistakes in the documentation. > Correct them. > > Signed-off-by: Pavel Fedin > --- > Documentation/virtual/kvm/devices/arm-vgic.txt | 18 ++ > 1 file changed,

Re: [PATCH v4 4/7] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

Hi Pavel, On Mon, Sep 28, 2015 at 06:27:31PM +0300, 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, >

Re: [PATCH v3 17/20] KVM: ARM64: Add PMU overflow interrupt routing

On 24/09/15 23:31, Shannon Zhao wrote: > When calling perf_event_create_kernel_counter to create perf_event, > assign a overflow handler. Then when perf event overflows, set > irq_pending and call kvm_vcpu_kick() to sync the interrupt. > > Signed-off-by: Shannon Zhao >

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

Hi Suzuki, On Tue, Sep 15, 2015 at 04:41:12PM +0100, Suzuki K. Poulose wrote: > From: "Suzuki K. Poulose" > > Introduce helpers for finding the number of page table > levels required for a given VA width, shift for a particular > page table level. > > Convert the

RE: [PATCH v2 11/15] KVM: arm64: handle pending bit for LPIs in ITS emulation

Hello! > +/* Called with the distributor lock held by the caller. */ > +void vits_unqueue_lpi(struct kvm_vcpu *vcpu, int lpi) > +{ > + struct vgic_its *its = >kvm->arch.vgic.its; > + struct its_itte *itte; > + > + spin_lock(>lock); > + > + /* Find the right ITTE and put the

Re: [PATCH v3 03/20] KVM: ARM64: Add offset defines for PMU registers

On 24/09/15 23:31, Shannon Zhao wrote: > We are about to trap and emulate acccesses to each PMU register > individually. This adds the context offsets for the AArch64 PMU > registers and their AArch32 counterparts. > > Signed-off-by: Shannon Zhao > --- >

RE: [PATCH] genirq: Move irq_set_vcpu_affinity out of "#ifdef CONFIG_SMP"

Hi Thomas & Paolo, > -Original Message- > From: Jiang Liu [mailto:jiang@linux.intel.com] > Sent: Saturday, October 03, 2015 5:11 PM > To: Wu, Feng; t...@linutronix.de; pbonz...@redhat.com > Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] genirq: Move

Re: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

On Wed, 7 Oct 2015 21:09:07 +0300 Pavel Fedin wrote: > Hello! > > > LPIs do not have an active state, at the redistributor or otherwise. > > Then what do they become after they were ACK'ed and before EOI'ed? Nothing. They are gone. What is left at the CPU interface is

[PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

Factor out the GICv3-specific documentation into a separate documentation file. Add description for how to access distributor, redistributor, and CPU interface registers for GICv3 in this new file. Acked-by: Peter Maydell Acked-by: Marc Zyngier

Re: [PATCH v2 11/15] KVM: arm64: handle pending bit for LPIs in ITS emulation

On Wed, Oct 07, 2015 at 11:39:30AM +0300, Pavel Fedin wrote: > Hello! > > > +/* Called with the distributor lock held by the caller. */ > > +void vits_unqueue_lpi(struct kvm_vcpu *vcpu, int lpi) > > +{ > > + struct vgic_its *its = >kvm->arch.vgic.its; > > + struct its_itte *itte; > > + > > +

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

On 07/10/15 10:26, Marc Zyngier wrote: On 07/10/15 09:26, Christoffer Dall wrote: Hi Suzuki, On Tue, Sep 15, 2015 at 04:41:12PM +0100, Suzuki K. Poulose wrote: From: "Suzuki K. Poulose" Introduce helpers for finding the number of page table levels required for a

Re: [PATCH 2/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

On 06/10/2015 22:33, Radim Krčmář wrote: > 2015-08-15 02:00+0200, Paolo Bonzini: >> On 14/08/2015 10:38, Radim Krčmář wrote: How do you reproduce the bug? >>> I run rhel4 (2.6.9) kernel on 2 VCPUs and frequently alternate >>> smp_affinity of "timer". The bug is hit within seconds. >> >>

Re: [PATCH 11/15] arm64: Cleanup VTCR_EL2 computation

On 07/10/15 11:11, Marc Zyngier wrote: On 15/09/15 16:41, Suzuki K. Poulose wrote: From: "Suzuki K. Poulose" diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h index bdf139e..699554d 100644 --- a/arch/arm64/include/asm/kvm_arm.h +++

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Tue, Oct 06, 2015 at 01:59:27PM -0400, Bandan Das wrote: > Joerg Roedel writes: > > > > So svm->vmcb->control.next_rip is only written by hardware or in > > svm_check_intercept(). Both cases write only to this field, if the > > hardware supports X86_FEATURE_NRIPS. The write in

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

On 07/10/15 09:26, Christoffer Dall wrote: Hi Suzuki, On Tue, Sep 15, 2015 at 04:41:12PM +0100, Suzuki K. Poulose wrote: From: "Suzuki K. Poulose" Introduce helpers for finding the number of page table levels required for a given VA width, shift for a particular page

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

On 07/10/15 09:26, Christoffer Dall wrote: > Hi Suzuki, > > On Tue, Sep 15, 2015 at 04:41:12PM +0100, Suzuki K. Poulose wrote: >> From: "Suzuki K. Poulose" >> >> Introduce helpers for finding the number of page table >> levels required for a given VA width, shift for a

Re: [PATCH 12/15] arm: kvm: Move fake PGD handling to arch specific files

On 15/09/15 16:41, Suzuki K. Poulose wrote: > From: "Suzuki K. Poulose" > > Rearrange the code for fake pgd handling, which is applicable > to only ARM64. The intention is to keep the common code cleaner, > unaware of the underlying hacks. > > Cc:

Re: [PATCH 13/15] arm64: kvm: Rewrite fake pgd handling

On 15/09/15 16:41, Suzuki K. Poulose wrote: > From: "Suzuki K. Poulose" > > The existing fake pgd handling code assumes that the stage-2 entry > level can only be one level down that of the host, which may not be > true always(e.g, with the introduction of 16k pagesize).

Re: [PATCH 2/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

On 13/08/2015 15:46, Radim Krčmář wrote: > + if (kvm_x86_ops->sync_pir_to_irr(vcpu)) > + kvm_make_request(KVM_REQ_EVENT, vcpu); > + The call to sync_pir_to_irr belongs more in vcpu_scan_ioapic, I think. More importantly, I think that KVM_REQ_EVENT is a latent bug for

Re: [PATCH 11/15] arm64: Cleanup VTCR_EL2 computation

On 15/09/15 16:41, Suzuki K. Poulose wrote: > From: "Suzuki K. Poulose" > > No functional changes. Group the common bits for VCTR_EL2 > initialisation for better readability. The granule size > and the entry level are controlled by the page size. > > Cc: Christoffer Dall

Re: [Qemu-devel] [PATCH v2 00/18] implement vNVDIMM

On Wed, Aug 26, 2015 at 06:49:35PM +0800, Xiao Guangrong wrote: > On 08/26/2015 12:26 AM, Stefan Hajnoczi wrote: > >On Fri, Aug 14, 2015 at 10:51:53PM +0800, Xiao Guangrong wrote: > >Have you thought about live migration? > > > >Are the contents of the NVDIMM migrated since they are registered as

Re: [PATCH] kvm: svm: Only propagate next_rip when guest supports it

Hi Joerg, [auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore] config: i386-randconfig-x009-201540 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>):

[PATCH] kvm: svm: Only propagate next_rip when guest supports it

On Wed, Oct 07, 2015 at 01:03:35PM +0200, Joerg Roedel wrote: > But we don't care if L1 writes something into its own next_rip, as we > never read this value from its VMCB. We only copy the next_rip value we > get from our shadow-vmcb to it on an emulated vmexit. So I still don't > understand what

Virtio drivers for WindowsServer 2012R2 network problems no outgoing traffic in Openstack

Hi KVM developers, currently I'm facing a tricky issue when I'm using the Virtio drivers (Fedora [1]) for a WindowsServer2012R2 virtual machine on Openstack I've created a WindowsServer Image following this tutorial [2]. I've installed the virtio drivers but without the Cloud-Init step. I've

Re: [PATCH 13/15] arm64: kvm: Rewrite fake pgd handling

On 07/10/15 12:13, Marc Zyngier wrote: On 15/09/15 16:41, Suzuki K. Poulose wrote: From: "Suzuki K. Poulose" The existing fake pgd handling code assumes that the stage-2 entry level can only be one level down that of the host, which may not be true always(e.g, with the

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Wed, Oct 07, 2015 at 10:58:07AM -0400, Bandan Das wrote: > Ok, looks like I am making some incorrect "vmx" assumptions here. What happens > when we exit from L2 to L0, arent' we looking at the VMCB L1 is using to run > L2 ? Wouldn't that trigger the warning if the host processor does not

Re: [PATCH v3 12/16] KVM: arm64: handle pending bit for LPIs in ITS emulation

On 07/10/15 16:10, Pavel Fedin wrote: > Hello! > >> As the actual LPI number in a guest can be quite high, but is mostly >> assigned using a very sparse allocation scheme, bitmaps and arrays >> for storing the virtual interrupt status are a waste of memory. >> We use our equivalent of the

Re: [Qemu-devel] [PATCH v2 00/18] implement vNVDIMM

On 10/07/2015 10:02 PM, Stefan Hajnoczi wrote: On Wed, Aug 26, 2015 at 06:49:35PM +0800, Xiao Guangrong wrote: On 08/26/2015 12:26 AM, Stefan Hajnoczi wrote: On Fri, Aug 14, 2015 at 10:51:53PM +0800, Xiao Guangrong wrote: Have you thought about live migration? Are the contents of the NVDIMM

Re: [PATCH 2/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

2015-10-07 11:29+0200, Paolo Bonzini: > On 13/08/2015 15:46, Radim Krčmář wrote: >> +if (kvm_x86_ops->sync_pir_to_irr(vcpu)) >> +kvm_make_request(KVM_REQ_EVENT, vcpu); >> + > > The call to sync_pir_to_irr belongs more in vcpu_scan_ioapic, I think. Will do so in v2. > More

[PATCH v3 13/16] KVM: arm64: sync LPI configuration and pending tables

The LPI configuration and pending tables of the GICv3 LPIs are held in tables in (guest) memory. To achieve reasonable performance, we cache this data in our own data structures, so we need to sync those two views from time to time. This behaviour is well described in the GICv3 spec and is also

[PATCH v3 05/16] KVM: arm/arm64: extend arch CAP checks to allow per-VM capabilities

KVM capabilities can be a per-VM property, though ARM/ARM64 currently does not pass on the VM pointer to the architecture specific capability handlers. Add a "struct kvm*" parameter to those function to later allow proper per-VM capability reporting. Signed-off-by: Andre Przywara

[PATCH v3 14/16] KVM: arm64: implement ITS command queue command handlers

The connection between a device, an event ID, the LPI number and the allocated CPU is stored in in-memory tables in a GICv3, but their format is not specified by the spec. Instead software uses a command queue in a ring buffer to let the ITS implementation use their own format. Implement handlers

[PATCH v3 15/16] KVM: arm64: implement MSI injection in ITS emulation

When userland wants to inject a MSI into the guest, we have to use our data structures to find the LPI number and the VCPU to receive the interrupt. Use the wrapper functions to iterate the linked lists and find the proper Interrupt Translation Table Entry. Then set the pending bit in this ITTE to

[PATCH v3 12/16] KVM: arm64: handle pending bit for LPIs in ITS emulation

As the actual LPI number in a guest can be quite high, but is mostly assigned using a very sparse allocation scheme, bitmaps and arrays for storing the virtual interrupt status are a waste of memory. We use our equivalent of the "Interrupt Translation Table Entry" (ITTE) to hold this extra status

[PATCH v3 16/16] KVM: arm64: enable ITS emulation as a virtual MSI controller

If userspace has provided a base address for the ITS register frame, we enable the bits that advertise LPIs in the GICv3. When the guest has enabled LPIs and the ITS, we enable the emulation part by initializing the ITS data structures and trapping on ITS register frame accesses by the guest. Also

Re: [PATCH 2/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

2015-10-07 11:31+0200, Paolo Bonzini: > What's the issue with > handle_irq? I get #PF instead of callback after redirecting to VCPU 1. No idea what causes it, yet -- seeing handle_irq's iplementation made me postpone debugging :) -- To unsubscribe from

RE: [PATCH v3 12/16] KVM: arm64: handle pending bit for LPIs in ITS emulation

Hello! > As the actual LPI number in a guest can be quite high, but is mostly > assigned using a very sparse allocation scheme, bitmaps and arrays > for storing the virtual interrupt status are a waste of memory. > We use our equivalent of the "Interrupt Translation Table Entry" > (ITTE) to hold

[PATCH v3 03/16] KVM: extend struct kvm_msi to hold a 32-bit device ID

The ARM GICv3 ITS MSI controller requires a device ID to be able to assign the proper interrupt vector. On real hardware, this ID is sampled from the bus. To be able to emulate an ITS controller, extend the KVM MSI interface to let userspace provide such a device ID. For PCI devices, the device ID

[PATCH v3 11/16] KVM: arm64: add data structures to model ITS interrupt translation

The GICv3 Interrupt Translation Service (ITS) uses tables in memory to allow a sophisticated interrupt routing. It features device tables, an interrupt table per device and a table connecting "collections" to actual CPUs (aka. redistributors in the GICv3 lingo). Since the interrupt numbers for the

[PATCH v3 07/16] KVM: arm64: Introduce new MMIO region for the ITS base address

The ARM GICv3 ITS controller requires a separate register frame to cover ITS specific registers. Add a new VGIC address type and store the address in a field in the vgic_dist structure. Provide a function to check whether userland has provided the address, so ITS functionality can be guarded by

[PATCH v3 10/16] KVM: arm64: implement basic ITS register handlers

Add emulation for some basic MMIO registers used in the ITS emulation. This includes: - GITS_{CTLR,TYPER,IIDR} - ID registers - GITS_{CBASER,CREADR,CWRITER} those implement the ITS command buffer handling Most of the handlers are pretty straight forward, but CWRITER goes some extra miles to

[PATCH v3 06/16] KVM: arm/arm64: make GIC frame address initialization model specific

Currently we initialize all the possible GIC frame addresses in one function, without looking at the specific GIC model we instantiate for the guest. As this gets confusing when adding another VGIC model later, lets move these initializations into the respective model's emulation init functions.

[PATCH v3 01/16] KVM: arm/arm64: VGIC: don't track used LRs in the distributor

Currently we track which IRQ has been mapped to which VGIC list register and also have to synchronize both. We used to do this to hold some extra state (for instance the active bit). It turns out that this extra state in the LRs is no longer needed and this extra tracking causes some pain later.

[PATCH v3 08/16] KVM: arm64: handle ITS related GICv3 redistributor registers

In the GICv3 redistributor there are the PENDBASER and PROPBASER registers which we did not emulate so far, as they only make sense when having an ITS. In preparation for that emulate those MMIO accesses by storing the 64-bit data written into it into a variable which we later read in the ITS

[PATCH v3 04/16] KVM: arm/arm64: add emulation model specific destroy function

Currently we destroy the VGIC emulation in one function that cares for all emulated models. To be on par with init_model (which is model specific), lets introduce a per-emulation-model destroy method, too. Use it for a tiny GICv3 specific code already, later it will be handy for the ITS emulation.

[PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

Hi, another respin and rebase of the ITS emulation series. Major changes compared to v2 (beside some minor things like added comments and function renames) are the rebasing and adaption to 4.3-rc and Christoffer's timer rework series. Also the locking has been reworked to cope with the

[PATCH v3 02/16] KVM: arm/arm64: remove now unused code after stay-in-LR rework

Now that we synchronize the LR state into our emulation upon guest exit, there is no need for taking extra care of disabled IRQs. Remove that code. Signed-off-by: Andre Przywara --- Changelog v2..v3: - new patch virt/kvm/arm/vgic.c | 29 - 1

[PATCH v3 09/16] KVM: arm64: introduce ITS emulation file with stub functions

The ARM GICv3 ITS emulation code goes into a separate file, but needs to be connected to the GICv3 emulation, of which it is an option. Introduce the skeleton with function stubs to be filled later. Introduce the basic ITS data structure and initialize it, but don't return any success yet, as we

Re: [PATCH v2 13/15] KVM: arm64: implement ITS command queue command handlers

Hi Eric, thanks a lot for your comments. I just found this email, which seemed to have been crushed between my holidays and KVM forum. I tried to address your concerns in my new revision, some have become obsolete due to the reworked locking. So I refrain from answering in detail here, since some

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Joerg Roedel writes: > On Tue, Oct 06, 2015 at 01:59:27PM -0400, Bandan Das wrote: >> Joerg Roedel writes: >> > >> > So svm->vmcb->control.next_rip is only written by hardware or in >> > svm_check_intercept(). Both cases write only to this field, if the >> >

Re: [PATCH] kvm: svm: Only propagate next_rip when guest supports it

On Wed, Oct 07, 2015 at 11:48:36AM -0400, Bandan Das wrote: > Ok, understood now. The warn_on would trigger in L1 only if it has > decided to disable nrips for some reason as was the case here. So, > my reasoning behind putting the warning was incorrect. Okay, so I think the warning can be

Re: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

On 07/10/15 17:05, Pavel Fedin wrote: > Hello! > > One more concern about the whole thing. I already replied to the previous > series, but looks like my > reply was missed. > Your implementation does not care about live migration at all. And there's > one fundamental issue > with it. In the

Re: [PATCH v3 12/16] KVM: arm64: handle pending bit for LPIs in ITS emulation

On 07/10/15 16:46, Pavel Fedin wrote: > Hello! > >> Sure. And you then have to parse and validate all the tables each and >> every time you're going to inject an interrupt (because the guest can >> change the table content behind your back). You are quickly going to >> notice that your

RE: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

Hello! One more concern about the whole thing. I already replied to the previous series, but looks like my reply was missed. Your implementation does not care about live migration at all. And there's one fundamental issue with it. In the redistributor LPIs can be only pending, but in the CPU

RE: [PATCH v3 12/16] KVM: arm64: handle pending bit for LPIs in ITS emulation

Hello! > Sure. And you then have to parse and validate all the tables each and > every time you're going to inject an interrupt (because the guest can > change the table content behind your back). You are quickly going to > notice that your performance is abysmal. I don't see any real

Re: [PATCH] kvm: svm: Only propagate next_rip when guest supports it

Joerg Roedel writes: > On Wed, Oct 07, 2015 at 01:03:35PM +0200, Joerg Roedel wrote: >> But we don't care if L1 writes something into its own next_rip, as we >> never read this value from its VMCB. We only copy the next_rip value we >> get from our shadow-vmcb to it on an

RE: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

Hello! > LPIs do not have an active state, at the redistributor or otherwise. Then what do they become after they were ACK'ed and before EOI'ed? I tried to google up this thing, and came up with this email: http://www.spinics.net/lists/kvm-arm/msg16032.html. It says that "SW must issue a

Re: [PATCH] kvm: svm: Only propagate next_rip when guest supports it

On 07.10.2015 18:14, Joerg Roedel wrote: Dirk is currently testing whether this (fixed) patch solves the problem in his setup. Tested-By: Dirk Mueller Works fine here. Thanks! Greetings, Dirk -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body

Gelten Sie für dringende Darlehen bieten1.4%

-- BancoPosta Loans Viale Europa, 175-00144 Roma, Italy. Email: bancoposta-loansfact...@outlook.com Zu wen es angeht. BancopPosta Management bietet einfache und günstige Darlehen online für Einzelperson/Firmen, braucht das Geld zu investieren oder ein Geschäft zu starten. Darlehensbetrag