Hi Paolo,
As suggested by You, the following is the issue info. Is this something to be
fixed in host kernel?
Description:
FreeBSD 64bit(10.0) Guest freezes at "booting" on Linux KVM, host running
RHEL6.4 or RHEL 6.5.
Tested various versions of FreeBSD, Any version of FreeBSD 64bit will fr
On Tue, Sep 16, 2014 at 08:57:31AM -0400, Andrew Jones wrote:
>
>
> - Original Message -
> > Il 16/09/2014 14:43, Andrew Jones ha scritto:
> > > I don't think we need to worry about this case. AFAIU, enabling the
> > > caches for a particular cpu shouldn't require any synchronization.
> >
Il 26/09/2014 03:21, Tang Chen ha scritto:
>>>
>>> I'd like to help to test the patches.
>>> Would you please tell me what is the best way to test this patch-set ?
>> How did _you_ test the patches?...
>
> I just added "-cpu xxx,-x2apic" option, start the guest, using numactl
> to bind it
> to a n
Il 26/09/2014 00:26, Andres Lagar-Cavilla ha scritto:
> Confusion around -EBUSY and zero (inside a BUG_ON no less).
>
> Reported-by: AndreA Arcangeli
> Signed-off-by: Andres Lagar-Cavilla
> ---
> virt/kvm/kvm_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/
Il 26/09/2014 08:00, Tiejun Chen ha scritto:
> We can use get_cpu() and put_cpu() to replace
> preempt_disable()/cpu = smp_processor_id() and
> preempt_enable() for slightly better code.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/x86/kernel/kvmclock.c | 19 ---
> 1 file changed,
Hi Shannon,
On Fri, Sep 26, 2014 at 01:57:46PM +0800, Shannon Zhao wrote:
>
> On 2014/9/26 1:49, Christoffer Dall wrote:
> > The sgi values calculated in read_set_clear_sgi_pend_reg() and
> > write_set_clear_sgi_pend_reg() were horribly incorrectly multiplied by 4
> > with catastrophic results in
On 2014/9/26 16:44, Christoffer Dall wrote:
> Hi Shannon,
>
> On Fri, Sep 26, 2014 at 01:57:46PM +0800, Shannon Zhao wrote:
>>
>> On 2014/9/26 1:49, Christoffer Dall wrote:
>>> The sgi values calculated in read_set_clear_sgi_pend_reg() and
>>> write_set_clear_sgi_pend_reg() were horribly incorre
On 2014/9/26 1:49, Christoffer Dall wrote:
> The sgi values calculated in read_set_clear_sgi_pend_reg() and
> write_set_clear_sgi_pend_reg() were horribly incorrectly multiplied by 4
> with catastrophic results in that subfunctions ended up overwriting
> memory not allocated for the expected purp
On Tue, Sep 23, 2014 at 04:46:01PM +0200, Antonios Motakis wrote:
> Some IOMMUs accept an IOMMU_NOEXEC protection flag in addition to
> IOMMU_READ and IOMMU_WRITE. Expose this as an IOMMU capability.
>
> Signed-off-by: Antonios Motakis
> ---
> include/linux/iommu.h | 1 +
> 1 file changed, 1 ins
On Fri, Sep 26, 2014 at 05:26:00PM +0800, Shannon Zhao wrote:
>
>
> On 2014/9/26 16:44, Christoffer Dall wrote:
> > Hi Shannon,
> >
> > On Fri, Sep 26, 2014 at 01:57:46PM +0800, Shannon Zhao wrote:
> >>
> >> On 2014/9/26 1:49, Christoffer Dall wrote:
> >>> The sgi values calculated in read_set_c
When we catch something that's not a permission fault or a translation
fault, we log the unsupported FSC in the kernel log, but we were masking
off the bottom bits of the FSC which was not very helpful.
Also correctly report the FSC for data and instruction faults rather
than telling people it was
On 26 September 2014 11:32, Christoffer Dall
wrote:
> When we catch something that's not a permission fault or a translation
> fault, we log the unsupported FSC in the kernel log, but we were masking
> off the bottom bits of the FSC which was not very helpful.
>
> Also correctly report the FSC for
On Thu, Sep 25, 2014 at 07:32:19PM +0100, Christoffer Dall wrote:
> From: Joel Schopp
>
> The current aarch64 calculation for VTTBR_BADDR_MASK masks only 39 bits
> and not all the bits in the PA range. This is clearly a bug that
> manifests itself on systems that allocate memory in the higher add
Hi Paolo,
The following changes since commit f51770ed465e6eb41da7fa16fd92eb67069600cf:
kvm: Make init_rmode_identity_map() return 0 on success. (2014-09-17 13:10:12
+0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvm-arm-
To support read-only memory regions on arm and arm64, we have a need to
resolve a gfn to an hva given a pointer to a memslot to avoid looping
through the memslots twice and to reuse the hva error checking of
gfn_to_hva_prot(), add a new gfn_to_hva_memslot_prot() function and
refactor gfn_to_hva_pro
When userspace loads code and data in a read-only memory regions, KVM
needs to be able to handle this on arm and arm64. Specifically this is
used when running code directly from a read-only flash device; the
common scenario is a UEFI blob loaded with the -bios option in QEMU.
Note that the MMIO e
From: Will Deacon
Sparse kicks up about a type mismatch for kvm_target_cpu:
arch/arm64/kvm/guest.c:271:25: error: symbol 'kvm_target_cpu' redeclared with
different type (originally declared at ./arch/arm64/include/asm/kvm_host.h:45)
- different modifiers
so fix this by adding the missing cons
From: Eric Auger
No more needed. irq.h would be void on ARM.
Acked-by: Paolo Bonzini
Signed-off-by: Eric Auger
Signed-off-by: Marc Zyngier
---
virt/kvm/eventfd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 3c5981c..0c712a7 100644
--- a/vir
From: Ard Biesheuvel
The ISS encoding for an exception from a Data Abort has a WnR
bit[6] that indicates whether the Data Abort was caused by a
read or a write instruction. While there are several fields
in the encoding that are only valid if the ISV bit[24] is set,
WnR is not one of them, so we
From: Marc Zyngier
As it stands, nothing prevents userspace from injecting an interrupt
before the guest's GIC is actually initialized.
This goes unnoticed so far (as everything is pretty much statically
allocated), but ends up exploding in a spectacular way once we switch
to a more dynamic allo
The VGIC virtual distributor implementation documentation was written a
very long time ago, before the true nature of the beast had been
partially absorbed into my bloodstream. Clarify the docs.
Plus, it fixes an actual bug. ICFRn, pfff.
Signed-off-by: Christoffer Dall
---
virt/kvm/arm/vgic.c
Writes to GICD_ISPENDRn and GICD_ICPENDRn are currently not handled
correctly for level-triggered interrupts. The spec states that for
level-triggered interrupts, writes to the GICD_ISPENDRn activate the
output of a flip-flop which is in turn or'ed with the actual input
interrupt signal. Correspo
From: Marc Zyngier
So far, all the VGIC data structures are statically defined by the
*maximum* number of vcpus and interrupts it supports. It means that
we always have to oversize it to cater for the worse case.
Start by changing the data structures to be dynamically sizeable,
and allocate them
If we unqueue a level-triggered interrupt completely, and the LR does
not stick around in the active state (and will therefore no longer
generate a maintenance interrupt), then we should clear the queued flag
so that the vgic can actually queue this level-triggered interrupt at a
later time and dea
From: Marc Zyngier
It is now quite easy to delay the allocation of the vgic tables
until we actually require it to be up and running (when the first
vcpu is kicking around, or someones tries to access the GIC registers).
This allow us to allocate memory for the exact number of CPUs we
have. As n
The sgi values calculated in read_set_clear_sgi_pend_reg() and
write_set_clear_sgi_pend_reg() were horribly incorrectly multiplied by 4
with catastrophic results in that subfunctions ended up overwriting
memory not allocated for the expected purpose.
This showed up as bugs in kfree() and the kerne
We have a special bitmap on the distributor struct to keep track of when
level-triggered interrupts are queued on the list registers. This was
named irq_active, which is confusing, because the active state of an
interrupt as per the GIC spec is a different thing, not specifically
related to edge-t
From: Joel Schopp
The current aarch64 calculation for VTTBR_BADDR_MASK masks only 39 bits
and not all the bits in the PA range. This is clearly a bug that
manifests itself on systems that allocate memory in the higher address
space range.
[ Modified from Joel's original patch to be based on PHY
From: Marc Zyngier
Having a dynamic number of supported interrupts means that we
cannot relly on VGIC_NR_SHARED_IRQS being fixed anymore.
Instead, make it take the distributor structure as a parameter,
so it can return the right value.
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
The irq_state field on the distributor struct is ambiguous in its
meaning; the comment says it's the level of the input put, but that
doesn't make much sense for edge-triggered interrupts. The code
actually uses this state variable to check if the interrupt is in the
pending state on the distribut
From: Marc Zyngier
In order to make the number of interrupts configurable, use the new
fancy device management API to add KVM_DEV_ARM_VGIC_GRP_NR_IRQS as
a VGIC configurable attribute.
Userspace can now specify the exact size of the GIC (by increments
of 32 interrupts).
Reviewed-by: Christoffer
When we catch something that's not a permission fault or a translation
fault, we log the unsupported FSC in the kernel log, but we were masking
off the bottom bits of the FSC which was not very helpful.
Also correctly report the FSC for data and instruction faults rather
than telling people it was
Writes to GICD_ISPENDR0 and GICD_ICPENDR0 ignore all settings of the
pending state for SGIs. Make sure the implementation handles this
correctly.
Signed-off-by: Christoffer Dall
---
virt/kvm/arm/vgic.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/virt/
From: Marc Zyngier
Nuke VGIC_NR_IRQS entierly, now that the distributor instance
contains the number of IRQ allocated to this GIC.
Also add VGIC_NR_IRQS_LEGACY to preserve the current API.
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 6 +++---
virt/
From: Marc Zyngier
Now that we can (almost) dynamically size the number of interrupts,
we're facing an interesting issue:
We have to evaluate at runtime whether or not an access hits a valid
register, based on the sizing of this particular instance of the
distributor. Furthermore, the GIC spec s
From: Marc Zyngier
We now have the information about the number of CPU interfaces in
the distributor itself. Let's get rid of VGIC_MAX_CPUS, and just
rely on KVM_MAX_VCPUS where we don't have the choice. Yet.
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h
From: Will Deacon
is_valid_cache returns true if the specified cache is valid.
Unfortunately, if the parameter passed it out of range, we return
-ENOENT, which ends up as true leading to potential hilarity.
This patch returns false on the failure path instead.
Cc: Christoffer Dall
Cc: Marc Zyn
From: Will Deacon
We currently return the number of bytes not copied if set_timer_reg
fails, which is almost certainly not what userspace would like.
This patch returns -EFAULT instead.
Cc: Christoffer Dall
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Christoffer Dall
---
arc
From: Will Deacon
vgic_ioaddr_overlap claims to return a bool, but in reality it returns
an int. Shut sparse up by fixing the type signature.
Cc: Christoffer Dall
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Christoffer Dall
---
virt/kvm/arm/vgic.c | 2 +-
1 file changed, 1 in
From: Will Deacon
We extract the vgic probe function from the of_device_id data pointer,
which is const. Kill the sparse warning by ensuring that the local
function pointer is also marked as const.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Christoffer Dall
---
virt/kvm/arm/v
From: Will Deacon
Running sparse results in a bunch of noisy address space mismatches
thanks to the broken __percpu annotation on kvm_get_running_vcpus.
This function returns a pcpu pointer to a pointer, not a pointer to a
pcpu pointer. This patch fixes the annotation, which kills the warnings
f
On Fri, Sep 26, 2014 at 12:16:35PM +0200, Christoffer Dall wrote:
> On Fri, Sep 26, 2014 at 05:26:00PM +0800, Shannon Zhao wrote:
> >
> >
> > On 2014/9/26 16:44, Christoffer Dall wrote:
> > > Hi Shannon,
> > >
> > > On Fri, Sep 26, 2014 at 01:57:46PM +0800, Shannon Zhao wrote:
> > >>
> > >> On 2
On Sep 26, 2014, at 4:42 AM, Christoffer Dall wrote:
Hi, Christoffer
> This patch adds the necessary support for all host kernel PGSIZE and
> VA_SPACE configuration options for both EL2 and the Stage-2 page tables.
>
> However, for 40bit and 42bit PARange systems, the architecture mandates
> tha
On Fri, Sep 26, 2014 at 11:48 AM, Joerg Roedel wrote:
> On Tue, Sep 23, 2014 at 04:46:01PM +0200, Antonios Motakis wrote:
>> Some IOMMUs accept an IOMMU_NOEXEC protection flag in addition to
>> IOMMU_READ and IOMMU_WRITE. Expose this as an IOMMU capability.
>>
>> Signed-off-by: Antonios Motakis
>
On Wed, Sep 24, 2014 at 7:00 PM, Alex Williamson
wrote:
> On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
>> This patch allows to set an eventfd for a patform device's interrupt,
>> and also to trigger the interrupt eventfd from userspace for testing.
>>
>> Signed-off-by: Antonios Motak
On Wed, Sep 24, 2014 at 1:11 AM, Alex Williamson
wrote:
> On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
>> Enable building the VFIO AMBA driver. VFIO_AMBA depends on VFIO_PLATFORM,
>> since it is sharing a portion of the code, and it is essentially implemented
>> as a platform device
Ok, they will be posted separately.
Thanks
On Wed, Sep 24, 2014 at 12:45 AM, Alex Williamson
wrote:
> On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
>> As already demonstrated with PCI [1] and the platform bus [2], a
>> driver_override property in sysfs can be used to bypass the id m
On Wed, Sep 24, 2014 at 1:01 AM, Alex Williamson
wrote:
>
> On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
> > Driver to bind to Linux platform devices, and callbacks to discover their
> > resources to be used by the main VFIO PLATFORM code.
> >
> > Signed-off-by: Antonios Motakis
> >
On Tue, Sep 23, 2014 at 04:46:06PM +0200, Antonios Motakis wrote:
> As already demonstrated with PCI [1] and the platform bus [2], a
> driver_override property in sysfs can be used to bypass the id matching
> of a device to a AMBA driver. This can be used by VFIO to bind to any AMBA
> device reques
On Wed, Sep 24, 2014 at 12:40 AM, Alex Williamson
wrote:
> On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
>> Some IOMMU drivers, such as the ARM SMMU driver, make available the
>> IOMMU_NOEXEC flag, to set the page tables for a device as XN (execute never).
>> This affects devices such
On Wed, Sep 24, 2014 at 12:30 AM, Alex Williamson
wrote:
> On Tue, 2014-09-23 at 16:21 -0600, Alex Williamson wrote:
>> On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
>> > We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
>> > and expose its availability via the
On Thu, Sep 25, 2014 at 02:50:29PM -0700, Andres Lagar-Cavilla wrote:
> It's nearly impossible to name it right because 1) it indicates we can
> relinquish 2) it returns whether we still hold the mmap semaphore.
>
> I'd prefer it'd be called mmap_sem_hold, which conveys immediately
> what this is
On Fri, Sep 26, 2014 at 10:25 AM, Andrea Arcangeli wrote:
> On Thu, Sep 25, 2014 at 02:50:29PM -0700, Andres Lagar-Cavilla wrote:
>> It's nearly impossible to name it right because 1) it indicates we can
>> relinquish 2) it returns whether we still hold the mmap semaphore.
>>
>> I'd prefer it'd be
On Fri, 2014-09-26 at 08:45 +0200, Frank Blaschka wrote:
> On Wed, Sep 24, 2014 at 10:05:57AM -0600, Alex Williamson wrote:
> > On Wed, 2014-09-24 at 10:47 +0200, Frank Blaschka wrote:
> > > On Mon, Sep 22, 2014 at 02:47:31PM -0600, Alex Williamson wrote:
> > > > On Fri, 2014-09-19 at 13:54 +0200,
On Fri, 2014-09-26 at 17:30 +0200, Antonios Motakis wrote:
> On Wed, Sep 24, 2014 at 1:01 AM, Alex Williamson
> wrote:
> >
> > On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
> > > Driver to bind to Linux platform devices, and callbacks to discover their
> > > resources to be used by th
On Fri, 2014-09-26 at 17:39 +0200, Antonios Motakis wrote:
> On Wed, Sep 24, 2014 at 12:40 AM, Alex Williamson
> wrote:
> > On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
> >> Some IOMMU drivers, such as the ARM SMMU driver, make available the
> >> IOMMU_NOEXEC flag, to set the page ta
On Thu, Sep 25, 2014 at 09:46:44PM -0600, Alex Williamson wrote:
>On Fri, 2014-09-26 at 13:19 +1000, Gavin Shan wrote:
>> On Wed, Sep 10, 2014 at 06:13:42PM +1000, Gavin Shan wrote:
>> >On Mon, May 19, 2014 at 01:01:10PM +1000, Gavin Shan wrote:
>> >>The MSIx vector table lives in device memory, wh
The MSIx vector table lives in device memory, which may be cleared as
part of a backdoor device reset. This is the case on the IBM IPR HBA
when the BIST is run on the device. When assigned to a QEMU guest,
the guest driver does a pci_save_state(), issues a BIST, then does a
pci_restore_state(). The
The patch exports 2 MSI message relevant functions, which will be
used by VFIO PCI driver. The VFIO PCI driver would be built as
a module.
Signed-off-by: Gavin Shan
Acked-by: Bjorn Helgaas
---
drivers/pci/msi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pc
The function should have been exported with EXPORT_SYMBOL_GPL()
as part of commit 92d18a68 ("drivers/vfio: Fix EEH build error").
Suggested-by: Alexey Kardashevskiy
Signed-off-by: Gavin Shan
---
drivers/vfio/vfio_spapr_eeh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
60 matches
Mail list logo
