If a TCG guest reboots during a running migration HTAB entries are not
marked dirty, and the destination boots with an invalid HTAB.
When a reboot occurs, explicitly mark the current HTAB dirty after
clearing it.
Signed-off-by: Samuel Mendoza-Jonas
---
hw/ppc/spapr.c | 16 +++-
1
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas
---
hw/ppc/spapr.c | 38
The n_valid and n_invalid fields are unsigned short integers but it is
possible to have more than 65535 entries in a contiguous hunk, overflowing
the field. This results in an incorrect HTAB being sent to the destination
during migration.
Signed-off-by: Samuel Mendoza-Jonas
---
hw/ppc/spapr.c
separate patch
- Removed unnecessary locks (relevant operations occur under BQL)
- TCG: Set HTAB dirty instead of resetting migration state
- Minor style fixes
Samuel Mendoza-Jonas (3):
spapr: Fix stale HTAB during live migration (KVM)
spapr: Fix integer overflow during migration (TCG)
spapr: Fix
On 05/11/14 19:05, Alexander Graf wrote:
>
>
> On 05.11.14 07:17, Samuel Mendoza-Jonas wrote:
>> If a TCG guest reboots during a running migration HTAB entries are not
>> marked dirty, and the destination boots with an invalid HTAB.
>>
>> When a reboot occurs
On 05/11/14 18:57, Alexander Graf wrote:
>
>
> On 05.11.14 07:17, Samuel Mendoza-Jonas wrote:
>> If a guest reboots during a running migration, changes to the
>> hash page table are not necessarily updated on the destination.
>> Opening a new file descriptor to th
If a TCG guest reboots during a running migration HTAB entries are not
marked dirty, and the destination boots with an invalid HTAB.
When a reboot occurs reset the state of HTAB migration, and explicitly
inform the destination of invalid entries.
Signed-off-by: Samuel Mendoza-Jonas
---
hw/ppc
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas
---
hw/ppc/spapr.c | 47
If a spapr guest reboots during a live migration, the guest HTAB on the
destination is not updated properly, usually resulting in a kernel panic.
This is a (delayed!) follow up to my previous patch including a fix
for TCG guests as well as KVM.
Samuel Mendoza-Jonas (2):
spapr: Fix stale HTAB
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas
---
Changes in v5: Use mutex on
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas
---
Changes in v4: Readability
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas
---
Changes in v3: Pointed out by
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas
---
Changes in v2: Forgot check on
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas
---
hw/ppc/spapr.c | 6 ++
1
14 matches
Mail list logo