Add Linux 4.19 support and change the default preference to 4.19 by rneilturner · Pull Request #1094 · OpenXT/xenclient-oe

rneilturner · 2019-02-27T14:48:12Z

See OXT-1497 https://openxt.atlassian.net/browse/OXT-1497

Signed-off-by: Richard Turner turnerr@ainfosec.com

jean-edouard · 2019-02-27T20:19:33Z

Built here: http://openxt-builder.ainfosec.com:8010/builders/openxt/builds/1873

crogers1 · 2019-02-27T21:18:46Z

Tested build on Dell 9010, Legacy boot. Installed HVM windows guest w/stubdom, rebooted guest 15-20 times, no problems. Networking is up and connected, UIVM is up. No segfaults in the logs.

+1

rneilturner · 2019-02-28T13:51:54Z

There was one change with 4.19 that may need to be addressed. During boot, the splash screen gets overwritten by the Dom0 display logging. This seems to be new behavior between 4.14 and 4.19. There are linux command line arguments that could be supplied to reduce this output considerably, notably reducing the loglevel down to say 2 (critical logs only) and supplying the quiet option. Another option is introducing a graphical boot process such as Plymouth or psplash.

jandryuk · 2019-02-28T14:30:18Z

Hi, @rneilturner, thanks for working on this.

This patchset is quite large - 31000+ lines changed. Were there any particular patches requiring significant or notable changes?

Finally, there was some discussion about dropping patches. Would you please list the dropped patches in the commit message.

I see you bumped the stubdom memory. Did you observe a specific issue requiring that? That change may be better split out into its own commit with an explanation.

rneilturner · 2019-02-28T15:08:34Z

@jandryuk I uploaded the patch diff from 4.14 to 4.19 to the OXT ticket. Some of the bigger changes are:

0001-x86-xen-don-t-write-ptes-directly-in-32-bit-PV-guest.patch and 0002-x86-pae-use-64-bit-atomic-xchg-function-in-native_pt.patch is no longer needed.
blktap patch needed refactoring for its queue flag clear
gem foreign patch needed changes to i915_gem_foreign_get_pages. Function definition change and needed to set its pages.
Netfront support backend relocate patch needed changes for the netback changed event.
thorough-reset-interface-to-pciback-s-sysfs.patch pci_try_reset_slot function changed to pci_reset_bus, which takes into account both the bus and slot.
usbback-base.patch needed refactoring of its io timer.
xen-txt-add-xen-txt-eventlog-module.patch tpm_is_tpm2 function argument change.

Other changes were very minor and were attributed to slight changes in API.

I decided not to drop any patches with this PR. I figured we can have a separate discussion on this. Candidates for removal include acpi-video-delay-init.patch and intel-amt-support.patch.

This kernel increased the size requirement for our stubdom's, slightly bigger kernel overall even after trimming as much as I could. Without this change I was getting OOM when booting guests.

jandryuk

My comments mainly come from the diff posted in Jira.

jandryuk · 2019-02-28T17:25:24Z

recipes-kernel/linux/4.19/linux-openxt_4.19.20.bb

+
+FILESEXTRAPATHS_prepend := "${THISDIR}/patches:${THISDIR}/defconfigs:"
+SRC_URI += "${KERNELORG_MIRROR}/linux/kernel/v${PV_MAJOR}.x/linux-${PV}.tar.xz;name=kernel \
+    file://bridge-carrier-follow-prio0.patch;patch=1 \


All these patch=1 flags can be dropped since bitbake treats .patch files as patches by default.

Agreed, fix coming.

jandryuk · 2019-02-28T17:26:05Z

recipes-kernel/linux/4.19/patches/netfront-support-backend-relocate.patch

+ 	case XenbusStateUnknown:
+		/* if the backend vanishes from xenstore, close frontend */
+		if (!xenbus_exists(XBT_NIL, dev->otherend, "") &&
+		  (dev->state != XenbusStateUnknown)) {


Indenting here is messed up.

Agreed, fix coming.

jandryuk · 2019-02-28T17:26:10Z

recipes-kernel/linux/4.19/patches/netfront-support-backend-relocate.patch

+-		if (dev->state != XenbusStateInitialising)
+		/* allow reconnect if our state is either initialising, or closed */
+		if (dev->state != XenbusStateInitialising &&
+		  dev->state != XenbusStateClosed)


Indenting here is messed up.

Agreed, fix coming.

jandryuk · 2019-02-28T17:26:47Z

recipes-kernel/linux/4.19/patches/skb-forward-copy-bridge-param.patch

+ int br_dev_queue_push_xmit(struct net *net, struct sock *sk, struct sk_buff *skb)
+ {
+ 	skb_push(skb, ETH_HLEN);
+	struct sk_buff *new_skb;


This declaration should be added before skb_push

Agreed, fix coming.

jandryuk · 2019-02-28T17:40:26Z

recipes-kernel/linux/4.19/patches/blktap2.patch

+
+out:
+
+	BTDBG("returning %d\n", (


Re-exporting elevator_init is easiest for now, but is probably wrong long term. The linux block subsystem will be multiqueue-only, and blk_init_queue will be going away in addition to elevator_init. I don't know what it would take to convert multiqueue, but I imagine that will need to be done.

Agreed it will have to be done. I took a few hours last week and determined its probably going to take a week of dev/test work on the blktap driver to get it working with multi queue. This would be a good follow-on task once we rebase and accept the upstream blktap implementation.

rneilturner · 2019-02-28T21:06:50Z

PR has been updated with corrections on linux-openxt_4.19.20.bb, netfront-support-backend-relocated.patch, and skb-forward-copy-bridge-param.patch.

jandryuk · 2019-03-01T12:54:18Z

recipes-kernel/linux/4.19/patches/netfront-support-backend-relocate.patch

+ 	case XenbusStateUnknown:
+		/* if the backend vanishes from xenstore, close frontend */
+		if (!xenbus_exists(XBT_NIL, dev->otherend, "") &&
+		   (dev->state != XenbusStateUnknown)) {


This line should still be indented 1 more space - "(" aligned under "!".

Thanks, @rneilturner

Lindent didn't pick up on this but I will update regardless.

Patch has been updated

jandryuk

Thanks, @rneilturner

eric-ch

LGTM.

jean-edouard

All LGTM, except for that slot reset thing.

jean-edouard · 2019-03-01T19:43:13Z

recipes-kernel/linux/4.19/patches/thorough-reset-interface-to-pciback-s-sysfs.patch

+		return pci_reset_function(dev);
+	}
+
+	//Next, we'll try the next gentlest: a hotplugging reset


This "gentlest" solution is the exact same as the "most drastic" one below.
pci_reset_bus() seems to now try a slot reset first, so I get where you coming from, but those 2 ifs should probably be merged and the comments and debug messages fixed up...

With pci_reset_bus() determines if slot reset is possible using pci_probe_reset_slot(), which is what device_supports_slot_reset(), introduced by this patch does. It seems this can just become:

if (allow_bus_reset) return pci_reset_bus(dev);

... With the helpers device_supports_slot_reset() and device_supports_bus_reset() no longer being necessary.

update coming soon. +1

jean-edouard · 2019-03-01T19:49:02Z

Built here: http://openxt-builder.ainfosec.com:8010/builders/openxt/builds/1876

Signed-off-by: Richard Turner <turnerr@ainfosec.com>

jean-edouard · 2019-03-04T18:54:52Z

Built here: http://openxt-builder.ainfosec.com:8010/builders/openxt/builds/1881

jean-edouard · 2019-03-05T14:28:39Z

Built here: http://openxt-builder.ainfosec.com:8010/builders/openxt/builds/1883

jean-edouard · 2019-03-05T14:42:51Z

I tested the latest build and found some issues:

The kernel logs to the screen at boot time, breaking the splash screen
This SELinux AVC prevents booting:

[   15.769963] audit: type=1400 audit(1551796299.940:4): avc:  denied  { read write } for  pid=875 comm="xenstored" name="hypercall" dev="devtmpfs" ino=10059 scontext=system_u:system_r:xenstored_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0

In permissive, it boots fine, but I also got the following AVC:

[   42.466378] audit: type=1400 audit(1551796689.280:31): avc:  denied  { read write } for  pid=1014 comm="surfman" path="/dev/xen/hypercall" dev="devtmpfs" ino=10059 scontext=system_u:system_r:surfman_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1

rneilturner · 2019-03-05T14:47:15Z

I noted the kernel logs taking over the boot screen in my comments above. I also offered some suggestions to resolve the issue but haven't seen any comments back.

I have not seen the SELinux issue you are seeing @jean-edouard, although my build tree is two weeks out of date with commits. Are you sure this problem is related to 4.19? Either way, I will update my build tree and take a look.

jean-edouard · 2019-03-05T14:50:38Z

Sorry, I missed your comment about the on-screen logs. Reducing the verbosity is not an option, since we need the logs on serial and in /var/log/messages.
I'll look into that issue.
I also did make sure the AVCs only happened with 4.19.

jean-edouard · 2019-03-05T14:54:06Z

~~Also for some reason, logging into dom0 (with serial / ssh / newrole) now gives these AVCs:~~

[  748.473286] audit: type=1400 audit(1551797395.290:38): avc:  denied  { read } for  pid=4295 comm="sshd" name="config" dev="dm-3" ino=108122 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
[  748.479305] audit: type=1400 audit(1551797395.290:39): avc:  denied  { open } for  pid=4295 comm="sshd" path="/etc/selinux/config" dev="dm-3" ino=108122 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
[  748.485587] audit: type=1400 audit(1551797395.290:40): avc:  denied  { getattr } for  pid=4295 comm="sshd" path="/etc/selinux/config" dev="dm-3" ino=108122 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1

jandryuk · 2019-03-05T15:03:48Z

I think the console output is coming from
arch/x86/xen/enlighten_pv.c around line 1388:
add_preferred_console("tty", 0, NULL);
Hopefully there is a command line option to turn it off.

@jean-edouard how did you get unlabeled files?

jean-edouard · 2019-03-05T15:05:51Z

Oh, that's probably from editing that file outside of OpenXT to be able to boot... Please disregard.

rneilturner · 2019-03-05T15:11:25Z

My tree is before Xen 4.11 and TBOOT 1.9.9 was merged. I will test my changes before and after these features were merged.

jean-edouard · 2019-03-05T15:41:33Z

Randomly tried adding video.is_vga=0 to the Linux cmdline, which surprisingly mostly did the trick, except that it also stopped logging to the serial console...

rneilturner · 2019-03-05T16:00:29Z

Seems Fedora 29 running kernel 4.18 with Xen 4.11 ran into the same SELinux problems. https://bugzilla.redhat.com/show_bug.cgi?id=1679293

jandryuk · 2019-03-05T16:43:27Z

For the AVCs, we probably just need this added to dev-xen-privcmd.patch:
/dev/xen/hypercall -c gen_context(system_u:object_r:xen_device_t,s0)

rneilturner · 2019-03-05T16:51:27Z

Thanks @jandryuk I will give that a go.

rneilturner · 2019-03-05T19:22:38Z

@jandryuk that resolved the avc denial issue. I have added a commit to this PR with the changes.

Resolves avc denial audit: type=1400 audit(1551796299.940:4): avc: denied { read write } for pid=875 comm=xenstored name=hypercall dev=devtmpfs ino=10059 scontext=system_u:system_r:xenstored_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0 Signed-off-by: Richard Turner <turnerr@ainfosec.com>

jandryuk · 2019-03-05T20:14:39Z

LGTM

jean-edouard · 2019-03-05T23:14:30Z

Built here: http://openxt-builder.ainfosec.com:8010/builders/openxt/builds/1887

jean-edouard · 2019-03-05T23:25:57Z

One more AVC, XSM this time... Sorry I didn't catch that that earlier.

(XEN) avc:  denied  { resource_map } for domid=4 target=3 scontext=system_u:system_r:stubdom_t tcontext=system_u:system_r:hvm_guest_t tclass=domain2

Edit: actually, the build also includes the rebased blktap3, not sure which PR causes the AVC...
Edit2: either way, fixed here: OpenXT/xsm-policy#22

rneilturner · 2019-03-06T14:07:03Z

@jean-edouard I looked at this last night and also fixed it here: rneilturner/xsm-policy@206ff18

Either implementation works for me. Thanks for looking at this also.

jandryuk · 2019-03-06T15:56:03Z

I would go with @rneilturner 's change, but insert the new line after domain:

 allow stubdom_t $1:domain { getdomaininfo set_target shutdown settime };
+allow stubdom_t $1:domain2 resource_map;

rneilturner · 2019-03-06T15:59:29Z

PR posted for the xsm-policy change: OpenXT/xsm-policy#23

jean-edouard · 2019-03-06T21:58:47Z

Built here: http://openxt-builder.ainfosec.com:8010/builders/openxt/builds/1890

Everything works fine now, except the boot time console spam and the audio passthrough (tested on Dells E7470 and E7480).

Here are the passthrough logs:

Mar  6 22:58:34.642126 kernel:[  119.628816] BUG: unable to handle kernel paging request at efeef000
Mar  6 22:58:34.642140 kernel:[  119.630804] *pdpt = 00000000154d2027 *pde = 0000000000000000 
Mar  6 22:58:34.642141 kernel:[  119.632707] Oops: 0002 [#1] SMP
Mar  6 22:58:34.642142 kernel:[  119.634581] CPU: 0 PID: 1056 Comm: xenmgr Tainted: G           O      4.19.20 #1
Mar  6 22:58:34.642143 kernel:[  119.636402] Hardware name: Dell Inc. Latitude E7470/0T6HHJ, BIOS 1.17.5 07/11/2017
Mar  6 22:58:34.642144 kernel:[  119.638222] EIP: memset+0xb/0x20
Mar  6 22:58:34.642144 kernel:[  119.640055] Code: f9 01 72 0b 8a 0e 88 0f 8d b4 26 00 00 00 00 8b 45 f0 83 c4 04 5b 5e 5f 5d c3 90 8d 74 26 00 55 89 e5 57 89 c7 53 89 c3 89 d0 <f3> aa 89 d8 5b 5f 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 55
Mar  6 22:58:34.642145 kernel:[  119.642002] EAX: 00000000 EBX: efeef000 ECX: 00010000 EDX: 00000000
Mar  6 22:58:34.642146 kernel:[  119.643874] ESI: 0002feef EDI: efeef000 EBP: d5d1dca4 ESP: d5d1dc9c
Mar  6 22:58:34.642147 kernel:[  119.645783] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 EFLAGS: 00010296
Mar  6 22:58:34.642147 kernel:[  119.647662] CR0: 80050033 CR2: efeef000 CR3: 154e4000 CR4: 00042660
Mar  6 22:58:34.642148 kernel:[  119.649550] Call Trace:
Mar  6 22:58:34.642149 kernel:[  119.651448]  xen_destroy_contiguous_region+0x31/0x120
Mar  6 22:58:34.642150 kernel:[  119.653336]  xen_swiotlb_free_coherent+0xb9/0x230
Mar  6 22:58:34.642150 kernel:[  119.655279]  ? xen_swiotlb_unmap_page+0x20/0x20
Mar  6 22:58:34.642151 kernel:[  119.657166]  snd_dma_free_pages+0x12d/0x150 [snd_pcm]
Mar  6 22:58:34.642152 kernel:[  119.659052]  snd_free_sgbuf_pages+0x9d/0xf0 [snd_pcm]
Mar  6 22:58:34.642152 kernel:[  119.660981]  snd_dma_free_pages+0x45/0x150 [snd_pcm]
Mar  6 22:58:34.642153 kernel:[  119.662860]  ? ___cache_free+0xdb/0x170
Mar  6 22:58:34.642154 kernel:[  119.664760]  snd_pcm_lib_preallocate_free+0x18/0x60 [snd_pcm]
Mar  6 22:58:34.642155 kernel:[  119.666699]  snd_pcm_lib_preallocate_free_for_all+0x1f/0x50 [snd_pcm]
Mar  6 22:58:34.642156 kernel:[  119.668585]  snd_pcm_free+0x20/0x50 [snd_pcm]
Mar  6 22:58:34.642156 kernel:[  119.670458]  snd_pcm_dev_free+0xb/0x10 [snd_pcm]
Mar  6 22:58:34.642157 kernel:[  119.672385]  __snd_device_free+0x33/0x80
Mar  6 22:58:34.642157 kernel:[  119.674219]  snd_device_free_all+0x39/0x70
Mar  6 22:58:34.642158 kernel:[  119.676116]  release_card_device+0x14/0x70
Mar  6 22:58:34.642159 kernel:[  119.677928]  device_release+0x26/0x80
Mar  6 22:58:34.642159 kernel:[  119.679751]  kobject_put+0x84/0x1d0
Mar  6 22:58:34.642160 kernel:[  119.681643]  put_device+0xf/0x20
Mar  6 22:58:34.642161 kernel:[  119.683456]  snd_card_free+0x50/0x80
Mar  6 22:58:34.642162 kernel:[  119.685278]  azx_remove+0x3c/0x50 [snd_hda_intel]
Mar  6 22:58:34.642162 kernel:[  119.687159]  pci_device_remove+0x2d/0xa0
Mar  6 22:58:34.642163 kernel:[  119.688998]  device_release_driver_internal+0x174/0x230
Mar  6 22:58:34.642164 kernel:[  119.690852]  device_release_driver+0xc/0x10
Mar  6 22:58:34.642164 kernel:[  119.692776]  unbind_store+0x6a/0x140
Mar  6 22:58:34.642165 kernel:[  119.694653]  ? bind_store+0x150/0x150
Mar  6 22:58:34.642166 kernel:[  119.696531]  drv_attr_store+0x18/0x30
Mar  6 22:58:34.642166 kernel:[  119.698483]  ? drv_attr_show+0x30/0x30
Mar  6 22:58:34.642167 kernel:[  119.700348]  sysfs_kf_write+0x30/0x50
Mar  6 22:58:34.642172 kernel:[  119.702219]  ? sysfs_kf_bin_read+0xc0/0xc0
Mar  6 22:58:34.642178 kernel:[  119.704172]  kernfs_fop_write+0xe1/0x170
Mar  6 22:58:34.642179 kernel:[  119.706069]  ? kernfs_vma_page_mkwrite+0x70/0x70
Mar  6 22:58:34.642179 kernel:[  119.708024]  __vfs_write+0x2e/0x180
Mar  6 22:58:34.642180 kernel:[  119.709940]  ? security_file_permission+0x2c/0xb0
Mar  6 22:58:34.642181 kernel:[  119.711865]  ? rw_verify_area+0x5c/0x110
Mar  6 22:58:34.642181 kernel:[  119.713873]  vfs_write+0x8f/0x170
Mar  6 22:58:34.642182 kernel:[  119.715800]  ksys_write+0x44/0xa0
Mar  6 22:58:34.642183 kernel:[  119.717784]  sys_write+0x11/0x20
Mar  6 22:58:34.642184 kernel:[  119.719696]  do_fast_syscall_32+0x88/0x200
Mar  6 22:58:34.642185 kernel:[  119.721639]  entry_SYSENTER_32+0x6b/0xbe
Mar  6 22:58:34.642186 kernel:[  119.723671] EIP: 0xb7f99d19
Mar  6 22:58:34.642186 kernel:[  119.725636] Code: 08 8b 80 64 cd ff ff 85 d2 74 02 89 02 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
Mar  6 22:58:34.642187 kernel:[  119.727832] EAX: ffffffda EBX: 0000000b ECX: b4ba3db0 EDX: 0000000c
Mar  6 22:58:34.642188 kernel:[  119.729969] ESI: b6ba6d99 EDI: b6ba6da4 EBP: b498de80 ESP: b6afd274
Mar  6 22:58:34.642189 kernel:[  119.732164] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000282
Mar  6 22:58:34.642190 kernel:[  119.734341] Modules linked in: vfat fat sha256_generic xts algif_skcipher af_alg snd_hda_codec_hdmi txt fbtap(O) hid_multitouch hid snd_hda_codec_realtek snd_hda_codec_generic xen_netfront v4v(O) dell_smm_hwmon hwmon i915 dell_laptop dell_wmi dell_smbios sparse_keymap crc32c_intel dell_wmi_descriptor e1000e aesni_intel drm_kms_helper dcdbas snd_hda_intel syscopyarea crypto_simd snd_hda_codec sysfillrect cryptd ptp sysimgblt snd_hda_core fb_sys_fops snd_pcm psmouse tpm_tis drm pps_core snd_timer xhci_pci tpm_tis_core xhci_hcd i2c_algo_bit tpm wmi dell_rbtn rfkill
Mar  6 22:58:34.642190 kernel:[  119.741455] CR2: 00000000efeef000
Mar  6 22:58:34.642191 kernel:[  119.743796] ---[ end trace 4953acf46de185be ]---
Mar  6 22:58:34.642192 kernel:[  119.746188] EIP: memset+0xb/0x20
Mar  6 22:58:34.642192 kernel:[  119.748588] Code: f9 01 72 0b 8a 0e 88 0f 8d b4 26 00 00 00 00 8b 45 f0 83 c4 04 5b 5e 5f 5d c3 90 8d 74 26 00 55 89 e5 57 89 c7 53 89 c3 89 d0 <f3> aa 89 d8 5b 5f 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 55
Mar  6 22:58:34.642193 kernel:[  119.751066] EAX: 00000000 EBX: efeef000 ECX: 00010000 EDX: 00000000
Mar  6 22:58:34.642194 kernel:[  119.753409] ESI: 0002feef EDI: efeef000 EBP: d5d1dca4 ESP: c19faebc
Mar  6 22:58:34.642195 kernel:[  119.755713] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 EFLAGS: 00010296
Mar  6 22:58:34.642195 kernel:[  119.757982] CR0: 80050033 CR2: efeef000 CR3: 154e4000 CR4: 00042660

rneilturner · 2019-03-07T02:32:39Z

@jean-edouard I will take a look tomorrow at the problem you are seeing with the passthrough on the onboard audio device using the E7470. I will scrounge up an E7470 if I can to test it out.

rneilturner · 2019-03-07T02:33:51Z

Maybe related to this fix.....torvalds/linux@7250f42#diff-bbe12856743579912d20395c8ce87558

rneilturner · 2019-03-07T13:31:04Z

I was able to recreate the issue with a Dell 7040. Passthrough of an integrated audio device is not something we test here very often. Passthrough of an add-on GPU and NIC worked fine.

stacktrust · 2019-03-07T15:59:04Z

Some GPUs have an audio device which must also be passed through for the GPU to work.

rneilturner · 2019-03-07T16:06:26Z

@stacktrust this is not the case for the above problem. This is a problem with an integrated audio device not attached to any GPU. I was able to passthrough the audio device on a GPU.

rneilturner · 2019-03-07T23:57:31Z

Status Update: We have been testing 4.19 with a variety of GPU's today and found with certain GPU's, the audio device is not getting assigned to pciback. It so happens the first two GPU's we tested worked just fine. We can force this assignment with the audio device to occur but it causes more issues with pcifront when we do this. Comments or suggestions in this investigation is highly encouraged! We will continue going forward in our investigation and will post any updates as they come in.

rneilturner · 2019-03-08T17:53:16Z

We have narrowed down the issue to the unbinding of the snd-hda-intel driver. This doesn't seem to be an issue with x64 OpenXT running Linux 4.19. There has been a significant amount of churn on the Intel audio driver in 4.17 and 4.19. The investigation continues.

rneilturner · 2019-03-15T01:29:06Z

Verified running Ubuntu 16.04 32-bit with Linux 5.0 with vanilla Xen causes the exact kernel crash we are seeing when unbinding the intel audio driver. If you don't run Ubuntu with Xen the problem does NOT occur.

rneilturner · 2019-03-15T01:41:52Z

Also verified the problem was introduced in Linux Kernel 4.17.

rneilturner · 2019-03-22T14:24:09Z

This PR now depends on the 64-bit PR by @crogers1 : #1101

Signed-off-by: Richard Turner <turnerr@ainfosec.com>

jean-edouard · 2019-03-25T14:24:58Z

Built here: http://openxt-builder.ainfosec.com:8010/builders/openxt64/builds/6461

jean-edouard · 2019-03-25T17:15:27Z

Merging soon.

jandryuk · 2019-03-25T17:35:26Z

recipes-kernel/linux/4.19/defconfigs/xenclient-uivm/defconfig

 # CONFIG_ATARI_PARTITION is not set
 # CONFIG_MAC_PARTITION is not set
+CONFIG_MSDOS_PARTITION=y
 # CONFIG_MSDOS_PARTITION is not set


This looks weird. Looks like 4.14 has CONFIG_MSDOS_PARTITION=y, so do we want to drop # CONFIG_MSDOS_PARTITION is not set

I'm good with dropping it. @jean-edouard if you approve I can have an update to this PR with the change.

Sorry, just saw that, please submit a separate PR for this, as I'm about to merge. Thanks

Ok. Merge away.

rneilturner force-pushed the uprev-4.19 branch 2 times, most recently from 0fc3f9b to 671922f Compare February 27, 2019 15:13

jandryuk reviewed Feb 28, 2019

View reviewed changes

rneilturner force-pushed the uprev-4.19 branch from 671922f to 52ccbf9 Compare February 28, 2019 19:57

jandryuk reviewed Mar 1, 2019

View reviewed changes

rneilturner force-pushed the uprev-4.19 branch from 52ccbf9 to 8f4e785 Compare March 1, 2019 13:48

jandryuk approved these changes Mar 1, 2019

View reviewed changes

eric-ch approved these changes Mar 1, 2019

View reviewed changes

jean-edouard reviewed Mar 1, 2019

View reviewed changes

rneilturner force-pushed the uprev-4.19 branch from 8f4e785 to d9e10c7 Compare March 1, 2019 20:23

Add Linux 4.19 support and change the default preference to 4.19

d9e10c7

Signed-off-by: Richard Turner <turnerr@ainfosec.com>

Update 4.19 Kernel for OpenXT to 64-bit

02f176c

Signed-off-by: Richard Turner <turnerr@ainfosec.com>

jandryuk reviewed Mar 25, 2019

View reviewed changes

stacktrust mentioned this pull request Mar 25, 2019

x86_64: Support 64-bit on OpenXT #1101

Merged

jean-edouard merged commit a33f2c3 into OpenXT:master Mar 25, 2019

Conversation

rneilturner commented Feb 27, 2019

Uh oh!

jean-edouard commented Feb 27, 2019

Uh oh!

crogers1 commented Feb 27, 2019

Uh oh!

rneilturner commented Feb 28, 2019

Uh oh!

jandryuk commented Feb 28, 2019

Uh oh!

rneilturner commented Feb 28, 2019

Uh oh!

jandryuk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rneilturner commented Feb 28, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jandryuk left a comment

Choose a reason for hiding this comment

Uh oh!

eric-ch left a comment

Choose a reason for hiding this comment

Uh oh!

jean-edouard left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jean-edouard commented Mar 1, 2019

Uh oh!

jean-edouard commented Mar 4, 2019

Uh oh!

jean-edouard commented Mar 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jean-edouard commented Mar 5, 2019

Uh oh!

rneilturner commented Mar 5, 2019

Uh oh!

jean-edouard commented Mar 5, 2019

Uh oh!

jean-edouard commented Mar 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jandryuk commented Mar 5, 2019

Uh oh!

jean-edouard commented Mar 5, 2019

Uh oh!

rneilturner commented Mar 5, 2019

jean-edouard commented Mar 5, 2019 •

edited

Loading

jean-edouard commented Mar 5, 2019 •

edited

Loading

jean-edouard commented Mar 5, 2019 •

edited

Loading

jean-edouard commented Mar 6, 2019 •

edited

Loading

rneilturner commented Mar 15, 2019 •

edited

Loading