@@ -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
@@ -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,14 @@ 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.
+B<gfx_passthru> is currently supported with the 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.
+upstream qemu-xen device-model.
Currently, valid values for the option are:
@@ -1903,10 +1894,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 +1914,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">.
+This option does not have any effect if using B<bios="rombios">.
=item B<pae=BOOLEAN>
@@ -2516,15 +2503,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 +2572,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 +2901,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 +2920,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">
@@ -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
--------------------------------------------
@@ -634,7 +634,7 @@ Path in xenstore to the backend, normally
Trustworthy copy of /local/domain/$DOMID/backend/$KIND/$DEVID/$NODE.
-#### /libxl/$DOMID/dm-version ("qemu_xen"|"qemu_xen_traditional") = [n,INTERNAL]
+#### /libxl/$DOMID/dm-version ("qemu_xen") = [n,INTERNAL]
The device model version for a domain.
@@ -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
@@ -74,7 +71,6 @@ ov=4.0
Ensure references to qemu trees and Mini-OS in xen.git's Config.mk are updated.
The variables and there content should be:
* QEMU_UPSTREAM_REVISION: qemu-xen-X.Y.0
- * QEMU_TRADITIONAL_REVISION: xen-X.Y.0
* MINIOS_UPSTREAM_REVISION: xen-RELEASE-X.Y.0
Where X.Y is the release version (e.g. 4.17).
@@ -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
@@ -58,7 +56,6 @@ t=RELEASE-$r
* change xen-unstable Config.mk
# QEMU_UPSTREAM_REVISION,
-# QEMU_TRADITIONAL_REVISION
# MINIOS_UPSTREAM_REVISION
# (drop any references to the specific commits, e.g. date or title)
* change SUPPORT.md heading version number; -unstable or -rc tag
@@ -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.
In preparation to no longer support qemu-traditional (including qemu-stubdom), remove it from documentation. Signed-off-by: Juergen Gross <jgross@suse.com> --- docs/man/xl-pci-configuration.5.pod | 4 +- docs/man/xl.cfg.5.pod.in | 46 +++------------- docs/misc/stubdom.txt | 52 ------------------- docs/misc/xenstore-paths.pandoc | 2 +- docs/process/branching-checklist.txt | 4 -- docs/process/release-technician-checklist.txt | 3 -- docs/process/xen-release-management.pandoc | 2 +- 7 files changed, 12 insertions(+), 101 deletions(-)