| Message ID | 20221202030003.11441-6-vikram.garhwal@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Introduce xenpv machine for arm architecture | expand |
Hi Stefano and Vikram, On 2/12/22 03:59, Vikram Garhwal wrote: > From: Stefano Stabellini <stefano.stabellini@amd.com> > > This is done to prepare for enabling xenpv support for ARM architecture. > On ARM it is possible to have a functioning xenpv machine with only the > PV backends and no IOREQ server. If the IOREQ server creation fails, > continue to the PV backends initialization. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> > Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> > --- > include/hw/xen/xen_common.h | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h > index 77ce17d8a4..6510ac15e0 100644 > --- a/include/hw/xen/xen_common.h > +++ b/include/hw/xen/xen_common.h > @@ -467,9 +467,10 @@ static inline void xen_unmap_pcidev(domid_t dom, > { > } > > -static inline void xen_create_ioreq_server(domid_t dom, > - ioservid_t *ioservid) How long are we supposed to maintain this code? Per [*]: In general XenProject.org supports stable branches for 18 months full support plus 18 months security fixes. When a new X.Y.0 release is made there is usually one more release on the to-be-retired stable branch to mop up any loose patches sitting in the repository at which point the branch is retired. 4.17 was just released. 4.5 was 7 years ago. IIUC EOL'ed 4 years ago. [*] https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases#Stable_Maintenance_Branches Regards, Phil.
On 2/12/22 08:19, Philippe Mathieu-Daudé wrote: > Hi Stefano and Vikram, > > On 2/12/22 03:59, Vikram Garhwal wrote: >> From: Stefano Stabellini <stefano.stabellini@amd.com> >> >> This is done to prepare for enabling xenpv support for ARM architecture. >> On ARM it is possible to have a functioning xenpv machine with only the >> PV backends and no IOREQ server. If the IOREQ server creation fails, >> continue to the PV backends initialization. >> >> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> >> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> >> --- >> include/hw/xen/xen_common.h | 13 ++++++++----- >> 1 file changed, 8 insertions(+), 5 deletions(-) >> >> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h >> index 77ce17d8a4..6510ac15e0 100644 >> --- a/include/hw/xen/xen_common.h >> +++ b/include/hw/xen/xen_common.h >> @@ -467,9 +467,10 @@ static inline void xen_unmap_pcidev(domid_t dom, >> { >> } >> -static inline void xen_create_ioreq_server(domid_t dom, >> - ioservid_t *ioservid) > > How long are we supposed to maintain this code? Per [*]: > > In general XenProject.org supports stable branches for 18 months full > support plus 18 months security fixes. When a new X.Y.0 release is > made there is usually one more release on the to-be-retired stable > branch to mop up any loose patches sitting in the repository at which > point the branch is retired. > > 4.17 was just released. 4.5 was 7 years ago. IIUC EOL'ed 4 years ago. > > [*] > https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases#Stable_Maintenance_Branches +Paolo for commit 14efd8d3b5 ("meson, configure: move Xen detection to meson"): xen_libs = { '4.11.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory', 'xengnttab', 'xenevtchn', 'xentoolcore' ], '4.10.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory', 'xengnttab', 'xenevtchn', 'xentoolcore' ], '4.9.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory', 'xengnttab', 'xenevtchn' ], '4.8.0': [ 'xenstore', 'xenctrl', 'xenforeignmemory', 'xengnttab', 'xenevtchn' ], '4.7.1': [ 'xenstore', 'xenctrl', 'xenforeignmemory', 'xengnttab', 'xenevtchn' ], '4.6.0': [ 'xenstore', 'xenctrl' ], '4.5.0': [ 'xenstore', 'xenctrl' ], '4.2.0': [ 'xenstore', 'xenctrl' ], } According to repology for the 'xen' package: FreeBSD (ports): 4.16 Debian 11: 4.14.5 Fedora 35: 4.16.2 Ubuntu 20.04: 4.11.3 OpenSUSE Leap 15.3: 4.14.1 RHEL 8: ?
On Fri, 1 Dec 2022, Philippe Mathieu-Daudé wrote: > On 2/12/22 08:19, Philippe Mathieu-Daudé wrote: > > Hi Stefano and Vikram, > > > > On 2/12/22 03:59, Vikram Garhwal wrote: > > > From: Stefano Stabellini <stefano.stabellini@amd.com> > > > > > > This is done to prepare for enabling xenpv support for ARM architecture. > > > On ARM it is possible to have a functioning xenpv machine with only the > > > PV backends and no IOREQ server. If the IOREQ server creation fails, > > > continue to the PV backends initialization. > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> > > > Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> > > > --- > > > include/hw/xen/xen_common.h | 13 ++++++++----- > > > 1 file changed, 8 insertions(+), 5 deletions(-) > > > > > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h > > > index 77ce17d8a4..6510ac15e0 100644 > > > --- a/include/hw/xen/xen_common.h > > > +++ b/include/hw/xen/xen_common.h > > > @@ -467,9 +467,10 @@ static inline void xen_unmap_pcidev(domid_t dom, > > > { > > > } > > > -static inline void xen_create_ioreq_server(domid_t dom, > > > - ioservid_t *ioservid) > > > > How long are we supposed to maintain this code? Per [*]: > > > > In general XenProject.org supports stable branches for 18 months full > > support plus 18 months security fixes. When a new X.Y.0 release is > > made there is usually one more release on the to-be-retired stable > > branch to mop up any loose patches sitting in the repository at which > > point the branch is retired. > > > > 4.17 was just released. 4.5 was 7 years ago. IIUC EOL'ed 4 years ago. Hi Philippe, So far we have not removed any of the old compatibility code in the xen headers like xen_common.h. However, you have a point and I think we could do so going forward. Like you wrote, 4.5 was 7 years ago, I would be happy to remove the old compatibility code to support ancient releases and that would simplify the code in the QEMU xen headers quite a bit. That said, the change in this patch is orthogonal. This is needed anyway because we can have very modern Xen builds without IOREQ server capabilities (it is a kconfig option). So we would still need this patch. Cheers, Stefano > > [*] > > https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases#Stable_Maintenance_Branches > > +Paolo for commit 14efd8d3b5 ("meson, configure: move Xen detection to > meson"): > > xen_libs = { > '4.11.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory', > 'xengnttab', 'xenevtchn', 'xentoolcore' ], > '4.10.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory', > 'xengnttab', 'xenevtchn', 'xentoolcore' ], > '4.9.0': [ 'xenstore', 'xenctrl', 'xendevicemodel', 'xenforeignmemory', > 'xengnttab', 'xenevtchn' ], > '4.8.0': [ 'xenstore', 'xenctrl', 'xenforeignmemory', 'xengnttab', > 'xenevtchn' ], > '4.7.1': [ 'xenstore', 'xenctrl', 'xenforeignmemory', 'xengnttab', > 'xenevtchn' ], > '4.6.0': [ 'xenstore', 'xenctrl' ], > '4.5.0': [ 'xenstore', 'xenctrl' ], > '4.2.0': [ 'xenstore', 'xenctrl' ], > } > > According to repology for the 'xen' package: > > FreeBSD (ports): 4.16 > Debian 11: 4.14.5 > Fedora 35: 4.16.2 > Ubuntu 20.04: 4.11.3 > OpenSUSE Leap 15.3: 4.14.1 > RHEL 8: ? >
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h index 77ce17d8a4..6510ac15e0 100644 --- a/include/hw/xen/xen_common.h +++ b/include/hw/xen/xen_common.h @@ -467,9 +467,10 @@ static inline void xen_unmap_pcidev(domid_t dom, { } -static inline void xen_create_ioreq_server(domid_t dom, - ioservid_t *ioservid) +static inline int xen_create_ioreq_server(domid_t dom, + ioservid_t *ioservid) { + return 0; } static inline void xen_destroy_ioreq_server(domid_t dom, @@ -600,8 +601,8 @@ static inline void xen_unmap_pcidev(domid_t dom, PCI_FUNC(pci_dev->devfn)); } -static inline void xen_create_ioreq_server(domid_t dom, - ioservid_t *ioservid) +static inline int xen_create_ioreq_server(domid_t dom, + ioservid_t *ioservid) { int rc = xendevicemodel_create_ioreq_server(xen_dmod, dom, HVM_IOREQSRV_BUFIOREQ_ATOMIC, @@ -609,12 +610,14 @@ static inline void xen_create_ioreq_server(domid_t dom, if (rc == 0) { trace_xen_ioreq_server_create(*ioservid); - return; + return rc; } *ioservid = 0; use_default_ioreq_server = true; trace_xen_default_ioreq_server(); + + return rc; } static inline void xen_destroy_ioreq_server(domid_t dom,