Xen 4.6 Uprev - Patch queue
Xen Patch Enumeration
States:
applied - Patch functionality is already contained in Xen version 4.6
applies - Patch applies cleanly to Xen 4.6
does-not-apply - Patch does not apply to Xen 4.6
Decisions:
K - Keep
D - Drop
R - Refactor
U - Upstream
Patch Name | Sub Systems | State | Upstream Commit | Decision | Comments |
|---|---|---|---|---|---|
config.patch | build |
|
| K | R: I moved these first 3 patches here when I messed with the blktap patches. I believe they are all valid. |
do-not-overwrite-cc-and-ld.patch | build |
|
| K | ditto |
disable-xen-root-check.patch | build |
|
| K | ditto |
bp-ept-update-aa9114edd97b292cd89b3616e3f2089471fd220.patch | xen | applied | 226bc8ee4e0fd26bd3cbdb533eb447fdcd7a90bf | D | covered by up-rev to 4.6 |
fix-xenctrl-enum-defn.patch | tools | applied | 31d2d1e08a0a7334d031c6a8ae98d0942f9e6362 | D | covered by up-rev to 4.6 |
xen-cpuidle-hang.patch | xen | tools | does-not-apply |
| D |
|
sb_reboot_turbo_workaround.patch | xen | applies |
| D | R: This is definitely something from XCE. The SDM has very little to say about this MSR other than "See http://biosbits.org.". Looks like it is somethign on the Nehalem CPUs: https://chromium.googlesource.com/ chromiumos/third_party/coreboot/+/master/util/msrtool/intel_nehalem.c I don't know what to do with it, flip a coin maybe... |
tapdisk_shutdown_recursion.patch | tools | applies |
| D | E: tapdisk is currently built from its own forked repository. So those patches would belong in that repo if anywhere. Also moving to blktap3 will probably take care of the tapdisk patches. R: See my comments on blktap-resume-fix.patch though since we don't know what the original issue was it could be argued that this is just cargo and should go. R: After further consideration we think this is some sort of workaround that never had enything to do with XT. We aren't even using it now so...drop. |
xen-allow-hvm.patch | xen | applied | d640a290f281704d8375ef388da53dbca9c1d248 | D | E: Isn't this upstream already? M: Yes |
blktap-resume-fix.patch | tools | applies |
| K | is this affected by the move to blktap3 E: blktap has its own repository in OpenXT. R: well that could change since I rebased on blktap2 in Xen and blktap3 could be a ways off. I went through all the blktap related patches in this patch queue and threw out most of them. The ones I kepts seemed to make sense to me. |
rmrr-validate-range.patch | xen | applied | 92181f18298ff8c415354150414efb7195c1b620 | D | covered by up-rev to 4.6 |
xentrace-format-handle-zero-tsc.patch | tools | applies |
| U | E: Could be posted upstream? R: Yea it looks valid, we can try to upstream. |
iobitmap-on-all-vcpus.patch | xen | does-not-apply |
| D | R: This is an XCE one, saw the origninal commit message. It was to fix some NVIDIA issue they had. The Xen part read: "Fix SMP issue, where the ioport mask was not propagated to all VCPUS." which is exactly what the patch does. I am inclined to drop it but I will let others chime in. R: This is very specific to a customer issue XCE had. If this were a general problem then nothing would work. Eric and I vote to drop. |
fix-32bit-xsm-interface.patch | xen | applied | 374900d9f3c5d1596b27a6ec29014c9981be0714 | D | a later commit (31d2d1e08a0a7334d031c6a8ae98d0942f9e6362) moves xenctl.h. covered by up-rev to 4.6 |
fix-pci-serial-hang.patch | xen | applied | 37f36d894ef43dc2986d0936612ec967c5a89be8 | D | covered by up-rev to 4.6 |
xsm-add-corespersocket.patch | xen | does-not-apply |
| K | functionality required for xc-xt-aperture-map.patch E: xc-xt-aperture-map.patch can be removed. M: Also needed for xc-xt-cpuid.patch |
incremental-dmesg-processing.patch | xen | does-not-apply |
| D | removing checks in conditionals seems broken R: Yea that looks wrong to me too. Not originally one of ours, I would remove it. |
add-percentages-to-xenpm.patch | tools | does-not-apply |
| D | can this patch be ignored? E: Debug instrumentation, can be ignored. R: Definitely we don't even use xenpm |
stack_on_triple_fault.patch | xen | does-not-apply |
| D | can this patch be ignored? E: Debug instrumentation, can be ignored. R: I agree on all the instrumentation patches, leave them out. |
hvmloader_print_e820.patch | tools | does-not-apply |
| D | can this patch be ignored? E: Debug instrumentation, can be ignored. |
microcode-info.patch | xen | applies |
| D | can this patch be ignored? E: Debug instrumentation, can be ignored. |
add_system_time_timestamps.patch | xen | does-not-apply |
| D | can this patch be ignored? E: Debug instrumentation, can be ignored. |
local-ipxe.patch | tools | applies |
| D | specifies usage of open source ipxe code E: Can be ignored, OpenXT builds ipxe in its separate repository. |
10ms_timeslice.patch | xen | applies |
| D | changes default timeslice to 10ms (why?) E: Yes, why? R: Checked our pre XCE pq and it is not there, probably added by XCE, I would leave it out. X: Was it related to providing support for audio? R: I have no idea. I see the original two commits but there is nothing informative in the comments. It was clearly an XCE thing that predated our common XT/XCE patch queue. |
publish_xentrace_formats.patch | tools | does-not-apply |
| D | why is this published E: No idea, it can probably be ignored. R: I think it can be ignored too. |
add-command-line-option-to-disable-arat.patch | xen | does-not-apply |
| D | is the command line option ever used? E: This is likely related to AMD CPUs which were affected by erratum 400 (http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf ?) R: The option is never used in OpenXT, I say drop it. |
hotplug-scripts-iptables.patch | tools | does-not-apply |
| D | structure of the script has changed completely. where is the DMD that allows this functionality to be commented out E: This script is not used in OpenXT afaict. R: And this was not our patch in the first place. I say nuke it. |
hvm-pm-s-states.patch | xen | tools | does-not-apply |
| D | adds hypercall to emulates PIIX4 (82371AB) Suspend and Resume Logic (Power On Suspend) (some of the patched header files no longer exist) R: That one is not in our original PQ either, may be an XCE thing. I don't see anything using that HVM op anywhere in our code. I think it can go. |
hvm-pm-hibernate-s-state.patch | tools | applies |
| K | adds power states R: We support guest S4 so I think this one should stay. |
prune-acpi-devices.patch | tools | applies |
| D | removes speaker and floppy drive from qemu device model (why?) E: Removes ASL descriptions in the DSDT passed to HVMLoader only. I have no memory of this and I seem to recall it was not part of former XenClientXT Xen 4.1 patch-queue. Also I would recommend to remove the piece instead of commenting. R: It is not in our old PQ and I see no reason to do this (probably an XCE thing). I would drop it. |
prune-vga-acpi-dev.patch | tools | applies |
| K | removes vga from qemu device model (why?) E: ASL descriptions only, removes "NOP" being returned for _S{1,2,3}D methods for VGA PCI device 0:2.0. Although the comment mentions cirrus in particular, I think this also applies to stdvga (currently default emulated device for QEMU in OpenXT). Ross knows better about ASL/AML. I think this avoid having the device from reporting it is not capable of D1, D2, D3, which prevents it from disabling S3 in a Windows guest. R: This one is really weird - actually the code it removes is really weird. It is not clear what returning 0 for these even does does according to the spec. This needs further investigation but this is still in upstream. Maybe it does only effect Cirrus and it was some weird quirk for their driver. Tracked down original commit here, we should keep it. |
xen-libhvm.patch | tools | applies |
| K | helper library for reading ACPI and SMBIOS firmware supporting passthrough R: I wrote this library but we don't use it, XCE did. This is more of an issue when we move to the libxl toolstack and have to deal with guest firmware machinery that is currently in xenvm. I would drop the patch for now and deal with it later - there is a ticket for it: https://openxt.atlassian.net/browse/OXT-505 Note: we are already using the hvmloader support for loading SMBIOS/ACPI bits into the guest. It is the toolstack side that needs work. |
smbios.patch | tools | applies |
| K | add cache information (type 7) to the SMBIOS tables, as well as additional debug information R: I checked and we used to add that type in via the old way we did smbios extra structure loading. We should probably keep it. |
qemu-acpi-tables.patch | tools | does-not-apply |
| D | R: I believe this is an XCE feature that used some back end bits in QEMU to get extra ACPI information. I am 99% sure we can just drop it, Eric can confirm the stuff isn't even in our QEMU. E: I confirm, we do not have the 0x0510 and 0x0511 IO port in our QEMU. |
acpi-no-hotplug.patch | tools | does-not-apply |
| D | E: Remove instead of commenting. R: A version of this was in our original pq. I wish I had some idea why we had to remove it. It is only used in the block of code in if (dm_version == QEMU_XEN_TRADITIONAL) so it doesn't really even make sense anymore. |
evtchn-do-not-set-pending-if-s3.patch | xen | does-not-apply |
| R | properly handles event channels on suspended VMs. Plus, evtchn_set_pending was removed in commit (443701ef0c7ff30872e27419cf4356fb6bdb4059) in favor of evtchn_port_set_pending R: We think it is needed but it also needs documentation about the fact that we don't know what it fixes. |
hvmloader-vga-command-io.patch | tools | applied | 2c4f5125fd5e343604a620bc621848c4bd1e6080 | D | covered by up-rev to 4.6 |
vbe-lfb-addr-matches-hvmloader.patch | tools | applies |
| D | R: Eric? E: VGABIOS is built in its own repo and this is already in its patch-queue (https://github.com/eric-ch/xenclient-oe/blob/master/recipes-openxt/vgabios/vgabios-0.7a/vbe-hvmloader-lfb-addr.patch). Need documentation though, see OXT-545. |
bios-uuid.patch | xen | tools | does-not-apply |
| D | adds functionality to set bios uuid (who uses this?) R: Grepping xenclient-oe.git reveals it is used in a couple of our xt patches and is in our XSM policy. xenclient-oe.git/recipes-extended/xen/files/gpt-iommu-mapping.patch We need it unless we manage to get rid of those patches. M: All of the related patches have been drop. A ticket will be submitted for the changes to the XSM policy components. |
bios-signature.patch | tools | does-not-apply |
| D | adds the ability to obtain BIOS signatures (functionality relocated from apci_utils.x to build.c) R: I guess that is reasonably useful but it won't work because we don't have the QEMU support (see qemu-acpi-tables.patch). We are also currently setting the BIOS signatures to XenClient Enterprise |
crash_flag_hypercall.patch | xen | does-not-apply |
| D | allows crash flag to be set R: This is an XCE thing, HVMOP_set_crash_flag is not referenced anywhere in OpenXT. Drop it. |
hvm-rtc.patch | xen | does-not-apply |
| R | E: For one, update the RTC when guest returns from PM state, that part should be important to keep RTC time consistent within guest. The second part about adjustment does not seem to bring much except sending QEMU the TIMEOFFSET IOREQ before updating the domain wallclock. There is a patch in QEMU to store diff for this guest in Xenstore to have it persistent accross reboots. Xen will be notified of this at QEMU's start through xc_domain_set_time_offset(). R: I think this patch is here because XCE used to use Xen to pause and resume guests and the clock would get scewed. I don't think this buys us anything because we do an actual guest S3 and wake. It needs more investigation though. It is possible we might see a need for it. |
large-remap.patch | xen | tools | does-not-apply |
| D | R: This is the XCE batch mapper. It can go but xc-xt-foreign-batch-cacheattr.patch will need to be rebased since bits of this patch appear in it. |
dom0_auto_mem.patch | xen |