On 07/23/2014 04:48 PM, Abel Gordon wrote:
> On Wed, Jul 23, 2014 at 11:42 AM, Jason Wang wrote:
>> >
>> > On 07/23/2014 04:12 PM, Razya Ladelsky wrote:
>>> > > Jason Wang wrote on 23/07/2014 08:26:36 AM:
>>> > >
> >> From: Jason Wang
> >> To: Razya Ladelsky/Haifa/IBM@IBMIL, kvm@vger.k
This adds a simple interface to allow a guest to request 64 bits of
host nonblocking entropy. This is independent of virtio-rng for a
couple of reasons:
- It's intended to be usable during early boot, when a trivial
synchronous interface is needed.
- virtio-rng gives blocking entropy, and m
This is a straightforward implementation: for each bit of internal
RNG state, request one bit from KVM_GET_RNG_SEED. This is done even
if RDSEED/RDRAND worked, since KVM_GET_RNG_SEED is likely to provide
cryptographically secure output even if the CPU's RNG is weak or
compromised.
Signed-off-by:
This does the same thing as the generic implementation, except
that it logs how many bits of each type it collected. I want to
know whether the initial seeding is working and, if so, whether
the RNG is fast enough.
(I know that hpa assures me that the hardware RNG is more than
fast enough, but I
It's considerably better than any of the alternatives on KVM.
Rather than reinventing all of the cpu feature query code, this fixes
native_cpuid to work in PIC objects.
I haven't combined it with boot/cpuflags.c's cpuid implementation:
including asm/processor.h from boot/cpuflags.c results in a f
Currently, init_std_data contains its own logic for using arch
random sources. This replaces that logic with a generic function
arch_get_rng_seed that allows arch code to supply its own logic.
The default implementation tries arch_get_random_seed_long and
arch_get_random_long individually.
The on
This introduces and uses a very simple synchronous mechanism to get
/dev/urandom-style bits appropriate for initial KVM PV guest RNG
seeding.
It also re-works the way that architectural random data is fed into
random.c's pools. I added a new arch hook called arch_get_rng_seed.
The default impleme
On 07/23/2014 11:44 PM, Eric Blake wrote:
On 07/23/2014 08:25 AM, Yang Hongyang wrote:
Virtual machine (VM) replication is a well known technique for
providing application-agnostic software-implemented hardware fault
tolerance "non-stop service". COLO is a high availability solution.
Both primar
On 07/23/2014 08:25 AM, Yang Hongyang wrote:
> We need a buffer to store migration data.
>
> On save side:
> all saved data was write into colo buffer first, so that we can know
s/was write/is written/
> the total size of the migration data. this can also separate the data
> transmission from
On book3e, guest last instruction is read on the exit path using load
external pid (lwepx) dedicated instruction. This load operation may fail
due to TLB eviction and execute-but-not-read entries.
This patch lay down the path for an alternative solution to read the guest
last instruction, by allow
In the context of replacing kvmppc_ld() function calls with a version of
kvmppc_get_last_inst() which allow to fail, Alex Graf suggested this:
"If we get EMULATE_AGAIN, we just have to make sure we go back into the guest.
No need to inject an ISI into the guest - it'll do that all by itself.
With
On book3e, KVM uses load external pid (lwepx) dedicated instruction to read
guest last instruction on the exit path. lwepx exceptions (DTLB_MISS, DSI
and LRAT), generated by loading a guest address, needs to be handled by KVM.
These exceptions are generated in a substituted guest translation contex
Add mising defines MAS0_GET_TLBSEL() and MAS1_GET_TSIZE() for Book3E.
Signed-off-by: Mihai Caraman
---
v6-v2:
- no change
arch/powerpc/include/asm/mmu-book3e.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-book3e.h
b/arch/powerpc/inc
The commit 1d628af7 "add load inst fixup" made an attempt to handle
failures generated by reading the guest current instruction. The fixup
code that was added works by chance hiding the real issue.
Load external pid (lwepx) instruction, used by KVM to read guest
instructions, is executed in a subs
Read guest last instruction from kvmppc_get_last_inst() allowing the function
to fail in order to emulate again. On bookehv architecture search for
the physical address and kmap it, instead of using Load External PID (lwepx)
instruction. This fixes an infinite loop caused by lwepx's data TLB miss
e
On 07/23/2014 08:25 AM, Yang Hongyang wrote:
> Guest will enter this state when paused to save/resore VM state
s/resore/restore/
> under colo checkpoint.
>
> Signed-off-by: Yang Hongyang
> ---
> qapi-schema.json | 4 +++-
> vl.c | 8
> 2 files changed, 11 insertions(+), 1
On 07/23/2014 08:25 AM, Yang Hongyang wrote:
> introduce an api colo_supported() to indicate COLO support, returns
> true if colo supported(configured with --enable-colo).
Space before () in English sentences:
s/supported(configured/supported (configured/
As I mentioned in the cover letter, defa
On 07/23/2014 08:25 AM, Yang Hongyang wrote:
> Virtual machine (VM) replication is a well known technique for
> providing application-agnostic software-implemented hardware fault
> tolerance "non-stop service". COLO is a high availability solution.
> Both primary VM (PVM) and secondary VM (SVM) run
On 07/23/2014 08:25 AM, Yang Hongyang wrote:
> Add a migration capability 'colo'. If this capability is on,
> The migration will never end, and the VM will be continuously
> checkpointed.
>
> Signed-off-by: Yang Hongyang
> ---
> include/qapi/qmp/qerror.h | 3 +++
> migration.c | 6
migrate colo info to migration target to tell the target colo is
enabled.
Signed-off-by: Yang Hongyang
---
Makefile.objs | 1 +
include/migration/migration-colo.h | 3 ++
migration-colo-comm.c | 68 ++
vl.c
enter colo checkpointed restore loop after live migration.
Signed-off-by: Yang Hongyang
---
include/migration/migration-colo.h | 6 ++
migration-colo-comm.c | 10 ++
migration-colo.c | 22 ++
migration.c| 3
implement colo save
Signed-off-by: Yang Hongyang
---
migration-colo.c | 44 ++--
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/migration-colo.c b/migration-colo.c
index a708872..03ac157 100644
--- a/migration-colo.c
+++ b/migration-colo.c
Because COLO Agent is under development. We add this hack for
test purpose. Trigger checkpoint every 500ms so that we can
test the process of COLO save/restore.
NOTE:
This is only a hack, and will be removed at last.
Signed-off-by: Yang Hongyang
---
migration-colo.c | 14 +-
1 file
implement colo checkpoint protocol.
Checkpoint synchronzing points.
Primary Secondary
NEW @
Suspend
SUSPENDED @
Suspend&Save state
SEND@
implement colo restore
Signed-off-by: Yang Hongyang
---
migration-colo.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/migration-colo.c b/migration-colo.c
index 03ac157..8596845 100644
--- a/migration-colo.c
+++ b/migration-colo.
COLO do not support qdev hotplug migration, disable it.
Signed-off-by: Yang Hongyang
---
migration-colo.c | 12
1 file changed, 12 insertions(+)
diff --git a/migration-colo.c b/migration-colo.c
index b90d9b6..f295e56 100644
--- a/migration-colo.c
+++ b/migration-colo.c
@@ -12,6 +12
The ram cache was initially the same as PVM's memory. At
checkpoint, we cache the dirty memory of PVM into ram cache
(so that ram cache always the same as PVM's memory at every
checkpoint), flush cached memory to SVM after we received
all PVM dirty memory(only needed to flush memory that was
both d
reuse migration bitmap under colo checkpoint, only send dirty pages
per-checkpoint.
Signed-off-by: Yang Hongyang
---
arch_init.c| 20 +++-
include/migration/migration-colo.h | 2 ++
migration-colo.c | 6 ++
stubs/migration-colo.c
Add a migration capability 'colo'. If this capability is on,
The migration will never end, and the VM will be continuously
checkpointed.
Signed-off-by: Yang Hongyang
---
include/qapi/qmp/qerror.h | 3 +++
migration.c | 6 ++
qapi-schema.json | 5 -
3 files changed,
introduce an api colo_supported() to indicate COLO support, returns
true if colo supported(configured with --enable-colo).
Signed-off-by: Yang Hongyang
---
Makefile.objs | 1 +
include/migration/migration-colo.h | 18 ++
migration-colo.c |
We need a buffer to store migration data.
On save side:
all saved data was write into colo buffer first, so that we can know
the total size of the migration data. this can also separate the data
transmission from colo control data, we use colo control data over
socket fd to synchronous both side
is_slaver is to determine whether the QEMU instance is a
slaver(migration target) at runtime.
is_master is to determine whether the QEMU instance is a
master(migration starter) at runtime.
This 2 APIs will be used later.
Signed-off-by: Yang Hongyang
---
migration-colo.c | 11 +++
1 file
Guest will enter this state when paused to save/resore VM state
under colo checkpoint.
Signed-off-by: Yang Hongyang
---
qapi-schema.json | 4 +++-
vl.c | 8
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 807f5a2..b421
Integrate COLO checkpointed save flow into qemu migration.
Add a migrate state: MIG_STATE_COLO, enter this migrate state
after the first live migration successfully finished.
Create a colo thread to do the checkpointed save.
Signed-off-by: Yang Hongyang
---
include/migration/migration-colo
We use COLO agent to compare the packets returned by
Primary VM and Secondary VM, and decide whether to start a
checkpoint according to some rules. It is a linux kernel
module for host.
COLO controller communicate with the agent through ioctl().
Signed-off-by: Yang Hongyang
---
migration-colo.c
Virtual machine (VM) replication is a well known technique for
providing application-agnostic software-implemented hardware fault
tolerance "non-stop service". COLO is a high availability solution.
Both primary VM (PVM) and secondary VM (SVM) run in parallel. They
receive the same request from clie
./configure --enable-colo/--disable-colo to switch COLO
support on/off.
COLO support is off by default.
Signed-off-by: Yang Hongyang
---
configure | 14 ++
1 file changed, 14 insertions(+)
diff --git a/configure b/configure
index f7685b5..4071943 100755
--- a/configure
+++ b/configu
SPRN_SIER and SPRN_MMCR2 are doublely saved, particularly
SPRN_MMCR2 is oversaved with a incorrect value which comes
from SPRN_PMC5
Signed-off-by: Xiao Guangrong
---
arch/powerpc/kvm/book3s_hv_interrupts.S | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_interru
> > Right. With this do you acknowledge that v5 (definitely overwritten
> approach)
> > is ok?
>
> I think I'm starting to understand your logic of v5. You write
> fetch_failed into *inst unswapped if the fetch failed.
"v5
- don't swap when load fails" :)
>
> I think that's ok, but I definite
On Wed, Jul 23, 2014 at 11:42 AM, Jason Wang wrote:
>
> On 07/23/2014 04:12 PM, Razya Ladelsky wrote:
> > Jason Wang wrote on 23/07/2014 08:26:36 AM:
> >
> >> From: Jason Wang
> >> To: Razya Ladelsky/Haifa/IBM@IBMIL, kvm@vger.kernel.org, "Michael S.
> >> Tsirkin" ,
> >> Cc: abel.gor...@gmail.com
On 07/23/2014 04:12 PM, Razya Ladelsky wrote:
> Jason Wang wrote on 23/07/2014 08:26:36 AM:
>
>> From: Jason Wang
>> To: Razya Ladelsky/Haifa/IBM@IBMIL, kvm@vger.kernel.org, "Michael S.
>> Tsirkin" ,
>> Cc: abel.gor...@gmail.com, Joel Nider/Haifa/IBM@IBMIL, Yossi
>> Kuperman1/Haifa/IBM@IBMIL, E
Am 23.07.2014 um 10:24 schrieb "mihai.cara...@freescale.com"
:
>> -Original Message-
>> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
>> ow...@vger.kernel.org] On Behalf Of Alexander Graf
>> Sent: Wednesday, July 23, 2014 12:21 AM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-..
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
> ow...@vger.kernel.org] On Behalf Of Alexander Graf
> Sent: Wednesday, July 23, 2014 12:21 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> kvm@vger.kernel.org
>
Jason Wang wrote on 23/07/2014 08:26:36 AM:
> From: Jason Wang
> To: Razya Ladelsky/Haifa/IBM@IBMIL, kvm@vger.kernel.org, "Michael S.
> Tsirkin" ,
> Cc: abel.gor...@gmail.com, Joel Nider/Haifa/IBM@IBMIL, Yossi
> Kuperman1/Haifa/IBM@IBMIL, Eran Raichstein/Haifa/IBM@IBMIL, Alex
> Glikson/Haifa/
gfn_to_page() will finally call hva_to_pfn() to get the pfn, and pin the page
in memory by calling GUP functions. This function unpins the page.
Will be used by the followed patches.
Signed-off-by: Tang Chen
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 17 -
2
This patch only handle "L1 and L2 vm share one apic access page" situation.
When L1 vm is running, if the shared apic access page is migrated, mmu_notifier
will
request all vcpus to exit to L0, and reload apic access page physical address
for
all the vcpus' vmcs (which is done by patch 5/6). And
apic access page is pinned in memory. As a result, it cannot be
migrated/hot-removed.
Actually, it is not necessary to be pinned.
The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer. When
the page is migrated, kvm_mmu_notifier_invalidate_page() will invalidate the
corresponding
ept identity pagetable and apic access page in kvm are pinned in memory.
As a result, they cannot be migrated/hot-removed.
But actually they don't need to be pinned in memory.
[For ept identity page]
Just do not pin it. When it is migrated, guest will be able to find the
new page in the next ept
In init_rmode_identity_map(), there two variables indicating the return
value, r and ret, and it return 0 on error, 1 on success. The function
is only called by vmx_create_vcpu(), and r is redundant.
This patch removes the redundant variable r, and make init_rmode_identity_map()
return 0 on succes
kvm_arch->ept_identity_pagetable holds the ept identity pagetable page. But
it is never used to refer to the page at all.
In vcpu initialization, it indicates two things:
1. indicates if ept page is allocated
2. indicates if a memory slot for identity page is initialized
Actually, kvm_arch->ept_i
We have APIC_DEFAULT_PHYS_BASE defined as 0xfee0, which is also the address
of
apic access page. So use this macro.
Signed-off-by: Tang Chen
---
arch/x86/kvm/svm.c | 3 ++-
arch/x86/kvm/vmx.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arc
51 matches
Mail list logo
