| Message ID | 20230530225544.280031-2-akrowiak@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | s390x/ap: fix hang when mdev attached to guest is removed | expand |
On 5/30/23 6:55 PM, Tony Krowiak wrote: > Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> > --- > linux-headers/linux/vfio.h | 9 +++++++++ > 1 file changed, 9 insertions(+) Worth nothing here that linux-headers patches should be generated using scripts/update-linux-headers.sh. Since this linux-headers update includes changes that aren't merged into the kernel yet, I would still use update-linux-headers.sh -- but also include in the commit message that this is a placeholder patch that includes unmerged uapi changes. Then once the kernel changes merge you can just have a proper linux-headers update patch in a subsequent qemu series. > > diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h > index 4a534edbdcba..2658fda219e8 100644 > --- a/linux-headers/linux/vfio.h > +++ b/linux-headers/linux/vfio.h > @@ -646,6 +646,15 @@ enum { > VFIO_CCW_NUM_IRQS > }; > > +/* > + * The vfio-ap bus driver makes use of the following IRQ index mapping. > + * Unimplemented IRQ types return a count of zero. > + */ > +enum { > + VFIO_AP_REQ_IRQ_INDEX, > + VFIO_AP_NUM_IRQS > +}; > + > /** > * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12, > * struct vfio_pci_hot_reset_info)
On 5/30/23 8:56 PM, Matthew Rosato wrote: > On 5/30/23 6:55 PM, Tony Krowiak wrote: >> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> >> --- >> linux-headers/linux/vfio.h | 9 +++++++++ >> 1 file changed, 9 insertions(+) > > Worth nothing here that linux-headers patches should be generated using scripts/update-linux-headers.sh. > > Since this linux-headers update includes changes that aren't merged into the kernel yet, I would still use update-linux-headers.sh -- but also include in the commit message that this is a placeholder patch that includes unmerged uapi changes. Then once the kernel changes merge you can just have a proper linux-headers update patch in a subsequent qemu series. I guess I do not understand the procedure here. I first determined the latest kernel release in which the vfio.h file was updated with the following command: git log --oneline origin/master -- linux-headers/linux/vfio.h According to the git log, the vfio.h file was last updated in kernel v6.3-rc5. I cloned that kernel from git.kernel.org/pub/scm/linux/kernel/git/stable and checked out kernel 6.3-rc5. I then made the changes to the linux-headers/linux/vfio.h file and ran the update-linux-headers.sh script and created this patch from that. Where did I go wrong? > >> >> diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h >> index 4a534edbdcba..2658fda219e8 100644 >> --- a/linux-headers/linux/vfio.h >> +++ b/linux-headers/linux/vfio.h >> @@ -646,6 +646,15 @@ enum { >> VFIO_CCW_NUM_IRQS >> }; >> >> +/* >> + * The vfio-ap bus driver makes use of the following IRQ index mapping. >> + * Unimplemented IRQ types return a count of zero. >> + */ >> +enum { >> + VFIO_AP_REQ_IRQ_INDEX, >> + VFIO_AP_NUM_IRQS >> +}; >> + >> /** >> * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12, >> * struct vfio_pci_hot_reset_info) >
On 5/31/23 8:52 AM, Anthony Krowiak wrote: > > > On 5/30/23 8:56 PM, Matthew Rosato wrote: >> On 5/30/23 6:55 PM, Tony Krowiak wrote: >>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> >>> --- >>> linux-headers/linux/vfio.h | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >> >> Worth nothing here that linux-headers patches should be generated using scripts/update-linux-headers.sh. >> >> Since this linux-headers update includes changes that aren't merged into the kernel yet, I would still use update-linux-headers.sh -- but also include in the commit message that this is a placeholder patch that includes unmerged uapi changes. Then once the kernel changes merge you can just have a proper linux-headers update patch in a subsequent qemu series. > > I guess I do not understand the procedure here. I first determined the latest kernel release in which the vfio.h file was updated with the following command: > git log --oneline origin/master -- linux-headers/linux/vfio.h > > According to the git log, the vfio.h file was last updated in kernel v6.3-rc5. I cloned that kernel from git.kernel.org/pub/scm/linux/kernel/git/stable and checked out kernel 6.3-rc5. I then made the changes to the linux-headers/linux/vfio.h file and ran the update-linux-headers.sh script and created this patch from that. Where did I go wrong? Presumably your kernel series that you just posted was built on top of 6.4-rc4, not v6.3-rc5 (if it's not, you should rebase onto a recent kernel like 6.4-rc4). Then, you want to point update-linux-headers.sh at that source repository which includes your changes. This will pull in all of the changes to the uapi up to kernel 6.4-rc* + your additional unmerged changes. FWIW, I just pointed update-linux-headers.sh at kernel master from today and I got the following: --- include/standard-headers/linux/const.h | 2 +- include/standard-headers/linux/virtio_blk.h | 18 +++---- .../standard-headers/linux/virtio_config.h | 6 +++ include/standard-headers/linux/virtio_net.h | 1 + linux-headers/asm-arm64/kvm.h | 33 ++++++++++++ linux-headers/asm-riscv/kvm.h | 53 ++++++++++++++++++- linux-headers/asm-riscv/unistd.h | 9 ++++ linux-headers/asm-s390/unistd_32.h | 1 + linux-headers/asm-s390/unistd_64.h | 1 + linux-headers/asm-x86/kvm.h | 3 ++ linux-headers/linux/const.h | 2 +- linux-headers/linux/kvm.h | 12 +++-- linux-headers/linux/psp-sev.h | 7 +++ linux-headers/linux/userfaultfd.h | 17 +++++- 14 files changed, 149 insertions(+), 16 deletions(-) --- In your case you would also see an additional line for linux-headers/linux/vfio.h, which would be your unmerged kernel uapi changes. Then you can include a cover letter something like: This is a placeholder that pulls in 6.4-rc4 + unmerged kernel changes required by this series. A proper header sync can be done once the associated kernel code merges. Here's an example from an old series where I did this before: https://lore.kernel.org/qemu-devel/20220606203614.110928-2-mjrosato@linux.ibm.com/ One of the main advantages of doing it this way is that if there are any uapi breakages unrelated to your patch we catch them now. That helps whoever might take your series (e.g. Thomas) avoid having to deal with the fallout later when sending a pull request. > >> >>> >>> diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h >>> index 4a534edbdcba..2658fda219e8 100644 >>> --- a/linux-headers/linux/vfio.h >>> +++ b/linux-headers/linux/vfio.h >>> @@ -646,6 +646,15 @@ enum { >>> VFIO_CCW_NUM_IRQS >>> }; >>> +/* >>> + * The vfio-ap bus driver makes use of the following IRQ index mapping. >>> + * Unimplemented IRQ types return a count of zero. >>> + */ >>> +enum { >>> + VFIO_AP_REQ_IRQ_INDEX, >>> + VFIO_AP_NUM_IRQS >>> +}; >>> + >>> /** >>> * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12, >>> * struct vfio_pci_hot_reset_info) >>
On Wed, May 31 2023, Anthony Krowiak <akrowiak@linux.ibm.com> wrote: > On 5/30/23 8:56 PM, Matthew Rosato wrote: >> On 5/30/23 6:55 PM, Tony Krowiak wrote: >>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> >>> --- >>> linux-headers/linux/vfio.h | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >> >> Worth nothing here that linux-headers patches should be generated using scripts/update-linux-headers.sh. >> >> Since this linux-headers update includes changes that aren't merged into the kernel yet, I would still use update-linux-headers.sh -- but also include in the commit message that this is a placeholder patch that includes unmerged uapi changes. Then once the kernel changes merge you can just have a proper linux-headers update patch in a subsequent qemu series. > > I guess I do not understand the procedure here. I first determined the > latest kernel release in which the vfio.h file was updated with the > following command: > git log --oneline origin/master -- linux-headers/linux/vfio.h > > According to the git log, the vfio.h file was last updated in kernel > v6.3-rc5. I cloned that kernel from > git.kernel.org/pub/scm/linux/kernel/git/stable and checked out kernel > 6.3-rc5. I then made the changes to the linux-headers/linux/vfio.h file > and ran the update-linux-headers.sh script and created this patch from > that. Where did I go wrong? I think your procedure is fine for changes that are local to a single header file. The one thing I'd recommend is to put an explicit "dummy patch, to be replaced by a proper headers update" note into the patch, so that it doesn't get merged by accident. (For complex changes, headers update + explicit note might be better, but the simple approach works in most cases.)
On 5/31/23 9:07 AM, Matthew Rosato wrote: > On 5/31/23 8:52 AM, Anthony Krowiak wrote: >> >> >> On 5/30/23 8:56 PM, Matthew Rosato wrote: >>> On 5/30/23 6:55 PM, Tony Krowiak wrote: >>>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> >>>> --- >>>> linux-headers/linux/vfio.h | 9 +++++++++ >>>> 1 file changed, 9 insertions(+) >>> >>> Worth nothing here that linux-headers patches should be generated using scripts/update-linux-headers.sh. >>> >>> Since this linux-headers update includes changes that aren't merged into the kernel yet, I would still use update-linux-headers.sh -- but also include in the commit message that this is a placeholder patch that includes unmerged uapi changes. Then once the kernel changes merge you can just have a proper linux-headers update patch in a subsequent qemu series. >> >> I guess I do not understand the procedure here. I first determined the latest kernel release in which the vfio.h file was updated with the following command: >> git log --oneline origin/master -- linux-headers/linux/vfio.h >> >> According to the git log, the vfio.h file was last updated in kernel v6.3-rc5. I cloned that kernel from git.kernel.org/pub/scm/linux/kernel/git/stable and checked out kernel 6.3-rc5. I then made the changes to the linux-headers/linux/vfio.h file and ran the update-linux-headers.sh script and created this patch from that. Where did I go wrong? > > Presumably your kernel series that you just posted was built on top of 6.4-rc4, not v6.3-rc5 (if it's not, you should rebase onto a recent kernel like 6.4-rc4). Then, you want to point update-linux-headers.sh at that source repository which includes your changes. This will pull in all of the changes to the uapi up to kernel 6.4-rc* + your additional unmerged changes. FWIW, I just pointed update-linux-headers.sh at kernel master from today and I got the following: > > --- > include/standard-headers/linux/const.h | 2 +- > include/standard-headers/linux/virtio_blk.h | 18 +++---- > .../standard-headers/linux/virtio_config.h | 6 +++ > include/standard-headers/linux/virtio_net.h | 1 + > linux-headers/asm-arm64/kvm.h | 33 ++++++++++++ > linux-headers/asm-riscv/kvm.h | 53 ++++++++++++++++++- > linux-headers/asm-riscv/unistd.h | 9 ++++ > linux-headers/asm-s390/unistd_32.h | 1 + > linux-headers/asm-s390/unistd_64.h | 1 + > linux-headers/asm-x86/kvm.h | 3 ++ > linux-headers/linux/const.h | 2 +- > linux-headers/linux/kvm.h | 12 +++-- > linux-headers/linux/psp-sev.h | 7 +++ > linux-headers/linux/userfaultfd.h | 17 +++++- > 14 files changed, 149 insertions(+), 16 deletions(-) > --- > > In your case you would also see an additional line for linux-headers/linux/vfio.h, which would be your unmerged kernel uapi changes. > > Then you can include a cover letter something like: > > This is a placeholder that pulls in 6.4-rc4 + unmerged kernel changes > required by this series. A proper header sync can be done once the > associated kernel code merges. > > Here's an example from an old series where I did this before: > > https://lore.kernel.org/qemu-devel/20220606203614.110928-2-mjrosato@linux.ibm.com/ > > One of the main advantages of doing it this way is that if there are any uapi breakages unrelated to your patch we catch them now. That helps whoever might take your series (e.g. Thomas) avoid having to deal with the fallout later when sending a pull request. Thanks Matt, I'll do this for v2. > >> >>> >>>> >>>> diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h >>>> index 4a534edbdcba..2658fda219e8 100644 >>>> --- a/linux-headers/linux/vfio.h >>>> +++ b/linux-headers/linux/vfio.h >>>> @@ -646,6 +646,15 @@ enum { >>>> VFIO_CCW_NUM_IRQS >>>> }; >>>> +/* >>>> + * The vfio-ap bus driver makes use of the following IRQ index mapping. >>>> + * Unimplemented IRQ types return a count of zero. >>>> + */ >>>> +enum { >>>> + VFIO_AP_REQ_IRQ_INDEX, >>>> + VFIO_AP_NUM_IRQS >>>> +}; >>>> + >>>> /** >>>> * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12, >>>> * struct vfio_pci_hot_reset_info) >>> >
On 5/31/23 9:07 AM, Cornelia Huck wrote: > On Wed, May 31 2023, Anthony Krowiak <akrowiak@linux.ibm.com> wrote: > >> On 5/30/23 8:56 PM, Matthew Rosato wrote: >>> On 5/30/23 6:55 PM, Tony Krowiak wrote: >>>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> >>>> --- >>>> linux-headers/linux/vfio.h | 9 +++++++++ >>>> 1 file changed, 9 insertions(+) >>> >>> Worth nothing here that linux-headers patches should be generated using scripts/update-linux-headers.sh. >>> >>> Since this linux-headers update includes changes that aren't merged into the kernel yet, I would still use update-linux-headers.sh -- but also include in the commit message that this is a placeholder patch that includes unmerged uapi changes. Then once the kernel changes merge you can just have a proper linux-headers update patch in a subsequent qemu series. >> >> I guess I do not understand the procedure here. I first determined the >> latest kernel release in which the vfio.h file was updated with the >> following command: >> git log --oneline origin/master -- linux-headers/linux/vfio.h >> >> According to the git log, the vfio.h file was last updated in kernel >> v6.3-rc5. I cloned that kernel from >> git.kernel.org/pub/scm/linux/kernel/git/stable and checked out kernel >> 6.3-rc5. I then made the changes to the linux-headers/linux/vfio.h file >> and ran the update-linux-headers.sh script and created this patch from >> that. Where did I go wrong? > > I think your procedure is fine for changes that are local to a single > header file. The one thing I'd recommend is to put an explicit "dummy > patch, to be replaced by a proper headers update" note into the patch, > so that it doesn't get merged by accident. > > (For complex changes, headers update + explicit note might be better, > but the simple approach works in most cases.) Will do. >
diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h index 4a534edbdcba..2658fda219e8 100644 --- a/linux-headers/linux/vfio.h +++ b/linux-headers/linux/vfio.h @@ -646,6 +646,15 @@ enum { VFIO_CCW_NUM_IRQS }; +/* + * The vfio-ap bus driver makes use of the following IRQ index mapping. + * Unimplemented IRQ types return a count of zero. + */ +enum { + VFIO_AP_REQ_IRQ_INDEX, + VFIO_AP_NUM_IRQS +}; + /** * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12, * struct vfio_pci_hot_reset_info)
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> --- linux-headers/linux/vfio.h | 9 +++++++++ 1 file changed, 9 insertions(+)