| Message ID | 20230613103159.524763-1-volodymyr_babchuk@epam.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | PCI devices passthrough on Arm, part 3 | expand |
On 6/13/23 06:32, Volodymyr Babchuk wrote: > Hello, > > This is another another version of vPCI rework (previous one can be > found at [1]). The biggest change is how vPCI locking is done. This > series uses per-domain vPCI rwlock. > > Note that this series does not include my work on reference counting > for PCI devices because this counting does not resolve isses we are > having for vPCI. While it is (maybe) nice to have PCI refcounting, it > does not moves us towards PCI on ARM. > > > [1] https://lore.kernel.org/all/20220204063459.680961-1-andr2000@gmail.com/ Thanks for sending this! Should this be v8? I see v7 at [2]. I had to rewind my xen.git back to 67c28bfc5245 for this series to apply cleanly (just before ee045f3a4a6d "vpci/header: cope with devices not having vpci allocated"). [2] https://lists.xenproject.org/archives/html/xen-devel/2022-07/msg01127.html
Hi Stewart, Stewart Hildebrand <stewart.hildebrand@amd.com> writes: > On 6/13/23 06:32, Volodymyr Babchuk wrote: >> Hello, >> >> This is another another version of vPCI rework (previous one can be >> found at [1]). The biggest change is how vPCI locking is done. This >> series uses per-domain vPCI rwlock. >> >> Note that this series does not include my work on reference counting >> for PCI devices because this counting does not resolve isses we are >> having for vPCI. While it is (maybe) nice to have PCI refcounting, it >> does not moves us towards PCI on ARM. >> >> >> [1] >> https://urldefense.com/v3/__https://lore.kernel.org/all/20220204063459.680961-1-andr2000@gmail.com/__;!!GF_29dbcQIUBPA!0BUqPos1zFKUoPwbKLLwKItNgBVPaBgxmH1Y6zXpms2bngrlWrzB-qMNvIaiAy2WSWMa93UrlvRi0ijYP8X4Ymx07GXYPO1W$ >> [lore[.]kernel[.]org] > > Thanks for sending this! > > Should this be v8? I see v7 at [2]. Oops, my bad. > I had to rewind my xen.git back to 67c28bfc5245 for this series to apply cleanly (just before ee045f3a4a6d "vpci/header: cope with devices not having vpci allocated"). I rebased this series onto staging about two weeks ago. Looks like there was new changes into the PCI code after that. Should I send a new, real v8 which is rebased onto current staging, or we'll wait for review for the current set of patches?
On 15.06.2023 11:39, Volodymyr Babchuk wrote: > Stewart Hildebrand <stewart.hildebrand@amd.com> writes: >> On 6/13/23 06:32, Volodymyr Babchuk wrote: >>> Hello, >>> >>> This is another another version of vPCI rework (previous one can be >>> found at [1]). The biggest change is how vPCI locking is done. This >>> series uses per-domain vPCI rwlock. >>> >>> Note that this series does not include my work on reference counting >>> for PCI devices because this counting does not resolve isses we are >>> having for vPCI. While it is (maybe) nice to have PCI refcounting, it >>> does not moves us towards PCI on ARM. >>> >>> >>> [1] >>> https://urldefense.com/v3/__https://lore.kernel.org/all/20220204063459.680961-1-andr2000@gmail.com/__;!!GF_29dbcQIUBPA!0BUqPos1zFKUoPwbKLLwKItNgBVPaBgxmH1Y6zXpms2bngrlWrzB-qMNvIaiAy2WSWMa93UrlvRi0ijYP8X4Ymx07GXYPO1W$ >>> [lore[.]kernel[.]org] >> >> Thanks for sending this! >> >> Should this be v8? I see v7 at [2]. > > Oops, my bad. > >> I had to rewind my xen.git back to 67c28bfc5245 for this series to apply cleanly (just before ee045f3a4a6d "vpci/header: cope with devices not having vpci allocated"). > > I rebased this series onto staging about two weeks ago. Looks like > there was new changes into the PCI code after that. > > Should I send a new, real v8 which is rebased onto current staging, or > we'll wait for review for the current set of patches? Please send a version which, at least at the time of posting, actually applies. Taking into account Stewart's observation on the version number makes it even more desirable to have a re-post. Jan
Hi Jan, Jan Beulich <jbeulich@suse.com> writes: > On 15.06.2023 11:39, Volodymyr Babchuk wrote: >> Stewart Hildebrand <stewart.hildebrand@amd.com> writes: >>> On 6/13/23 06:32, Volodymyr Babchuk wrote: >>>> Hello, >>>> >>>> This is another another version of vPCI rework (previous one can be >>>> found at [1]). The biggest change is how vPCI locking is done. This >>>> series uses per-domain vPCI rwlock. >>>> >>>> Note that this series does not include my work on reference counting >>>> for PCI devices because this counting does not resolve isses we are >>>> having for vPCI. While it is (maybe) nice to have PCI refcounting, it >>>> does not moves us towards PCI on ARM. >>>> >>>> >>>> [1] >>>> https://urldefense.com/v3/__https://lore.kernel.org/all/20220204063459.680961-1-andr2000@gmail.com/__;!!GF_29dbcQIUBPA!0BUqPos1zFKUoPwbKLLwKItNgBVPaBgxmH1Y6zXpms2bngrlWrzB-qMNvIaiAy2WSWMa93UrlvRi0ijYP8X4Ymx07GXYPO1W$ >>>> [lore[.]kernel[.]org] >>> >>> Thanks for sending this! >>> >>> Should this be v8? I see v7 at [2]. >> >> Oops, my bad. >> >>> I had to rewind my xen.git back to 67c28bfc5245 for this series to apply cleanly (just before ee045f3a4a6d "vpci/header: cope with devices not having vpci allocated"). >> >> I rebased this series onto staging about two weeks ago. Looks like >> there was new changes into the PCI code after that. >> >> Should I send a new, real v8 which is rebased onto current staging, or >> we'll wait for review for the current set of patches? > > Please send a version which, at least at the time of posting, actually > applies. Taking into account Stewart's observation on the version > number makes it even more desirable to have a re-post. I am terribly sorry about version mishmash. But Roger made valuable comments for the first patch already. So I'll post the updated version with an additional lock and other fixes. Should it be v8 or v9 in that case?
On 22.06.2023 00:11, Volodymyr Babchuk wrote: > Jan Beulich <jbeulich@suse.com> writes: >> On 15.06.2023 11:39, Volodymyr Babchuk wrote: >>> Stewart Hildebrand <stewart.hildebrand@amd.com> writes: >>>> On 6/13/23 06:32, Volodymyr Babchuk wrote: >>>>> Hello, >>>>> >>>>> This is another another version of vPCI rework (previous one can be >>>>> found at [1]). The biggest change is how vPCI locking is done. This >>>>> series uses per-domain vPCI rwlock. >>>>> >>>>> Note that this series does not include my work on reference counting >>>>> for PCI devices because this counting does not resolve isses we are >>>>> having for vPCI. While it is (maybe) nice to have PCI refcounting, it >>>>> does not moves us towards PCI on ARM. >>>>> >>>>> >>>>> [1] >>>>> https://urldefense.com/v3/__https://lore.kernel.org/all/20220204063459.680961-1-andr2000@gmail.com/__;!!GF_29dbcQIUBPA!0BUqPos1zFKUoPwbKLLwKItNgBVPaBgxmH1Y6zXpms2bngrlWrzB-qMNvIaiAy2WSWMa93UrlvRi0ijYP8X4Ymx07GXYPO1W$ >>>>> [lore[.]kernel[.]org] >>>> >>>> Thanks for sending this! >>>> >>>> Should this be v8? I see v7 at [2]. >>> >>> Oops, my bad. >>> >>>> I had to rewind my xen.git back to 67c28bfc5245 for this series to apply cleanly (just before ee045f3a4a6d "vpci/header: cope with devices not having vpci allocated"). >>> >>> I rebased this series onto staging about two weeks ago. Looks like >>> there was new changes into the PCI code after that. >>> >>> Should I send a new, real v8 which is rebased onto current staging, or >>> we'll wait for review for the current set of patches? >> >> Please send a version which, at least at the time of posting, actually >> applies. Taking into account Stewart's observation on the version >> number makes it even more desirable to have a re-post. > > I am terribly sorry about version mishmash. But Roger made valuable > comments for the first patch already. > > So I'll post the updated version with an additional lock and other > fixes. Should it be v8 or v9 in that case? I don't think that matters, unless you have v8 changelog entries already which were posted with the 2nd v7. Otherwise all that's relevant is that the version be clearly distinguishable from earlier ones. Jan