Skip to contentSkip to conversation

pc:piix4: Update smbus I/O space after a migration

PATCH In review [email protected] 5 participants 5 messages Nov 26, 2018 – Dec 3, 2018

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 pc:piix4: Update smbus I/O space after a migration

From: Corey Minyard <[email protected]>

Otherwise it won't be set up correctly and won't work after miigration.

Cc Michael S. Tsirkin <[email protected]>
Cc Igor Mammedov <[email protected]>
---
 hw/acpi/piix4.c | 1 +
 1 file changed, 1 insertion(+)

A rather obvious fix, in hindsight :).

hw/acpi/piix4.c +1 -0
index e330f24c71..2f4dd03b83 100644
@@ -173,6 +173,7 @@ static int vmstate_acpi_post_load(void *opaque, int version_id)
     PIIX4PMState *s = opaque;
 
     pm_io_space_update(s);
+    smbus_io_space_update(s);
     return 0;
 }
 
Signature · 1 line
2.17.1
#1 lore raw
Quoted 4 lines · On 11/26/18 12:28 PM, [email protected] wrote:

From: Corey Minyard <[email protected]>

Otherwise it won't be set up correctly and won't work after miigration.

Any opinions on this?  I think this would be good for 3.1. Without this when a migration occurs on piix4 the SMBus address space appears in the wrong place.  I'm not sure how bad that is, but SMBus certainly ceases to work.

-corey

Quoted 21 lines
Cc Michael S. Tsirkin <[email protected]>
Cc Igor Mammedov <[email protected]>
---
  hw/acpi/piix4.c | 1 +
  1 file changed, 1 insertion(+)

A rather obvious fix, in hindsight :).

hw/acpi/piix4.c +1 -0
index e330f24c71..2f4dd03b83 100644
@@ -173,6 +173,7 @@ static int vmstate_acpi_post_load(void *opaque, int version_id)
      PIIX4PMState *s = opaque;
 
      pm_io_space_update(s);
+    smbus_io_space_update(s);
      return 0;
  }
 
#2 lore raw
Quoted 6 lines · Corey Minyard
Quoted 4 lines · On 11/26/18 12:28 PM, [email protected] wrote:

From: Corey Minyard <[email protected]>

Otherwise it won't be set up correctly and won't work after miigration.

Quoted 6 lines

Any opinions on this?  I think this would be good for 3.1. Without this when a migration occurs on piix4 the SMBus address space appears in the wrong place.  I'm not sure how bad that is, but SMBus certainly ceases to work.

-corey

I have this queued. Thanks!

Quoted 21 lines
Quoted 20 lines
Cc Michael S. Tsirkin <[email protected]>
Cc Igor Mammedov <[email protected]>
---
  hw/acpi/piix4.c | 1 +
  1 file changed, 1 insertion(+)

A rather obvious fix, in hindsight :).

hw/acpi/piix4.c +1 -0
index e330f24c71..2f4dd03b83 100644
@@ -173,6 +173,7 @@ static int vmstate_acpi_post_load(void *opaque, int version_id)
      PIIX4PMState *s = opaque;
      pm_io_space_update(s);
+    smbus_io_space_update(s);
      return 0;
  }
#3 lore raw
Quoted 12 lines · Michael S. Tsirkin
Quoted 11 lines · Corey Minyard
Quoted 4 lines · On 11/26/18 12:28 PM, [email protected] wrote:

From: Corey Minyard <[email protected]>

Otherwise it won't be set up correctly and won't work after miigration.

Any opinions on this?  I think this would be good for 3.1. Without this when a migration occurs on piix4 the SMBus address space appears in the wrong place.  I'm not sure how bad that is, but SMBus certainly ceases to work.

Quoted 4 lines
Quoted 1 line

-corey

I have this queued. Thanks!

We've missed -rc3. Is the problem this patch addresses severe enough to warrant -rc4? Is it a regression since 3.0?

Signature · 3 lines
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org
#4 lore raw
Quoted 14 lines · Eric Blake
Quoted 12 lines · Michael S. Tsirkin
Quoted 11 lines · Corey Minyard
Quoted 4 lines · On 11/26/18 12:28 PM, [email protected] wrote:

From: Corey Minyard <[email protected]>

Otherwise it won't be set up correctly and won't work after miigration.

Any opinions on this? I think this would be good for 3.1. Without this when a migration occurs on piix4 the SMBus address space appears in the wrong place. I'm not sure how bad that is, but SMBus certainly ceases to work.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

-corey

I have this queued. Thanks!

We've missed -rc3. Is the problem this patch addresses severe enough to warrant -rc4? Is it a regression since 3.0?

The git history of the file suggests it's been like this for at least five years, so I would suggest this is not worth putting into -rc4 (we will have an rc4). Happy to hear contrary views, but I don't want to bloat rc4 out more than we can avoid...

thanks
-- PMM