On 06/06/2014 03:09 AM, Mario Smarduch wrote:
> 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 offse
Hi, all
I ran two linux guest on the same kvm host, then start the netserver on one vm,
start netperf on the other one, netperf command and test result shown as below,
netperf -H 196.5.5.71 -t TCP_STREAM -l 60 -- -m 1400 -M 1400
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 1
On Fri, Jun 06, 2014 at 03:21:04AM +0200, Borislav Petkov wrote:
> On Fri, Jun 06, 2014 at 12:24:26AM +0200, Alexander Graf wrote:
> > But can we drop the EMULATED name somehow? Can we rename [1] the ioctl
> > to say GET_UNSUPPORTED_CPUID or something along those lines? The name
> > is just a reall
On Fri, Jun 06, 2014 at 12:24:26AM +0200, Alexander Graf wrote:
> But can we drop the EMULATED name somehow? Can we rename [1] the ioctl
> to say GET_UNSUPPORTED_CPUID or something along those lines? The name
> is just a really really bad pick.
What do you mean, a "bad pick" :-P? I added extra car
On 06/05/2014 09:57 PM, Alexander Graf wrote:
>
> 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 s
The current realmode tests always report success when done, regardless to
whether any of the tests failed. Although the log includes the individual test
results, this behavior complicates the life of the tester.
Signed-off-by: Nadav Amit
---
x86/realmode.c | 6 +-
1 file changed, 5 insertio
An additional test case for the emulator was added to test smsw which is
trapped by the emulator. The other existing test-cases occur in the guest (at
least on VMX), since the values are read directly from the CR0 read shadow.
Signed-off-by: Nadav Amit
---
x86/emulator.c | 10 --
1 file
This patch set adds two tests for smsw. The first one is intended to add
coverage of smsw. It covers the case smsw is executed with memory operand in a
page which is write-protected by the hypervisor. Note that the existing smsw
tests are not supposed to be trapped by the hypervisor. This test was
The smsw instruction has an undocumented behavior, in which the high-order
16-bits of CR0 are also saved in a 32-bit destination register. This is
similar to the way smsw behaves in long-mode. However, it is hard to test the
long-mode case, since we need to cause an "invalid guest state" in long-m
On 06.06.14 00:32, Alexander Graf wrote:
On 05.06.14 19:33, Aneesh Kumar K.V wrote:
Alexander Graf writes:
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf 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
On 05.06.14 19:33, Aneesh Kumar K.V wrote:
Alexander Graf writes:
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf 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
On 05.06.14 21:57, Eduardo Habkost wrote:
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 05.06.14 19:48, Eduardo Habkost wrote:
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 oth
On Thu, 2014-06-05 at 19:03 +0200, Antonios Motakis wrote:
> Sharing the same spinlock with the VFIO bus driver is not necessary for
> the virqfd code, so remove that dependency.
I like the idea of consolidating this code, but I need more
justification for why the use of the lock here is independe
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 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)
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 Wed, May 7, 2014 at 1:52 PM, Gabriel L. Somlo 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
> monitor/mwait availabili
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 an
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
> ---
> include/linux/iommu.h | 5 +++--
> 1 file changed, 3 insert
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, 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-experimenta
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 peop
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
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 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])
>> +
> -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.
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 +0
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,+emulated
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 a
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.
Joonsoo Kim 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 bitmap management. Kv
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
- maki
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
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:
>
Alexander Graf writes:
> On 05.06.14 17:50, Aneesh Kumar K.V wrote:
>> Alexander Graf 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
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"
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 the
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
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 | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/iommu.h b/include/lin
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 | 2 +-
include/linux/iommu.h| 2 +-
2 files chang
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 d5a2200..15ab2af 100644
---
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
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iom
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
This patch forms the skeleton for platform devices support with VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/platform/Kconfig | 9 ++
drivers/vfio/platform/Ma
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 IOCTLs:
- VFIO_DEVICE_GET_INFO
- VFIO_DEV
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 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.c | 36 ++-
drivers/vfio/platform/vfio_platform_irq.c | 130 +++
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
---
drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
drivers/vfio/virqfd.c | 24 +---
include/linux/vfio.h
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 | 112 +
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.c
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
---
drivers/vfio/Makefile
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 | 86 ++-
drivers/vfio/platform/vfio_platform_private.h |
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
---
drivers/vfio/pci/vfio_pci.c | 8
drivers/vfio/vfio.c | 8
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
From: Kim Phillips
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 > /sys/bus/platform/devices/fff51000.ethern
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.c | 40 ++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/platform/vfio_p
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.
http://www.virtual
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf 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
Paolo Bonzini 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
>>
>>
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=
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
emula
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
emula
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 foo,+e
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 allo
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 1
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 th
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 explic
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 all-or-
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: <1379
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:
>
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 o
Alexander Graf 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
>>> ---
>>> arch/powerpc/kvm/book3s_emulate.c
Alexander Graf 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
>> ---
>>
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 cas
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
On Jun 5, 2014, at 5:53 PM, Paolo Bonzini 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 performed.
>
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 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_R
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 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
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 TC
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 modification
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 me
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
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insert
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
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/kvm/book
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
---
Note: this is on top of my last pull request
drivers/vhost/vhost.h | 11 +++
drivers/vhost/net.c | 8 +++-
dri
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 into
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
---
arch/powerpc/include/asm/kvm_host.h | 1 +
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
Ouch, I sent out wrong version of the patch.
Self-NAC
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
---
arch/powerpc/kvm/book3s_emulate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c
b/arch/powerpc/kvm/boo
Writing to IC is not allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V
---
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 --
arch/powerpc/kvm/book3s
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
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/include/asm/reg.h | 15 ++
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c
b/arch/powerpc/kvm/book3s_emulate.
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 in
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 tre
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 (64<<30)/(16<<20)*8 = 32K TCE table.
Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
ind
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 kvm_arch_com
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 u
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
---
This is on top of the recent pull request that I sent.
drivers/vhost/vhost.h | 11 +++
drivers/vhost/net.c | 8 +++
1 - 100 of 113 matches
Mail list logo
