| Message ID | 20220506153956.2217601-1-scgl@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | s390x: kvm: Honor storage keys during emulation | expand |
On Fri, May 06 2022, Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote: > Make use of the storage key support of the MEMOP ioctl, if available, > in order to support storage key checking during emulation. > > I did not update all the headers, since that broke the build, > not sure what the best way of dealing with that is. Yeah, the vfio change is expected to break the build; the fix should be easy (simple rename), and the code affected is deprecated anyway (there hasn't been any upstream implementation that actually exposed the interfaces). I think we should do that in a single commit to preserve bisectability; I have not seen any patches posted yet to actually use the new vfio migration interface, so a simple compile fixup should be all that is needed. > > Janis Schoetterl-Glausch (2): > Pull in MEMOP changes in linux-headers > target/s390x: kvm: Honor storage keys during emulation > > linux-headers/linux/kvm.h | 11 +++++++++-- > target/s390x/kvm/kvm.c | 9 +++++++++ > 2 files changed, 18 insertions(+), 2 deletions(-) > > > base-commit: 31abf61c4929a91275fe32f1fafe6e6b3e840b2a > -- > 2.32.0
On 5/9/22 10:06, Cornelia Huck wrote: > On Fri, May 06 2022, Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote: > >> Make use of the storage key support of the MEMOP ioctl, if available, >> in order to support storage key checking during emulation. >> >> I did not update all the headers, since that broke the build, >> not sure what the best way of dealing with that is. > > Yeah, the vfio change is expected to break the build; the fix should be > easy (simple rename), and the code affected is deprecated anyway (there > hasn't been any upstream implementation that actually exposed the > interfaces). I think we should do that in a single commit to preserve > bisectability; I have not seen any patches posted yet to actually use > the new vfio migration interface, so a simple compile fixup should be > all that is needed. So basically this patch (pasted below) https://lore.kernel.org/qemu-devel/20220404181726.60291-3-mjrosato@linux.ibm.com/ squashed with the updated headers. Subject: [PATCH v5 2/9] vfio: tolerate migration protocol v1 uapi renames Date: Mon, 4 Apr 2022 14:17:19 -0400 [thread overview] Message-ID: <20220404181726.60291-3-mjrosato@linux.ibm.com> (raw) In-Reply-To: <20220404181726.60291-1-mjrosato@linux.ibm.com> The v1 uapi is deprecated and will be replaced by v2 at some point; this patch just tolerates the renaming of uapi fields to reflect v1 / deprecated status. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> --- hw/vfio/common.c | 2 +- hw/vfio/migration.c | 19 +++++++++++-------- 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index 080046e3f5..7b1e12fb69 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -380,7 +380,7 @@ static bool vfio_devices_all_running_and_saving(VFIOContainer *container) return false; } - if ((migration->device_state & VFIO_DEVICE_STATE_SAVING) && + if ((migration->device_state & VFIO_DEVICE_STATE_V1_SAVING) && (migration->device_state & VFIO_DEVICE_STATE_RUNNING)) { continue; } else { diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c index ff6b45de6b..e109cee551 100644 --- a/hw/vfio/migration.c +++ b/hw/vfio/migration.c @@ -432,7 +432,7 @@ static int vfio_save_setup(QEMUFile *f, void *opaque) } ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_MASK, - VFIO_DEVICE_STATE_SAVING); + VFIO_DEVICE_STATE_V1_SAVING); if (ret) { error_report("%s: Failed to set state SAVING", vbasedev->name); return ret; @@ -532,7 +532,7 @@ static int vfio_save_complete_precopy(QEMUFile *f, void *opaque) int ret; ret = vfio_migration_set_state(vbasedev, ~VFIO_DEVICE_STATE_RUNNING, - VFIO_DEVICE_STATE_SAVING); + VFIO_DEVICE_STATE_V1_SAVING); if (ret) { error_report("%s: Failed to set state STOP and SAVING", vbasedev->name); @@ -569,7 +569,7 @@ static int vfio_save_complete_precopy(QEMUFile *f, void *opaque) return ret; } - ret = vfio_migration_set_state(vbasedev, ~VFIO_DEVICE_STATE_SAVING, 0); + ret = vfio_migration_set_state(vbasedev, ~VFIO_DEVICE_STATE_V1_SAVING, 0); if (ret) { error_report("%s: Failed to set state STOPPED", vbasedev->name); return ret; @@ -730,7 +730,7 @@ static void vfio_vmstate_change(void *opaque, bool running, RunState state) * start saving data. */ if (state == RUN_STATE_SAVE_VM) { - value = VFIO_DEVICE_STATE_SAVING; + value = VFIO_DEVICE_STATE_V1_SAVING; } else { value = 0; } @@ -768,8 +768,9 @@ static void vfio_migration_state_notifier(Notifier *notifier, void *data) case MIGRATION_STATUS_FAILED: bytes_transferred = 0; ret = vfio_migration_set_state(vbasedev, - ~(VFIO_DEVICE_STATE_SAVING | VFIO_DEVICE_STATE_RESUMING), - VFIO_DEVICE_STATE_RUNNING); + ~(VFIO_DEVICE_STATE_V1_SAVING | + VFIO_DEVICE_STATE_RESUMING), + VFIO_DEVICE_STATE_RUNNING); if (ret) { error_report("%s: Failed to set state RUNNING", vbasedev->name); } @@ -864,8 +865,10 @@ int vfio_migration_probe(VFIODevice *vbasedev, Error **errp) goto add_blocker; } - ret = vfio_get_dev_region_info(vbasedev, VFIO_REGION_TYPE_MIGRATION, - VFIO_REGION_SUBTYPE_MIGRATION, &info); + ret = vfio_get_dev_region_info(vbasedev, + VFIO_REGION_TYPE_MIGRATION_DEPRECATED, + VFIO_REGION_SUBTYPE_MIGRATION_DEPRECATED, + &info); if (ret) { goto add_blocker; } > >> >> Janis Schoetterl-Glausch (2): >> Pull in MEMOP changes in linux-headers >> target/s390x: kvm: Honor storage keys during emulation >> >> linux-headers/linux/kvm.h | 11 +++++++++-- >> target/s390x/kvm/kvm.c | 9 +++++++++ >> 2 files changed, 18 insertions(+), 2 deletions(-) >> >> >> base-commit: 31abf61c4929a91275fe32f1fafe6e6b3e840b2a >> -- >> 2.32.0 >
On Tue, May 10 2022, Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote: > On 5/9/22 10:06, Cornelia Huck wrote: >> On Fri, May 06 2022, Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote: >> >>> Make use of the storage key support of the MEMOP ioctl, if available, >>> in order to support storage key checking during emulation. >>> >>> I did not update all the headers, since that broke the build, >>> not sure what the best way of dealing with that is. >> >> Yeah, the vfio change is expected to break the build; the fix should be >> easy (simple rename), and the code affected is deprecated anyway (there >> hasn't been any upstream implementation that actually exposed the >> interfaces). I think we should do that in a single commit to preserve >> bisectability; I have not seen any patches posted yet to actually use >> the new vfio migration interface, so a simple compile fixup should be >> all that is needed. > > So basically this patch (pasted below) > https://lore.kernel.org/qemu-devel/20220404181726.60291-3-mjrosato@linux.ibm.com/ > squashed with the updated headers. Yes. We should probably queue that seperately, just to disarm that trap for everyone; unless there's already a vfio update in flight? (Sorry, I've lost track a bit.) > > Subject: [PATCH v5 2/9] vfio: tolerate migration protocol v1 uapi renames > Date: Mon, 4 Apr 2022 14:17:19 -0400 [thread overview] > Message-ID: <20220404181726.60291-3-mjrosato@linux.ibm.com> (raw) > In-Reply-To: <20220404181726.60291-1-mjrosato@linux.ibm.com> > > The v1 uapi is deprecated and will be replaced by v2 at some point; > this patch just tolerates the renaming of uapi fields to reflect > v1 / deprecated status. > > Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> > --- > hw/vfio/common.c | 2 +- > hw/vfio/migration.c | 19 +++++++++++-------- > 2 files changed, 12 insertions(+), 9 deletions(-) > > diff --git a/hw/vfio/common.c b/hw/vfio/common.c > index 080046e3f5..7b1e12fb69 100644 > --- a/hw/vfio/common.c > +++ b/hw/vfio/common.c > @@ -380,7 +380,7 @@ static bool vfio_devices_all_running_and_saving(VFIOContainer *container) > return false; > } > > - if ((migration->device_state & VFIO_DEVICE_STATE_SAVING) && > + if ((migration->device_state & VFIO_DEVICE_STATE_V1_SAVING) && > (migration->device_state & VFIO_DEVICE_STATE_RUNNING)) { > continue; > } else { > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c > index ff6b45de6b..e109cee551 100644 > --- a/hw/vfio/migration.c > +++ b/hw/vfio/migration.c > @@ -432,7 +432,7 @@ static int vfio_save_setup(QEMUFile *f, void *opaque) > } > > ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_MASK, > - VFIO_DEVICE_STATE_SAVING); > + VFIO_DEVICE_STATE_V1_SAVING); > if (ret) { > error_report("%s: Failed to set state SAVING", vbasedev->name); > return ret; > @@ -532,7 +532,7 @@ static int vfio_save_complete_precopy(QEMUFile *f, void *opaque) > int ret; > > ret = vfio_migration_set_state(vbasedev, ~VFIO_DEVICE_STATE_RUNNING, > - VFIO_DEVICE_STATE_SAVING); > + VFIO_DEVICE_STATE_V1_SAVING); > if (ret) { > error_report("%s: Failed to set state STOP and SAVING", > vbasedev->name); > @@ -569,7 +569,7 @@ static int vfio_save_complete_precopy(QEMUFile *f, void *opaque) > return ret; > } > > - ret = vfio_migration_set_state(vbasedev, ~VFIO_DEVICE_STATE_SAVING, 0); > + ret = vfio_migration_set_state(vbasedev, ~VFIO_DEVICE_STATE_V1_SAVING, 0); > if (ret) { > error_report("%s: Failed to set state STOPPED", vbasedev->name); > return ret; > @@ -730,7 +730,7 @@ static void vfio_vmstate_change(void *opaque, bool running, RunState state) > * start saving data. > */ > if (state == RUN_STATE_SAVE_VM) { > - value = VFIO_DEVICE_STATE_SAVING; > + value = VFIO_DEVICE_STATE_V1_SAVING; > } else { > value = 0; > } > @@ -768,8 +768,9 @@ static void vfio_migration_state_notifier(Notifier *notifier, void *data) > case MIGRATION_STATUS_FAILED: > bytes_transferred = 0; > ret = vfio_migration_set_state(vbasedev, > - ~(VFIO_DEVICE_STATE_SAVING | VFIO_DEVICE_STATE_RESUMING), > - VFIO_DEVICE_STATE_RUNNING); > + ~(VFIO_DEVICE_STATE_V1_SAVING | > + VFIO_DEVICE_STATE_RESUMING), > + VFIO_DEVICE_STATE_RUNNING); > if (ret) { > error_report("%s: Failed to set state RUNNING", vbasedev->name); > } > @@ -864,8 +865,10 @@ int vfio_migration_probe(VFIODevice *vbasedev, Error **errp) > goto add_blocker; > } > > - ret = vfio_get_dev_region_info(vbasedev, VFIO_REGION_TYPE_MIGRATION, > - VFIO_REGION_SUBTYPE_MIGRATION, &info); > + ret = vfio_get_dev_region_info(vbasedev, > + VFIO_REGION_TYPE_MIGRATION_DEPRECATED, > + VFIO_REGION_SUBTYPE_MIGRATION_DEPRECATED, > + &info); > if (ret) { > goto add_blocker; > } >> >>> >>> Janis Schoetterl-Glausch (2): >>> Pull in MEMOP changes in linux-headers >>> target/s390x: kvm: Honor storage keys during emulation >>> >>> linux-headers/linux/kvm.h | 11 +++++++++-- >>> target/s390x/kvm/kvm.c | 9 +++++++++ >>> 2 files changed, 18 insertions(+), 2 deletions(-) >>> >>> >>> base-commit: 31abf61c4929a91275fe32f1fafe6e6b3e840b2a >>> -- >>> 2.32.0 >>
On 10/05/2022 15.43, Cornelia Huck wrote: > On Tue, May 10 2022, Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote: > >> On 5/9/22 10:06, Cornelia Huck wrote: >>> On Fri, May 06 2022, Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote: >>> >>>> Make use of the storage key support of the MEMOP ioctl, if available, >>>> in order to support storage key checking during emulation. >>>> >>>> I did not update all the headers, since that broke the build, >>>> not sure what the best way of dealing with that is. >>> >>> Yeah, the vfio change is expected to break the build; the fix should be >>> easy (simple rename), and the code affected is deprecated anyway (there >>> hasn't been any upstream implementation that actually exposed the >>> interfaces). I think we should do that in a single commit to preserve >>> bisectability; I have not seen any patches posted yet to actually use >>> the new vfio migration interface, so a simple compile fixup should be >>> all that is needed. >> >> So basically this patch (pasted below) >> https://lore.kernel.org/qemu-devel/20220404181726.60291-3-mjrosato@linux.ibm.com/ >> squashed with the updated headers. > > Yes. We should probably queue that seperately, just to disarm that trap > for everyone; unless there's already a vfio update in flight? (Sorry, I've > lost track a bit.) Unless somebody else has queued this already, I can try to come up with a separate pull request for the header update today or tomorrow. Thomas