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)
+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,
--
2.17.0Hi 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: ?
>
© 2016 - 2026 Red Hat, Inc.