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 <akrow...@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-mjros...@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) >>
