On 06/05/2014 05:11 AM, Mario Smarduch wrote:
+ spin_lock(kvm-mmu_lock);
+
+ for (i = 0; i n / sizeof(long); i++) {
+ unsigned long mask;
+ gfn_t offset;
+
+ if (!dirty_bitmap[i])
+ continue;
+
+ is_dirty =
On 2014-06-04 23:17, Bandan Das wrote:
Verify that vmon fails with unaligned vmxon region or
any bits set beyong the physical address width. Also verify
failure with an invalid revision identifier.
Signed-off-by: Bandan Das b...@redhat.com
---
x86/vmx.c | 46
This adds a capability number for 64-bit TCE tables support.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 944cd21..e6972bf 100644
---
This adds a capability number for in-kernel support for VFIO on
SPAPR platform.
The capability will tell the user space whether in-kernel handlers of
H_PUT_TCE can handle VFIO-targeted requests or not. If not, the user space
must not attempt allocating a TCE table in the host kernel via
the
The existing KVM_CREATE_SPAPR_TCE only supports 32bit windows which is not
enough for directly mapped windows as the guest can get more than 4GB.
This adds KVM_CREATE_SPAPR_TCE_64 ioctl and advertises it
via KVM_CAP_SPAPR_TCE_64 capability.
Since 64bit windows are to support Dynamic DMA windows
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's tree
(correct?).
Thanks!
Alexey Kardashevskiy (3):
On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
+This creates a virtual TCE (translation control entry) table, which
+is an IOMMU for PAPR-style virtual I/O. It is used to translate
+logical addresses used in virtual I/O into guest physical addresses,
+and provides a
Marc,
On Wed, Jun 4, 2014 at 5:20 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On Wed, Jun 04 2014 at 7:19:42 am BST, Lei Wen adrian.w...@gmail.com wrote:
On Tue, Jun 3, 2014 at 5:11 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On Tue, Jun 03 2014 at 3:14:33 am BST, Lei Wen
On 06/05/2014 05:38 PM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
+This creates a virtual TCE (translation control entry) table, which
+is an IOMMU for PAPR-style virtual I/O. It is used to translate
+logical addresses used in virtual I/O
On Mon, Jun 02, 2014 at 09:29:56AM +0200, Eric Auger wrote:
This patch enables irqfd and irq routing on ARM.
It turns on CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQ_ROUTING
irqfd framework enables to assign physical IRQs to guests.
1) user-side uses KVM_IRQFD VM ioctl to pass KVM a
On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
No trees yet. For 64GB window we need (6430)/(1620)*8 = 32K TCE table.
Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
indeed. But we need to deal with 4k and 64k guests.
Il 05/06/2014 09:00, Jan Kiszka ha scritto:
+ rflags = read_rflags() | X86_EFLAGS_CF | X86_EFLAGS_ZF;
+ write_rflags(rflags);
+ ret1 = vmx_on();
Can we ensure that the compiler doesn't inject any ops between
write_rflags and the vmxon that overwrite CF or ZF?
No, in fact if vmx_on were
On Mon, Jun 02, 2014 at 04:42:36PM +0200, Eric Auger wrote:
On 06/02/2014 03:54 PM, Marc Zyngier wrote:
Hi Eric,
On Mon, Jun 02 2014 at 8:29:56 am BST, Eric Auger eric.au...@linaro.org
wrote:
[...]
@@ -408,11 +411,27 @@ static bool handle_mmio_clear_pending_reg(struct
kvm_vcpu
commit 2ae76693b8bcabf370b981cd00c36cd41d33fabc
vhost: replace rcu with mutex
replaced rcu sync for memory accesses with VQ mutex locl/unlock.
This is correct since all accesses are under VQ mutex, but incomplete:
we still do useless rcu lock/unlock operations, someone might copy this
code
On Wed, Jun 04, 2014 at 10:51:12PM +0300, Michael S. Tsirkin wrote:
On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote:
On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote:
Il 02/06/2014 23:58, Eric Dumazet ha scritto:
This looks dubious
What about using kfree_rcu()
Refactor code to make sure features are only accessed
under VQ mutex. This makes everything simpler, no need
for RCU here anymore.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
This is on top of the recent pull request that I sent.
drivers/vhost/vhost.h | 11 +++
On Wed, Jun 04, 2014 at 03:47:54PM +0200, Eric Auger wrote:
Currently when a KVM region is deleted or moved after
KVM_SET_USER_MEMORY_REGION ioctl, the corresponding
intermediate physical memory is not unmapped.
This patch corrects this and unmaps the region's IPA range
in
On 05.06.14 12:27, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
No trees yet. For 64GB window we need (6430)/(1620)*8 = 32K TCE table.
Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c
This patchset adds support for emulating VTB, IC and Doorbell features in P8.
Doorbell support is dummy since we don't support SMT cores with PR-KVM.
-aneesh
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h | 1 +
Since we don't support SMT yet, we should always find zero in
Directed privileged doorbell exception state register.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Writing to IC is not allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/book3s.c | 6 ++
arch/powerpc/kvm/book3s_emulate.c | 3 +++
arch/powerpc/kvm/book3s_hv.c| 6
On Thu, Jun 05, 2014 at 01:44:14PM +0300, Michael S. Tsirkin wrote:
Refactor code to make sure features are only accessed
under VQ mutex. This makes everything simpler, no need
for RCU here anymore.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Ouch, I sent out wrong version of the
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
commit 2ae76693b8bcabf370b981cd00c36cd41d33fabc
vhost: replace rcu with mutex
replaced rcu sync for memory accesses with VQ mutex locl/unlock.
This is correct since all accesses are under VQ mutex, but incomplete:
we still do useless rcu lock/unlock operations, someone might copy this
code
Refactor code to make sure features are only accessed
under VQ mutex. This makes everything simpler, no need
for RCU here anymore.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Note: this is on top of my last pull request
drivers/vhost/vhost.h | 11 +++
drivers/vhost/net.c |
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insertions(+)
On 05.06.14 14:21, Alexander Graf wrote:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 18
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE modifications, but would have some
nicely swappable
On 05.06.14 14:30, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE
On 06/05/2014 10:30 PM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE
On 06/05/2014 12:28 PM, Christoffer Dall wrote:
On Mon, Jun 02, 2014 at 09:29:56AM +0200, Eric Auger wrote:
This patch enables irqfd and irq routing on ARM.
It turns on CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQ_ROUTING
irqfd framework enables to assign physical IRQs to guests.
1)
On Wed, Jun 04, 2014 at 10:44:48PM +0200, Borislav Petkov wrote:
On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote:
That should be the purpose of KVM_GET_EMULATED_CPUID, so MWAIT could be
added in __do_cpuid_ent_emulated. However, the corresponding QEMU patches
were never
On Thu, Jun 05, 2014 at 03:15:15PM +0200, Eric Auger wrote:
On 06/05/2014 12:28 PM, Christoffer Dall wrote:
On Mon, Jun 02, 2014 at 09:29:56AM +0200, Eric Auger wrote:
This patch enables irqfd and irq routing on ARM.
It turns on CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQ_ROUTING
Il 02/06/2014 17:34, Nadav Amit ha scritto:
In 64-bit mode, when the destination is a register, the assignment is done
according to the operand size. Otherwise (memory operand or no 64-bit mode), a
16-bit assignment is performed.
I'm sorry, I'm missing the place where 64-bit mode is taken into
On Jun 5, 2014, at 5:53 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 02/06/2014 17:34, Nadav Amit ha scritto:
In 64-bit mode, when the destination is a register, the assignment is done
according to the operand size. Otherwise (memory operand or no 64-bit mode),
a
16-bit assignment is
On 06/05/2014 08:02 AM, Nadav Amit wrote:
I'm sorry, I'm missing the place where 64-bit mode is taken into account?
It is not, since on 32-bit mode the high-order 16 bits of a register
destination are undefined.
If I recall correctly, in this case the high-order 16-bits on native
system
Il 05/06/2014 17:04, H. Peter Anvin ha scritto:
On 06/05/2014 08:02 AM, Nadav Amit wrote:
I'm sorry, I'm missing the place where 64-bit mode is taken into account?
It is not, since on 32-bit mode the high-order 16 bits of a register
destination are undefined.
If I recall correctly, in this
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:21, Alexander Graf wrote:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
On 06/05/2014 04:39 PM, Christoffer Dall wrote:
On Thu, Jun 05, 2014 at 03:15:15PM +0200, Eric Auger wrote:
On 06/05/2014 12:28 PM, Christoffer Dall wrote:
On Mon, Jun 02, 2014 at 09:29:56AM +0200, Eric Auger wrote:
This patch enables irqfd and irq routing on ARM.
It turns on
On Thu, Jun 05, 2014 at 05:58:02PM +0200, Eric Auger wrote:
On 06/05/2014 04:39 PM, Christoffer Dall wrote:
On Thu, Jun 05, 2014 at 03:15:15PM +0200, Eric Auger wrote:
On 06/05/2014 12:28 PM, Christoffer Dall wrote:
On Mon, Jun 02, 2014 at 09:29:56AM +0200, Eric Auger wrote:
This patch
This implements GET_SUPPORTED_CPUID support using an explicit option for it:
allow-emulation. We don't want any emulated feature to be enabled by accident,
so they will be enabled only if the user explicitly wants to allow them.
References to previous patch and discussions:
Message-Id:
On 05.06.14 18:12, Eduardo Habkost wrote:
This implements GET_SUPPORTED_CPUID support using an explicit option for it:
allow-emulation. We don't want any emulated feature to be enabled by accident,
so they will be enabled only if the user explicitly wants to allow them.
So is this an
Il 05/06/2014 18:24, Alexander Graf ha scritto:
On 05.06.14 18:12, Eduardo Habkost wrote:
This implements GET_SUPPORTED_CPUID support using an explicit option
for it:
allow-emulation. We don't want any emulated feature to be enabled by
accident,
so they will be enabled only if the user
On 05.06.14 18:26, Paolo Bonzini wrote:
Il 05/06/2014 18:24, Alexander Graf ha scritto:
On 05.06.14 18:12, Eduardo Habkost wrote:
This implements GET_SUPPORTED_CPUID support using an explicit option
for it:
allow-emulation. We don't want any emulated feature to be enabled by
accident,
so
Il 05/06/2014 18:40, Alexander Graf ha scritto:
kvm_set_cpuid(cpuid);
but enabling all experimental features inside KVM just because we want
one or two of them is very counter-intuitive. Imagine we'd introduce
emulation support for AVX. Suddenly allow-emulation (which I'd need for
Mac OS X
On 05.06.14 18:44, Paolo Bonzini wrote:
Il 05/06/2014 18:40, Alexander Graf ha scritto:
kvm_set_cpuid(cpuid);
but enabling all experimental features inside KVM just because we want
one or two of them is very counter-intuitive. Imagine we'd introduce
emulation support for AVX. Suddenly
Il 05/06/2014 18:45, Alexander Graf ha scritto:
Only if you were using -cpu somethingThatHasAVX, though, no?
Yes. The same argument goes the other way around. I want to use AVX
emulation, do allow-emulation and suddenly I get MONITOR/MWAIT emulation.
What about:
- letting -cpu
On 05.06.14 18:52, Paolo Bonzini wrote:
Il 05/06/2014 18:45, Alexander Graf ha scritto:
Only if you were using -cpu somethingThatHasAVX, though, no?
Yes. The same argument goes the other way around. I want to use AVX
emulation, do allow-emulation and suddenly I get MONITOR/MWAIT
On 05.06.14 18:52, Paolo Bonzini wrote:
Il 05/06/2014 18:45, Alexander Graf ha scritto:
Only if you were using -cpu somethingThatHasAVX, though, no?
Yes. The same argument goes the other way around. I want to use AVX
emulation, do allow-emulation and suddenly I get MONITOR/MWAIT
Il 05/06/2014 18:54, Alexander Graf ha scritto:
What about:
- letting -cpu foo,+emulatedfeature just work
- adding emulated=yes that blindly enables all emulated features
- making -cpu ...,check prints a warning for emulated features
unless emulated=yes
How about we remove the emulated=yes
Paolo Bonzini pbonz...@redhat.com writes:
Il 03/06/2014 09:02, Michal Nazarewicz ha scritto:
On Tue, Jun 03 2014, Joonsoo Kim wrote:
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Signed-off-by: Joonsoo Kim
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
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.
The effort on VFIO_PLATFORM has been partially conducted under the SAVE FP7
project.
From: Kim Phillips kim.phill...@freescale.com
Needed by platform device drivers, such as the upcoming
vfio-platform driver, in order to bypass the existing OF, ACPI,
id_table and name string matches, and successfully be able to be
bound to any device, like so:
echo vfio-platform
Allow to memory map the MMIO regions of the device so userspace can
directly access them.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/vfio/platform/vfio_platform.c | 40 ++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff
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
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 a.mota...@virtualopensystems.com
---
drivers/vfio/platform/vfio_platform_irq.c | 86 ++-
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
many different VFIO bus drivers.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/vfio/pci/vfio_pci.c | 8
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.
Signed-off-by: Antonios Motakis
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 a.mota...@virtualopensystems.com
---
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 a.mota...@virtualopensystems.com
---
drivers/vfio/platform/vfio_platform.c | 36 ++-
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 a.mota...@virtualopensystems.com
---
drivers/vfio/platform/Makefile| 2 +-
Sharing the same spinlock with the VFIO bus driver is not necessary for
the virqfd code, so remove that dependency.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
drivers/vfio/virqfd.c | 24
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.
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 IOCTLs:
- VFIO_DEVICE_GET_INFO
-
This patch forms the skeleton for platform devices support with VFIO.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/platform/Kconfig |
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
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 a.mota...@virtualopensystems.com
---
drivers/vfio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1
With an ARM SMMU, interrupt remapping should always be safe from the
SMMU's point of view, as it is properly handled by the GIC.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The ARM SMMU supports the IOMMU_NOEXEC protection flag. Add the
corresponding IOMMU capability.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
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
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 a.mota...@virtualopensystems.com
---
include/linux/iommu.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
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 a.mota...@virtualopensystems.com
---
drivers/iommu/arm-smmu.c | 2 +-
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
On Thu, Jun 05, 2014 at 06:45:16PM +0200, Alexander Graf wrote:
On 05.06.14 18:44, Paolo Bonzini wrote:
Il 05/06/2014 18:40, Alexander Graf ha scritto:
kvm_set_cpuid(cpuid);
but enabling all experimental features inside KVM just because we want
one or two of them is very
On Thu, Jun 05, 2014 at 06:57:57PM +0200, Paolo Bonzini wrote:
Il 05/06/2014 18:54, Alexander Graf ha scritto:
What about:
- letting -cpu foo,+emulatedfeature just work
- adding emulated=yes that blindly enables all emulated features
- making -cpu ...,check prints a warning for
Alexander Graf ag...@suse.de writes:
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB
On Thu, Jun 05, 2014 at 06:40:25PM +0200, Alexander Graf wrote:
On 05.06.14 18:26, Paolo Bonzini wrote:
Il 05/06/2014 18:24, Alexander Graf ha scritto:
On 05.06.14 18:12, Eduardo Habkost wrote:
This implements GET_SUPPORTED_CPUID support using an explicit option
for it:
allow-emulation.
Il 05/06/2014 19:17, Eduardo Habkost ha scritto:
If you don't want MONITOR/MWAIT you shouldn't be using a CPU model
containing MONITOR/MWAIT in the first place. If you use -cpu
somethingWithMONITOR, that means you are already asking QEMU for a CPU
with MONITOR. If you were not getting
Il 05/06/2014 19:19, Eduardo Habkost ha scritto:
On Thu, Jun 05, 2014 at 06:57:57PM +0200, Paolo Bonzini wrote:
Il 05/06/2014 18:54, Alexander Graf ha scritto:
What about:
- letting -cpu foo,+emulatedfeature just work
- adding emulated=yes that blindly enables all emulated features
-
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on
On Thu, Jun 05, 2014 at 06:58:17PM +0200, Alexander Graf wrote:
On 05.06.14 18:52, Paolo Bonzini wrote:
Il 05/06/2014 18:45, Alexander Graf ha scritto:
Only if you were using -cpu somethingThatHasAVX, though, no?
Yes. The same argument goes the other way around. I want to use AVX
On Thu, Jun 05, 2014 at 07:38:49PM +0200, Paolo Bonzini wrote:
Il 05/06/2014 19:17, Eduardo Habkost ha scritto:
If you don't want MONITOR/MWAIT you shouldn't be using a CPU model
containing MONITOR/MWAIT in the first place. If you use -cpu
somethingWithMONITOR, that means you are already
On Thu, Jun 05, 2014 at 07:39:42PM +0200, Paolo Bonzini wrote:
Il 05/06/2014 19:19, Eduardo Habkost ha scritto:
On Thu, Jun 05, 2014 at 06:57:57PM +0200, Paolo Bonzini wrote:
Il 05/06/2014 18:54, Alexander Graf ha scritto:
What about:
- letting -cpu foo,+emulatedfeature just work
-
Sorry for following the discussion backwards, but I see now that you
started with a proposal that would cover both cases (the one you care
about, and the one I care about), make both of us happy, but it was lost
in favour of other suggestions I disagreed with:
On Thu, Jun 05, 2014 at 06:24:22PM
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Antonios Motakis
Sent: Thursday, June 05, 2014 10:33 PM
To: alex.william...@redhat.com; kvm...@lists.cs.columbia.edu;
io...@lists.linux-foundation.org
On 06/04/2014 11:55 PM, Xiao Guangrong wrote:
On 06/05/2014 05:11 AM, Mario Smarduch wrote:
+spin_lock(kvm-mmu_lock);
+
+for (i = 0; i n / sizeof(long); i++) {
+unsigned long mask;
+gfn_t offset;
+
+if (!dirty_bitmap[i])
+
Sorry for replying to my own message, but I believe we can now summarize
a possible solution that makes everybody happy, and the plans for it:
On Thu, Jun 05, 2014 at 03:02:53PM -0300, Eduardo Habkost wrote:
On Thu, Jun 05, 2014 at 07:39:42PM +0200, Paolo Bonzini wrote:
Il 05/06/2014 19:19,
On Thu, Jun 05, 2014 at 04:12:08PM -0300, Eduardo Habkost wrote:
In the meantime, we could:
* Include the less fine-tuned allow-emulation (or
allow-experimental-features) option, which is implemented by this
series, for people who use enforce and/or don't care too much about
On 06/05/2014 01:24 PM, Borislav Petkov wrote:
On Thu, Jun 05, 2014 at 04:12:08PM -0300, Eduardo Habkost wrote:
In the meantime, we could:
* Include the less fine-tuned allow-emulation (or
allow-experimental-features) option, which is implemented by this
series, for people who use
On Thu, Jun 05, 2014 at 01:45:06PM -0600, Eric Blake wrote:
On 06/05/2014 01:24 PM, Borislav Petkov wrote:
On Thu, Jun 05, 2014 at 04:12:08PM -0300, Eduardo Habkost wrote:
In the meantime, we could:
* Include the less fine-tuned allow-emulation (or
allow-experimental-features)
The new option will allow slow emulated features (the ones returned by
GET_EMULATED_CPUID) to be enabled. We don't want to allow them to be
enabled by accident, so they will be enabled only if emulation is
explicitly allowed by the user.
Use x- prefix on the property name, to document that it is
On Thu, 2014-06-05 at 19:03 +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 a.mota...@virtualopensystems.com
---
include/linux/iommu.h | 5 +++--
On Thu, 2014-06-05 at 19:03 +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 and
On Wed, May 7, 2014 at 1:52 PM, Gabriel L. Somlo gso...@gmail.com wrote:
Treat monitor and mwait instructions as nop, which is architecturally
correct (but inefficient) behavior. We do this to prevent misbehaving
guests (e.g. OS X = 10.7) from crashing after they fail to check for
On Thu, 2014-06-05 at 19:03 +0200, Antonios Motakis wrote:
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.
On Thu, Jun 05, 2014 at 01:59:17PM -0700, Eric Northup wrote:
On Wed, May 7, 2014 at 1:52 PM, Gabriel L. Somlo gso...@gmail.com wrote:
Treat monitor and mwait instructions as nop, which is architecturally
correct (but inefficient) behavior. We do this to prevent misbehaving
guests (e.g. OS
1 - 100 of 157 matches
Mail list logo
