Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

> I added the warning so that we catch if the next_rip field is being written > to (even if the feature isn't supported) by a buggy L1 hypervisor. Interesting, so how about this patch? 0001-KVM-nSVM-Check-for-NRIP-support-before-accepting-con.patch Description: Binary data Thanks, Dirk

Re: [PATCH v2 01/15] KVM: arm/arm64: VGIC: don't track used LRs in the distributor

Hi Pavel, On 02/10/15 13:39, Pavel Fedin wrote: > Hello! > >> Can't you use the ELRSR bitmap instead? The idea of lr_used sounds like >> a moot optimization to me. > > This perfectly works on 4.2, but will break HW interrupt forwarding on 4.3. > If you look at 4.3 >

RE: [PATCH v2 01/15] KVM: arm/arm64: VGIC: don't track used LRs in the distributor

Hello! One more concern. > 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

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 02/10/2015 12:16, Peter Maydell wrote: > On 2 October 2015 at 11:05, Paolo Bonzini wrote: >> On 02/10/2015 11:58, Peter Maydell wrote: >>> I definitely dislike the latter -- userspace ends up having to >>> emulate part of the CPU even though that CPU support is really

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > How do boards other than 'virt' work when emulated without KVM? Under "emulated without KVM" we normally suppose full software emulation (known in qemu as TCG). In this case CPU code is interpreted, and KVM is not used at all. Some boards (like vexpress) have own platform-specific

RE: [PATCH v2 01/15] KVM: arm/arm64: VGIC: don't track used LRs in the distributor

Hello! > For instance how did you come up with that 16384? LPIs could actually be > much bigger (in fact the emulation currently support up to 64k). Well, read "at least 16384". I actually don't remember the exact value you've put in. > > Since the map itself is actually used only for

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

W dniu 01.10.2015 o 16:18, Paolo Bonzini pisze: > > On 01/10/2015 16:12, Janusz wrote: >> Now, I can also add, that the problem is only when I allow VM to use >> more than one core, so with option for example: >> -smp 8,cores=4,threads=2,sockets=1 and other combinations like -smp >> 4,threads=1

RE: [PATCH v2 01/15] KVM: arm/arm64: VGIC: don't track used LRs in the distributor

Hello! > Can't you use the ELRSR bitmap instead? The idea of lr_used sounds like > a moot optimization to me. This perfectly works on 4.2, but will break HW interrupt forwarding on 4.3. If you look at 4.3 __kvm_vgic_sync_hwstate(), you'll notice that for HW interrupts lr_used and elrsr_ptr

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 02/10/2015 11:58, Peter Maydell wrote: > On 2 October 2015 at 10:30, Paolo Bonzini wrote: >> >> >> On 02/10/2015 09:28, Pavel Fedin wrote: >>> 2. Another possible approach, based on how device tree binding is handled >>> by Linux. It is possible >>> to remove virtual

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 2 October 2015 at 11:18, Paolo Bonzini wrote: > > > On 02/10/2015 12:16, Peter Maydell wrote: >> On 2 October 2015 at 11:05, Paolo Bonzini wrote: >>> On 02/10/2015 11:58, Peter Maydell wrote: I definitely dislike the latter -- userspace ends up

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > - How do you find out that your guest is Linux? Yes, i agree. No way. And it's not host kernel's job anyway. > - How do you ensure that the guest will not require the virtual timer? Agree again. Except device tree, no way. If the guest has its own hardcoded assumptions, it's

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On Fri, 2 Oct 2015 10:28:42 +0300 Pavel Fedin wrote: [...] > 1. If there's no in-kernel irqchip, we revert to older timer > behavior (ARCH_TIMER_CTRL_IT_MASK hack), and forward the timer IRQ to > userspace using new KVM_EXIT_IRQ return code. Timer IRQ has to be > treated

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > I mean in the device tree. Does the boot loader realize it's under a > hypervisor, and provide different device trees to the kernel? This has nothing to do with the device tree. Device tree is static. The logic sits inside Linux kernel itself: a) If we are running in HYP mode (we

Re: [PATCH v2 01/15] KVM: arm/arm64: VGIC: don't track used LRs in the distributor

Hi Pavel, On 02/10/15 10:55, Pavel Fedin wrote: > Hello! One more concern. > >> 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

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 2 October 2015 at 11:05, Paolo Bonzini wrote: > On 02/10/2015 11:58, Peter Maydell wrote: >> I definitely dislike the latter -- userspace ends up having to >> emulate part of the CPU even though that CPU support is really >> there in hardware. Also it requires us to edit

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 02/10/2015 09:28, Pavel Fedin wrote: > 2. Another possible approach, based on how device tree binding is handled by > Linux. It is possible > to remove virtual timer IRQ from the device tree, in this case the kernel > reverts to using physical > timer. When running under hypervisor,

Re: [Qemu-devel] [PATCHv2] arm: Fail on unknown subtest

On Thu, Oct 01, 2015 at 03:46:25PM -0400, Christopher Covington wrote: > Signed-off-by: Christopher Covington > --- > arm/selftest.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arm/selftest.c b/arm/selftest.c > index fc9ec60..f4a5030 100644 > ---

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 2 October 2015 at 10:30, Paolo Bonzini wrote: > > > On 02/10/2015 09:28, Pavel Fedin wrote: >> 2. Another possible approach, based on how device tree binding is handled >> by Linux. It is possible >> to remove virtual timer IRQ from the device tree, in this case the

Re: [Qemu-devel] [PATCH] arm: Add PMU test

On Thu, Oct 01, 2015 at 03:47:21PM -0400, Christopher Covington wrote: > Beginning with just a read of the control register, add plumbing > for testing the ARM Performance Monitors Unit (PMU). > > Signed-off-by: Christopher Covington Hi Christopher, PMU tests are a great

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > I like the latter. But I guess one could even do both? You know, you are right, they absolutely do not contradict each other. Patch set for #1 is quite not big, if you are interested, and nobody votes strongly against, i can rebase it to 4.3 and post. Kind regards, Pavel Fedin

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

Hi Christoffer, On 29/09/15 15:49, 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 > natural VGIC_NR_SGIS. Change this slightly confusing use of the > defines. > > Note:

Re: [PATCH 09/15] arm64: Add page size to the kernel image header

On Tue, Sep 15, 2015 at 04:41:18PM +0100, Suzuki K. Poulose wrote: > From: Ard Biesheuvel > > This patch adds the page size to the arm64 kernel image header > so that one can infer the PAGESIZE used by the kernel. This will > be helpful to diagnose failures to boot the

[PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

Current KVM code has lots of old redundancies, which can be cleaned up. This patchset is actually a better alternative to http://www.spinics.net/lists/arm-kernel/msg430726.html, which allows to keep piggy-backed LRs. The idea is based on the fact that our code also maintains LR state in elrsr, and

[PATCH 1/2] KVM: arm/arm64: Optimize away redundant LR tracking

Currently we use vgic_irq_lr_map in order to track which LRs hold which IRQs, and lr_used bitmap in order to track which LRs are used or free. vgic_irq_lr_map is actually used only for piggy-back optimization, and can be easily replaced by iteration over lr_used. This is good because in future,

[PATCH 2/2] KVM: arm/arm64: Merge vgic_set_lr() and vgic_sync_lr_elrsr()

Now we see that vgic_set_lr() and vgic_sync_lr_elrsr() are always used together. Merge them into one function, saving from second vgic_ops dereferencing every time. Additionally, remove unnecessary vgic_set_lr() in vgic_unqueue_irqs(), because the following vgic_retire_lr() will reset lr.state to

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

Hi Christoffer, On 29/09/15 15:49, Christoffer Dall wrote: > 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

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

Hi Christoffer, On 29/09/15 15:49, Christoffer Dall wrote: > 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

[PATCH] kvm: Allow the Hyper-V vendor ID to be specified

According to Microsoft documentation, the signature in the standard hypervisor CPUID leaf at 0x4000 identifies the Vendor ID and is for reporting and diagnostic purposes only. We can therefore allow the user to change it to whatever they want, within the 12 character limit. Add a new

[kvm-unit-tests PATCHv2] arm: Add PMU test

Add test the ARM Performance Monitors Unit (PMU). The informational fields from the control register are printed, but not checked, and the number of cycles it takes to run a known-instruction-count loop is printed, but not checked. Once QEMU is fixed, we can at least begin to check for IPC == 1

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > So let me put it another way. The only way I look into this is when we > have this particular platform fully supported in mainline. I am sorry for possible misunderstanding. Please give me one more minute to defend myself... So far, we are not putting back timer disable hack. So,

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

On 29/09/15 15:49, Christoffer Dall wrote: > 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. > >

Re: linux-next: Tree for Oct 2 (kvm)

On 10/01/15 22:27, Stephen Rothwell wrote: > Hi all, > > There will be no linux-next release on Monday. > > Changes since 20151001: > on x86_64: ERROR: "irq_set_vcpu_affinity" [arch/x86/kvm/kvm-intel.ko] undefined! Full randconfig file is attached. -- ~Randy # # Automatically generated

Re: [PATCH 09/15] arm64: Add page size to the kernel image header

On Fri, Oct 02, 2015 at 04:49:01PM +0100, Catalin Marinas wrote: > On Tue, Sep 15, 2015 at 04:41:18PM +0100, Suzuki K. Poulose wrote: > > From: Ard Biesheuvel > > > > This patch adds the page size to the arm64 kernel image header > > so that one can infer the PAGESIZE

Re: [PATCH 09/15] arm64: Add page size to the kernel image header

On 02/10/15 17:31, Catalin Marinas wrote: > On Fri, Oct 02, 2015 at 04:49:01PM +0100, Catalin Marinas wrote: >> On Tue, Sep 15, 2015 at 04:41:18PM +0100, Suzuki K. Poulose wrote: >>> From: Ard Biesheuvel >>> >>> This patch adds the page size to the arm64 kernel image

Re: PCI passthrough problem

On Thu, 2015-10-01 at 21:00 -0600, Alex Williamson wrote: > On Thu, 2015-10-01 at 22:38 -0400, Phil (list) wrote: > > On Thu, 2015-10-01 at 08:32 -0400, Mauricio Tavares wrote: > > > On Thu, Oct 1, 2015 at 3:27 AM, Phil (list) > > > wrote: > > > > If this isn't the right

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On Fri, Oct 02, 2015 at 05:54:53PM +0300, Pavel Fedin wrote: > Hello! > > > So let me put it another way. The only way I look into this is when we > > have this particular platform fully supported in mainline. > > I am sorry for possible misunderstanding. Please give me one more minute to >

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

On Fri, Oct 02, 2015 at 03:52:42PM +0100, Andre Przywara wrote: > Hi Christoffer, > > On 29/09/15 15:49, Christoffer Dall wrote: > > Currently vgic_process_maintenance() processes dealing with a completed > > level-triggered interrupt directly, but we are soon going to reuse this > > logic for

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

On Fri, Oct 02, 2015 at 06:18:03PM +0100, Andre Przywara wrote: > On 29/09/15 15:49, Christoffer Dall wrote: > > 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

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

On Fri, Oct 02, 2015 at 03:51:50PM +0100, Andre Przywara wrote: > Hi Christoffer, > > On 29/09/15 15:49, Christoffer Dall wrote: > > 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

Re: [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi interrupt

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > An MSI-address is allocated and programmed in pcie device > during interrupt configuration. Now for a pass-through device, > try to create the iommu mapping for this allocted/programmed > msi-address. If the iommu mapping is created and

Re: [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > This Patch adds the VFIO APIs to add and remove reserved iova > regions. The reserved iova region can be used for mapping some > specific physical address in iommu. > > Currently we are planning to use this interface for adding iova >

Re: [RFC PATCH 6/6] arm-smmu: Allow to set iommu mapping for MSI

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > Finally ARM SMMU declare that iommu-mapping for MSI-pages are not > set automatically and it should be set explicitly. > > Signed-off-by: Bharat Bhushan > --- > drivers/iommu/arm-smmu.c | 7 ++- > 1

Re: [RFC PATCH 4/6] vfio: Add interface to iommu-map/unmap MSI pages

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > For MSI interrupts to work for a pass-through devices we need > to have mapping of msi-pages in iommu. Now on some platforms > (like x86) does this msi-pages mapping happens magically and in these > case they chooses an iova which they

Re: [RFC PATCH 2/6] iommu: Add interface to get msi-pages mapping attributes

[really ought to consider cc'ing the iommu list] On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > This APIs return the capability of automatically mapping msi-pages > in iommu with some magic iova. Which is what currently most of > iommu's does and is the default behaviour. > > Further

Re: [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > This patch allows the user-space to know whether msi-pages > are automatically mapped with some magic iova or not. > > Even if the msi-pages are automatically mapped, still user-space > wants to over-ride the automatic iova selection for

[RFC] Handling CP15 timer without in-kernel irqchip

Hello! Since c2f58514cfb374d5368c9da945f1765cd48eb0da ("arm/arm64: KVM: vgic: Check for !irqchip_in_kernel() when mapping resources") we can run qemu with kernel_irqchip=off option. The only remaining problem is how to handle CP15 timer in this case. I have applied my old experimental

RE: [PATCH v2 09/15] KVM: arm64: implement basic ITS register handlers

Hello! Long time has passed, but i started working on live migration of this thing, and found some more problems. > @@ -117,9 +305,26 @@ int vits_init(struct kvm *kvm) > struct vgic_dist *dist = >arch.vgic; > struct vgic_its *its = >its; > > + dist->pendbaser =

Re: [RFC PATCH v3] os-android: Add support to android platform

2015-09-28 19:40 GMT+08:00 Paolo Bonzini : > > > On 24/09/2015 15:21, Houcheng Lin wrote: >> +if [ "$android" = "yes" ] ; then >> + LIBS="-lglib-2.0 -lgthread-2.0 -lz -lpixman-1 -lintl -liconv -lc $LIBS" >> + libs_qga="-lglib-2.0 -lgthread-2.0 -lz -lpixman-1 -lintl -liconv

[RFC PATCH v4] os-android: Add support to android platform

Hi, The v4 patch uses qemu_getdtablesize(), remove os-android.h and use a local buffer when calling ptsname_r(). This patch is based on version: 007e620a7576e4ce2ea6955541e87d8ae8ed32ae. --- Building QEMU on android reqiures