Commit 346874c9507a ("KVM: x86: Fix CR3 reserved bits") removed non-PAE
reserved bits which were not according to Intel SDM. However, residue was left
in a debug assertion (CR3_NONPAE_RESERVED_BITS). Remove it.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/paging_tmpl.h | 3 +--
1 file changed, 1
Il 22/09/2014 23:54, Andres Lagar-Cavilla ha scritto:
> @@ -1406,32 +1406,24 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned
> long *rmapp,
> struct rmap_iterator uninitialized_var(iter);
> int young = 0;
>
> - /*
> - * In case of absence of EPT Access and Dirty Bits s
Il 22/09/2014 21:43, Borislav Petkov ha scritto:
>> > On x86_64, kernel text mappings are mapped read-only with
>> > CONFIG_DEBUG_RODATA.
> Hmm, that depends on DEBUG_KERNEL.
>
> I think you're actually talking about distro kernels which enable
> CONFIG_DEBUG_RODATA, right?
This is for guest ker
Il 23/09/2014 09:01, Nadav Amit ha scritto:
> Commit 346874c9507a ("KVM: x86: Fix CR3 reserved bits") removed non-PAE
> reserved bits which were not according to Intel SDM. However, residue was
> left
> in a debug assertion (CR3_NONPAE_RESERVED_BITS). Remove it.
>
> Signed-off-by: Nadav Amit
>
Il 23/09/2014 04:44, Chen Yucong ha scritto:
> Avoid open coded calculations for bank MSRs by using well-defined
> macros that hide the index of higher bank MSRs.
>
> No semantic changes.
>
> Signed-off-by: Chen Yucong
> ---
> arch/x86/kvm/x86.c |8
> 1 file changed, 4 insertions(+
On 09/23/2014 08:49 AM, Gleb Natapov wrote:
> On Mon, Sep 22, 2014 at 09:29:19PM +0200, Paolo Bonzini wrote:
>> Il 22/09/2014 21:20, Christian Borntraeger ha scritto:
>>> "while using trinity to fuzz KVM, we noticed long stalls on invalid ioctls.
>>> Lets bail out early on invalid ioctls". or simi
kvm_get_xtime_nsec could overflow. If we make kvm_get_boot_base_ns
compute the equivalent of 3.17's base_mono+offs_boot formula (instead of
just offs_boot), we can avoid that and drop kvm_get_xtime_nsec altogether.
Signed-off-by: Paolo Bonzini
---
external-module-compat-comm.h | 3 +--
externa
Il 23/09/2014 10:06, Christian Borntraeger ha scritto:
> Yes. Davids explanation also makes sense as a commit message. Paolo,
> if you use David patch with a better description of the "why" I am
> fine with this patch.
Done, thanks everybody!
Paolo
--
To unsubscribe from this list: send the line
On Tue, Sep 23, 2014 at 10:00:12AM +0200, Paolo Bonzini wrote:
> Il 22/09/2014 21:43, Borislav Petkov ha scritto:
> >> > On x86_64, kernel text mappings are mapped read-only with
> >> > CONFIG_DEBUG_RODATA.
> > Hmm, that depends on DEBUG_KERNEL.
> >
> > I think you're actually talking about distr
On 23.09.14 00:28, Alex Williamson wrote:
> On Tue, 2014-09-23 at 00:08 +0200, Alexander Graf wrote:
>>
>> On 22.09.14 22:47, Alex Williamson wrote:
>>> On Fri, 2014-09-19 at 13:54 +0200, frank.blasc...@de.ibm.com wrote:
This set of patches implements a vfio based solution for pci
pass-
Il 22/09/2014 23:33, Christoffer Dall ha scritto:
> Commit "c77dcac KVM: Move more code under CONFIG_HAVE_KVM_IRQFD" added
> functionality that depends on definitions in ioapic.h when
> __KVM_HAVE_IOAPIC is defined.
>
> At the same time, "0ba0951 KVM: EVENTFD: remove inclusion of irq.h"
> removed
Your security is very important to us. Please take a moment to read this
information.
We have made some changes to our Online Banking system to increase security on
your account, and to safeguard your transactions, ensuring that you are safe
when banking online.
We recommend you to update y
Linus,
The following changes since commit f3670394c29ff3730638762c1760fd2f624e6d7b:
Revert "x86/efi: Fixup GOT in all boot code paths" (2014-09-22 23:05:49 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes u
This patch series aims to implement VFIO support for platform devices that
reside behind an IOMMU. Examples of such devices are devices behind an ARM
SMMU, or behind a Samsung Exynos System MMU.
This version of the patch series introduces numerous fixes and cleanups based
on the feedback received
Allow to memory map the MMIO regions of the device so userspace can
directly access them.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/platform/vfio_p
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
---
drivers/vfio/platform/vfio_platform.c | 96 +++
include/uapi/linux/vfio.h | 1 +
2 files
Now we have finally completely decoupled virqfd from VFIO_PCI. We can
initialize it from the VFIO generic code, in order to safely use it from
multiple independent VFIO bus drivers.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci.c | 8
drivers/vfio/vfio.c | 8
Virqfd just needs to keep accesses to any struct *virqfd safe, but this
comes into play only when creating or destroying eventfds, so sharing
the same spinlock with the VFIO bus driver is not necessary.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
driver
The virqfd functionality that is used by VFIO_PCI to implement interrupt
masking and unmasking via an eventfd, is generic enough and can be reused
by another driver. Move it to a separate file in order to allow the code
to be shared.
Also properly export virqfd_enable and virqfd_disable in the pro
VFIO_PCI passes the VFIO device structure *vdev via eventfd to the handler
that implements masking/unmasking of IRQs via an eventfd. We can replace
it in the virqfd infrastructure with an opaque type so we can make use
of the mechanism from other VFIO bus drivers.
Signed-off-by: Antonios Motakis
With this patch the VFIO user will be able to set an eventfd that can be
used in order to mask and unmask IRQs of platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 48 +--
drivers/vfio/platform/vfio_platform_private.h |
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 Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 89 ++-
drivers/vfio/platform/vfio_platform_priv
Adds support to mask interrupts, and also for automasked interrupts.
Level sensitive interrupts are exposed as automasked interrupts and
are masked and disabled automatically when they fire.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 120 +
This patch is a skeleton for the VFIO_DEVICE_SET_IRQS IOCTL, around which
most IRQ functionality is implemented in VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 41 ++--
drivers/vfio/platform/vfio_platform_irq.c | 56 +++
Hi Antonios,
On Tue, Sep 23, 2014 at 03:46:00PM +0100, Antonios Motakis wrote:
> Exposing the XN flag of the SMMU driver as IOMMU_NOEXEC instead of
> IOMMU_EXEC makes it enforceable, since for IOMMUs that don't support
> the XN flag pages will always be executable.
>
> Signed-off-by: Antonios Mot
VFIO returns a file descriptor which we can use to manipulate the memory
regions of the device. Usually, the user will mmap memory regions that are
addressable on page boundaries, however for memory regions where this is
not the case we cannot provide mmap functionality due to security concerns.
Fo
A VFIO userspace driver will start by opening the VFIO device
that corresponds to an IOMMU group, and will use the ioctl interface
to get the basic device info, such as number of memory regions and
interrupts, and their properties. This patch enables the
VFIO_DEVICE_GET_INFO ioctl call.
Signed-off
This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
which allows the user to learn about the available MMIO resources of
a device.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 84 +--
drivers/vfio/platform/vfio_plat
Return information for the interrupts exposed by the device.
This patch extends VFIO_DEVICE_GET_INFO with the number of IRQs
and enables VFIO_DEVICE_GET_IRQ_INFO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/Makefile| 2 +-
drivers/vfio/platform/vfio_platform_common
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 whose resources are discovered via AMBA specific APIs
in the kernel.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platfo
This patch forms the common skeleton code for platform devices support
with VFIO. This will include the core functionality of VFIO_PLATFORM,
however binding to the device and discovering the device resources will
be done with the help of a separate file where any Linux platform bus
specific code wi
Enable building the VFIO PLATFORM driver that allows to use Linux platform
devices with VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/platform/Kconfig | 9 +
drivers/vfio/platform/Makefile | 4
4 f
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_amba.c | 108 ++
include/uapi/linux/vfio.h | 1 +
2 files changed, 109 insertions(+
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_IOMMU_PROT_NOEXEC.
This way the user can control whether the XN flag will be set on the
requested mappings. The IOMMU_NOEXEC flag needs to be available for all
the IOMMUs of
Add documentation for alternative binding path 'driver_override' for
AMBA devices.
Signed-off-by: Antonios Motakis
---
Documentation/ABI/testing/sysfs-bus-amba | 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-amba
diff --git a/D
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 as the ARM PL330 DMA Controller, which respects
this flag and will refuse to fetch DMA instructions from memory where the
XN fl
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 requested by the user.
[1]
http://lists-archives.com/linux-kernel/28030441-pci
This allows to make use of the VFIO_IOMMU_TYPE1 driver with platform
devices on ARM. The driver can then be used with an Exynos SMMU, or
ARM SMMU driver.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/Kcon
The ARM SMMU supports the IOMMU_NOEXEC protection flag. Add the
corresponding IOMMU capability.
Signed-off-by: Antonios Motakis
---
drivers/iommu/arm-smmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c7cbdda..7c0fa25 100644
---
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 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e1a6
Exposing the XN flag of the SMMU driver as IOMMU_NOEXEC instead of
IOMMU_EXEC makes it enforceable, since for IOMMUs that don't support
the XN flag pages will always be executable.
Signed-off-by: Antonios Motakis
---
drivers/iommu/arm-smmu.c | 9 +
include/linux/iommu.h| 2 +-
2 file
On Mon, Sep 08, 2014 at 12:49:48PM +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 08, 2014 at 11:17:50AM +0200, David Marchand wrote:
> > Send a protocol version as the first message from server, clients must close
> > communication if they don't support this protocol version.
>
> What's the motiv
On Tue, Sep 23, 2014 at 12:49 AM, Paolo Bonzini wrote:
> Il 22/09/2014 23:54, Andres Lagar-Cavilla ha scritto:
>> @@ -1406,32 +1406,24 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned
>> long *rmapp,
>> struct rmap_iterator uninitialized_var(iter);
>> int young = 0;
>>
>> - /
Il 23/09/2014 19:04, Andres Lagar-Cavilla ha scritto:
> I'm not sure. The addition is not always by PAGE_SIZE, since it
> depends on the current level we are iterating at in the outer
> kvm_handle_hva_range(). IOW, could be PMD_SIZE or even PUD_SIZE, and
> is_large_pte() enough to tell?
>
> This i
After "kvm: Fix page ageing bugs"
Signed-off-by: Andres Lagar-Cavilla
---
arch/powerpc/include/asm/kvm_ppc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index fb86a22..d4a92d7 100644
--- a/arch/power
On Tue, Sep 23, 2014 at 10:58 AM, Andres Lagar-Cavilla
wrote:
> After "kvm: Fix page ageing bugs"
>
> Signed-off-by: Andres Lagar-Cavilla
I can resend without the 1/2 (git n00b growing pains). Otherwise that
should fix the kbuild error. Apologies for that.
Andres
> ---
> arch/powerpc/include/a
Il 23/09/2014 20:03, Andres Lagar-Cavilla ha scritto:
> I can resend without the 1/2 (git n00b growing pains). Otherwise that
> should fix the kbuild error. Apologies for that.
No problem, kvm/queue is there for this reason. It can be rebased, so
I'll just squash this into the patch.
Paolo
--
To
I have a couple of SATA disks (software RAID on some partitions) with a system
that has become unreliable on them. I plan to add more disks and install a new
system on them (Debian wheezy). I will still need to run things on the old OS
(simultaneously running the new OS) to migrate.
Is there
Will,
Your commit 80ce1639727e ("KVM: VFIO: register kvm_device_ops
dynamically") is included in linux-next since next-20140918. It removes
the last usage of CONFIG_KVM_VFIO. After that commit setting KVM_VFIO is
pointless.
Is the patch to remove the Kconfig symbol KVM_VFIO from the tree queued
s
Callbacks don't have to do extra computation to learn what the caller
(lvm_handle_hva_range()) knows very well. Useful for
debugging/tracing/printk/future.
Signed-off-by: Andres Lagar-Cavilla
---
arch/x86/kvm/mmu.c | 38 ++
include/trace/events/kvm.h |
Il 23/09/2014 21:34, Andres Lagar-Cavilla ha scritto:
> Callbacks don't have to do extra computation to learn what the caller
> (lvm_handle_hva_range()) knows very well. Useful for
> debugging/tracing/printk/future.
>
> Signed-off-by: Andres Lagar-Cavilla
> ---
> arch/x86/kvm/mmu.c | 38
Il 23/09/2014 21:09, Paul Bolle ha scritto:
> Will,
>
> Your commit 80ce1639727e ("KVM: VFIO: register kvm_device_ops
> dynamically") is included in linux-next since next-20140918. It removes
> the last usage of CONFIG_KVM_VFIO. After that commit setting KVM_VFIO is
> pointless.
>
> Is the patch
On Tue, 2014-09-23 at 13:00 +1000, Alexey Kardashevskiy wrote:
> Modern IBM POWERPC systems support multiple IOMMU tables per PE
> so we need a more reliable way (compared to container_of()) to get
> a PE pointer from the iommu_table struct pointer used in IOMMU functions.
>
> At the moment IOMMU
On Sunday 21 September 2014 13:21:06, Michael S. Tsirkin wrote:
> On Sun, Sep 21, 2014 at 11:36:44AM +0200, Stefan Fritsch wrote:
> > On Sunday 21 September 2014 11:09:14, Michael S. Tsirkin wrote:
> > > On Thu, Sep 18, 2014 at 09:18:37PM +0200, Stefan Fritsch wrote:
> > > > On Monday 01 September
On Tue, 2014-09-23 at 13:00 +1000, Alexey Kardashevskiy wrote:
> At the moment the iommu_table struct has a set_bypass() which enables/
> disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
> which calls this callback when external IOMMU users such as VFIO are
> about to get ove
On Tue, 2014-09-23 at 13:01 +1000, Alexey Kardashevskiy wrote:
> This defines and implements VFIO IOMMU API which lets the userspace
> create and remove DMA windows.
>
> This updates VFIO_IOMMU_SPAPR_TCE_GET_INFO to return the number of
> available windows and page mask.
>
> This adds VFIO_IOMMU_
On Tue, 2014-09-23 at 15:58 +0100, Will Deacon wrote:
> Hi Antonios,
>
> On Tue, Sep 23, 2014 at 03:46:00PM +0100, Antonios Motakis wrote:
> > Exposing the XN flag of the SMMU driver as IOMMU_NOEXEC instead of
> > IOMMU_EXEC makes it enforceable, since for IOMMUs that don't support
> > the XN flag
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 capability VFIO_IOMMU_PROT_NOEXEC.
> This way the user can control whether the XN flag will be set on the
> requested mappings.
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 capability VFIO_IOMMU_PROT_NOEXEC.
> > This way the user can co
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 as the ARM PL330 DMA Controller, which respects
> this flag an
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 matching
> of a device to a AMBA driver. This can be used by VFIO to bind to any AMBA
> device requested by
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
> ---
> drivers/vfio/platform/vfio_platform.c | 96
>
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 whose resources are discovered via AMBA specific APIs
> in the
Hi Paolo,
I'm not sure if this patch is following your comment. Please review.
And all the other comments are followed. If this patch is OK, I'll
send v8 soon.
Thanks.
We are handling "L1 and L2 share one apic access page" situation when migrating
apic access page. We should do some handling w
Hi Andres,
On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote:
>1. We were calling clear_flush_young_notify in unmap_one, but we are
>within an mmu notifier invalidate range scope. The spte exists no more
>(due to range_start) and the accessed bit info has already been
>propagated
65 matches
Mail list logo