| Message ID | 20191220173502.15615-1-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | libxc/migration: Drop unimplemneted domain types | expand |
Hi Andrew, On 20/12/2019 17:35, Andrew Cooper wrote: > x86 PVH is completely obsolete - it was intended for legacy PVH before that > idea was abandoned. There was an RFC series for ARM in 2015, but there is > plenty of outstanding work which hasn't been done yet. > > No functional change. New types can be (re)introduced with the code which > actually implements them. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <julien@xen.org>
On Fri, Dec 20, 2019 at 05:35:02PM +0000, Andrew Cooper wrote: > x86 PVH is completely obsolete - it was intended for legacy PVH before that > idea was abandoned. There was an RFC series for ARM in 2015, but there is > plenty of outstanding work which hasn't been done yet. > > No functional change. New types can be (re)introduced with the code which > actually implements them. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wl@xen.org>
Andrew Cooper writes ("[PATCH] libxc/migration: Drop unimplemneted domain types"):
> x86 PVH is completely obsolete - it was intended for legacy PVH before that
> idea was abandoned. There was an RFC series for ARM in 2015, but there is
> plenty of outstanding work which hasn't been done yet.
>
> No functional change. New types can be (re)introduced with the code which
> actually implements them.
...
> - 0x0003: x86 PVH.
> -
> - 0x0004: ARM.
> -
> - 0x0005 - 0xFFFFFFFF: Reserved.
> + 0x0003 - 0xFFFFFFFF: Reserved.
This is reclaiming those numbers. Could there be any software which
uses them ? Eg, maybe someone put the RFC series into production ?
Ian.
On 20/12/2019 18:24, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH] libxc/migration: Drop unimplemneted domain types"): >> x86 PVH is completely obsolete - it was intended for legacy PVH before that >> idea was abandoned. There was an RFC series for ARM in 2015, but there is >> plenty of outstanding work which hasn't been done yet. >> >> No functional change. New types can be (re)introduced with the code which >> actually implements them. > ... >> - 0x0003: x86 PVH. >> - >> - 0x0004: ARM. >> - >> - 0x0005 - 0xFFFFFFFF: Reserved. >> + 0x0003 - 0xFFFFFFFF: Reserved. > This is reclaiming those numbers. Yes > Could there be any software which uses them ? Not plausibly, no, given... > Eg, maybe someone put the RFC series into production ? ... the rather large set of outstanding TODO items in IanC's RFC series, which included "the hypervisor is unstable when logdirty gets enabled" IIRC. ~Andrew
Andrew Cooper writes ("Re: [PATCH] libxc/migration: Drop unimplemneted domain types"):
> On 20/12/2019 18:24, Ian Jackson wrote:
> > Could there be any software which uses them ?
>
> Not plausibly, no, given...
>
> > Eg, maybe someone put the RFC series into production ?
>
> ... the rather large set of outstanding TODO items in IanC's RFC series,
> which included "the hypervisor is unstable when logdirty gets enabled" IIRC.
OK :-).
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Hi, On 20/12/2019 18:30, Andrew Cooper wrote: > On 20/12/2019 18:24, Ian Jackson wrote: >> Andrew Cooper writes ("[PATCH] libxc/migration: Drop unimplemneted domain types"): >>> x86 PVH is completely obsolete - it was intended for legacy PVH before that >>> idea was abandoned. There was an RFC series for ARM in 2015, but there is >>> plenty of outstanding work which hasn't been done yet. >>> >>> No functional change. New types can be (re)introduced with the code which >>> actually implements them. >> ... >>> - 0x0003: x86 PVH. >>> - >>> - 0x0004: ARM. >>> - >>> - 0x0005 - 0xFFFFFFFF: Reserved. >>> + 0x0003 - 0xFFFFFFFF: Reserved. >> This is reclaiming those numbers. > > Yes > >> Could there be any software which uses them ? > > Not plausibly, no, given... > >> Eg, maybe someone put the RFC series into production ? > > ... the rather large set of outstanding TODO items in IanC's RFC series, > which included "the hypervisor is unstable when logdirty gets enabled" IIRC. Some people after Ian picked up the work (AFAIK Linaro were the last ones), but yes the code was still an RFC even after that. So I would not worry too much on potential use. Cheers,
Hi, I forgot to mention the type in the commit title: s/unimplemneted/implemented/ Cheers,
On 20/12/2019 19:04, Julien Grall wrote: > Hi, > > I forgot to mention the type in the commit title: > > s/unimplemneted/implemented/ Oops. TYVM. Fixed. ~Andrew
diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc index 313be3e80d..a7a8a08936 100644 --- a/docs/specs/libxc-migration-stream.pandoc +++ b/docs/specs/libxc-migration-stream.pandoc @@ -160,11 +160,7 @@ type 0x0000: Reserved. 0x0002: x86 HVM. - 0x0003: x86 PVH. - - 0x0004: ARM. - - 0x0005 - 0xFFFFFFFF: Reserved. + 0x0003 - 0xFFFFFFFF: Reserved. page_shift Size of a guest page as a power of two. diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c index 370d98d94a..46fd928de2 100644 --- a/tools/libxc/xc_sr_common.c +++ b/tools/libxc/xc_sr_common.c @@ -8,8 +8,6 @@ static const char *dhdr_types[] = { [DHDR_TYPE_X86_PV] = "x86 PV", [DHDR_TYPE_X86_HVM] = "x86 HVM", - [DHDR_TYPE_X86_PVH] = "x86 PVH", - [DHDR_TYPE_ARM] = "ARM", }; const char *dhdr_type_to_str(uint32_t type) diff --git a/tools/libxc/xc_sr_stream_format.h b/tools/libxc/xc_sr_stream_format.h index 051afa7dcd..37a7da6eab 100644 --- a/tools/libxc/xc_sr_stream_format.h +++ b/tools/libxc/xc_sr_stream_format.h @@ -43,8 +43,6 @@ struct xc_sr_dhdr #define DHDR_TYPE_X86_PV 0x00000001U #define DHDR_TYPE_X86_HVM 0x00000002U -#define DHDR_TYPE_X86_PVH 0x00000003U -#define DHDR_TYPE_ARM 0x00000004U /* * Record Header diff --git a/tools/python/xen/migration/libxc.py b/tools/python/xen/migration/libxc.py index 70bcb8d15b..432750c9fa 100644 --- a/tools/python/xen/migration/libxc.py +++ b/tools/python/xen/migration/libxc.py @@ -32,14 +32,10 @@ DHDR_TYPE_x86_pv = 0x00000001 DHDR_TYPE_x86_hvm = 0x00000002 -DHDR_TYPE_x86_pvh = 0x00000003 -DHDR_TYPE_arm = 0x00000004 dhdr_type_to_str = { DHDR_TYPE_x86_pv : "x86 PV", DHDR_TYPE_x86_hvm : "x86 HVM", - DHDR_TYPE_x86_pvh : "x86 PVH", - DHDR_TYPE_arm : "ARM", } # Records
x86 PVH is completely obsolete - it was intended for legacy PVH before that idea was abandoned. There was an RFC series for ARM in 2015, but there is plenty of outstanding work which hasn't been done yet. No functional change. New types can be (re)introduced with the code which actually implements them. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: George Dunlap <George.Dunlap@eu.citrix.com> CC: Ian Jackson <ian.jackson@citrix.com> CC: Jan Beulich <JBeulich@suse.com> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Wei Liu <wl@xen.org> CC: Julien Grall <julien@xen.org> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- docs/specs/libxc-migration-stream.pandoc | 6 +----- tools/libxc/xc_sr_common.c | 2 -- tools/libxc/xc_sr_stream_format.h | 2 -- tools/python/xen/migration/libxc.py | 4 ---- 4 files changed, 1 insertion(+), 13 deletions(-)