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. M: OXT-577 - Getting issue details... STATUS
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: OXT-505 - Getting issue details... STATUS 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. M: OXT-578 - Getting issue details... STATUS
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 xenclient-oe.git/recipes-extended/xen/files/xc-xt-aperture-map.patch xenclient-oe.git/recipes-extended/xen/files/xc-xt-set-servicevm.patch xsm-policy.git/policy/flask/access_vectors:# XEN_DOMCTL_setbiosuuid 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. OXT-584 - Getting issue details... STATUS
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. M: OXT-585 - Getting issue details... STATUS
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	does-not-apply		D	E: was briefly mentioned in OXT-285. I do not think think is used or useful any more. R: Yea that is an XCE thing we never used, drop it.
rombios-faster.patch	tools	applies		D	removes floppy drive setup and other functionality E: OpenXT uses SeaBIOS built separately. This can be ignored.
include-seabios.patch	tools	applies		D	enables a seabios alternative E: SeaBIOS is built separately. This can be ignored.
xc-xt-hvm-get-time.patch	tools	does-not-apply		D	returns xen uptime R: This one seems to only be used by the (possibly non-functional) audio-daemon PV userland backend. Maybe we can find a way to do this without a patch? R: Posted to the mailing list. If we can remove the PV audio stuff, we can just check these patches in with the daemon and drop them here. See OXT-554
hvm-rtc-refresh-time.patch	xen	applies		K	refresh time before it is set but time is set prior to function being called (race condition fix?) E: refresh the current_tm each time rtc_set_time is called. I am not sure this is "still" required, current_tm is refreshed in the RTC IO port handler if the RTC is not in set mode and when disabling set mode. It could be a corner case though. R: If there is a corner case here we should investigate it further, perhaps we drop it in the end.
reboot-quirk-pci.patch	xen	applied	2bd6add4f5fa4ea2ba9297d6139e9dea42ea70a9	D	covered by up-rev to 4.6
xenstored-instrumentation.patch	tools	applies		D	limits xenstore trace statements. can this patch be ignored? E: Debug instrumentation, this can be ignored.
acpi-pm-feature.patch	tools	applies		K	R: This is a valid patch that supports our in guest ACPI features for batteries etc. It goes with bit in QEMU and xcpmd and I just recently fixed and refacgtored it.
xc-xt-hvm-info.patch	tools	applies		R	extends toolchain to display whether VT-x and VT-d are enabled E: This should be reworked and xc_physinfo() could be used directly by the toolstack (which I believe is the only piece using this?) M: OXT-586 - Getting issue details... STATUS
xc-xt-xenconsoled-syslog.patch	tools	does-not-apply		R	the changes to the create_domain_log, additions of safe_xs_read and name_from_dompath, add no additional functional with safe_xs_read tries=1 R: I think Eric was the original author of this though it had a lot of churn in our old PQ. Eric, what say you? E: I was? We probably want to keep the syslog part (so long we want the guest console in the logger). I think "renable_core_dumps()" does not work and should not be done here. M: OXT-587 - Getting issue details... STATUS
xc-xt-ept-respect-cacheattr-pin.patch	xen	applied	4d66f069d6abacd392f1301714fdfc64dc92917b	D	covered by up-rev to 4.6
xc-xt-interrupt-debug-info.patch	xen	applies		D	adds additional debug functionality. can this patch be ignored? E: Debug instrumentation, this can be ignored.
xc-xt-shadow-op-blow-tables.patch	xen \| tools	does-not-apply		D	R: I don't know what this is. I don't see any references to xc_shadow_blow_tables anywhere in OpenXT. No meaningful comments in commit messages. It can probably go. E: http://xen.markmail.org/thread/ahmyx2qath237hxd R: Nothing reverence xc_shadow_blow_tables anywhere so I think this can go.
xc-xt-vcpu-get-time.patch	xen	applies		D	is this functionality ever used? R: This is also a hypercall that is only used by the audio-daemon. See xc-xt-hvm-get-time.patch above. R: Posted to the mailing list. If we can remove the PV audio stuff, we can just check these patches in with the daemon and drop them here. See OXT-554
xc-xt-tboot-shutdown-disable-irqs.patch	xen	applies		K	R: This one is mine. Disabling irqs too early causes an assert in debug builds. I believe this is valid and should be upstreamed too.
xc-xt-txt-shutdown-acpi-access-width.patch	xen	applies		R	R: I tracked down the original commit for this and it is ugly. Seems it is for busted firmware on a Dell 980. I put the original commit message in the Notes section below if we decide to keep this. I am leaning towards not keeping it. R: We agreed this is a keeper because Dell 980's are still used. It needs to be renamed (with 980 i the name) and a comment added concerning the original issue documented below. M: Renamed to "xc-xt-Dell-980-txt-shutdown-acpi-access-width.patch" R: We can probably drop all the xc-xt- prefixes too - they don't really make any sense now. M: I will do it when I am done. I created a JIRA ticket to remind myself. OXT-589 - Getting issue details... STATUS
xc-xt-parse-video-from-mbi.patch	xen	applies		K	passes framebuffer info over the multiboot structure (why?) E: Get the MBI video info from the bootloader to Xen which will then pass it to dom0. R: I remember this one and we need it so early boot graphics are happy.
xc-xt-cpuid.patch	xen \| tools	does-not-apply		R	R: This is actually two CPUID related patches mashed into one. The part about the XciVMMXciVMM signature was used by our old custom Linux PV drivers to get them to load instead of std pvops ones. This part can go away. The other part came from a patch called "hvm-cpuid-multicore" with an initial commit message: "Import hvm-cpuid-multicore patch from xenserver's patch queue." and text from patch: "Expose vcpus as multiple cores in a smaller number of sockets, by adjusting the cpuid responses appropriately." R: Eric remembered this was to allow us to make Windows think that VCPUs were cores not CPUs so we could overcome CPU count limits and licensing issues in Windows. I believe the addition op XEN_DOMCTL_setcorespersocket is what configures Xen to deal with the differences between cores and CPUs. I think we should keep this stuff. M: Why is this marked as "R"? R: I believe we decided to keep it but some parts of it (related to the XciVMMXciVMM business) are not needed and should be removed. It is a patch with multiple earlier patches mashed in. M: OXT-590 - Getting issue details... STATUS
xc-xt-isa-irq-guest-binding.patch	xen	does-not-apply		D	R: This one is a mystery - it is related to passing through a device with an ISA IRQ. I can't remember anything like that. Also 1/3 of the patch got lost when it was ported to the current patch queue (an important 1/3).
xc-xt-set-servicevm.patch	xen \| tools	does-not-apply		D	adds service domain object to hypervisor\|toolchain and XSM structures R: Figured out where this came from. At some point XT had a requirement to allow service VMs to be able to access other guest's memory for VM introspection extension packs from 3rd parties. These operations are normally only something dom0 can do but this patch allows those operations in service VMs. This sounds dangerous to me TBH.
xc-xt-aperture-map.patch	xen \| tools	does-not-apply		D	E: Formerly used with the XenGFX device, now defunct. Removal tracked under OXT-509.
xc-xt-xen-translate.patch	xen \| tools	does-not-apply		R	translate guest psuedo-physical frame numbers (gpfn) to machine frame numbers (mfn) and XSM controls over the action (why?) E: This is done so Surfman can manage framebuffer's mfn directly, as it used to registered those directly to the IGD using former IGFX plugin. This can probably be changed with some refactoring so surfman would use pfns directly considering the gem_foreign object behaviour. M: OXT-591 - Getting issue details... STATUS
xc-xt-local-pxe-rom.patch	tools	applies		K	enables PXE booting (upstreamable?) and is this all that is needed? E: Pass the IPXE ROM, that is built out of Xen tree, path to the build system so it can be embedded in hvmloader.
xc-xt-v4v.patch	xen	does-not-apply		K	adds v4v functionality R: We want to keep this
xc-xt-v4v-viptables.patch	xen	does-not-apply		K	adds v4v iptables-like functionality R: We want to keep this
xc-xt-unmap-shared-info.patch	xen	does-not-apply		U	R: Eric and I agree this is legit. The original commit message talks about how this fixes guest S4 problems. Pasted commit message here. M: OXT-593 - Getting issue details... STATUS
xc-xt-foreign-batch-cacheattr.patch	tools	does-not-apply		K	R: This is for batch mapping and setting cache attrs during the map op. This is used by several things including xenfb2. It is a keeper. Note it will need to be rebased when we remove large-remap.patch.
xc-xt-allow-pat-cacheattrs-for-all-domains.patch	xen	does-not-apply		R	R: Tracked this one down, commit message: "framebuffer driver in uivm in XT relies on being able to set caching attributes on pages, through PAT. But, the disallow mask for pv domains does not allow them unless the PV domain is using passthrough devices. Just allow them for all pv domains as well. We had existing patch for this in XT, but it was uglier as it manipulated the check call sites instead of disallow mask, as well as it had confusing name "hvm_get_mem_pinned_cacheattr_always" So it seems to be needed ATM. Eric, thoughts? E: Altough I am not entirely clear why, this is required. Trying without it will crash the platform quickly. I would have thought this was allowing xenfb2 in UIVM to change the cache-attributes of the framebuffer region. It needs more investigation. M: OXT-594 - Getting issue details... STATUS
xc-xt-opt-disable-vmcs-shadowing.patch	xen	applies		R	R: Dug back in history on this one. This patch was introduced to turn of VMCS shadowing which was causing problems with nested virt. when we were trying to get Br's product to work on XenClient XT. Not sure what to do with it; Jed thinks we should drop it. R: Needs more investigation; would not be needed where HW support for nested virt. was present. M: OXT-595 - Getting issue details... STATUS
xc-xt-xenstore-use-pthread-always.patch	tools	does-not-apply		D	forces pthread to be used all the time (comment claims that libxenstore does not work without it) E: I misread this one. We used to have stub-domain programs linked statically. This became a problem with libxenstore as some program would assume to have libpthread linked (-DUSE_THREAD defined when libxenstore was built). This "hack" is no longer required anyway and Linux stub-domains no longer enforce static-linking.
xc-xt-hvmloader-legacy-seabios-optionroms.patch	tools	does-not-apply		R	E: Same as IPXE, pass the path where SeaBIOS is built to Xen's build system. M: In Xen 4.6.1 seabios-dir is only built if SEABIOS_PATH is not specified. I believe the first hunk of this patch can be removed. OXT-596 - Getting issue details... STATUS
xc-xt-hvmloader-move-reservation-area.patch	tools	applies		D	R: Looking at the history, it looks like we are just moving the top of hvmloader's reserved areas out of where we map the frame buffer. I say keep it. Eric, what do you think? E: AFAICR this was used with gpt-superblanker to have those 16M of memory in the guest's e820 (for the superblanker). It is defunct.
xc-xt-tools-v3-mapspace-workaround.patch	xen	does-not-apply		D	R: I remember this, it is a nasty one to deal with a problem in earlier versions of Windows tools that had the XENMAPSPACE_* values wrong. It is fixed in our current tools. This would only effect upgrades from XenClient XT 3.x to OpenXT and I don't even know if that is possible. R: I checked and the upgrade path for existing customers involved removing old tools. So it should be fine to drop this hideous thing.
gpt-iommu-mapping.patch	xen \| tools	does-not-apply		D	E: Defunct IGFX (and AMDplugin?) PVM logic. Add hypercalls to tweak IOMMU entries to redirect device DMA accesses to pages used by the guest (map_batch would have gfn→mfn, x_mapping would take gfns1 and gfns2, translate gfns2→mfns2 and do map_batch for gfns1→mfns2).
gpt-superblanker.patch	tools	applies		D	E: Defunct IGFX/PVM. Reserve a 16M region in the e820 for the "superblanker". This was still conditioned to doing IGD pass-through, which the toolstack does not allow.
gpt-nvidia.patch	tools	applies		D	E: quirk to load stdvga VGABIOS when passing through an NVIDIA card... Not sure why.
gpt-quiet-log.patch	xen	does-not-apply		D	can this patch be ignored? E: I think it should, this log can be of use.
gpt-igd-hp-resume-workaround.patch	xen	applies		D	specific to HP computers. can this patch be ignored? R: IGFX code, not needed.
gpt-s3-resume-reason.patch	xen	applies		R	E: This does not seem pass-through related. Sets WAK_STS (although macro names it RSM_STS) and PWRBTN_STS in PM1a register. I do not think this is used, PM1 is currently emulated in QEMU and those bits will be set according to the logic implemented there. I can confirmed the QEMU emulation is called and PM1a R/W trap in QEMU. So HVM will get this register from QEMU. I think this should go. hvm-pm-s-state introduced an HVMOP to use that register, but I do not see much checking for those bits in Xen. So without the HVMOP, it's pretty much defunct. R: Yea this is all coming back to me now. Xen intercepts IO to some of the register banks (PM1a STS and TMR) and others are mapped into QEMU (PM1a CNT and GPE0). I am going to mark this as refactor. I will work on fixing all this up and making sure everything matches between Xen, hvmloader and QEMU. Maybe we should start making tickets. M: OXT-598 - Getting issue details... STATUS
flask-bool-utility-fix.patch	tools	applied	2e43e19fb3ca68b1a2a320d339a53c2007909f9b	D	covered by up-rev to 4.6
flask-persist-booleans.patch	tools	applies		D	R: This is built into a utility called flask-set-bool. I do not see this used anywhere in the project. Jed searched an entire build tree and it is not referenced anywhere. Also the path is references does not exist ("/config/xsm/boolean/"). Drop it.
cpufreq_gov_stop_avoid_panic.patch	xen	applies		K	R: I think this one looks legit and maybe should be upstreamed too. The original commit comment: "Avoid panic in cpufreq_gov_stop Looks like cpufreq_gov_stop is called without having a start first so this patch will check if the givernor has been enabled before disabling it." R: Put a note in the patch comment that this may be able to be upstreamed. Machon will investigate further.
fix-memcpy-in-x86-emulate.patch	xen	applies		K	R: I think this one looks legit and maybe should be upstreamed too. See the original commit comment here. R: Put a note in the patch comment that this may be able to be upstreamed. Machon will investigate further, may be fixed upstream already.
stubdomain-msi-irq-access.patch	xen	does-not-apply		K	E: Allow QEMU running in a stubdom to do xc_physdev_map_pirq_msi(). PCI pass-through, with QEMU in a stub-domain, will surface the passed-through device in the stub-domain for config. space access. So QEMU will trap config. space access to set up MSI, and needs to xc_physdev_map_pirq_msi().
workaround-nehalem-igd-vtd.patch	xen	applies		K	see patch comments R: Keep it, it was accepted into OpenXT as a valid workaround.
xen-x86-Fix-up-rules-when-forcing-mno-sse.patch	xen	applies		K	R: I think that is perfectly valid, keep it.
xsa-125-long-latency-MMIO-mapping-operations-are-not-preemptible.patch	xen \| tools	applied	master:b10bca0483a1fa74de99807b89b13b27064794e1	D	covered by up-rev to 4.6
xsa-127-certain-domctl-operations-may-be-abused-to-lock-up-the-host.patch	xen	applied	master:83d1be544cbcd81720d2617f94976e851ce780dc	D	covered by up-rev to 4.6
xsa-132-information-leak-through-XEN_DOMCTL_gettscinfo.patch	xen	applied	master:a92efb747bbf256c20278517dfc179ced84bb869	D	covered by up-rev to 4.6
xsa-134-GNTTABOP_swap_grant_ref-operation-misbehavior.patch	xen	applied	master:5d5c09d853d3f212861f70c577c65d1703f752ae	D	covered by up-rev to 4.6
xsa-136-vulnerability-in-the-iret-hypercall-handler.patch	xen	applied	master:2ba368d13893402b2f1fb3c283ddcc714659dd9b	D	covered by up-rev to 4.6
xsa-137-xl-command-line-config-handling-stack-overflow.patch	tools	applied	master:dd84604f35bd3855c57146eb8fe53924c10d3963	D	covered by up-rev to 4.6
xsa-142-libxl-fails-to-honour-readonly-flag-on-disks-with-qemu-xen.patch	tools	applied	master:9204673fc60f606ec2b280a377e69d7fceedf5d6	D	covered by up-rev to 4.6
xsa-148-uncontrolled-creation-of-large-page-mappings-by-PV-guests.patch	xen	applied	master:fe360c90ea13f309ef78810f1a2b92f2ae3b30b8	D	covered by up-rev to 4.6
xsa-149-leak-of-main-per-domain-vcpu-pointer-array.patch	xen	applied	master:d46896ebbb23f3a9fef2eb6066ae614fd1acfd96	D	covered by up-rev to 4.6
xsa-150-long-latency-populate-on-demand-operation-is-not-preemptible.patch	xen	applied	master:101ce53266866144e724ed593173bc4098b300b9	D	covered by up-rev to 4.6
xsa-151-leak-of-per-domain-profiling-related-vcpu-pointer-array.patch	xen	applied	master:6e97c4b37386c2d09e09e9b5d5d232e37728b960	D	covered by up-rev to 4.6
xsa-152-some-pmu-and-profiling-hypercalls-log-without-rate-limiting.patch	xen	applied	master:95e7415843b94c346e5ba8682665f508f220e04b	D	covered by up-rev to 4.6
xsa-153-populate-on-demand-balloon-size-inaccuracy-can-crash-guests.patch	tools	applied	master:e294a0c3af9f4443dc692b180fb1771b1cb075e8	D	covered by up-rev to 4.6
xsa-156-cpu-lockup-during-exception-delivery.patch	xen	applied	master:bd2239d9fa975a1ee5bcd27c218ae042cd0a57bc	D	covered by up-rev to 4.6
xsa-155-paravirtualized-drivers-incautious-about-shared-memory-contents.patch	tools	does-not-apply	master:7d66a4ba695ab8d13b214fb816dd59e443ae1ec9 master:19f6c522a6a9599317ee1d8c4a155d1400d04c89 master:3f20b8def0f4c0d912f1ffc1893199b6e8820477	K	needs to be ported
xsa-159-XENMEM_exchange-error-handling-issues.patch	xen	applied	master:eedecb3cf0b2ce1ffc2eb08f3c73f88d42c382c9	D	covered by up-rev to 4.6
xsa-160-libxl-leak-of-pv-kernel-and-initrd-on-error.patch	tools	applied	master:f02ad357247901ad83e3910f3dadd70e231f3f3d	D	covered by up-rev to 4.6
xsa-165-information-leak-in-legacy-x86-FPU-XMM-initialization.patch	xen	applied	master:75904ac35f589b420d6d30415a64888b121d6484	D	covered by up-rev to 4.6
xsa-166-ioreq-handling-possibly-susceptible-to-multiple-read-issue.patch	xen	applied	master:b452430a4cdfc801fa4bc391aed7522365e1deb6	D	covered by up-rev to 4.6
xsa-167-pv-superpage-functionality-missing-sanity-checks.patch	xen	applied	master:b701ccc8ab35ff63bc4d613ec3c7bafec15aa0ee	D	covered by up-rev to 4.6
xsa-168-intercept-issue-with-invlpg-on-non-canonical-address.patch	xen	applied	master:828e114f7cdd9910483783ab0563b178325e579a	D	covered by up-rev to 4.6
xsa-169-unintentional-logging-upon-guest-changing-callback-method.patch	xen	applied	master:18eed42622b698e99f2950c293ae969ccaffe9ef	D	covered by up-rev to 4.6
xsa-170-guest-user-mode-may-crash-guest-with-non-canonical-rip.patch	xen	does-not-apply	master:ffbbfda37782a2408953af1a3e00ada80bb141bc	K	needs to be ported
xsa-173-x86-shadow-pagetables-address-width-overflow.patch	xen	does-not-apply	master:8b17648339ba801c4c7937b5f13dd25068e54e60	K	needs to be ported
xen-fix-xsave.patch	xen	applied	master:e8121c54ec8cc6a92ae2d7219e7a7fede6dfd137	D	covered by up-rev to 4.6

Notes

Notes to big to fit in the table...

Note xc-xt-txt-shutdown-acpi-access-width

This is the text from the original commit. I still think this is hacky but it is what Intel told us to do. This info should go in the patch header if we decide to keep it:

Fix Dell 980 platform shutdown with TXT
    
    From Joe:
    
    {quote}
    OK, I've found the problem.
    
    The PM1a_CNT block on the Dell looks like:
    [0ACh 0172  12]           PM1A Control Block : <Generic Address Structure>
    [0ACh 0172   1]                     Space ID : 01 (SystemIO)
    [0ADh 0173   1]                    Bit Width : 10
    [0AEh 0174   1]                   Bit Offset : 00
    [0AFh 0175   1]         Encoded Access Width : 01 (Byte Access:8)
    [0B0h 0176   8]                      Address : 0000000000000804
    
    The access width is 1 (byte).  However, doing a single byte out causes the hang.  So Dell's ACPI table is incorrect.
    
    The reason this works for Xen w/o tboot is that Xen ignores the access width and always does a 16 bit outw--which works.  But according to one of our ACPI maintainers, the code really should respect the access width value.
    
    If I run Linux w/ tboot it appears that Linux is changing the access width value to 0 and that defaults to 16 bits--which works.
    
    At any rate, the following change to Xen fixes this and is essentially what Xen is doing internally:
    static void tboot_sleep(u8 sleep_state)
    {
        uint32_t shutdown_type;
    
        tbg.space_id = g.space_id;          \
        tbg.bit_width = g.bit_width;        \
        tbg.bit_offset = g.bit_offset;      \
        tbg.access_width = g.access_width;  \
        tbg.address = g.address;
    
        /* sizes are not same (due to packing) so copy each one */
        TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1a_cnt_blk,
                    acpi_sinfo.pm1a_cnt_blk);
        g_tboot_shared->acpi_sinfo.pm1a_cnt_blk.access_width = 2;   <-------------- add this line...
        TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1b_cnt_blk,
                    acpi_sinfo.pm1b_cnt_blk);
        g_tboot_shared->acpi_sinfo.pm1b_cnt_blk.access_width = 2;   <-------------- and this line
        TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1a_evt_blk,
                    acpi_sinfo.pm1a_evt_blk);
        TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1b_evt_blk,
                    acpi_sinfo.pm1b_evt_blk);
    {quote}

Note prune-vga-acpi-dev

This has been in Xen for ages. It looks like a "fix" to deal with some issues on XP and server 2003. I think we should keep this since the ASL that is removed doesn't look right and doesn't follow the spec. The commit message:

commit 16d3c5de3c50b79296c288df876bec8b26d17d37
Author: Keir Fraser <keir.fraser@citrix.com>
Date:   Mon Dec 28 09:38:34 2009 +0000

    hvmloader: Fix Windows XP standby with cirrus VGA
    
    Fix it by telling OSPM don't power down vga card on entering S3
    state. The trick works for XP and Windows2003, but Vista still refuse
    to allow S3.
    
    It is picked from kvm-userdapce.git commit 60e85d, author "Gleb
    Natapov".
    
    Signed-off-by: Yu Ke <ke.yu@intel.com>

Note fix-memcpy-in-x86-emulate

This is the commit message for this patch.

    Make sure writebacks to guest memory are properly atomic
    
    When running x86_emulate, the code that writes the results back to guest
    memory must ensure that the proper atomicity guaranteed by the instructions
    being emulated is maintained. memcpy provides for atomic quadword writes
    but writes the last 1-7 bytes using single byte operations (rep movsb) so
    32- and 16- bit updates are not done atomically.
    
    This change uses specific atomnic operations if the size is 4 or 2 bytes.

Note xc-xt-unmap-shared-info.patch

    XENMAPSPACE_shared_info can also unmmap the shinfo page
    
    When hibernating/resuming from disk HVM linux guests, there is the
    situation where the booting domU linux kernel requests via a hypercall
    its shared info page mapping but the just resumed from hibernation  kernel
    has no idea what that page was and it may inadvertently use the old shared info
    mapping - thinking it is a free page (when in fact is not).
    
    Therefore before freezing, the booting kernel has to restore(undo) its
    shared info mapping so the hypercall involving XENMAPSPACE_shared_info
    has now the ability to undo the operation if the xatp.gpfn field is
    passed the "magic" value INVALID_MFN.

Development and Coding