On Wed, Jun 18, 2014 at 01:50:00PM +0800, Tang Chen wrote:
[Questions]
And by the way, would you guys please answer the following questions for me ?
1. What's the ept identity pagetable for ? Only one page is enough ?
2. Is the ept identity pagetable only used in realmode ?
Can we
Hi Gleb,
Thanks for the quick reply. Please see below.
On 06/18/2014 02:12 PM, Gleb Natapov wrote:
On Wed, Jun 18, 2014 at 01:50:00PM +0800, Tang Chen wrote:
[Questions]
And by the way, would you guys please answer the following questions for me ?
1. What's the ept identity pagetable for ?
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
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 jan.kis...@siemens.com
---
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 patch for
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.
vhost-user
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
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
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.
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 waiman.l...@hp.com
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
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 the
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
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.
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;
+
+old =
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 waiman.l...@hp.com
This patch extracts the logic for the exchange of new and previous tail
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
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
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
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
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
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
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 na...@cs.technion.ac.il
---
arch/x86/kvm/emulate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Nadav Amit nadav.a...@gmail.com
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 na...@cs.technion.ac.il
---
arch/x86/kvm/vmx.c |
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
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 na...@cs.technion.ac.il
---
arch/x86/kvm/emulate.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
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
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 na...@cs.technion.ac.il
---
x86/emulator.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff
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 na...@cs.technion.ac.il
---
x86/realmode.c | 11 +++
1 file changed, 11
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 na...@cs.technion.ac.il
---
arch/x86/kvm/emulate.c | 4
1
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
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 if
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.
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
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 na...@cs.technion.ac.il
---
x86/emulator.c | 6 +-
1 file changed, 5
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.
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) a
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
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 na...@cs.technion.ac.il
---
x86/emulator.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
-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 and dropped
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
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
accessing
Alexander Graf ag...@suse.de 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 ag...@suse.de
As per patches sent by anton we don't need this. We can branch to the
On 18.06.14 17:21, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de 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 ag...@suse.de
As per patches sent by
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
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
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 Longwaiman.l...@hp.com
This patch extracts
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
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 access
-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: PPC:
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.
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
Peter Zijlstra pet...@infradead.org 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.
From: Nikolay Nikolaev n.nikol...@virtualopensystems.com
Add a function to check if the eventfd capability is present in KVM in
the host kernel.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
Signed-off-by: Nikolay Nikolaev n.nikol...@virtualopensystems.com
Reviewed-by: Michael
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
Nadav Amit na...@cs.technion.ac.il 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
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 this
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
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
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
Paolo Bonzini pbonz...@redhat.com 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 pbonz...@redhat.com 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
On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit na...@cs.technion.ac.il 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
On 6/18/14, 8:59 PM, Eric Northup wrote:
On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit na...@cs.technion.ac.il 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
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 the function
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
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.
Instead,
On Wed, Jun 18, 2014 at 10:59:14AM -0700, Eric Northup wrote:
On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit na...@cs.technion.ac.il wrote:
mwait and monitor are currently handled as nop. Considering this behavior,
they
should still be handled correctly, i.e., check execution conditions and
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
instructions to
Gabriel L. Somlo gso...@gmail.com 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 na...@cs.technion.ac.il wrote:
mwait and monitor are currently handled as nop. Considering this behavior,
they
should still be handled
On Sun, Jun 15, 2014 at 02:47:06PM +0200, Peter Zijlstra wrote:
From: Waiman Long waiman.l...@hp.com
This patch renames the paravirt_ticketlocks_enabled static key to a
more generic paravirt_spinlocks_enabled name.
Signed-off-by: Waiman Long waiman.l...@hp.com
Signed-off-by: Peter
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 waiman.l...@hp.com
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
On Sun, Jun 15, 2014 at 02:47:02PM +0200, Peter Zijlstra wrote:
From: Peter Zijlstra pet...@infradead.org
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
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
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
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
*
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
On Mon, 16 Jun 2014 14:40:46 +0900 Joonsoo Kim iamjoonsoo@lge.com 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
On Tue, 17 Jun 2014 10:25:07 +0900 Joonsoo Kim iamjoonsoo@lge.com 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
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 mtosa...@redhat.com
---
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 mtosa...@redhat.com
---
arch/x86/kvm/mmu.c | 71 ++---
1 file changed, 62 insertions(+), 9 deletions(-)
To be used by next patch.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
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(+),
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
Reload remote vcpus MMU from GET_DIRTY_LOG codepath, before
deleting a pinned spte.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
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 values
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 m.smard...@samsung.com
---
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
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 m.smard...@samsung.com
---
arch/arm/include/asm/kvm_host.h |1 +
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 m.smard...@samsung.com
---
1 - 100 of 114 matches
Mail list logo
