[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [QEMU][PATCH v2 05/11] include/hw/xen/xen_common: return error from xen_create_ioreq_server
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@xxxxxxx> > > > > > > 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@xxxxxxx> > > > Signed-off-by: Vikram Garhwal <vikram.garhwal@xxxxxxx> > > > --- > > > 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: ? >
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |