On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition keeping last_vcpu per logical partition id.
With the ne
Il 18/06/2014 07:32, Jan Kiszka ha scritto:
Check for required-0 or required-1 bits as well as known field value
restrictions. Also check the consistency between VMX_*_CTLS and
VMX_TRUE_*_CTLS and between CR0/4_FIXED0 and CR0/4_FIXED1.
Signed-off-by: Jan Kiszka
---
Changes in v3:
- integrated
On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote:
> Il 17/06/2014 11:03, David Marchand ha scritto:
> >>Unless someone steps up and maintains ivshmem, I think it should be
> >>deprecated and dropped from QEMU.
> >
> >Then I can maintain ivshmem for QEMU.
> >If this is ok, I will send a
On Tue, Jun 17, 2014 at 11:03:32AM +0200, David Marchand wrote:
> On 06/17/2014 04:54 AM, Stefan Hajnoczi wrote:
> >ivshmem has a performance disadvantage for guest-to-host
> >communication. Since the shared memory is exposed as PCI BARs, the
> >guest has to memcpy into the shared memory.
> >
> >v
Il 17/06/2014 22:36, Konrad Rzeszutek Wilk ha scritto:
+ /* One more attempt - but if we fail mark it as pending. */
+ if (val == _Q_LOCKED_VAL) {
+ new = Q_LOCKED_VAL |_Q_PENDING_VAL;
+
+ old = atomic_cmpxchg(&lock->val, val, new);
+ if (old
Hi all,
I'm using a KVM/Qemu nested SVM setup to debug another hypervisor
(Jailhouse) I contribute to. IOW, the scheme is: AMD64 Linux host
running [paravirtualized] AMD64 Linux guest (the same kernel as the
host) running Jailhouse.
Jailhouse, in turn, uses Nested Paging to virtualize xAPIC:
VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO should
not do byte swapping and simply return values as it gets them from
PCI device.
Instead, the existing code assumes that byte stream in read/write is
little-endi
Hi,
I'm working on OSv (https://github.com/cloudius-systems/osv), a guest
operating system.
I've been investigating a phenomena of KVM_SYSTEM_TIME being marked as
unstable (PVCLOCK_TSC_STABLE_BIT cleared) by KVM on a modern
single-socket CPU since the very beginning of guest's life time.
Accordin
Il 17/06/2014 22:55, Konrad Rzeszutek Wilk ha scritto:
On Sun, Jun 15, 2014 at 02:47:01PM +0200, Peter Zijlstra wrote:
From: Waiman Long
This patch extracts the logic for the exchange of new and previous tail
code words into a new xchg_tail() function which can be optimized in a
later patch.
Il 15/06/2014 14:47, Peter Zijlstra ha scritto:
- for (;;) {
- new = (val & ~_Q_PENDING_MASK) | _Q_LOCKED_VAL;
-
- old = atomic_cmpxchg(&lock->val, val, new);
- if (old == val)
- break;
-
- val = old;
- }
+
Il 15/06/2014 14:47, Peter Zijlstra ha scritto:
XXX: merge into the pending bit patch..
Agree, or if not move it right after the pending bit patch, before the
NR_CPUS optimization.
Paolo
It is possible so observe the pending bit without the locked bit when
the last owner has just released
Il 17/06/2014 00:08, Waiman Long ha scritto:
+void __pv_queue_unlock(struct qspinlock *lock)
+{
+ int val = atomic_read(&lock->val);
+
+ native_queue_unlock(lock);
+
+ if (val & _Q_LOCKED_SLOW)
+ ___pv_kick_head(lock);
+}
+
Again a race can happen here between th
Il 15/06/2014 14:47, Peter Zijlstra ha scritto:
#if !defined(CONFIG_X86_OOSTORE) && !defined(CONFIG_X86_PPRO_FENCE)
-#definequeue_spin_unlock queue_spin_unlock
/**
* queue_spin_unlock - release a queue spinlock
* @lock : Pointer to queue spinlock structure
*
* An effective sm
On 2014-06-18 13:36, Valentine Sinitsyn wrote:
> Hi all,
>
> I'm using a KVM/Qemu nested SVM setup to debug another hypervisor
> (Jailhouse) I contribute to. IOW, the scheme is: AMD64 Linux host
> running [paravirtualized] AMD64 Linux guest (the same kernel as the
> host) running Jailhouse.
>
> J
On Wed, Jun 18, 2014 at 01:29:48PM +0200, Paolo Bonzini wrote:
> Il 17/06/2014 22:36, Konrad Rzeszutek Wilk ha scritto:
> >+/* One more attempt - but if we fail mark it as pending. */
> >+if (val == _Q_LOCKED_VAL) {
> >+new = Q_LOCKED_VAL |_Q_PENDING_VAL;
> >+
> >+ol
On Wed, Jun 18, 2014 at 01:37:45PM +0200, Paolo Bonzini wrote:
> Il 17/06/2014 22:55, Konrad Rzeszutek Wilk ha scritto:
> >On Sun, Jun 15, 2014 at 02:47:01PM +0200, Peter Zijlstra wrote:
> >>From: Waiman Long
> >>
> >>This patch extracts the logic for the exchange of new and previous tail
> >>code
Recent Intel CPUs have 10 variable range MTRRs. Since operating systems
sometime make assumptions on CPUs while they ignore capability MSRs, it is
better for KVM to be consistent with recent CPUs. Reporting more MTRRs than
actually supported has no functional implications.
Signed-off-by: Nadav Ami
Certain instructions (e.g., mwait and monitor) cause a #UD exception when they
are executed in privilaged mode. This is in contrast to the regular privilaged
instructions which cause #GP. In order not to mess with SVM interception of
mwait and monitor which assumes privilage level assertions take p
On 06/14/2014 10:51 PM, Christoffer Dall wrote:
> The handling of writes to the GICD_ISPENDRn and GICD_ICPENDRn is
> currently not handled correctly for level-triggered interrupts.
Hi Christoffer,
Thanks for this patch serie. I can confirm it fixes my QEMU/VFIO issue
where all IRQs were pending cl
KVM handles monitor-mwait as nop, but does not check any of the preconditions
for the instructions. These instructions may generate all kind of exceptions
(#UD, #PF, #GP, #SS). They can also be executed in real-mode. This patch-set
moves the handling of monitor-mwait to the emulator, to allow the
Certain instructions, such as monitor and xsave do not support big real mode
and cause a #GP exception if any of the accessed bytes effective address are
not within [0, 0x]. This patch introduces a flag to mark these
instructions, including the necassary checks.
Signed-off-by: Nadav Amit
---
mwait and monitor are currently handled as nop. Considering this behavior, they
should still be handled correctly, i.e., check execution conditions and generate
exceptions when required. mwait and monitor may also be executed in real-mode
and are not handled in that case. This patch performs the e
VMX instructions use 32-bit operands in 32-bit mode, and 64-bit operands in
64-bit mode. The current implementation is broken since it does not use the
register operands correctly, and always uses 64-bit for reads and writes.
Moreover, write to memory in vmwrite only considers long-mode, so it ign
The current emulation of bit operations ignores the offset from the destination
on 64-bit target memory operands. This patch fixes this behavior.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/emulate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/emulate.c b/a
From: Nadav Amit
When the guest sets DR6 and DR7, KVM asserts the high 32-bits are clear, and
otherwise injects a #GP exception. This exception should only be injected only
if running in long-mode.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/vmx.c | 2 +-
arch/x86/kvm/x86.h | 18 ++
Currently, the hypercall handling routine only considers LME as an indication
to whether the guest uses 32/64-bit mode. This is incosistent with hyperv
hypercalls handling and against the common sense of considering cs.l as well.
This patch uses is_64_bit_mode instead of is_long_mode for that matte
On long-mode the current NOP (0x90) emulation still writes back to RAX. As a
result, EAX is zero-extended and the high 32-bits of RAX are cleared.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/emulate.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/emulate.c
This patch-set checks recent emulator bugs as well as monitor-mwait emulation
in real-mode.
Nadav Amit (5):
x86: Testing nop instruction on 64-bit
x86: test xadd with two identical operands
x86: Test btcq with operand larger than 64
x86: check cmov instruction on 64-bit
x86: Test monitor
cmov instruction on 64-bit with dword destination register operand should clear
bits [63:32]. This test checks this behavior due to previous KVM bug.
Signed-off-by: Nadav Amit
---
x86/emulator.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/x86/emulator.c b/
monitor and mwait are now considered to behave as nop. New patch enables
monitor and mwait in realmode as well. This test checks whether they are
handled as nop in realmode as well.
Signed-off-by: Nadav Amit
---
x86/realmode.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/x8
On 32-bit mode only bits [31:0] of the CR should be used for setting the CR
value. Otherwise, the host may incorrectly assume the value is invalid if bits
[63:32] are not zero. Moreover, the CR is currently being read twice when CR8
is used. Last, nested mov-cr exiting is modified to handle the
Return unhandlable error on inter-privilage level ret instruction. This is
since the current emulation does not check the privilage level correctly when
loading the CS, and does not pop RSP/SS as needed.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/emulate.c | 4
1 file changed, 4 insertions
The emulator does not emulate the xadd instruction correctly if the two
operands are the same. In this (unlikely) situation the result should be the
sum of X and X (2X) when it is currently X. The solution is to first perform
writeback to the source, before writing to the destination. The only
i
On 06/14/2014 10:51 PM, Christoffer Dall wrote:
> 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 i
Even if the condition of cmov is not satisfied, bits[63:32] should be cleared.
This is clearly stated in Intel's CMOVcc documentation. The solution is to
reassign the destination onto itself if the condition is unsatisfied. For that
matter the original destination value needs to be read.
Signed-
This patch-set resolves several emulator bugs. Each fix is independent of the
others. The DR6 bug can occur during DR-access exit (regardless to
unrestricted mode, MMIO and SPT).
Changes in v2:
Introduced kvm_register_readl and kvm_register_writel which consider long-mode
and cs.l when reading
Previously, KVM did not calculate the offset for bit-operations correctly when
quad-word operands were used. This test checks btcq when operand is larger
than 64 in order to check this scenario.
Signed-off-by: Nadav Amit
---
x86/emulator.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion
Previously, KVM emulated xadd incorrectly when the source and destination
operands were identical. The expected result is that the register would hold
the sum (2x) and not the previous value (x). This test checks this behavior.
It should be executed with a disabled unrestricted mode.
Signed-off-
On 06/14/2014 10:51 PM, Christoffer Dall wrote:
> 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. I think this amalgamates the
> two evil beings (myself and the code
Hello Stefan,
On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote:
One more thing to add to the list:
static void ivshmem_read(void *opaque, const uint8_t * buf, int flags)
The "flags" argument should be "size". Size should be checked before
accessing buf.
You are welcome to send a fix and I will
On 06/18/2014 12:51 PM, Stefan Hajnoczi wrote:
Actually, you can avoid this memory copy using frameworks like DPDK.
I guess it's careful to allocate all packets in the mmapped BAR?
Yes.
That's fine if you can modify applications but doesn't work for
unmodified applications using regular n
Previously, nop instruction emulation on 64-bit caused RAX bits [63:32] to be
cleared. This test checks the behavior is correct and RAX is unmodified.
Signed-off-by: Nadav Amit
---
x86/emulator.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/x86/emulator.c b/x86/emulator.c
ind
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.06.2014 12:48, schrieb Stefan Hajnoczi:
> On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote:
>> Il 17/06/2014 11:03, David Marchand ha scritto:
Unless someone steps up and maintains ivshmem, I think it
should be deprecated a
Il 18/06/2014 00:10, James Hogan ha scritto:
The patchset depends on v4 of "target-mips: implement UserLocal
Register". I'm aiming for QEMU 2.1, hopefully it isn't too late to get
some final review.
Thanks to everybody who has already taken part in review.
This patchset implements KVM support f
On Wed, Jun 18, 2014 at 01:38:09PM +0200, Tomasz Grabiec wrote:
> Hi,
>
> I'm working on OSv (https://github.com/cloudius-systems/osv), a guest
> operating system.
Right, please add a "tsc_matched" field to kvm_vcpu_arch (to keep
track per-vcpu) and then increment the global counter only once
per
Il 18/06/2014 16:57, David Marchand ha scritto:
Hello Stefan,
On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote:
One more thing to add to the list:
static void ivshmem_read(void *opaque, const uint8_t * buf, int flags)
The "flags" argument should be "size". Size should be checked before
accessin
Alexander Graf writes:
> We use ABIv2 on Little Endian systems which gets rid of the dotted function
> names. Branch to the actual functions when we see such a system.
>
> Signed-off-by: Alexander Graf
As per patches sent by anton we don't need this. We can branch to the
function rathen than th
On 18.06.14 17:21, Aneesh Kumar K.V wrote:
Alexander Graf writes:
We use ABIv2 on Little Endian systems which gets rid of the dotted function
names. Branch to the actual functions when we see such a system.
Signed-off-by: Alexander Graf
As per patches sent by anton we don't need this. We c
On 06/18/2014 08:03 AM, Paolo Bonzini wrote:
Il 17/06/2014 00:08, Waiman Long ha scritto:
+void __pv_queue_unlock(struct qspinlock *lock)
+{
+int val = atomic_read(&lock->val);
+
+native_queue_unlock(lock);
+
+if (val & _Q_LOCKED_SLOW)
+___pv_kick_head(lock);
+}
+
Again a r
Il 18/06/2014 16:19, Nadav Amit ha scritto:
VMX instructions use 32-bit operands in 32-bit mode, and 64-bit operands in
64-bit mode. The current implementation is broken since it does not use the
register operands correctly, and always uses 64-bit for reads and writes.
Moreover, write to memory
Il 18/06/2014 16:19, Nadav Amit ha scritto:
This patch-set resolves several emulator bugs. Each fix is independent of the
others. The DR6 bug can occur during DR-access exit (regardless to
unrestricted mode, MMIO and SPT).
Changes in v2:
Introduced kvm_register_readl and kvm_register_writel w
On 06/18/2014 09:50 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 18, 2014 at 01:37:45PM +0200, Paolo Bonzini wrote:
Il 17/06/2014 22:55, Konrad Rzeszutek Wilk ha scritto:
On Sun, Jun 15, 2014 at 02:47:01PM +0200, Peter Zijlstra wrote:
From: Waiman Long
This patch extracts the logic for the ex
Il 18/06/2014 17:46, Waiman Long ha scritto:
The #1 patch is nice by itself - as it lays out the foundation of the
MCS-similar code - and if Ingo decides he does not want this pending
byte-lock bit business - it can be easily reverted or dropped.
The pending bit code is needed for performance
On Wed, Jun 18, 2014 at 03:52:55PM +, Liang, Kan wrote:
> perf ignore LBR and offcore_rsp.
>
> x86, perf: Protect LBR and offcore rsp against KVM lying
>
> With -cpu host, KVM reports LBR and offcore support, if the host has
> support.
> When the guest perf driver tries to ac
> -Original Message-
> From: Mihai Caraman [mailto:mihai.cara...@freescale.com]
> Sent: Wednesday, June 18, 2014 9:15 PM
> To: kvm-...@vger.kernel.org
> Cc: kvm@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Caraman Mihai Claudiu-
> B02008; Bhushan Bharat-R65777
> Subject: [PATCH] KVM: P
The patch 08c9a188d0d0fc0f0c5e17d89a06bb59c493110f
kvm: powerpc: use caching attributes as per linux pte
do not handle properly the error case, letting mmu_lock locked. The lock
will further generate a RCU stall from kvmppc_e500_emul_tlbwe() caller.
In case of an error go to out label.
Si
On 6/18/14, 6:41 PM, Paolo Bonzini wrote:
Il 18/06/2014 16:19, Nadav Amit ha scritto:
VMX instructions use 32-bit operands in 32-bit mode, and 64-bit
operands in
64-bit mode. The current implementation is broken since it does not
use the
register operands correctly, and always uses 64-bit for r
Peter Zijlstra writes:
>
> This order indicates Andi is the author; but there's no corresponding
> From.
I wrote an early version of the patch, but Kan took it over and extended
it. So both are authors.
BTW Kan you may want to use git send-email to get standard format.
>
>> Signed-off-by: K
From: Nikolay Nikolaev
Add a function to check if the eventfd capability is present in KVM in
the host kernel.
Signed-off-by: Antonios Motakis
Signed-off-by: Nikolay Nikolaev
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
Acked-by: Paolo Bonzini
---
include/sysemu/kvm.h
Il 18/06/2014 16:19, Nadav Amit ha scritto:
Certain instructions (e.g., mwait and monitor) cause a #UD exception when they
are executed in privilaged mode.
It's actually "non-privileged mode" (Priv means the instruction is
privileged, not the mode). So I've renamed the flag to PrivUD.
Paolo
Il 18/06/2014 16:19, Nadav Amit ha scritto:
mwait and monitor are currently handled as nop. Considering this behavior, they
should still be handled correctly, i.e., check execution conditions and generate
exceptions when required. mwait and monitor may also be executed in real-mode
and are not ha
Nadav Amit writes:
> mwait and monitor are currently handled as nop. Considering this behavior,
> they
> should still be handled correctly, i.e., check execution conditions and
> generate
> exceptions when required. mwait and monitor may also be executed in real-mode
Is this necessary ? They a
Il 18/06/2014 18:43, Bandan Das ha scritto:
> mwait and monitor are currently handled as nop. Considering this behavior,
they
> should still be handled correctly, i.e., check execution conditions and
generate
> exceptions when required. mwait and monitor may also be executed in real-mode
Is th
Il 18/06/2014 18:01, Nadav Amit ha scritto:
Perhaps I am missing something, but I don't see where my mistake is.
The VMREAD source operand is always read as 64-bits and I made no
changes there. Therefore, if bits 63:32 are not zero, the instruction
should fail when attempting to access the fie
Hi Jan,
If we want to provide useful nested SVM support, this must be feasible.
If there is a bug, it has to be fixed.
I was more concerned about if it is supported (and it means I do
something wrong), or if it is not supported (at least, now).
Maybe you can describe how you configured the i
On Wed, 2014-06-18 at 10:15 +0300, Mihai Caraman wrote:
> On vcpu schedule, the condition checked for tlb pollution is too loose.
> The tlb entries of a vcpu become polluted (vs stale) only when a different
> vcpu within the same logical partition runs in-between. Optimize the tlb
> invalidation co
Paolo Bonzini writes:
> Il 18/06/2014 18:43, Bandan Das ha scritto:
>>> > mwait and monitor are currently handled as nop. Considering this
>>> > behavior, they
>>> > should still be handled correctly, i.e., check execution conditions and
>>> > generate
>>> > exceptions when required. mwait and
On Jun 18, 2014, at 7:06 PM, Paolo Bonzini wrote:
> Il 18/06/2014 18:01, Nadav Amit ha scritto:
>>>
>>
>> Perhaps I am missing something, but I don't see where my mistake is.
>> The VMREAD source operand is always read as 64-bits and I made no
>> changes there. Therefore, if bits 63:32 are not
On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote:
> mwait and monitor are currently handled as nop. Considering this behavior,
> they
> should still be handled correctly, i.e., check execution conditions and
> generate
> exceptions when required. mwait and monitor may also be executed in real-m
On 6/18/14, 8:59 PM, Eric Northup wrote:
On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote:
mwait and monitor are currently handled as nop. Considering this behavior, they
should still be handled correctly, i.e., check execution conditions and generate
exceptions when required. mwait and monito
> >>However, I *do* agree with you that it's simpler to just squash this patch
> >>into 01/11.
> >Uh, did I say that? Oh I said why don't make it right the first time!
> >
> >I meant in terms of seperating the slowpath (aka the bytelock on the pending
> >bit) from the queue (MCS code). Or renaming
Quoting Gabriel's post http://www.spinics.net/lists/kvm/msg103792.html :
[...]
> E.g., OS X 10.5 *does* check CPUID, and panics if it doesn't find it.
> It needs the MONITOR cpuid flag to be on, *and* the actual
> instructions to work.
On Wed, Jun 18, 2014 at 11:23 AM, Nadav Amit wrote:
> On
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
> VFIO exposes BARs to user space as a byte stream so userspace can
> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
> not do byte swapping and simply return values as it gets them from
> PCI device.
>
> Inste
On Wed, Jun 18, 2014 at 10:59:14AM -0700, Eric Northup wrote:
> On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote:
> > mwait and monitor are currently handled as nop. Considering this behavior,
> > they
> > should still be handled correctly, i.e., check execution conditions and
> > generate
> >
On Wed, Jun 18, 2014 at 11:30:07AM -0700, Eric Northup wrote:
> Quoting Gabriel's post http://www.spinics.net/lists/kvm/msg103792.html :
>
> [...]
>
> > E.g., OS X 10.5 *does* check CPUID, and panics if it doesn't find it.
> > It needs the MONITOR cpuid flag to be on, *and* the actual
> > instruc
"Gabriel L. Somlo" writes:
> On Wed, Jun 18, 2014 at 10:59:14AM -0700, Eric Northup wrote:
>> On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote:
>> > mwait and monitor are currently handled as nop. Considering this behavior,
>> > they
>> > should still be handled correctly, i.e., check executio
On Sun, Jun 15, 2014 at 02:47:06PM +0200, Peter Zijlstra wrote:
> From: Waiman Long
>
> This patch renames the paravirt_ticketlocks_enabled static key to a
> more generic paravirt_spinlocks_enabled name.
>
> Signed-off-by: Waiman Long
> Signed-off-by: Peter Zijlstra
Acked-by: Konrad Rzeszutek
On Sun, Jun 15, 2014 at 02:47:05PM +0200, Peter Zijlstra wrote:
> When we detect a hypervisor (!paravirt, see later patches), revert to
Please spell out the name of the patches.
> a simple test-and-set lock to avoid the horrors of queue preemption.
Heheh.
>
> Signed-off-by: Peter Zijlstra
> --
On Sun, Jun 15, 2014 at 02:47:04PM +0200, Peter Zijlstra wrote:
> From: Waiman Long
>
> Currently, atomic_cmpxchg() is used to get the lock. However, this is
> not really necessary if there is more than one task in the queue and
> the queue head don't need to reset the queue code word. For that c
On Sun, Jun 15, 2014 at 02:47:02PM +0200, Peter Zijlstra wrote:
> From: Peter Zijlstra
>
> When we allow for a max NR_CPUS < 2^14 we can optimize the pending
> wait-acquire and the xchg_tail() operations.
>
> By growing the pending bit to a byte, we reduce the tail to 16bit.
> This means we can
KVM never supported the CPUID_ACPI flag, so it doesn't make sense to
have it enabled by default when KVM is enabled.
The motivation here is exactly the same we had for the MONITOR flag.
And like on the MONITOR flag case, we don't need machine-type compat code
because it is currently impossible to
TCG doesn't support VMX, and nested VMX is not enabled by default on the
KVM kernel module.
So, there's no reason to have VMX enabled by default on the core2duo and
coreduo CPU models, today. Even the newer Intel CPU model definitions
don't have it enabled.
In this case, we need machine-type comp
The following CPU features were never supported by neither TCG or KVM,
so they are useless on the CPU model definitions, today:
* CPUID_DTS (DS)
* CPUID_HT
* CPUID_TM
* CPUID_PBE
* CPUID_EXT_DTES64
* CPUID_EXT_DSCPL
* CPUID_EXT_EST
* CPUID_EXT_TM2
* CPUID_EXT_XTPR
* CPUID_EXT_PDCM
* CPU
Most of the bits that make "enforce" breaks were introduced in 2010 by commit
8560efed6a72a816c0115f41ddb9d79f7ce63f28. The intention behind that commit made
sense, the only problem is that we can't guarantee guest ABI stability across
hosts if we simply rely on trimming of CPU features based on ho
On Mon, 16 Jun 2014 14:40:46 +0900 Joonsoo Kim wrote:
> PPC KVM's CMA area management requires arbitrary bitmap granularity,
> since they want to reserve very large memory and manage this region
> with bitmap that one bit for several pages to reduce management overheads.
> So support arbitrary bi
On Tue, 17 Jun 2014 10:25:07 +0900 Joonsoo Kim wrote:
> > >v2:
> > > - Although this patchset looks very different with v1, the end result,
> > > that is, mm/cma.c is same with v1's one. So I carry Ack to patch 6-7.
> > >
> > >This patchset is based on linux-next 20140610.
> >
> > Thanks for
On 06/18/2014 01:55 PM, Eduardo Habkost wrote:
> The following CPU features were never supported by neither TCG or KVM,
> so they are useless on the CPU model definitions, today:
>
The overall idea of this series makes sense to me (yes, I'd love to get
libvirt to the point that we can use enforce
Skip pinned shadow pages when selecting pages to zap.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/mmu.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
Index: kvm/arch/x86/kvm/mmu.c
===
---
Request KVM_REQ_MMU_RELOAD when deleting sptes from MMU notifiers.
Keep pinned sptes intact if page aging.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/mmu.c | 71 ++---
1 file changed, 62 insertions(+), 9 deletions(-)
Index: kvm.pinned-spt
To be used by next patch.
Signed-off-by: Marcelo Tosatti
---
arch/x86/include/asm/kvm_host.h |2 +-
arch/x86/kvm/mmu.c | 11 ++-
arch/x86/kvm/paging_tmpl.h |2 +-
arch/x86/kvm/x86.c |2 +-
4 files changed, 9 insertions(+), 8 deletions(-)
Ind
Allow vcpus to pin spte translations by:
1) Creating a per-vcpu list of pinned ranges.
2) On mmu reload request:
- Fault ranges.
- Mark sptes with a pinned bit.
- Mark shadow pages as pinned.
3) Then modify the following actions:
- Page age => skip spte flush.
Required by PEBS support as discussed at
Subject: [patch 0/5] Implement PEBS virtualization for Silvermont
Message-Id: <1401412327-14810-1-git-send-email-a...@firstfloor.org>
Thread.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.k
Reload remote vcpus MMU from GET_DIRTY_LOG codepath, before
deleting a pinned spte.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/mmu.c |3 +++
1 file changed, 3 insertions(+)
Index: kvm.pinned-sptes/arch/x86/kvm/mmu.c
===
-
On 06/19/2014 04:35 AM, Alex Williamson wrote:
> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>> VFIO exposes BARs to user space as a byte stream so userspace can
>> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
>> not do byte swapping and simply return
This patch adds support for keeping track of VM dirty pages. As dirty page log
is retrieved, the pages that have been written are write protected again for
next write and log read. For ARMv8 read of dirty log returns invalid operation.
Signed-off-by: Mario Smarduch
---
arch/arm/include/asm/kvm_h
This patch adds support for handling 2nd stage page faults during migration,
it disables faulting in huge pages, and dissolves huge pages to page tables.
In case migration is canceled huge pages will be used again. For ARMv8
logging is hardcoded to false.
Signed-off-by: Mario Smarduch
---
arch/a
Patch adds support for initial write protection VM memlsot. This patch series
assumes that huge PUDs will not be used in 2nd stage tables. For ARMv8 nothing
happens here.
Signed-off-by: Mario Smarduch
---
arch/arm/include/asm/kvm_host.h |1 +
arch/arm/include/asm/kvm_mmu.h|
Patch adds HYP interface for global VM TLB invalidation without address
parameter. Moved VM TLB flushing back to architecture layer.
This patch depends on the unmap_range() patch, it needs to be applied first.
No changes to ARMv8.
Signed-off-by: Mario Smarduch
---
arch/arm/include/asm/kvm_asm.h
This patch adds support for dirty page logging so far tested only on ARMv7,
and verified to compile on ARMv8. With dirty page logging, GICv2 vGIC and arch
timer save/restore support, live migration is supported.
Dirty page logging support -
- initially write protects VM RAM memory regions - 2nd s
On Wed, Jun 18, 2014 at 08:12:03PM -0300, mtosa...@redhat.com wrote:
> Required by PEBS support as discussed at
>
> Subject: [patch 0/5] Implement PEBS virtualization for Silvermont
> Message-Id: <1401412327-14810-1-git-send-email-a...@firstfloor.org>
Thanks marcelo. I'll give it a stress test h
1 - 100 of 107 matches
Mail list logo
