docs: remove qemu-traditional support from documentation

In preparation to no longer support qemu-traditional (including
qemu-stubdom), remove it from documentation.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

docs/man/xl-pci-configuration.5.pod

@@ -111,8 +111,8 @@ if this parameter is not specified.
 =item Description
 
 By default pciback only allows PV guests to write "known safe" values
-into PCI configuration space, likewise QEMU (both qemu-xen and
-qemu-xen-traditional) imposes the same constraint on HVM guests.
+into PCI configuration space, likewise QEMU imposes the same constraint
+on HVM guests.
 However, many devices require writes to other areas of the configuration space
 in order to operate properly.  This option tells the backend (pciback or QEMU)
 to allow all writes to the PCI configuration space of this device by this

docs/man/xl.cfg.5.pod.in

@@ -841,7 +841,7 @@ This option does not control the emulated graphics card presented to
 an HVM guest. See B<Emulated VGA Graphics Device> below for how to
 configure the emulated device. If B<Emulated VGA Graphics Device> options
 are used in a PV guest configuration, B<xl> will pick up B<vnc>, B<vnclisten>,
-B<vncpasswd>, B<vncdisplay>, B<vncunused>, B<sdl>, B<opengl> and
+B<vncpasswd>, B<vncdisplay>, B<vncunused>, B<sdl> and
 B<keymap> to construct the paravirtual framebuffer device for the guest.
 
 Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
@@ -895,12 +895,6 @@ is used.
 Specifies the path to the X authority file that should be used to
 connect to the X server when the B<sdl> option is used.
 
-=item B<opengl=BOOLEAN>
-
-Enable OpenGL acceleration of the SDL display. Only effects machines
-using B<device_model_version="qemu-xen-traditional"> and only if the
-device-model was compiled with OpenGL support. The default is 0 (disabled).
-
 =item B<keymap=LANG>
 
 Configure the keymap to use for the keyboard associated with this
@@ -1215,17 +1209,11 @@ working graphics passthrough. See the XenVGAPassthroughTestedAdapters
 L<https://wiki.xenproject.org/wiki/XenVGAPassthroughTestedAdapters> wiki page
 for graphics cards currently supported by B<gfx_passthru>.
 
-B<gfx_passthru> is currently supported both with the qemu-xen-traditional
-device-model and upstream qemu-xen device-model.
-
 When given as a boolean the B<gfx_passthru> option either disables graphics
 card passthrough or enables autodetection.
 
 When given as a string the B<gfx_passthru> option describes the type
-of device to enable. Note that this behavior is only supported with the
-upstream qemu-xen device-model. With qemu-xen-traditional IGD (Intel Graphics
-Device) is always assumed and options other than autodetect or explicit IGD
-will result in an error.
+of device to enable.
 
 Currently, valid values for the option are:
 
@@ -1903,10 +1891,7 @@ it may be useful to request a different one, like UEFI.
 
 =item B<rombios>
 
-Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default
-when B<device_model_version=qemu-xen-traditional>. This is the only BIOS
-option supported when B<device_model_version=qemu-xen-traditional>. This is
-the BIOS used by all previous Xen versions.
+Loads ROMBIOS, a 16-bit x86 compatible BIOS.
 
 =item B<seabios>
 
@@ -1926,8 +1911,7 @@ Override the path to the blob to be used as BIOS. The blob provided here MUST
 be consistent with the B<bios=> which you have specified. You should not
 normally need to specify this option.
 
-This option does not have any effect if using B<bios="rombios"> or
-B<device_model_version="qemu-xen-traditional">.
+Requires B<device_model_version="qemu-xen">.
 
 =item B<pae=BOOLEAN>
 
@@ -2516,15 +2500,10 @@ Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
 available.
 
-When using the qemu-xen-traditional device-model, the default as well as
-minimum amount of video RAM for stdvga is 8 MB, which is sufficient for e.g.
-1600x1200 at 32bpp. For the upstream qemu-xen device-model, the default and
-minimum is 16 MB.
+When using stdvga, the default and minimum is 16 MB.
 
-When using the emulated Cirrus graphics card (B<vga="cirrus">) and the
-qemu-xen-traditional device-model, the amount of video RAM is fixed at 4 MB,
-which is sufficient for 1024x768 at 32 bpp. For the upstream qemu-xen
-device-model, the default and minimum is 8 MB.
+When using the emulated Cirrus graphics card (B<vga="cirrus">), the
+default and minimum is 8 MB.
 
 For QXL vga, both the default and minimal are 128MB.
 If B<videoram> is set less than 128MB, an error will be triggered.
@@ -2590,12 +2569,6 @@ B<qemu(1)> manpage. The default is B<en-us>.
 Specifies that the display should be presented via an X window (using
 Simple DirectMedia Layer). The default is (0) not enabled.
 
-=item B<opengl=BOOLEAN>
-
-Enable OpenGL acceleration of the SDL display. Only effects machines
-using B<device_model_version="qemu-xen-traditional"> and only if the
-device-model was compiled with OpenGL support. Default is (0) false.
-
 =item B<nographic=BOOLEAN>
 
 Enable or disable the virtual graphics device.  The default is to
@@ -2925,11 +2898,6 @@ Valid values are:
 Use the device-model merged into the upstream QEMU project.
 This device-model is the default for Linux dom0.
 
-=item B<qemu-xen-traditional>
-
-Use the device-model based upon the historical Xen fork of QEMU.
-This device-model is still the default for NetBSD dom0.
-
 =back
 
 It is recommended to accept the default value for new guests.  If
@@ -2949,8 +2917,7 @@ to specify this option.
 Override the path to the kernel image used as device-model stubdomain.
 The binary provided here MUST be consistent with the
 B<device_model_version> which you have specified.
-In case of B<qemu-xen-traditional> it is expected to be MiniOS-based stubdomain
-image, in case of B<qemu-xen> it is expected to be Linux-based stubdomain
+In case of B<qemu-xen> it is expected to be Linux-based stubdomain
 kernel.
 
 =item B<stubdomain_cmdline="STRING">

docs/misc/stubdom.txt

@@ -23,58 +23,6 @@ and https://wiki.xen.org/wiki/Device_Model_Stub_Domains for more
 information on device model stub domains
 
 
-Toolstack to MiniOS ioemu stubdomain protocol
----------------------------------------------
-
-This section describe communication protocol between toolstack and
-qemu-traditional running in MiniOS stubdomain. The protocol include
-expectations of both qemu and stubdomain itself.
-
-Setup (done by toolstack, expected by stubdomain):
- - Block devices for target domain are connected as PV disks to stubdomain,
-   according to configuration order, starting with xvda
- - Network devices for target domain are connected as PV nics to stubdomain,
-   according to configuration order, starting with 0
- - if graphics output is expected, VFB and VKB devices are set for stubdomain
-   (its backend is responsible for exposing them using appropriate protocol
-   like VNC or Spice)
- - other target domain's devices are not connected at this point to stubdomain
-   (may be hot-plugged later)
- - QEMU command line (space separated arguments) is stored in
-   /vm/<target-uuid>/image/dmargs xenstore path
- - target domain id is stored in /local/domain/<stubdom-id>/target xenstore path
-?? - bios type is stored in /local/domain/<target-id>/hvmloader/bios
- - stubdomain's console 0 is connected to qemu log file
- - stubdomain's console 1 is connected to qemu save file (for saving state)
- - stubdomain's console 2 is connected to qemu save file (for restoring state)
- - next consoles are connected according to target guest's serial console configuration
-
-Startup:
-1. PV stubdomain is started with ioemu-stubdom.gz kernel and no initrd
-2. stubdomain initialize relevant devices
-3. stubdomain signal readiness by writing "running" to /local/domain/<stubdom-id>/device-model/<target-id>/state xenstore path
-4. now stubdomain is considered running
-
-Runtime control (hotplug etc):
-Toolstack can issue command through xenstore. The sequence is (from toolstack POV):
-1. Write parameter to /local/domain/<stubdom-id>/device-model/<target-id>/parameter.
-2. Write command to /local/domain/<stubdom-id>/device-model/<target-id>/command.
-3. Wait for command result in /local/domain/<stubdom-id>/device-model/<target-id>/state (command specific value).
-4. Write "running" back to /local/domain/<stubdom-id>/device-model/<target-id>/state.
-
-Defined commands:
- - "pci-ins" - PCI hot plug, results:
-   - "pci-inserted" - success
-   - "pci-insert-failed" - failure
- - "pci-rem" - PCI hot remove, results:
-   - "pci-removed" - success
-   - ??
- - "save" - save domain state to console 1, results:
-   - "paused" - success
- - "continue" - resume domain execution, after loading state from console 2 (require -loadvm command argument), results:
-   - "running" - success
-
-
 Toolstack to Linux ioemu stubdomain protocol
 --------------------------------------------
 

docs/misc/xenstore-paths.pandoc

@@ -636,7 +636,8 @@ Trustworthy copy of /local/domain/$DOMID/backend/$KIND/$DEVID/$NODE.
 
 #### /libxl/$DOMID/dm-version ("qemu_xen"|"qemu_xen_traditional") = [n,INTERNAL]
 
-The device model version for a domain.
+The device model version for a domain. Note that "qemu_xen_traditional" is
+a device model variant which has been removed from Xen.
 
 #### /libxl/$DOMID/remus/netbuf/$DEVID/ifb = STRING [n,INTERNAL]
 

docs/process/branching-checklist.txt

@@ -14,8 +14,6 @@ ov=4.0
     cd ~/git/qemu-xen.git
     git branch staging-$v staging
     git branch stable-$v master
-    cd ~/git/qemu-xen-traditional.git
-    git branch stable-$v master
 
 # make branch in libvirt
     ssh xen@xenbits.xen.org
@@ -63,7 +61,6 @@ ov=4.0
     cp xen--staging.patchbot-reported-heads xen--staging-$v.patchbot-reported-heads
     cp qemu-xen--master.patchbot-reported-heads  qemu-xen--stable-$v.patchbot-reported-heads
     cp qemu-xen--staging.patchbot-reported-heads  qemu-xen--staging-$v.patchbot-reported-heads
-    cp qemu-xen-traditional--master.patchbot-reported-heads qemu-xen-traditional--stable-$v.patchbot-reported-heads
 
     #emacs versions
     perl -i~ -pe 'next unless m/\b\Q'$ov'\E\b/; $x=$_; $x=~ s/\b\Q'$ov'\E\b/'$v'/g; print $x;' versions

docs/process/release-technician-checklist.txt

@@ -32,8 +32,6 @@ t=RELEASE-$r
   git show # should show appropriate intended commit
   git-tag -u 'Xen.org Xen tree code signing' -m "Xen $v" xen-$v
 
-  git-push xenbits.xen.org:/home/xen/git/qemu-xen-traditional.git $s:stable-$x xen-$v
-
 # consider making tag in minios, and updating xen.git Config.mk
   git checkout SOMETHING
   git show # should show appropriate intended commit

docs/process/xen-release-management.pandoc

@@ -193,7 +193,7 @@ from the last RC:
 
 1. Send out commit moratorium emails to committers@.
 
-2. Check all the trees (mini-os, qemu-trad, qemu-xen, seabios, ovmf etc).
+2. Check all the trees (mini-os, qemu-xen, seabios, ovmf etc).
 They have the correct commits and all security patches applied. There will be
 tools provided.